cleanstart/openldap 2.6.12 — Issues and Mitigations

1. Environment variables are not evaluated

Despite Docker Hub documentation suggesting env var support (LDAP_DOMAIN, LDAP_ADMIN_PASSWORD, etc.), the cleanstart/openldap:2.6.12 image does not process them. It is a bare Alpine OpenLDAP package that reads directly from /etc/openldap/slapd.conf.

The image ships with hardcoded defaults: - suffix: dc=my-domain,dc=com - rootdn: cn=Manager,dc=my-domain,dc=com - rootpw: secret

Diagnosis: Container logs show the defaults being loaded:

slapd.conf: line 63 (suffix    "dc=my-domain,dc=com")
slapd.conf: line 64 (rootdn    "cn=Manager,dc=my-domain,dc=com")

Also confirmed via:

podman exec -it ldap ldapsearch -x -H ldap://localhost:389 -s base -b "" namingContexts
# Returns: namingContexts: dc=my-domain,dc=com

Mitigation: Mount a custom slapd.conf into the container:

volumes:
  - ./slapd.conf:/etc/openldap/slapd.conf:z

The custom slapd.conf sets the correct suffix, rootdn, and rootpw for your domain.

2. Permission denied on data directory

When running with user: 1007:1007, slapd fails with:

slapd.conf: line 72: invalid path: Permission denied

The non-root user cannot create or write to /var/lib/openldap/openldap-data.

Mitigation: Either remove the user: directive (let the container run as root), or pre-create the host directory with correct permissions:

mkdir -p /var/lib/cicd/ldap/data
chmod 777 /var/lib/cicd/ldap/data

3. Port binding fails as non-root

When running with user: 1007:1007, slapd cannot bind to port 389 (privileged port):

daemon: bind(6) failed errno=13 (Permission denied)
slapd stopped.

Mitigation: Remove the user: directive to run as root (binds to 389), or configure slapd to listen on port 1389 and update all references accordingly.

4. Volume mount paths differ from osixia/openldap

The cleanstart/openldap image uses different internal paths than the commonly documented osixia/openldap:

Mounting to the wrong paths means the entrypoint (if any) can't find or write config, and slapd can't find its database.

Mitigation: Use the correct paths in docker-compose:

volumes:
  - ./slapd.conf:/etc/openldap/slapd.conf:z
  - /var/lib/cicd/ldap/data:/var/lib/openldap/openldap-data:z

5. SELinux volume labels

Using :Z (uppercase, private label) can prevent slapd from writing to mounted volumes. The entrypoint or slapd silently fails and falls back to defaults.

Mitigation: Use :z (lowercase, shared label) for LDAP volumes.

6. Base DN does not exist after fresh start

After a clean initialization, the LDAP database is empty. The suffix in slapd.conf defines what the server will accept, but does not create the actual directory entry. Attempting to create entries under the base DN fails with:

LDAP error: No such object

Mitigation: Bootstrap the base DN with an LDIF file:

podman cp bootstrap.ldif ldap:/tmp/bootstrap.ldif
podman exec -it ldap ldapadd -x -H ldap://localhost:389 \
  -D "cn=admin,dc=pathoris,dc=de" -w admin \
  -f /tmp/bootstrap.ldif

The bootstrap.ldif creates the base entry and initial organizational units.

7. Admin password only set on first initialization

The admin password (rootpw in slapd.conf) is baked into the database on first start. If the data volume was initialized with a different password (or empty), changing slapd.conf or env vars has no effect.

Mitigation: Wipe the data directory and restart:

podman-compose stop ldap
rm -rf /var/lib/cicd/ldap/data/*
podman-compose up -d ldap

Image selection rationale