Closed wwjnufc closed 1 month ago
Hi @wwjnufc , First of all thank you for this very well described issue :)
I ran your values on my side only using :
customSchemaFiles:
00-argon2-setup.ldif: |-
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: /opt/bitnami/openldap/lib/openldap/argon2.so
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcPasswordHash
olcPasswordHash: {ARGON2}
And after openldap-0
startup I ran
I have no name!@openldap-0:/$ ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -LLL -Q '(objectClass=olcModuleList)'
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /opt/bitnami/openldap/libexec/openldap
olcModuleLoad: {0}pw-sha2.so
olcModuleLoad: {1}/opt/bitnami/openldap/lib/openldap/argon2.so
dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /opt/bitnami/openldap/lib/openldap
olcModuleLoad: {0}syncprov.so
So it seems to work.
One thing I noticed in your log is the line
openldap-stack-ha 03:49:59.08 INFO ==> Using persisted data
indicating that it's not the first start of the pod.
Make sure you install the chart in a clean namespace or remove all pvc
related to openldap
.
Especially when you debug customSchemaFiles
as files will only be applied the first time.
Hi @jp-gouin thanks for your prompt feedback!
I retested by doing a helm delete, kubectl pv & pvc delete to clean everything and indeed it is showing up now.
<<K9s-Shell>> Pod: dit/openldap-0 | Container: openldap-stack-ha
I have no name!@openldap-0:/$ ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -LLL -Q '(objectClass=olcModuleList)'
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}syncprov
olcModuleLoad: {1}/opt/bitnami/openldap/lib/openldap/argon2.so
olcModuleLoad: {2}/opt/bitnami/openldap/lib/openldap/ppolicy.so
That means, from what I understand on customSchemaFiles, it
If point #2 is the case, then what is the suggestion to add more modules to openldap during startup on an already running cluster? I have a requirement to add new modules to an existing OpenLDAP cluster but I am hoping perform it with a less destructive method to avoid downtime (e.g take backup, delete the pvc then reload from backup).
Glad to hear.
You are right, customSchemaFiles
is only applied during the first startup of openldap
This is a limitation of the container not the chart.
To add module during the first startup, then you should use customSchemaFiles
and add all your module in there.
Any other time (e.g after first startup) , you have to connect into one openldap
pod and run ldapadd -Y EXTERNAL -H ldapi:/// ... your_module.ldif
Assuming you have replication, it'll be replicated to all other nodes
Ok, understand now. Thought there would be a more programmatic method to load the modules post first startup.
I shall explore other methods (e.g. post startup cron) to try and achieve something similar.
Thanks!
You might want to take a look at https://github.com/bitnami/containers/issues/44545 as someone already tried to build something to fix that limitation
Reference: https://github.com/bitnami/containers/issues/69669
Describe the bug customSchemaFiles not loading module during startup
Logs
Name and Version
bitnami/openldap:2.6.3
What architecture are you using?
amd64
What steps will reproduce the bug?
In value file, add the following block
ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -LLL -Q '(objectClass=olcModuleList)' olcModuleLoad
it doesn't appear as module loaded.ldapmodify -Y EXTERNAL -H ldapi:/// -f /opt/bitnami/openldap/etc/schema/00-argon2-setup.ldif
What is the expected behavior?
The ldif defined in customSchemaFiles should be executed during OpenLDAP startup
What do you see instead?
The ldif is doesn't appear to be triggered at all
Additional information
dit root(k8s: minikube) $ minikube version minikube version: v1.32.0 commit: 8220a6eb95f0a4d75f7f2d7b14cef975f050512d
dit root(k8s: minikube) $ docker --version Docker version 24.0.7, build 24.0.7-0ubuntu2~20.04.1
dit root(k8s: minikube) $ helm version version.BuildInfo{Version:"v3.15.2", GitCommit:"1a500d5625419a524fdae4b33de351cc4f58ec35", GitTreeState:"clean", GoVersion:"go1.22.4"}