`ldapdelete` when there is no data crashes the pod

[waldner]

Describe the bug

If I run ldapdelete -r after all data has been deleted, the pod crashes (container is terminated with error 139).

To Reproduce

$ ldapdelete -c -x -r -H ldap://ldap.example.com  -D "cn=admin,dc=om,dc=dsn,dc=example" -w admin  "dc=om,dc=dsn,dc=example"
# works fine, but then:
$ ldapdelete -c -x -r -H ldap://ldap.example.com  -D "cn=admin,dc=om,dc=dsn,dc=example" -w admin  "dc=om,dc=dsn,dc=example"
ldap_search: No such object (32)
ldap_result: Can't contact LDAP server (-1)

Looking at kubectl get pods -n openldap, I can see that the pod that was hit by the last request has been terminated and is restarting. No error in the logs. From there on, every ldapdelete query crashes the pod, unless some data is added to the directory, in which case it can be deleted without errors (but then subsequent deletes cause the pod to crash again, as explained).

Expected behavior

Perhaps an error should be returned to the user, but certainly the pod should not crash.

This is an installation with ArgoCD, here is the Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: openldap
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://jp-gouin.github.io/helm-openldap
    targetRevision: 4.2.2
    chart: openldap-stack-ha
    helm:
      values: |

        global:
          ldapDomain: "dc=om,dc=dsn,dc=example"
          adminUser: admin
          adminPassword: admin
          configUser: admin
          configPassword: admin

        replicaCount: 2

        phpldapadmin:
          ingress:
            enabled: true
            ingressClassName: nginx
            annotations:
              cert-manager.io/cluster-issuer: le-cluster
              cert-manager.io/renew-before: 720h

            hosts:
              - ldap-admin.example.com
            tls:
              - secretName: ldap-admin-secret
                hosts:
                  - ldap-admin.example.com
          env:
            PHPLDAPADMIN_LDAP_CLIENT_TLS_REQCERT: "never"

        ltb-passwd:
          ingress:
            enabled: true
            ingressClassName: nginx
            annotations:
              cert-manager.io/cluster-issuer: le-cluster
              cert-manager.io/renew-before: 720h

            hosts:
              - ldap-ltb.example.com
            tls:
              - secretName: ldap-ltb-secret
                hosts:
                  - ldap-ltb.example.com

        service:
          type: LoadBalancer
          annotations:
            external-dns.alpha.kubernetes.io/hostname: ldap.example.com

        persistence:
          enabled: true

  destination:
    server: https://kubernetes.default.svc
    namespace: openldap
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
      allowEmpty: true
    syncOptions:
      - CreateNamespace=true

[jp-gouin]

Does this also delete cn=config data ?

What is the log of the pod when it crashes ?

[waldner]

These are the last lines in the log before the pod dies:

66117734.37444f7d 0x7fa8867fc700 conn=69035 fd=15 ACCEPT from IP=10.42.155.195:10677 (IP=0.0.0.0:1389)
66117734.37455e2e 0x7fa886ffd700 conn=69035 op=0 BIND dn="cn=admin,dc=om,dc=dsn,dc=example" method=128
66117734.37463ad2 0x7fa886ffd700 conn=69035 op=0 BIND dn="cn=admin,dc=om,dc=dsn,dc=example" mech=SIMPLE bind_ssf=0 ssf=0
66117734.37478060 0x7fa886ffd700 conn=69035 op=0 RESULT tag=97 err=0 qtime=0.000011 etime=0.000175 text=
66117734.374fcb7c 0x7fa8877fe700 conn=69035 op=1 SRCH base="dc=om,dc=dsn,dc=example" scope=1 deref=0 filter="(objectClass=*)"
66117734.37512cc6 0x7fa8877fe700 conn=69035 op=1 SRCH attr=1.1
66117734.3753c30e 0x7fa8877fe700 conn=69035 op=1 SEARCH RESULT tag=101 err=32 qtime=0.000020 etime=0.000318 nentries=0 text=
66117734.3758e7e0 0x7fa887fff700 conn=69035 op=2 DEL dn="dc=om,dc=dsn,dc=example"

cn=config data seems to still be there, or at least ldapsearch -x -H ldap://ldap.example.com -w admin -D "cn=admin,cn=config" -b "cn=config" does return data.

[jp-gouin]

Hi @waldner sorry for the long delay

I reproduced your issue. From what I see the behavior is expected.

you delete dc=om,dc=dsn,dc=example and in the log I can see DEL dn="dc=om,dc=dsn,dc=example" So when you run the ldapdelete command again the "dc=om,dc=dsn,dc=example" is empty, ergo the ldap_search: No such object (32)

I assume the ldap_result: Can't contact LDAP server (-1) is a default answer

If you run LDAPTLS_REQCERT=never ldapsearch -x -w admin -H ldap://openldap -D "cn=admin,dc=om,dc=dsn,dc=example" -b "dc=om,dc=dsn,dc=example

you can contact the database and it returns :

# extended LDIF
#
# LDAPv3
# base <dc=om,dc=dsn,dc=example> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

Which, again, is expected after the delete

[waldner]

Sorry, I understand the replies are correct, but I think that the container should not crash....