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

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?

>
>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
>



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
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