This attribute is said to be "no longer used" (https://tools.ietf.org/html/rfc2256).
I would prefer to not define by default an obsolete attribute.

The rest of the patch looks good to me

I don't want to define it either - all of these attributes are "no longer used", and shouldn't be used. But we have no way to say "don't create this, but we support reading it and validating entries with it" in our schema machinery. And we have to accept that OpenLDAP does have this attributes in their schemas. I'd really rather not have stuff from 99user.ldif that may override or interfer with 00core.ldif, and when we import from openldap these attributes are gonna have to exist. So we have to chose if we supply them on our terms in 00core.ldif, correct and checked by us, or if we let the openldap_2_389 tool do it, in a way that may confuse support or us by adding these crazy schemas.

So that's why I added it even though it's no longer used.

@firstyear, I understand there is no good choice.
The patch adds obsolete definitions in 389-ds standard schema (00core.ldif).

An option is to deliver those obsolete attributes in '/share/dirsrv/data/openldap.ldif' schema file. Then add a checking in openldap_2_389, so that if 'egrep -i "knowledgeInformation|presentationAddress..." ' is not empty it copy the schema file in the directory specific schema before the import.
Is this option too risk for support ?

So my thinking is still to include these in 00core.ldif. It's much simpler for the migration tool, because then we don't need to move schema as required. A concern here is the migration will only run on one server in a topology, and that topology may already be established. How would we "ensure" openldap.ldif is linked on all the new replicas? That's now work the admin has to perform that they may not know about.

From a code and admin perspective, shipping it "by default" gives a consistent experience on all servers, minimises the migration work, and long term is better - I don't want admins in 10 years time having to still be remembering to symlink in a schema because of a decision we made now.

These attributes really really are unlikely to be used, at all, and adding them really isn't going to hurt us, or make life harder. We could probably skip adding them and no one would notice. But there is always that one case ....

So I still think having them here, even if not perfect, is the simplest long term solution.

If only one replica is updated with the new definitions, whether it is via openldap.ldif or 00core.ldif, the new definitions will be pushed during replications sessions to the rest of the topology. The new definitions will unfortunately be "learned" in 99user.ldif rather than openldap.ldif or 00core.ldif.

I have no strong concern making the change in 00core.ldif and the patch looks good to me. ACK

Yeah, I think that's a concern because what happens if you backup/restore to a new master not in the topology? tHen the schema isn't learnt either.

It' seems a lot easier to stick with 00core.ldif. Thanks for the ack and the discussion :)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/4001

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.