dokuwiki: Run container as 33:33

[penguineer]

It would be nice if the Dokuwiki container were run as www-data (UID:GID 33:33) instead of root.

Best practices aside, running the container as root triggers an chown call on the data directory by the container's entrypoint script, which can be a lengthy procedure. For my wiki it is so long that the readiness probe times out and kills the container long before it is done.

The Dokuwiki behavior makes sense. If the user does not select the correct user for the container, they may also not have done that for the data directory. For a K8S workload this behavior is sub-optimal. Every time the pod is re-located, my Wiki is gone for 5 minutes.

I would like to propose that the correct user is set in the chart, maybe even using a variable, and administrators are advised to set the correct permissions in the data directory (chown -R 33:33 in the end).

My current setting is:

securityContext:
  runAsUser: 33
  runAsGroup: 33

Coding this as a variable, such as dokuwiki.runAsUser would regain some flexibility on the configuration side, but then again, this sanitizing step would be a one-time fix anyways. Any subsequent run only takes time.

[ChaosKid42]

Thanks. I'll look into into on the weekend. I run the container as www-data myself so it would be nice to have that as the default. I'll have to figure out how to make it run without any manual intervention of the admin. Furthermore I will have to see that the automatic tests continue to work.

[ChaosKid42]

fixed by 4ce37c9

[penguineer]

Thank you for taking care of this so fast!

[unmacaque]

Hi,

after 4ce37c9 deploying a fresh instance of dokuwiki with no prior deployments or volume claims now leads to startup failure and the following log message.

+ set -e
++ id -u
++ id -g
+ echo 'Started under UID 33 GID 33.'
Started under UID 33 GID 33.
+ '[' 33 -eq 0 ']'
+ /dokuwiki-storagesetup.sh
+ set -e
+ mkdir -p /storage/data
mkdir: cannot create directory '/storage/data': Permission denied

The documentation states that I should "make sure the pv is writeable by uid/gid 33 (www-data)". How do I even do that if the chart does not do it by itself?

[penguineer]

I don't think the chart can change access to the PV directory, as this is determined by the provisioner.

I am using nfs-subdir-external-provisioner, which creates directories with 777 in provisioner.go#L115 (not ideal and there is a PR to improve this).

Which Provisioner are you using?

I also explicitly create the PVC and provide it to the helm chart via persistence.existingClaim.

[ChaosKid42]

I think I will add the option to add an init container to the pod so that you can use e.g. a busybox container to execute chmod on the volume.

[penguineer]

In the running dokuwiki pod:

www-data@dokuwiki-6696b8964c-dr8d4:/storage$ chown 33:33 .
chown: changing ownership of '.': Operation not permitted

Which makes sense, as this would mean changing the ownership of the directory in the CSI/host system. Same way I cannot change rights on any contained directories if I don't have access rights to the parent directory.

When running as root, it is root making this change, which would be allowed (and this is why running containers as root is bad). Now IMHO this must be solved on the PV side.

[ChaosKid42]

@unmacaque e737257 should do the trick.

[unmacaque]

That did the trick indeed. Thanks a lot!