Re: Thoughts on swapping to rfc2307bis.ldif by default

[thierry bordaz <tbordaz@xxxxxxxxxx>]

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.

regards
thierry
> > 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@xxxxxxx> wrote:
> > > > >
> > > > >
> > > > >
> > > > > > On 3 Mar 2020, at 04:32, thierry bordaz <tbordaz@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> > > > > > > To unsubscribe send an email to 
> > > > > > > 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > > > > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
> > > > > > _______________________________________________
> > > > > > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> > > > > > To unsubscribe send an email to 
> > > > > > 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > > > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
> > > > > —
> > > > > Sincerely,
> > > > >
> > > > > William Brown
> > > > >
> > > > > Senior Software Engineer, 389 Directory Server
> > > > > SUSE Labs
> > > > > _______________________________________________
> > > > > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> > > > > To unsubscribe send an email to 
> > > > > 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
> > > > —
> > > > Sincerely,
> > > >
> > > > William Brown
> > > >
> > > > Senior Software Engineer, 389 Directory Server
> > > > SUSE Labs
> > > > _______________________________________________
> > > > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> > > > To unsubscribe send an email to 
> > > > 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
> > > _______________________________________________
> > > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> > > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > > 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@xxxxxxxxxxxxxxxxxxxxxxx
> >
> > --
> > 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx