On 3 Mar 2020, at 04:32, thierry bordaz <tbordaz(a)redhat.com>
wrote:
On 3/2/20 7:24 AM, William Brown wrote:
> 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.
Is not it the opposite ?
I was reading the schema as I was reading this.
> * ipServiceProtocol, ipHostNumber, ipNetworkNumber and nisMapName
change from "sup name" to "syntax 1.3.6.1.4.1.1466.115.121.1.15". sup
name is also syntax 1.3.6.1.4.1.1466.115.121.1.15 so this channge is minimal.
> * posixGroup and posixAccount change from structural to auxillary in rfc2307bis
(allowing them to be combined with person or nsAccount).
Right but for 389-ds the structural requirement is not enforced, so it should not be a
problem
You know, that's probably actually the best thing I've heard all day. It makes
this problem much easier.
>
> Objectively, rfc2307bis is the better schema - but as with all proposals like this,
there is always a risk of breaking customers or compatibility.
I agree on both :)
>
> 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?
It would be interesting to have a complete list of the differences. at the moment with
the listed differences I think 2307bis would support 2307 entries. In addition, 2307bis
looks to be a superset of 2307 so that it would be replicated in a mmr topology.
Right. I'll get a list of all the differences, and knowing that structural isn't
enforced does make things easier - a lot easier. It may be less disruptive to swap to
2307bis by default if that's the case.
Because of some bug, 99user.ldif will contains all overridden definitions not the only
new/changed one.
The idea of a dsctl tool looks good. It could be to create a task that check all entries
conform a schema. If all entries conform 2307bis we could replace the default 2307 schema
file with the 2307bis.
Yeah, a task could help here too.
>
>
> [0]
https://tools.ietf.org/html/draft-howard-rfc2307bis-02
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproje...
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs