LDAP_DOMAIN & LDAP_BASE_DN informations request & brainstorming

[obourdon]

Besides what the code is currently doing with this variables, is it possible to get an insight/explanation of what these are really meant for and what relationship they have between each other

The reasons I am asking this is because:

• there are many issues linked to these variables (Unable to set ldap domain to anything other than example.org #338, LDAP_DOMAIN and LDAP_BASE_DN discrepancy #172, LDAP_BASE_DN needs to be defined #282, ...)\
• these are specific to osixia/docker-openldap and not related to OpenLDAP distribution itself
• I have added some more tests and code to fix some issues Fix domain dn #341, but I am not the only one Fixes #172. LDAP_BASE_DN env was not used for the actual LDAP base #238
• looking at LDAP_DOMAIN and LDAP_BASE_DN discrepancy #172 made me try using something like --env LDAP_BASE_DN="ou=hazard,o=dummy,c=cz" -e LDAP_DOMAIN=dummy.cz which puzzles me even more as

1. ou, o & c are replaced by dc

root@b19e90335125:/# slapcat | grep dn:
dn: dc=dummy,dc=cz
dn: cn=admin,dc=dummy,dc=cz

2. other configuration file are a mix

root@b19e90335125:/# find /etc/ldap/ -type f -print | xargs egrep 'dummy|hazard'
/etc/ldap/slapd.d/cn=config/olcDatabase={1}mdb.ldif:olcSuffix: dc=dummy,dc=cz
/etc/ldap/slapd.d/cn=config/olcDatabase={1}mdb.ldif:olcRootDN: cn=admin,dc=dummy,dc=cz
/etc/ldap/slapd.d/cn=config/olcDatabase={1}mdb.ldif: =admin,ou=hazard,o=dummy,c=cz" write by anonymous auth by * none
/etc/ldap/slapd.d/cn=config/olcDatabase={1}mdb.ldif:olcAccess: {1}to * by self read by dn="cn=admin,ou=hazard,o=dummy,c=cz" writ

I think interested/concerned people should analyse this further deep so that we can exchange and possibly rework on this so that it fits most needs and be non-ambiguous in its usage.

All ideas/comments/... welcome

[jelmd]

Well, this stuff doesn't make sense, yepp.

Just found out, that again a "very clever" debian package script is responsible for this garbage - see /var/lib/dpkg/info/slapd.config . Because of the very questionable "always config on package install" debian policy, it gets invoked always when package reconfiguration gets requested (on package install, update) or if manually requested e.g. like dpkg-reconfigure -f noninteractive slapd as osixia/docker-openldap does in its startup.sh.

IMHO, osixia should do its own reliable configuration and not use those very questionable and IMHO dangerous debian scripts and should not use /etc/ldap/slapd.d as config dir, because the debian scripts will mangle it ...

[zicklag]

Yeah, I definitely agree that this is confusing. At this point I feel like just deleting all the out-of-the-box config in a derivative image and doing all my own ldiff files. Feels like the safest option.

[joshuacox]

I had many of the above problems as well with setting the LDAP variables and strange happenings afterward, in the end using this helm chart solved my problems: https://github.com/jp-gouin/helm-openldap.git

[pavelhoral]

Here are my two cents:

The relation between domain name and base DN is confusing to many, even more that it is forced on us. OpenLDAP's Debian package simply expects that everyone is doing RFC 2247. That assumption might be OK in majority of use cases, however not in all of them. And there is little to no guidance available when someone wants their naming context not to be domain based.

I think README should mention RFC 2247 and I think an example should be created that shows how someone can create default database with suffix o=Example. This should be done either by renaming the default database (is that even possible?) or completely dropping it and creating a new one.

Btw. in one of my use-cases I ended up not using this image and created my own with the following dockerfile fragment:

RUN echo "slapd slapd/no_configuration boolean true" | debconf-set-selections \
    && apt-get update \
    && apt-get install -y slapd ldap-utils \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

This allowed me to create initial config to my liking.