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

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