-
-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
postgres running as root on kubernetes/helm #470
Comments
tsearch-extras is no longer required; we support vanilla postres, with dictionary files (so https://zulip.readthedocs.io/en/latest/production/postgresql.html#cloud-provider-managed-postgresql-e-g-amazon-rds applies). |
@timabbott Thanks, but I'm still a bit confused. How can that work with kubernetes? The pod will crash with Why does |
I tripped over this today too. I fought with it for a while, it's quite a mess. Eventually I found that setting the helm value Looking at the history of this, #462 updated the postgresql chart version from 11.1.22 to 15.5.32, and a comment says it was tested. But it clearly didn't work here on a new installation. Maybe root access is only needed for the first-time initialization scripts? |
Good to hear that it's possible to run, but I'm too cautious to just ignore The problem is less the chart, and more the image, I believe. Edit:
Maybe just a permission issue. |
Looks like postgres itself still runs as the postgres user; it's only the container entrypoint (and my % kubectl -n zulip exec pod/zulip-postgresql-0 -- ps -a
PID USER TIME COMMAND
1 postgres 0:04 postgres
102 postgres 0:00 postgres: checkpointer
103 postgres 0:00 postgres: background writer
104 postgres 0:01 postgres: walwriter
105 postgres 0:00 postgres: autovacuum launcher
[snip]
68763 root 0:00 ps -a That looks quite normal to me.
Well, I think that's because you commented it out; better to set it to 0 (root's uid). It has a value that way, so it won't get overridden. And you'll also need to change several other problematic flags, such as This is why setting
That happened because |
Agreed - That seems to be fairly normal, but it still shouldn't be necessary.
totally missed that. Seems like the bitnami image offloads even Setting it up like this got it working for me:
|
Seems like there's quite a mismatch between the bitnami chart and this non-bitnami postgresql image. We both had to dive deep into the details to find a way to make it work at all... |
@mikkeschiren do you have a recommendation for how to resolve this? |
In the setup I have worked on, I did this as an override: postgresql:
primary:
containerSecurityContext:
readOnlyRootFilesystem: false
runAsUser: 1001 And that has worked fine for us. But this need proper handling and investigation. I will get back to it. |
Following the guide at https://github.com/zulip/docker-zulip/blob/main/kubernetes/chart/zulip/README.md, you have to run postgresql as root/
runAsUser: 0
which will fail on default policies. (as seen in #421 (comment))Is it really necessary to run it as root? Does pgroonga require this?
Is it possible to use vanilla postgres as a drop in replacement at the cost of full text search quality?Edit:
Looks like
tsearch-extras
#92 is needed at the very least.The text was updated successfully, but these errors were encountered: