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

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.

regards
thierry
>
>>
>> Regards,
>> Ludwig
>>
>> On 03/03/2020 10:17 AM, thierry bordaz wrote:
>>>
>>>
>>> On 3/3/20 4:12 AM, William Brown wrote:
>>>>
>>>>> On 3 Mar 2020, at 11:18, William Brown <wbrown@suse.de> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 3 Mar 2020, at 04:32, thierry bordaz <tbordaz@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.
>>>> I need to apologise for being so short in this answer! Thierry was
>>>> correct in this case.
>>>>
>>>> Here is the full set of differences between the two:
>>>>
>>>> uidNumber: +EQUALITY integerMatch
>>>> gidNumber: +EQUALITY integerMatch
>>>> gecos: +EQUALITY caseIgnoreIA5Match SUBSTR
>>>> caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
>>>> -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>>>> homeDirectory: +EQUALITY caseExactIA5Match
>>>> loginShell: +EQUALITY caseExactIA5Match
>>>> shadowLastChange: +EQUALITY integerMatch
>>>> shadowMin: +EQUALITY integerMatch
>>>> shadowMax: +EQUALITY integerMatch
>>>> shadowWarning: +EQUALITY integerMatch
>>>> shadowInactive: +EQUALITY integerMatch
>>>> shadowExpire: +EQUALITY integerMatch
>>>> shadowFlag: +EQUALITY integerMatch
>>>> memberUid: +EQUALITY caseExactIA5Match
>>>> memberNisNetgroup: +EQUALITY caseExactIA5Match SUBSTR
>>>> caseExactIA5SubstringsMatch
>>>> nisNetgroupTriple: +EQUALITY caseIgnoreIA5Match
>>>> ipServicePort: +EQUALITY integerMatch
>>>> ipServiceProtocol: +SUP name -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>>>> ipProtocolNumber: +EQUALITY integerMatch
>>>> oncRpcNumber: +EQUALITY integerMatch
>>>> ipHostNumber: +SUP name -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>>>> ipNetworkNumber: +SUP name -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>>>> ipNetmaskNumber: +EQUALITY caseIgnoreIA5Match SYNTAX
>>>> 1.3.6.1.4.1.1466.115.121.1.26 -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>>>> macAddress: +EQUALITY caseIgnoreIA5Match SYNTAX
>>>> 1.3.6.1.4.1.1466.115.121.1.26 -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>>>> bootParameter: +EQUALITY caseExactIA5Match
>>>> nisMapName: +SUP name -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>>>> nisMapEntry: +EQUALITY caseExactIA5Match SUBSTR
>>>> caseExactIA5SubstringsMatch
>>>>
>>>> + attributeTypes: ( 1.3.6.1.1.1.1.28 NAME 'nisPublicKey' DESC 'NIS
>>>> public key' EQUALITY octetStringMatch SYNTAX
>>>> 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
>>>> + attributeTypes: ( 1.3.6.1.1.1.1.29 NAME 'nisSecretKey' DESC 'NIS
>>>> secret key' EQUALITY octetStringMatch SYNTAX
>>>> 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
>>>> + attributeTypes: ( 1.3.6.1.1.1.1.30 NAME 'nisDomain' DESC 'NIS
>>>> domain' EQUALITY caseIgnoreIA5Match SYNTAX
>>>> 1.3.6.1.4.1.1466.115.121.1.26 )
>>>> + attributeTypes: ( 1.3.6.1.1.1.1.31 NAME 'automountMapName' DESC
>>>> 'automount Map Name' EQUALITY caseExactIA5Match SUBSTR
>>>> caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
>>>> SINGLE-VALUE )
>>>> + attributeTypes: ( 1.3.6.1.1.1.1.32 NAME 'automountKey' DESC
>>>> 'Automount Key value' EQUALITY caseExactIA5Match SUBSTR
>>>> caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
>>>> SINGLE-VALUE )
>>>> + attributeTypes: ( 1.3.6.1.1.1.1.33 NAME 'automountInformation'
>>>> DESC 'Automount information' EQUALITY caseExactIA5Match SUBSTR
>>>> caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
>>>> SINGLE-VALUE )
>>>>
>>>> posixAccount:
>>>> shadowAccount:
>>>> posixGroup: +AUXILLARY -MUST cn STRUCTURAL
>>>> ipService:
>>>> ipProtocol:
>>>> oncRpc:
>>>> ipHost: - MAY o $ ou $ owner $ seeAlso $ serialNumber +MAY
>>>> userPassword
>>>> ipNetwork: -MUST cn +MAY cn
>>>> nisNetgroup:
>>>> nisMap:
>>>> nisObject:
>>>> ieee802Device: -MUST cn MAY description $ l $ o $ ou $ owner $
>>>> seeAlso $ serialNumber
>>>> bootableDevice: -MUST cn MAY description $ l $ o $ ou $ owner $
>>>> seeAlso $ serialNumber
>>>> nisMap: +OID 1.3.6.1.1.1.2.9 -OID 1.3.6.1.1.1.2.13
>>>>
>>>> + objectClasses: ( 1.3.6.1.1.1.2.14 NAME 'nisKeyObject' SUP top
>>>> AUXILIARY DESC 'An object with a public and secret key' MUST ( cn $
>>>> nisPublicKey $ nisSecretKey ) MAY ( uidNumber $ description ) )
>>>> + objectClasses: ( 1.3.6.1.1.1.2.15 NAME 'nisDomainObject' SUP top
>>>> AUXILIARY DESC 'Associates a NIS domain with a naming context' MUST
>>>> nisDomain )
>>>> + objectClasses: ( 1.3.6.1.1.1.2.16 NAME 'automountMap' SUP top
>>>> STRUCTURAL MUST ( automountMapName ) MAY description )
>>>> + objectClasses: ( 1.3.6.1.1.1.2.17 NAME 'automount' SUP top
>>>> STRUCTURAL DESC 'Automount information' MUST ( automountKey $
>>>> automountInformation ) MAY description ) ## namedObject is needed
>>>> for groups without members
>>>> + objectClasses: ( 1.3.6.1.4.1.5322.13.1.1 NAME 'namedObject' SUP
>>>> top STRUCTURAL MAY cn )
>>>>
>>>>
>>>>
>>>>>>> * 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.
>>>> Looking at the differences above, while we don't have to worry
>>>> about the structural changes, I'm concerned about some of the
>>>> reductions in some values MAY/MUST sets. That could cause some
>>>> unexpected behaviour.
>>>>
>>>> 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.
>>>>>>> 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@lists.fedoraproject.org
>>>>>>> To unsubscribe send an email to
>>>>>>> 389-devel-leave@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
>>>>>> _______________________________________________
>>>>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>>>>>> To unsubscribe send an email to
>>>>>> 389-devel-leave@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
>>>>> —
>>>>> 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-leave@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
>>>> —
>>>> 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-leave@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
>>> _______________________________________________
>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-devel-leave@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
>>
>> --
>> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
>> Handelsregister: Amtsgericht München, HRB 153243,
>> Geschäftsführer: Charles Cachera, Laurie Krebs, Michael O'Neill,
>> Thomas Savage
>>
>
>
>
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@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