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

Hi,

I have no expertise in this area, but would like to get also Alexander's
opinion and view from IPA

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