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
changed notes
On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah@openldap.org wrote: > The process for converting a slapd configuration to cn=config making use of > slapo-chain at a global level is seriously broken. It's not as bad, just a little bit 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 This is the catchall database used to handle referrals that are not handled by any other database you configure by hand. It collects all the chain-* settings that appear before the first chain-uri. > 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: Yeah that is a problem. > 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) Maybe we just need to inherit objectclass: olcLdapDatabase somehow in olcChainOverlay and keep these settings in the overlay entry, or specify a bogus URI to be configured there. Whatever is most useable and still allows for seamless expansion. > The *second* generated LDAP backend database is what is correct. > > Here's the LDIF for the incorrect database: > > [...] > > Here's the LDIF for the *correct* database: > > [...] -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Mon, Jan 22, 2018 at 11:57:38PM +0000, ondra@mistotebe.net wrote: > On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah@openldap.org wrote: >> 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 > > This is the catchall database used to handle referrals that are not > handled by any other database you configure by hand. It collects all the > chain-* settings that appear before the first chain-uri. > >> 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: > > Yeah that is a problem. Turns out the problem is different yet. When the overlay is started up after adding its entry, it generates a default backend internally. On adding the above backend it now thinks it has a default one already (even though there is no entry for it yet) and rejects it. >> This is because the first instance ({0}) is *missing* the required olcDbURI >> attribute. In addition, it generates completely bogus attribute values (See >> ITS#8693) > > Maybe we just need to inherit objectclass: olcLdapDatabase somehow in > olcChainOverlay and keep these settings in the overlay entry, or specify > a bogus URI to be configured there. Whatever is most useable and still > allows for seamless expansion. Still thinking making the overlay objectclass inherit the attributes from olcLdapDatabase instead of creating a fake DB but that can't be done for 2.4 and I have no idea how to properly go about that yet anyway. For 2.4 at least it might make sense to just use the flags on the default backend to say it has no entry associated with it (yet) and: - clear that in ldap_chain_cfadd_apply so we know it can be replaced later - also create the entry if slapd is just starting up (How about cn=config replication though? Upgrades need to be planned) - maybe only let a default backend be added if there really is no other backend yet (including the temporary ones used during normal operation), since those will get some defaults from it -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Wed, May 08, 2019 at 01:31:48PM +0000, ondra@mistotebe.net wrote: > On Mon, Jan 22, 2018 at 11:57:38PM +0000, ondra@mistotebe.net wrote: >> On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah@openldap.org wrote: >>> 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 >> >> This is the catchall database used to handle referrals that are not >> handled by any other database you configure by hand. It collects all the >> chain-* settings that appear before the first chain-uri. >> >>> 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: >> >> Yeah that is a problem. > > Turns out the problem is different yet. When the overlay is started up > after adding its entry, it generates a default backend internally. On > adding the above backend it now thinks it has a default one already (even > though there is no entry for it yet) and rejects it. There is now a patch here that exploits the above to know if the common backend has been added from slapd.conf/explicitly or implicitly like in the original report. https://github.com/mistotebe/openldap/tree/its8799 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
changed notes changed state Open to Release moved from Incoming to Software Bugs
Fixed in master Fixed in RE24 (2.4.48) See also ITS#8693
changed notes changed state Release to Closed