On Nov 10, 2016, at 20.47, Howard Chu <[email protected]> wrote: > > [email protected] wrote: >> recently i noticed these entries in slapcat output: >> >>> slapcat -F '/var/lib/ldap/config' -b 'cn=config' -H >>> 'ldap:///cn=config??base' >> 5824aae9 PROXIED attributeDescription "OU" inserted. >> 5824aae9 PROXIED attributeDescription "DC" inserted. >> dn: cn=config >> objectClass: olcGlobal >> cn: config >> olcArgsFile: /var/run/slapd/slapd.args >> olcConnMaxPending: 1000 >> olcConnMaxPendingAuth: 1000 >> olcGentleHUP: FALSE >> olcIdleTimeout: 0 >> olcPidFile: /var/run/slapd/slapd.pid >> olcReadOnly: FALSE >> olcReverseLookup: FALSE >> olcSaslSecProps: noanonymous >> olcTLSCACertificateFile: /etc/pki/trusted_root_authorities/example_corp_ >> root_ca-cert.pem >> olcTLSCertificateFile: /etc/ldap/pki/dsa1.example.net-cert.pem >> olcTLSCertificateKeyFile: /etc/ldap/pki/dsa1.example.net-key.pem >> olcTLSVerifyClient: never >> olcAttributeTypes: {0}( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) >> DESC ' >> RFC2256: organizational unit this object belongs to' SUP name ) >> olcAttributeTypes: {1}( 0.9.2342.19200300.100.1.25 NAME ( 'dc' >> 'domainComponen >> t' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match >> SUBSTR >> caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >> SINGLE-VAL >> UE ) >> structuralObjectClass: olcGlobal >> entryUUID: 65ca1166-8375-102d-9386-497a4dd6665c >> creatorsName: cn=config >> createTimestamp: 20090130235646Z >> contextCSN: 20120805020044.490450Z#000000#000#000000 >> contextCSN: 20120317151625.496021Z#000000#001#000000 >> olcLogLevel: stats sync >> entryCSN: 20161110171407.752985Z#000000#000#000000 >> modifiersName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=net >> modifyTimestamp: 20161110171407Z >> >> in the past, i'd seen this, due to ou and dc attributes being referenced >> before their schema elements were loaded. so, as can be seen above, i >> moved the declarations of these attributes to the beginning of the config, >> so to speak, at which point, the messages were no longer printed. >> >> but now they're back, and i'm curious why. there is very little parsed >> prior to the attribute declarations, i believe? what am i missing? >> presumably, it's as it was before, and something is referencing these >> attributes, but how can i determine what? > > It is the cn=config entry itself. The LDIF is parsed into Attributes before > the Attributes themselves are processed by the config engine. In this case > you can either ignore the message, since it's harmless, or change your admin > DNs to avoid using non-core attributes.
ah, modifiersName - thanks for the gentle cluebat. i'm now remembering this was the other half of the exercise in the past, and it had been so long since i'd modified cn=config itself that i'd forgotten.
