hmm - this confuses me. i believe that the ou and dc attributes are known to the system, as demonstrated below, to the best of my abilities. what can i do to reveal more clues regarding this? # entries present in back-config filesystem olcAttributeTypes: {49}( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainCompone nt' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match SUBST R caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VA LUE ) olcAttributeTypes: {8}( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC ' RFC2256: organizational unit this object belongs to' SUP name ) olcAttributeTypes: {9}( 2.5.4.12 NAME 'title' DESC 'RFC2256: title associated with the entity' SUP name ) # entries present in cn=config directory 'uid=dit_admin,ou=role_accounts,ou=accounts,dc=dipswitch,dc=net' -b 'cn={0}core,cn=schema,cn=config' -s base 'olcattributetypes' | grep -A 3 -i 'domainCompon' Enter LDAP Password: olcAttributeTypes: {49}( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainCompone nt' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match SUBST R caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VA LUE ) 'uid=dit_admin,ou=role_accounts,ou=accounts,dc=dipswitch,dc=net' -b 'cn={0}core,cn=schema,cn=config' -s base 'olcattributetypes' | grep -A 1 -i 'organizationalunit' Enter LDAP Password: olcAttributeTypes: {8}( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC ' RFC2256: organizational unit this object belongs to' SUP name ) # entries present in cn=subschema 'cn=subschema' 'attributetypes' | grep -A 2 -i domainComponent attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainComponent' ) D ESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match SUBSTR caseI gnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE- VALUE ) 'cn=subschema' 'attributetypes' | grep -A 1 -i organizationalunit attributeTypes: ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC 'RFC225 6: organizational unit this object belongs to' SUP name )

On Dec 09, 2010, at 20.26, Howard Chu wrote: thanks for the clarification. i have what i believe is a reasonable approach to this. for the potential benefit of the mailing list, i thought i'd offer a summary: the specific cause of the messages was the modifiersName operational attribute in various entries throughout cn=config. since cn=config is managed by a user whose entry is in another tree (in this case, uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com), the ou and dc attributes were being encountered before the related schema entries which defined them were read. manually overwriting the various modifiersName attributes (for example, with a value of cn=admin,cn=config) resulted in the messages disappearing, confirming this. the caveat here is that since the database is managed by a foreign entry, the messages will potentially return, following subsequent modifications (subject to the specific entry being modified, and whether or not it's read before the schema). to mostly address this, a bit of an unconventional approach is taken. the schema entries which define the two offending attributes are moved from their traditional location in cn={0}core,cn=schema,cn=config to the cn=config entry itself: Enter LDAP Password: dn: cn=config 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 ) although this is a bit messy - as i understand it, it's technically legal. the benefit is that these two attributes are read as early as possible, meaning that when entries referencing them are encountered, they're no longer unknown. almost. there appears to be one exception to this - the cn=config entry itself. if it's modifiersName attribute references a foreign entry, the messages are still printed, because - as it was explained to me - the function that parses LDIF into an entry does it's work before the olcAttributeTypes actually gets processed. in my case, this was a little discouraging, since cn=config was the entry that got the most exercise, due to modifications of olcLogLevel. however - to address this, i learned that the loglevel need not be adjusted in cn=config, and could instead be adjusted with the managedInfo attribute in cn=Log,cn=Monitor, which accepts the same values as olcLogLevel. ultimately, this means the following (at least for me): i now have a cn=config tree that is immune to this behavior, with the exception of the root entry, which means there is only one entry to overwrite the modifiersName attribute when changes are made. additionally, thanks to cn=Log,cn=Monitor, modification of cn=config now need only occur once in a great while, making the modifiersName modification reasonably palatable. all of this leads to no messages being printed to stderr, which means that cron does not send email every time a backup occurs. the last item i think might be worthy of mention, for the sake of posterity, is something that probably should have been more obvious to me, but wasn't, resulting in a bit of misinterpretation at first. two databases were being slapcat'd (cn=config and cn=example,cn=com), resulting in two sets of the "PROXIED attributeDescription.." messages being printed. initially, this gave me the impression that i had offending entries in both databases. however, this was not the case. the offending entries existed only in cn=config. however, since slapcat parses the config (e.g. reads the cn=config tree) even if you're ultimately processing some other database, the messages are printed nonetheless. ultimately, there is perhaps a better solution to this, but at the very least, i think for the moment, this is a satisfactory compromise. -ben