> On 4 Mar 2020, at 10:31, William Brown <[email protected]> wrote: > > > >> On 4 Mar 2020, at 00:26, thierry bordaz <[email protected]> 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.
https://pagure.io/389-ds-base/pull-request/50934 This is a PR of the compat schema. I can also provide supporting docs on the wiki if desired. > > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
