Re: slapcat, PROXIED attributeDescription inserted, and cron jobs

[ben thielsen <btb@bitrate.net>]

On Dec 09, 2010, at 20.26, Howard Chu wrote:

> btb@bitrate.net wrote:
>> hi-
>> 
>> i'm running slapcat from a daily cron job to back up cn=config and other
>> databases.  i've recently updated from 2.4.21 to 2.4.23, and notice now
>> in the output of slapcat, messages such as
>> 
>>  >slapcat -b 'cn=config' -l 'config.ldif'>  /dev/null
>> PROXIED attributeDescription "OU" inserted.
>> PROXIED attributeDescription "DC" inserted.
>> 
>> a bit of searching seems to indicate that these shouldn't be cause for
>> concern, and are just informative messages.
> 
> Correct.
> 
> Usually, these messages occur because one of your cn=config entries has a modifiersName or some other attribute containing a DN using these attributes, and the config backend hasn't read the cn=schema,cn=config tree yet.
> 
> This situation never happened in 2.3 because only "cn=config" had write access to the cn=config tree. But since 2.4 allows you to set the ACLs so that arbitrary users can write to the tree, you can run into these cases.

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:

>ldapsearch -LLLxZZWH 'ldap://dsa.example.com' -D 'uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com' -b 'cn=config' -s base 'olcattributetypes'
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