Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239)
The process for converting a slapd configuration to cn=config making use of slapo-chain at a global level is seriously broken.
This can be trivially illustrated by using the slapd.conf generated by test032.
After doing conversion, the resulting cn=config database has *two* ldap backends defined:
dn: olcDatabase={-1}frontend,cn=config dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf
The first instance ({0}ldap,...) isn't even valid. If you remove the entire chain configuration from this database, and then attempt to import it, you get the following:
ldapadd -H ldap:/// -D cn=config -w secret -f ./olcOverlay={0}chain.ldif adding new entry "olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config"
ldapadd -H ldap:/// -D cn=config -w secret -f ./olcDatabase={0}ldap.ldif adding new entry "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config" ldap_add: Object class violation (65)
This is because the first instance ({0}) is *missing* the required olcDbURI attribute. In addition, it generates completely bogus attribute values (See ITS#8693)
The *second* generated LDAP backend database is what is correct.
Here's the LDIF for the incorrect database:
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: none starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0
Here's the LDIF for the *correct* database:
dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldap://localhost:9012" olcDbStartTLS: none starttls=no olcDbIDAssertBind: mode=self flags=non-prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="cn=manager,dc=exampl e,dc=com" credentials="secret" keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0
However, even in the case of the *correct* LDIF, the bogus olcDbStartTLS attribute is defined (Again, ITS#8693)
This is the slapd.conf used to convert:
include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/nis.schema pidfile /tmp/slapd.1.pid argsfile /tmp/slapd.1.args
modulepath /usr/local/libexec/openldap moduleload back_mdb.la moduleload back_ldap.la moduleload back_monitor.la
overlay chain chain-uri ldap://localhost:9012/ chain-idassert-bind bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials=secret mode=self flags=non-prescriptive
database mdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory /tmp/db.1.a index objectClass eq index cn,sn,uid pres,eq,sub
database monitor