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