On Dec 09, 2010, at 20.26, Howard Chu wrote:
btb(a)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