Univention Bugzilla – Bug 54986
slap tools will not work anymore if /etc/ldap/slapd.d/config.ldif exists
Last modified: 2023-02-01 17:24:16 CET
As discussed internal we should open a bug for this issue. In the customer environment the directory and config /etc/ldap/slapd.d/ exist (how ever). As this is the OpenLDAP Default, this may happen by inexperienced UCS user or maybe by installing software. If the situation is in place it was not easy for the support to find the reason slapd was not willing to start any more. A manual start leeds into: olcAccess: {19}to dn.regex="^cn=([^,]+),cn=apps,cn=univention,dc=dc0,dc=testenv,dc=de$" attrs=children,entry,@organizational>>> dnPrettyNormal: <olcDatabase={1}mdb> => ldap_bv2dn(olcDatabase={1}mdb,0) <= ldap_bv2dn(olcDatabase={1}mdb)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcDatabase={1}mdb)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcDatabase={1}mdb)=0 62cecb7f <<< dnPrettyNormal: <olcDatabase={1}mdb>, <olcDatabase={1}mdb> 62cecb7f >>> dnNormalize: <dc=dc0,dc=testenv,dc=de> => ldap_bv2dn(dc=dc0,dc=testenv,dc=intranet,0) <= ldap_bv2dn(dc=dc0,dc=testenv,dc=de)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=dc0,dc=testenv,dc=de)=0 62cecb7f <<< dnNormalize: <dc=dc0,dc=testenv,dc=de> 62cecb7f >>> dnNormalize: <cn=admin,dc=dc0,dc=testenv,dc=de> => ldap_bv2dn(cn=admin,dc=dc0,dc=testenv,dc=intranet,0) <= ldap_bv2dn(cn=admin,dc=dc0,dc=testenv,dc=de)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=admin,dc=dc0,dc=testenv,dc=de)=0 62cecb7f <<< dnNormalize: <cn=admin,dc=dc0,dc=testenv,dc=de> 62cecb7f <= str2entry: str2ad(olcDbMaxReaders): attribute type undefined 62cecb7f UNKNOWN attributeDescription "OLCDBMAXREADERS" inserted. 62cecb7f <= str2entry: str2ad(olcDbMaxSize): attribute type undefined 62cecb7f UNKNOWN attributeDescription "OLCDBMAXSIZE" inserted. 62cecb7f <= str2entry: str2ad(olcDbRtxnSize): attribute type undefined 62cecb7f UNKNOWN attributeDescription "OLCDBRTXNSIZE" inserted. 62cecb7f >>> dnNormalize: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 62cecb7f <<< dnNormalize: <cn=config> 62cecb7f >>> dnNormalize: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 62cecb7f <<< dnNormalize: <cn=config> 62cecb7f <= str2entry(olcDatabase={1}mdb) -> 0x563befded188 62cecb7f : config_add_internal: DN="olcDatabase={1}mdb,cn=config" no structural objectClass in configuration table 62cecb7f config error processing olcDatabase={1}mdb,cn=config: 62cecb7f send_ldap_result: conn=-1 op=0 p=0 62cecb7f send_ldap_result: err=65 matched="" text="" 62cecb7f slapd destroy: freeing system resources. 62cecb7f slapd stopped. 62cecb7f connections_destroy: nothing to destroy. This was information was the the point we found the reason: cn=config` is the OpenLDAP configuration database (`/etc/ldap/slapd.d/`), which replaced the file `/etc/ldap/slapd.conf`. We do *NOT* use this in UCS: `slapd -f /etc/ldap/slapd.conf` should make sure it stays so; make sure this is used. If you have `/etc/ldap/slapd.d/` make sure there is no `cn=config.ldif` within; otherwise the OpenDLAP tools will default to use that instead of the legacy `slapd.conf`.
We explicitly use `slapd -f /etc/ldap/slapd.conf` to start the server, so `/etc/ldap/slapd.d/` does *not* get used even when it exists. We also use the same option when doing `slapadd` or `slapcat` or `slaptest` as they implement the same logic. Actually this is note the case everywhere. FYI: management/univention-ldap/01univention-ldap-server-init.inst has code the (re-)move /etc/ldap/slapd.d/cn=config.ldif during join.
we should add "-f /etc/ldap/slapd.conf" to the slaptest calls in: management/univention-ldap/scripts/ldap_setup_index management/univention-directory-listener/doc.34355/common.sh
Another customer is affected from this. On one server, the file /etc/ldap/slapd.d/cn=config.ldif wasn't removed at univention-join and caused slapindex to not build the index. This resulted in students could no longer be searched for in a school environment and exam mode could not be started/finished. After renaming the file to /etc/ldap/slapd.d/cn=config.ldif.DISABLED, slapindex worked again and students can be found again.
A simple diagnostic module may suffice
977fa552f1 | slapd will not start anymore if /etc/ldap/slapd.d/config exists db520a072f | Advisory update
As discussed, doesn't work: ====== root@primary20:~# touch /etc/ldap/slapd.d/cn=config.ldif root@primary20:~# slapindex WARNING! Runnig as root! There's a fair chance slapd will fail to start. Check file permissions! 63c92889 str2entry: entry -1 has no dn slapindex: bad configuration file! ====== 1. The /etc/default/slapd is not considered by the openldap slap* tools 2. management/univention-ldap/conffiles/etc/init.d/slapd already hardcodes SLAPD_CONF I think we need to go with Nikolas proposal from Comment 7
https://git.knut.univention.de/univention/ucs/-/merge_requests/632
977fa552f1 | slapd will not start anymore if /etc/ldap/slapd.d/config exists db520a072f | Advisory update 582624808f | slap tools must also work in case /etc/ldap/slapd.d/cn=config.ldif exists (even if invalid) 3a386a5a70 | workaround for linkcheck blocking work 11db6cc221 | remove advisory for ucs-test aab45bfd22 | Advisory update
Verified: * Code review * Package update * Advisory We'll need to release the documentation changes too. * doc/ext-performance * doc/ext-domain * doc/manual
<https://errata.software-univention.de/#/?erratum=5.0x566> <https://errata.software-univention.de/#/?erratum=5.0x567> <https://errata.software-univention.de/#/?erratum=5.0x568> <https://errata.software-univention.de/#/?erratum=5.0x569> <https://errata.software-univention.de/#/?erratum=5.0x570> <https://errata.software-univention.de/#/?erratum=5.0x571> <https://errata.software-univention.de/#/?erratum=5.0x572>