> On 4 Mar 2020, at 00:26, thierry bordaz <tbor...@redhat.com> wrote: > > > > On 3/3/20 11:59 AM, Alexander Bokovoy wrote: >> On ti, 03 maalis 2020, Ludwig Krispenz wrote: >>> Hi, >>> >>> I have no expertise in this area, but would like to get also Alexander's >>> opinion and view from IPA >> >> I don't have much to add to what Thierry and William covered already. >> Having a new draft with clarifications would be nice. >> >> Given that both 10rfc2307.ldif and 10rfc2307bis.ldif are present in >> default 389-ds deployment, why this schema conflict isn't a problem >> right now? > > Good point :) > 10rfc2307bis.ldif is in /share/dirsrv/data and 10rfc2307.ldif in > /share/dirsrv/schema. > Only 'schema' definitions are loaded in 'cn=schema'. The definitions in > 'data' are available for users but are not part of QE scope. > > I guess most of the users choose one rfc or the other and then the entries > will conform the chosen RFC. > A risk exists if we are moving a dataset from one rfc to the other. This > either during an import or if instances in the same replicated topology > create incompatible entries.
It's not a problem, because while we include both, we only actually install and load rfc2307.ldif. rfc2307bis.ldif is in a seperate directory as "example data", and thus is not loaded. In the past we made a decision to make schema load from /usr, which has caused at least one or two users to have issues with this specific schema as there was "no way" to remove rfc2307.ldif from the schema directory, but they wanted to use rfc2307bis. I think part of the reason we don't hear more complaints about this is as thierry said, we don't enforce the structural chain on posixGroup which is one of the major issues for rfc2307 that rfc2307bis resolves. So it's likely that most people don't notice that they are using rfc2307, instead thinking it's rfc2307bis as you can add posixGroup to other objectClasses. If we were to straight replace rfc2307 with rfc2307bis today I think we would have a compatability issue that may affect IPA, but the idea to have a compat that is a supported hybrid of both, would likely be non-disruptive, keep IPA working, and allow openldap imports. >>>>> >>>>> A possibility is making a rfc2307bis-compat.ldif instead that allows the >>>>> MAY of everything in rfc2307, but is based on rfc2307bis as the base. For >>>>> example, allowing "MAY description $ l $ o $ ou $ owner $ seeAlso $ >>>>> serialNumber" on ieee802Device and bootableDevice. That would make it >>>>> forward compatible, and actually quite seamless to upgrade. If we wanted >>>>> we could consider formalising it to a draft rfc given that's what >>>>> rfc2307bis is (a draft rfc). >>>>> >>>>> Thoughts? >>>> >>>> Sorry missed the end of the email ! >>>> Yes I think it is a good approach, deliver what we can that does not break >>>> existing deployment. >>>> For the remaining part of 2307bis we create a diagnostic/healthcheck tool >>>> that gives a go/no-go to apply a full 2307bis definition. I think that the compatibility I proposed wouldn't need an extra tool because both rfc2307 and rfc2307bis would be valid within it, so we could be supporting both in parallel. If anything I'd just need to code into my openldap migration tool to ignore the rfc2307 schema oids since we already have them in the compat. So, does drafting a rfc2307compat.ldif sound reasonable at this point? Do we think this is worth adding a draft rfc online as well, or is this something that really only affects us? If it's only us (i suspect it is ...) then I can also write a corresponding doc on the wiki. — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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.fedoraproject.org
