Sunday, March 1, 2020

[389-devel] Thoughts on swapping to rfc2307bis.ldif by default

Hi all,

As you may know, I'm currently working on a migration utility to help move from other ldap servers to 389-ds. Something that I have noticed in this process is that other servers default to rfc2307bis.ldif [0] by default. As part of the migration I would like to handle this situation a bit better. It's likely not viable for me to simply plaster rfc2307bis into 99user.ldif as part of the migration process, so I want to approach this better.

rfc2307 and rfc2307bis are incompatible schemas that redefine the same OIDs with new/different meanings. Some key examples:

* posixGroup in rfc2307 only requires gidNumber, rfc2307bis requires cn and gidNumber.
* ipServiceProtocol, ipHostNumber, ipNetworkNumber and nisMapName change from "sup name" to "syntax". sup name is also syntax so this channge is minimal.
* posixGroup and posixAccount change from structural to auxillary in rfc2307bis (allowing them to be combined with person or nsAccount).

Objectively, rfc2307bis is the better schema - but as with all proposals like this, there is always a risk of breaking customers or compatibility.

I'm wondering what would be a reasonable course of action for us to move to rfc2307bis by default. My current thoughts:

* have rfc2307bis vs rfc2307 as an option to dssetup so we use the correct schema in the setup.
* default the setup option to rfc2307bis
* Tests for handling both setup options
* Upgrades of the server should not affect the rfc2307 vs rfc2307bis status
* A dsctl tool to allow changing between the rfc2307/rfc2307bis.

Thoughts? Concern? Ideas? Comments?



William Brown

Senior Software Engineer, 389 Directory Server
389-devel mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:

No comments:

Post a Comment