Verifying that the database is working as expected

[parak]

Hi,

I'm attempting to move some code from 2.x (which worked fine) to 4.x (to get multimaster replication), and I'm starting with a fresh deployment of 4.x (latest 4.1.1 specifically) for test purposes. Previously in 2.x could use tools like slapcat to readily verify basic contents of the database, but now in 4.x even it shows essentially nothing (with the updated syntax):

I have no name!@openldap-0:/bitnami/openldap$ slapcat -F /bitnami/openldap/slapd.d/
The first database does not allow slapcat; using the first available one (2)
I have no name!@openldap-0:/bitnami/openldap$

And the only database there is cn=config. To try and eliminate I've pared down the values used to bare minimums - the only ones present are for disabling phpldapadmin and ltb-passwd. I've had some ldif files under customLdifFiles, including one to create a top level org, but it also doesn't shows up in slapcat.

Logs don't seem to indicate anything unusual other than when I attempt to add a basic organization:

  customLdifFiles:
    00-organization.ldif: |
      dn: dc=someorg
      dc: someorg
      o: Someorg, Inc.
      objectclass: top
      objectclass: dcObject
      objectclass: organization

643517d9.01b8c20d 0x7fc6b27fc700 conn=1012 op=1 ADD dn="dc=someorg"
643517d9.01b9e809 0x7fc6b27fc700 conn=1012 op=1 RESULT tag=105 err=53 qtime=0.000022 etime=0.000111 text=no global superior knowledge
ldap_add: Server is unwilling to perform (53)
    additional info: no global superior knowledge

Any ideas on what I might be completely confused on/missing here? Thanks!

[jp-gouin]

Hi @parak , can you try with :

customLdifFiles:
  00-organization.ldif: |-
    dn: dc=someorg
    dc: someorg
    o: Someorg, Inc.
    objectclass: top
    objectclass: dcObject
    objectclass: organization

Don't remember to delete the namespace and volumes

[parak]

@jp-gouin No effect - same thing, unfortunately. Before the loading of custom ldifs there are a bunch of (preconfigured) ldap operations on olcDatabase={2}mdb,cn=config which are successful, but the loading of the org ldif fails in the same manner.

[jp-gouin]

Could you provide your full values ?

[parak]

Sure, here they are (I use it as a subchart):

openldap-stack-ha:
  ltb-passwd:
    enabled: false
    ingress:
      enabled: false
  phpldapadmin:
    enabled: false
    ingress:
      enabled: false
  fullnameOverride: openldap
  customLdifFiles:
    00-organization.ldif: |-
      dn: dc=someorg
      dc: someorg
      o: Someorg, Inc.
      objectclass: top
      objectclass: dcObject
      objectclass: organization

The 00-organization.ldif does make it into /ldifs and is mentioned in the logs along with the no global superior knowledge error, so the values seem to be at least working as expected.

[JoWe112]

I experienced a similar problem, couldn't get the directory structure created. Not sure If I hade "ldap_add: Server is unwilling to perform (53)", but the result was the same

In my secret I had a dollar "$" sign in the password for LDAP_ADMIN_PASSWORD. Removed the "$" sign and deleted and recreated my release, and the directory structure was created.

[parak]

@JoWe112 Hmm, interesting, thanks. That doesn't seem to be my specific problem unfortunately, as after decoding the password secret I can see that it's definitely set to the default password. Just in case I tried setting it to something even simpler, but that didn't help either :(

[wynax]

hello, i have maybe a issue for your problem.

  customLdifFiles:
    00-organization.ldif: |-
      **dn: dc=someorg**
      dc: someorg
      o: Someorg, Inc.
      objectclass: top
      objectclass: dcObject
      objectclass: organization

I think the "dn:" must have the same value of the namingContexts. You can find the namingContexts on the root DSE.

In values.yaml, your namingContexts correspoding to :

## ldapDomain , can be explicit (e.g dc=toto,c=ca) or domain based (e.g example.com)
  ldapDomain: "example.org"

Let me now if it's work.

[parak]

Took a bit for me to try this again, but thanks for the tip @wynax, I needed to set global.ldapDomain in my particular case to be "someorg", and then things pretty much just started working as expected.

Much appreciated!