d88d3b07a5
Merge pull request 'Encrypt PostgreSQL data directory' (#166) from feature/pg_encfs into master
Cool. I like that one, too. Both short, and also is the name of a rocket, launching things into space. :)
... I had to fork the postgresql cookbook in order to add the possibility to correctly use custom data dirs on Debian-based systems👍
I have added the site cookbook as a git submodule. So when you pull the branch, just do a git submodule update --init.
All solved! I have everything running correctly now, with the cluster created in the encrypted data dir, and the services started by path units.
@greg I'm not experienced with writing Chef resources, but I think a resource in the encfs cookbook would make most sense, so that you simply describe that you want to wait for the encrypted dir to start a certain systemd service in the recipe of the respective service.
That is, for Postgres e.g., we'd only do something along the lines of:
create_encfs_path_activation_unit_for 'postgresql@12-main'
I have added a template for this to the encfs site cookbook, which looks like this:
[Unit]
Description=Start <%= @service_unit %> when encrypted data directory is mounted
[Path]
PathExists=/tmp/data-dir-mounted.txt
Unit=<%= @service_unit %>
[Install]
WantedBy=multi-user.target
I keep running into issues with the code here. There's actually no cluster created with the correct datadir, but all the files are created in the default directory. So starting the process later fails with it complaining that the datadir is not a valid cluster directory. However, trying pg_createcluster then correctly fails, stating that the cluster config already exists.
... adding a postgres system user to the default recipe fixes the problem. However, when trying to unlock encfs, it does not accept the password from the data bag:
mount_encfs[2065]: Error decoding volume key, password incorrect
I think this code is probably too prone to errors:
command <<-EOF
echo "y\\\n
y\\\n
p\\\n
#{encfs_password}\\\n
#{encfs_password}\\\n
"
I just tried this branch by adding the recipes for a postgres master and encfs to the Vagrant config's runlist. However, Chef runs fail, claiming there's no postgres user:
cannot determine user id for 'postgres', does the user exist on this system?
I cannot find this user being created in a site-cookbook, but it is the default user for the postgres cookbook's user resource.
BTW, I just noticed that encfs and gitea are the only two cookbooks using an underscore as space, while all the others use a hyphen.
I think it would be interesting to try path-based activation of units. This would basically map 1:1 to the human understanding of "start the postgres service as soon as path /mnt/data/postgres" becomes available.
I think using a service unit for encfs may not be the right approach for this. It is not a running service, like e.g. postgres, but only mounts a directory once.
Btw, here are the names of the nearest galaxies starting with the letter D:
- Donatiello
- Draco (Draco Dwarf + Draco II)
- Dwingeloo (1 + 2)
@greg Any preference?
I carefully read the text again, and if we want to keep the IPs, then they have to put the new machine in the same place as the old one. This means that Centaurus would be in a different DC (DC 11 vs 13).
I also asked around and @maxsan told me that when you change a Lightning Network node's external IP in the config, it would actually be communicated to other nodes and picked up by the network. So it looks like we could change the IP after all.
Considering these facts, I would propose to ditch the old IP eventually and move everything over to the new IP bit by bit, after the new server has been provisioned.
@greg WDYT?