On 3 Mar 2020, at 04:32, thierry bordaz <tbordaz(a)redhat.com&gt; 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 ?

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

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

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.

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

> On 3 Mar 2020, at 11:18, William Brown <wbrown(a)suse.de&gt; wrote: > > > >> On 3 Mar 2020, at 04:32, thierry bordaz <tbordaz(a)redhat.com&gt; 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? >>> 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...

On 3/3/20 4:12 AM, William Brown wrote: > >> On 3 Mar 2020, at 11:18, William Brown <wbrown(a)suse.de&gt; wrote: >> >> >> >>> On 3 Mar 2020, at 04:32, thierry bordaz <tbordaz(a)redhat.com&gt; 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...

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(a)suse.de&gt; wrote: >>>> >>>> >>>> >>>>> On 3 Mar 2020, at 04:32, thierry bordaz <tbordaz(a)redhat.com&gt; 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 >

On 4 Mar 2020, at 10:31, William Brown <wbrown(a)suse.de&gt; wrote: > On 4 Mar 2020, at 00:26, thierry bordaz <tbordaz(a)redhat.com&gt; 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.

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