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@xxxxxxxxxxxxx> wrote:
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 helm chart.
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/total 0 lrwxrwxrwx 1 root root 14 Mar 23 03:32 tls.crt -> ..data/tls.crtlrwxrwxrwx 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"
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 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 -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@xxxxxxxxxxxxx B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
