Hi William,
thanks for the reply.
On 22.03.22 at 23:22 William Brown wrote:
On 22 Mar 2022, at 19:22, Johannes Kastl kastl@b1-systems.de wrote:
- Does the docker container have any kind of bootstrapping mechanism included, i.e. I put some LDIF files somewhere and those get imported automatically? Or is the idea to just setup a working server, that the user can then put things into. And that state is being preserved in /data/? I guess it is the latter.
At the moment we can't import an ldif like this. There are lots of issues with state management in this kind of setup, that LDAP is not well suited to cope with.
No problem, then I know that I do not need to build anything like that into the helm chart.
- The choice of certificate/key naming is unfortunate, as Kubernetes secrets automatically contain a tls.key and tls.crt file. I can easily inject such a secret, but as 389ds is expecting server.key and server.crt, I guess those files would just be ignored. Right?
Could this maybe be enhanced (not changed, to keep backwards compatibility)? That would make life in Kubernetes land easier.
It's annoying that kubernetes is so inflexible in how it emits the certs like this. Can you explain more about how it puts them into the volume or similar? That way we can work out what the right answer is.
Here is an example from another pod, where the Kubernetes secret is mounted into the pod into /certificate:
~ $ ls -lh /certificate/ total 0 lrwxrwxrwx 1 root root 14 Mar 23 03:32 tls.crt -> ..data/tls.crt lrwxrwxrwx 1 root root 14 Mar 23 03:32 tls.key -> ..data/tls.key ~ $
As you can see, there are two "files", that are being generated from the two key-values-pairs inside the secret. Those are actually linked into that directory.
But the default names are tls.crt and tls.key.
I will try to do subpath mounting, i.e. I will specify where each of the keys is "mounted" to, aka which file name it gets. But AFAIK this has some drawbacks, but currently it seems like the only option.
Alternative approach: I would need to have a look if I can somehow use a different "CMD" in Kubernetes, I am thinking of a small script that just copies tls.key and tls.crt from $LOCATION to /data/... somehwere, where 389ds expects them. And then runs "/usr/lib/dirsrv/dscontainer -r"
- The Dockerhub page say "Instances now support running dirsrv as non-root...". However I could not get it to run without root permissions. That might have been due to the "wrong" user I picked. So, before spending more time on debugging this, is this still supported? Which user/group should I pick to do that?
Any! What version of the container are you running? You'll need the upstream version which has the correct nsswitch components in place.
I tried running without root permissions, but immediately got CrashLoopBackOff errors in Kubernetes. But if you say it should work then I will dig deeper into that and try to get it working. I am using the latest image from dockerhub, tag 2.0.
Kind Regards, Johannes