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,

On 31Jan24 16:16+0000, Howard Chu wrote:

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

Do I understand correctly, that sbin/slapcat should also load initalize all modules from slapd config?

...

• 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.

We have not indexed that. Thanks!

...

• 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.

Great! I'll revert the changes about that and will mark those attributes obsolete. The OBSOLETE tag is not specified closer in manual. The RFC says it is an indicator. I think, the tag is _just_ an meta data in the schema and slapd will mostly ignore it, right?

...

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.

Will do.

Many Thanks,

Bastian Tweddell wrote:

On 31Jan24 16:16+0000, Howard Chu wrote:

...

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

Do I understand correctly, that sbin/slapcat should also load initalize all modules from slapd config?

Yes, all the tools fully process the config.

...

...

• 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.

Great! I'll revert the changes about that and will mark those attributes obsolete. The OBSOLETE tag is not specified closer in manual. The RFC says it is an indicator. I think, the tag is _just_ an meta data in the schema and slapd will mostly ignore it, right?

Right.