Re: PROXIED attributeDescription "<foo>" inserted

[btb@bitrate.net]

On Nov 10, 2016, at 20.47, Howard Chu <hyc@symas.com> wrote:
> 
> btb@bitrate.net 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.