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(a)suse.de> wrote:
>>>
>>>
>>>
>>>>On 3 Mar 2020, at 04:32, thierry bordaz <tbordaz(a)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(a)lists.fedoraproject.org
>>>>>To unsubscribe send an email to
>>>>>389-devel-leave(a)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.fedoraproje...
>>>>_______________________________________________
>>>>389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>>>>To unsubscribe send an email to
>>>>389-devel-leave(a)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.fedoraproje...
>>>—
>>>Sincerely,
>>>
>>>William Brown
>>>
>>>Senior Software Engineer, 389 Directory Server
>>>SUSE Labs
>>>_______________________________________________
>>>389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>>>To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
>>—
>>Sincerely,
>>
>>William Brown
>>
>>Senior Software Engineer, 389 Directory Server
>>SUSE Labs
>>_______________________________________________
>>389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>>To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
>_______________________________________________
>389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
--
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