[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-technical
Subject:    Re: UNKNOWN attributeDescription "..." inserted.
From:       Howard Chu <hyc () symas ! com>
Date:       2024-01-31 16:16:17
Message-ID: 7da5da5a-aa80-0225-9064-84472d66571e () symas ! com
[Download RAW message or body]

Bastian Tweddell wrote:
> Dear all,
> 
> We are facing 'UNKNOWN attributeDescription' errors in our 
> infrastructure, caused by two different reasons. I realized those only 
> by using `slapcat` which prints the following error/warning message to 
> STDERR:
> ```
> UNKNOWN attributeDescription "..." inserted.
> ```
> In both cases, this issue does not degrade the production of our system. 
> All operations including syncreplication are working in normal 
> parameter. 
> 
> Case A:
> In our production, a dedicated slapd syncrepl consumer has the totp 
> module from contrib enabled and ldapbind calls against '{TOTP1}' are 
> performed. This module introduces a new attribute "authTimestamp".
> IIUC, `slapcat` cannot know about this attribute, because it is 
> not in the config. But attributes of that type are stored in the MDB. 
> I'd like to ask:
> - How should we deal with this situation?

File a bug against the totp module. If it is using this attribute, it
should be registering it in the schema during module initialization.

> - Is it safe to continue as is or should we define the attribute 
>   "authTimestamp" in our schema extension as well?

It's mostly safe, unless you configured an index on authtimestamp and
needed to run slapindex on it.

> Case B:
> We are about to remove some attribute definitions from our schema 
> extension. These are obsolete and not in use in the DB anymore. On the 
> testbed slapd+syncrepl works as expected. But here as well, even though 
> that the DB does not contain any of the obsolete attributes in any 
> entry, `slapcat` throws the same error/warning for all removed 
> attributes from the schema file.
> My first approach was to re-index the database (even with truncate 
> mode), which did not solve the situation. Stopping the consumer slapd, 
> removing the mdb files and restarting the syncrepl solves it. But on 
> production I would not want to do re-sync everything unnecessarily (it 
> would be possible though).
> I'd like to ask here:
> - Is there a way to cleanup MDB from obsolete attributes?

Generally no, the DB records every attribute type you have ever used.

> - Where/how are those attributes referenced in MDB?

Internal lookup tables.

> - Would it harm to ignore those errors?

They're just warnings. If they were errors, slapd would not start up.

> - Is the removal of attribute definitions from the schema not 
>   supported/suggested at all?

Never recommended, no. If you're retiring a definition, just add OBSOLETE to it.

> Btw, we are running slapd 2.6.3 with mdb backend. (Upgrade to 2.6.7 is 
> in planning now).
> 
> During the composition of this mail, further issues came up with 
> slapd-totp and I would like to add some follow-up questions here. If you 
> prefer, I'll write another mail or I could open an issue on bugzilla.

Open a separate issue in bugzilla.
> 
> 1. By reading some code in slapd-totp.c I recognized that the introduced 
>    attribute authTimestamp is SINGLE-VALUE. But slapcat reveals that 
>    entries have multiple values of authTimestamp. This sounds not 
>    correct to me.
> 2. In slapd-totp.c: line 856 and 873 both call `ch_calloc` for the same 
>    structm, shadowing the same pointer. This looks like a memory leak to 
>    me, because also only one free is called. (I might be wrong though).

Note that contrib modules are explicitly not maintained by the Project.
You'll need to find someone in the community to fix these issues for you.
> 
> Many thanks in advance,
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
[prev in list] [next in list] [prev in thread] [next in thread]