theforeman
Backup and restore container gateway postgres DB
Adds backup and restore support for the container gateway DB. Only adds support for the postgres version of the database for now.
One notable change was that the DB commands need to be run as foreman-proxy since no password is saved for the database. The container gateway uses unix socket auth for the connection, so only the owning user can access the DB (as far as I know).
As such, I've added support for running generic commands as a different user.
To test, try backup and restore on both a normal Foreman/Katello install and on a smart proxy with the container gateway installed.
ToDos:
- [x] Figure out why stderr is ending up in the container gateway database dump
- [x] Write tests
I looked into the issue where stderr makes it into the dump file. It seems that this was always the case since the final command looks like sudo -u foreman-proxy -- pg_dump -Fc database > dump_file 2>&1. That would redirect stderr into stdout, which is being redirected into dump_file.
I'm guessing this wasn't an issue before because pg_dump was always getting run as root. In my case, foreman-proxy had no permissions to change directories into the place where I started the command, which caused an error which then made it literally into the dump file.
I also ended up adding lines to change the backup ownership to foreman-proxy:foreman-proxy in order for the foreman-proxy user to have access. I noticed we deal with this issue slightly differently for restore -- there's a simple error telling the user to change the backup permissions. This is a bit different for backup though, because the user isn't the one creating the inner backup directory. I'm curious if anyone can see any issues coming out of this.
I originally thought this would be required for Katello 4.14 since I assume the change to postgres would introduce a regression in backup & restore. It looks like it does not, in fact it appears that offline backup is backing up the container gateway DB for free somehow. Once the installer is run, the container_gateway DB is correctly created. So, users restoring at least can still just do a smart proxy sync to restore their content.
As such, I don't think we need to rush this for the upcoming Foreman release in case there are other concerns with the implementation that pop up. I'm personally a bit busy with getting other things in shape for the release, but please let me know if anyone thinks there's a new regression that I'm missing.
It looks like it does not, in fact it appears that offline backup is backing up the container gateway DB for free somehow.
It will not anymore (since we merged https://github.com/theforeman/foreman_maintain/pull/893), so caution! :)
Since this has slipped a little on our team priorities, I'm going to call this a PoC and get things updated once the strategy is determined to be sound.
- This needs a rebase, as we re-did quite some parts of
base_database.rb, sorry. - Is my assumption correct, we do not support external DB for proxies at all right now?
* Is my assumption correct, we do not support external DB for proxies at all right now?
I'll preface this by saying I'm not sure if we support external DBs for proxies, but, if we do ...
We did not test external container gateway external DBs. If I remember correctly, we have all of the connection information ready to be modified to an external host, so it should work to be remote.
If my PR here does not respect external databases but should, I'll fix it.
@evgeni I've rebased this and changed the PR to use the postgres user for "local" database commands.
I need to get the tests passing again.
I've tested this on a container gateway enabled smart proxy with online backup & restore.
The latest code ensures all local DB connections use unix sockets with a simple connection string (like postgres:///foreman). It's been tested on a capsule and I'm currently testing on a satellite system (so far so good).
Edit: the satellite system test worked.