Re: Antw: Re: Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

>>> Howard Chu <hyc@symas.com> schrieb am 04.09.2019 um 03:40 in Nachricht
<120f8d33-171a-3712-9f13-473fb55ea09e@symas.com>:
> Ulrich Windl wrote:
>>>>> Michael Ströder <michael@stroeder.com> schrieb am 29.08.2019 um 16:34
in
>> Nachricht <37c75ce9-b21e-9380-9f71-72c40086b01e@stroeder.com>:
>>> On 8/29/19 8:32 AM, Ulrich Windl wrote:
>>>>>>> Quanah Gibson-Mount <quanah@symas.com> schrieb am 28.08.2019 um 15:56
>> in
>>>> Nachricht <F0468E4D7DD097415B5FC5C1@[192.168.1.144]>:
>>>>> ‑‑On Wednesday, August 28, 2019 11:02 AM +0200 Ulrich Windl 
>>>>> <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
>>>>>> After systemd tearing down one of our LDAP servers I noticed the
>>>>>> following message when the server was restarted: slapd[10525]: UNKNOWN
>>>>>> attributeDescription "AUDITCONTEXT" inserted.
>>>>>> [..]
>>>>>> The schema knows in olcAttributeTypes (olcSchemaConfig):
>>>>>> ( 1.3.6.1.4.1.4203.666.11.5.1.30 NAME 'auditContext' DESC 'DN of
>>>>>> auditContainer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE‑VALUE
>>>>>> NO‑USER‑MODIFICATION USAGE dSAOperation )
>>>>>>
>>>>>> What I'l like to know: Is there any thing I could fix in the
>>>>>> configuration to make the message go away, or is it some software
issue
>>>>>> in slapd?
>>>>>
>>>>> I've seen this when an attribute is introduced into the cn=config
database
>> 
>>>>> that's not part of the built‑in slapd schema.  It can be harmless in
that
>> 
>>>>> case.
>>>>
>>>> I grepped for the attribute in external schema files, but didn't find
it.
>> As 
>>> I
>>>> found it when querying slapd, I conclude that the definition shown above

>>> must
>>>> be build into slapd.
>>>
>>> Attribute type description 'auditContext' and all other schema
>>> definitions for accesslog overlay are defined in C code of
>>> slapo-accesslog. If you don't load slapo-accesslog then you normally
>>> don't see the schema.
>>>
>>> I don't know what inconsistent content your cn=config has though.
>> 
>> Still I don't quite understand it: It seems the attribute is also in the
>> config database (dn: cn=schema,cn=config), so why is it unknown when slapd
>> starts? It cannot be the reason that the schema is provided by an overlay.

> That
>> would apply when starting the first time only, maybe (when the schema 
> database
>> isn't populated yet by the overlay).
> 
> http://www.openldap.org/doc/admin24/slapdconf2.html 
> 
> Section 5.2.3
> 
> The contents of the file corresponding to cn=schema are always ignored, and

> the actual
> runtime contents of the cn=schema entry are always the actual hardcoded 
> schema in the
> slapd process. As such, you should only trust the contents of an ldapsearch

> of the
> cn=schema,cn=config entry, and always disregard whatever was stored in the 
> file.

That was unexpected for me. Is there a technical reason for this design? I see
some chicken/egg problem, but for a synced config setup this seems
non-optimal.

Regards,
Ulrich