[bitnami/postgresql-repmgr] Cannot specify a custom pg_hba.conf #1048
Comments
Scharfenberg
changed the title
|
Some code digging improved my understanding... The password authentication error is a follow-up error after a first docker run failed. This is what I've noticed with Approach 3 and the same is true for Approach 1 (it's harder to observe with docker swarm as the container is started over and over again so it's easy to miss the first underlying error). The underlying error is the same in all approach, but it's much easier to see with docker-compose as the failing containers are not started over and over again: I have no idea what the reason for this issue could be. It could be that the custom pg_hba.conf blocks the database access. But as mentioned before it's a copy of the default pg_hba.conf as it is created by the container if I do not specify my own file. Also it allows access from all IPs to all databases with all users, using md5. |
|
Changing all pg_hba.conf entries to 'trust' will fix the database access issue. It will work then with approach 3 but with approach 1 I encounter a new issue. |
|
Hi, We've had some discussions about this. Currently, if you provide a pg_hba.conf, it will use it during the container initialization. However, for initializing the slaves, it needs some special pg_hba.conf permissions. When you add a custom pg_hba.conf, there could be some incompatibilities during that initialization time. Would it make sense to use the provided pg_hba.conf AFTER the initialization? One thing that you could try is to perform a first initialization of the cluster without providing a custom pg_hba.conf, and then, after having it initialized, restart all of the nodes but this time providing your configuration. Could that work? |
|
Before I answer your questions, @javsalgar, some more obervations:
|
|
Comming back to your questions, @javsalgar: |
|
Hi, Great, thank you very much for your input. I would like to bring this up to the rest of the team so we can use the custom configuration files only when running the initialization. I presume this would require some discussion and analysis so it will take a bit before implementing it. However, as soon as there are more news, I will update this ticket. |
|
I have had the same issues as @Scharfenberg when trying to add a custom pg_hba.conf file. I have used the two-step workaround that @javsalgar suggested, and it works for me, but only after I made some logic changes to the code. In rootfs/opt/bitnami/scripts/libpostgresql.sh, I re-structured the line 556
|
|
Hi, I checked the stack overflow case and I don't see the part where it says that the original |
|
In the first answer in the stack overflow case, you see: I know that before I made the modification, the function postgresql_create_pghba was called in all cases, completely messing up my custom file in the container. The file on my mounted volume was OK, but the file passed as a parameter to the postgresql process was incorrect. |
|
Hi, This is strange, I have not been able to reproduce it. What is more, further in the question it says: "So. bottom line: it appears that all sub-expressions are evaluated when using -a and -o with test or [." We are not using |
|
I have tried to reproduce my results with that change listed above, and it had no effect. I realize that I had made more than the above, so I think you're correct. I think the most significant thing for getting a custom pg_hba.conf to work with 'trusted' authentication is to set the variable REPMGR_PGHBA_TRUST_ALL. This stops the postgresql_restrict_pghba function from re-writing 'trust' to 'md5' in the running pg_hba.conf. BTW, I think the conditions for executing the call for postgresql_restrict_pghba in librepmgr.sh are too simple. They ignore the fact that it could be a custom pg_hba.conf. For example, the call could be: |
|
Hi, I think we should re-evaluate how we deal with custom files. I'm convinced that they should not be considered at initialization time but only at runtime. However that would be major change and will require discussion. |
|
Hi, I'm not sure if this is already being worked on but similar to those above, I'm having an issue where I can't specify a single entry to be trusted, such as the example below. As described above, all entries are changed to md5 (or trust if REPMGR_PGHBA_TRUST_ALL=yes is used) |
|
Hi, I'm afraid it is still in our backlog. As soon as we have more news, we will update the ticket. Stay tuned! |
|
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback. |
|
Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary. |
javsalgar
added
the
on-hold
|
We are going to transfer this issue to In order to unify the approaches followed in Bitnami containers and Bitnami charts, we are moving some issues in Please follow bitnami/containers to keep you updated about the latest bitnami images. More information here: https://blog.bitnami.com/2022/07/new-source-of-truth-bitnami-containers.html |
fmulero
changed the title
|
Unfortunately, this issue was created a year ago and although there is an internal task to fix it, it was not prioritized as something to address in the short/mid term. It's not a technical reason but something related to the capacity since we're a small team. Being said that, contributions via PRs are more than welcome in both repositories (containers and charts). Just in case you would like to contribute. During this year, there are several releases of this asset and it's possible the issue has gone as part of other changes. If that's not the case and you are still experiencing this issue, please feel free to reopen it and we will re-evaluate it. |
github-actions
bot
added
solved
and removed
on-hold
|
How about these change? 3cc1fc8 What it does is delaying custom Below |
Description
I'm trying to specify a custom pg_hba.conf file for my postresql-repmgr cluster consisting of two nodes in streaming replication setup.
Unfortunately I cannot use the bind mount approach from the README as I'm using docker swarm.
Therefore I've tried two other approaches -- both without success.
/bitnami/repmgr/conf/pg_hba.confusing the docker swarm config mechanism./bitnami/repmgr/confas a volume with the nfs driver.Approach 1
The excerpt from my compose file:
The resulting error message (from my log server):
Notes:
user: rootto my services to circumvent issues due to the non-root container I encounter the same password authentication issue as in approach 2.Approach 2
The excerpt from my compose file:
The resulting error message (from docker service logs):
Notes:
Approach 3
I've taken the example docker-compose.yml file and added this bind mount to both postgres services:
Of course I've also set the correct permissions on the host holder and its content.
As long as the folder is empty everything works fine. As soon as I add the pg_hba.conf the start of the primary container fails with error 2 on the first run:
On the second and each subsequent run (without deleting my volumes) I get this already known error:
General steps to reproduce the issues in approach 1 and 2
When modifying and testing my docker-compose.yml file I use these steps to have a clean setup each time:
docker stack rm postgresdocker volume pruneon all involved docker nodesdocker stack deploy --compose-file docker-compose.yml postgresThe full docker-compose.yml file used in approach 1 and 2
(currently approach 2 is active by outcommenting approach 1 elements):
Output of docker version
Output of docker info
The text was updated successfully, but these errors were encountered: