thanks for the reply.
On 22.03.22 at 23:22 William Brown wrote:
> On 22 Mar 2022, at 19:22, Johannes Kastl
> 1. 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
> 2. 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/
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.
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
> 3. 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
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.
Linux Consultant & Trainer
Tel.: +49 (0) 151 2372 5802
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg
GF: Ralph Dehner
Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537