Run Zulip with securityContext as UID 1000

[WillNilges]

Hello, I am trying to run zulip on k3s using the helm chart. It works fine with my setup as long as I don't apply a securityContext to make it run as user 1000.

  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000

When I do that, I get the following error:

/home/zulip/deployments/current/scripts/zulip-puppet-apply must be run as root.

I did a bit of searching, but all I found was this issue, which wasn't really relevant.

Wondering if there could be a way to run the zulip container in day-to-day operations as a non-root user? Looking at the entrypoint.sh Perhaps a new entrypoint command could be introduced that skips some of the initialization steps on a server that has already been created, or if that's not possible, perhaps one could create a Containerfile that performs these initialization steps and stores them as layers? I admit I know nothing about how Zulip actually works, so what I am describing might be impossible.

Another acceptable solution might be to use a rootless k3s setup.

Appreciate any advice or solutions here. My friend group is evaluating self-hosting Zulip as an alternative to discord, and so far first impressions have been very good.

[alexmv]

This is in the realm of possibility, but not straightforward. The configuration here comes from the non-Docker tooling, so very much assumes it runs as root to be able to configure the entire host. We re-run it on every startup, to make sure the files on disk line up with the configuration as specified. There are certainly ways of doing that that wouldn't require root, but that would be a whole parallel configuration path, which would be brittle.

I suspect it would be possible to run puppet as zulip as long as it was limited to only examining/changing files owned by zulip (probably by limiting resources using a puppet tag). I also suspect that supervisor could be made to run as zulip as well, with some finagling. Cron could be replaced with, e.g. https://github.com/aptible/supercronic. There are some other small corner cases (e.g. not being able to use low-numbered ports) but I suspect that would get most of the way.