search

jp-gouin / helm-openldap

Helm chart of Openldap in High availability with multi-master replication and PhpLdapAdmin and Ltb-Passwd
Apache License 2.0
192 stars 116 forks source link

customSchemaFiles not loading module during startup #186

Closed wwjnufc closed 1 month ago

wwjnufc commented 1 month ago

Reference: https://github.com/bitnami/containers/issues/69669

Describe the bug customSchemaFiles not loading module during startup

Logs

init-tls-secret -----                                                                                                                                                                                                                    │
│ Stream closed EOF for dit/openldap-0 (init-tls-secret)                                                                                                                                                                                   │
│ openldap-stack-ha  03:49:58.38 INFO  ==> ** Starting LDAP setup **                                                                                                                                                                       │
│ openldap-stack-ha  03:49:58.69 INFO  ==> Validating settings in LDAP_* env vars                                                                                                                                                          │
│ openldap-stack-ha  03:49:58.88 INFO  ==> Initializing OpenLDAP...                                                                                                                                                                        │
│ openldap-stack-ha  03:49:58.88 DEBUG ==> Ensuring expected directories/files exist...                                                                                                                                                    │
│ openldap-stack-ha  03:49:59.08 INFO  ==> Using persisted data                                                                                                                                                                            │
│ openldap-stack-ha  03:49:59.18 INFO  ==> ** LDAP setup finished! **                                                                                                                                                                      │
│ openldap-stack-ha                                                                                                                                                                                                                        │
│ openldap-stack-ha  03:49:59.38 INFO  ==> ** Starting slapd **                                                                                                                                                                            │
│ openldap-stack-ha 66a079e7.17211c94 0x7f162e23d740 @(#) $OpenLDAP: slapd 2.6.3 (Jan 17 2023 16:44:38) $                                                                                                                                  │
│ openldap-stack-ha     @a34c3898a374:/bitnami/blacksmith-sandox/openldap-2.6.3/servers/slapd                                                                                                                                              │
│ openldap-stack-ha 66a079e7.22c15252 0x7f162e23d740 slapd starting                                                                                                                                                                        │
│ openldap-stack-ha 66a079e9.11f28293 0x7f162ca83700 conn=1000 fd=14 ACCEPT from IP=10.244.0.1:57204 (IP=0.0.0.0:1389)                                                                                                                     │
│ openldap-stack-ha 66a079e9.12012cc7 0x7f1627fff700 conn=1000 fd=14 closed (connection lost)                                                                                                                                              │
│ openldap-stack-ha 66a079fd.11d8e154 0x7f162ca83700 conn=1001 fd=14 ACCEPT from IP=10.244.0.1:50598 (IP=0.0.0.0:1389)                                                                                                                     │
│ openldap-stack-ha 66a079fd.11d9a42c 0x7f1627fff700 conn=1002 fd=16 ACCEPT from IP=10.244.0.1:50600 (IP=0.0.0.0:1389)                                                                                                                     │
│ openldap-stack-ha 66a079fd.11e03394 0x7f1626ffd700 conn=1001 fd=14 closed (connection lost)                                                                                                                                              │
│ openldap-stack-ha 66a079fd.11e1693a 0x7f1627fff700 conn=1002 fd=16 closed (connection lost)                                                                                                                                              │
│ openldap-stack-ha 66a07a07.11d27fcf 0x7f162ca83700 conn=1003 fd=14 ACCEPT from IP=10.244.0.1:55720 (IP=0.0.0.0:1389)                                                                                                                     │
│ openldap-stack-ha 66a07a07.11d3180e 0x7f16277fe700 conn=1004 fd=15 ACCEPT from IP=10.244.0.1:55718 (IP=0.0.0.0:1389)                                                                                                                     │
│ openldap-stack-ha 66a07a07.11d50574 0x7f1626ffd700 conn=1003 fd=14 closed (connection lost)                                                                                                                                              │
│ openldap-stack-ha 66a07a07.11d6700e 0x7f1626ffd700 conn=1004 fd=15 closed (connection lost)                                                                                                                                              │
│ openldap-stack-ha 66a07a11.11dcf363 0x7f162ca83700 conn=1005 fd=14 ACCEPT from IP=10.244.0.1:60384 (IP=0.0.0.0:1389)                                                                                                                     │
│ openldap-stack-ha 66a07a11.11dd5e9f 0x7f16277fe700 conn=1006 fd=16 ACCEPT from IP=10.244.0.1:60368 (IP=0.0.0.0:1389)                                                                                                                     │
│ openldap-stack-ha 66a07a11.11e1270f 0x7f1627fff700 conn=1005 fd=14 closed (connection lost)                                                                                                                                              │
│ openldap-stack-ha 66a07a11.11e3e094 0x7f1626ffd700 conn=1006 fd=16 closed (connection lost)                                                                                                                                              │
│ openldap-stack-ha 66a07a1b.11d97867 0x7f162ca83700 conn=1007 fd=14 ACCEPT from IP=10.244.0.1:35806 (IP=0.0.0.0:1389)                                                                                                                     │
│ openldap-stack-ha 66a07a1b.11db26fd 0x7f16277fe700 conn=1008 fd=15 ACCEPT from IP=10.244.0.1:35808 (IP=0.0.0.0:1389)                                                                                                                     │
│ openldap-stack-ha 66a07a1b.11dd6ead 0x7f1627fff700 conn=1007 fd=14 closed (connection lost)                                                                                                                                              │
│ openldap-stack-ha 66a07a1b.11e19946 0x7f1626ffd700 conn=1008 fd=15 closed (connection lost)                                                                                                                                              │
│ openldap-stack-ha 66a07a1c.10b6477b 0x7f162ca83700 conn=1009 fd=14 ACCEPT from PATH=/opt/bitnami/openldap/var/run/ldapi (PATH=/opt/bitnami/openldap/var/run/ldapi)                                                                       │
│ openldap-stack-ha 66a07a1c.10b88b82 0x7f16277fe700 conn=1009 op=0 BIND dn="" method=163                                                                                                                                                  │
│ openldap-stack-ha 66a07a1c.10ba3063 0x7f16277fe700 conn=1009 op=0 BIND authcid="gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth"                         │
│ openldap-stack-ha 66a07a1c.10bb1ae5 0x7f16277fe700 conn=1009 op=0 BIND dn="gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth" mech=EXTERNAL bind_ssf=0 ssf=71                                                                   │
│ openldap-stack-ha 66a07a1c.10bbc81d 0x7f16277fe700 conn=1009 op=0 RESULT tag=97 err=0 qtime=0.000028 etime=0.000292 text=                                                                                                                │
│ openldap-stack-ha 66a07a1c.10beee4c 0x7f1627fff700 conn=1009 op=1 SRCH base="cn=config" scope=2 deref=0 filter="(objectClass=olcModuleList)"                                                                                             │
│ openldap-stack-ha 66a07a1c.10bf8db3 0x7f1627fff700 conn=1009 op=1 SRCH attr=olcModuleLoad                                                                                                                                                ││ openldap-stack-ha 66a07a1c.10c10f47 0x7f1627fff700 conn=1009 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000018 etime=0.000239 nentries=1 text=                                                                                             │
│ openldap-stack-ha 66a07a1c.10c3c0f1 0x7f1626ffd700 conn=1009 op=2 UNBIND                                                                                                                                                                 │
│ openldap-stack-ha 66a07a1c.10c4795b 0x7f1626ffd700 conn=1009 fd=14 closed

Name and Version

bitnami/openldap:2.6.3

What architecture are you using?

amd64

What steps will reproduce the bug?

  1. In value file, add the following block

    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}
  2. Verified that ldif is created image
  3. However, when i run ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -LLL -Q '(objectClass=olcModuleList)' olcModuleLoad it doesn't appear as module loaded.
  4. Manually running the ldif will load the module ldapmodify -Y EXTERNAL -H ldapi:/// -f /opt/bitnami/openldap/etc/schema/00-argon2-setup.ldif image

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"}

jp-gouin commented 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.

wwjnufc commented 1 month ago

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

  1. will always create the ldif file
  2. will only ldapadd/modify it during startup of a clean install

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).

jp-gouin commented 1 month ago

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

wwjnufc commented 1 month ago

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!

jp-gouin commented 1 month ago

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