The Bitnami patch #66
Conversation
andyundso
force-pushed
the
fix-with-bitnami-image
branch
from
03f543d to
4d84608
Compare
| # Copy default configuration in case the original container does not provide it (Bitnami ...) | ||
| RUN mkdir -p /opt/pgautoupgrade && \ | ||
| chmod 660 /opt/pgautoupgrade && \ | ||
| chown 999:999 /opt/pgautoupgrade | ||
| COPY --chown=999 postgresql.conf pg_hba.conf /opt/pgautoupgrade/ |
There was a problem hiding this comment.
as an alternative to the copy process, we could also invoke pg_setup_hba_conf() in the entrypoint.sh to generate a valid pg_hba.conf. postgresql.conf I am not sure ...
|
Hi @justinclift, you mentioned you have quite a lot of work on your table. not sure if that is still the case, otherwise I would appreciate a review on this PR. |
There was a problem hiding this comment.
Nice PR 😄
This looks good to me on reviewing the code, but I'm not in a position to test currently! I can hopefully test in a few days to verify the upgrade works as intended.
But it's a small change & you have a test included, so I'm pretty confident this should be fine!
Unfortunately yeah. Life is quite challenging at the moment. 😦 In theory, I should start having a bit of free time next week though. Should be able to start |
|
Sorry for the lack of response. Should actually have time late next week, as I'm finishing up some unrelated stuff this week. |
From what I read at #21, it is currently not possible to use
pgautoupgradewhen using a Bitnami container before, as:postgresql.confandpg_hba.conffiles are missing.pgautoupgraderan.The first issue was trivial fix: Provide default files for this case in the container (sadly the Postgres installation does only contain incomplete sample files).
The second one was more difficult: The default entrypoint script downgrades itself from
rootto thepostgres. Part of it is a security concern, but alsopostgrescommands without password cannot be executed when running asrootuser.I did not want to mess with the
entrypointscript too much, so I instead opted to create a new entrypoint script, which keeps track of the two files mentioned earlier, as well as the existing permissions on the Postgres data directory. This script keeps its root permissions, so re-applying the permissions should be possible. Then it invokes the previous entrypoint script. Once the container terminates and "one shot" mode is enabled, the previous permissions are re-applied.I also added some additional documentation about this behaviour in the README, as well as an additional test that booting up an empty
pgautoupgradecontainer works, since starting an empty container takes quite a different path in the entrypoint script, and I wanted to make sure that this still works.