finally I had some time to try and get the 389ds server running in Kubernetes.
As I am also still learning Kubernetes (and will be for the next few years,
always something new to learn), I tried to get this into a helm chart. And: It
This means, I can create a Kubernetes secret containing the DS_DM_PASSWORD and
SUFFIX_NAME variables, and the pod running inside Kubernetes gets those values
injected from the secret.
I could connect to the server using the "cn=Directory Manager", i.e. I get an
"No such object" response but no longer a "ldap_bind: Invalid credentials (49)"
There are three questions that I could not answer myself:
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.
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.
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?
Thanks in advance, and have a nice day everyone!
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
Post a Comment