[389-devel] 389 DS nightly 2020-03-04 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/03/04/report-389-ds-base-1.4.3.3-20200304gitc013a02.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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] Re: Thoughts on swapping to rfc2307bis.ldif by default
> On 4 Mar 2020, at 00:26, thierry bordaz 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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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] please review: PR 50929 - Unable to create a suffix with countryName in CLI/UI
https://pagure.io/389-ds-base/pull-request/50929 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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] Re: Thoughts on swapping to rfc2307bis.ldif by default
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 wrote: On 3 Mar 2020, at 04:32, thierry bordaz 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 $
[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 wrote: On 3 Mar 2020, at 04:32, thierry bordaz 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
[389-devel] Re: Thoughts on swapping to rfc2307bis.ldif by default
Hi, I have no expertise in this area, but would like to get also Alexander's opinion and view from IPA 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 wrote: On 3 Mar 2020, at 04:32, thierry bordaz 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
[389-devel] Re: Thoughts on swapping to rfc2307bis.ldif by default
On 3/3/20 4:12 AM, William Brown wrote: On 3 Mar 2020, at 11:18, William Brown wrote: On 3 Mar 2020, at 04:32, thierry bordaz 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
[389-devel] Re: Thoughts on swapping to rfc2307bis.ldif by default
On 3/3/20 4:12 AM, William Brown wrote: On 3 Mar 2020, at 11:18, William Brown wrote: On 3 Mar 2020, at 04:32, thierry bordaz 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 I have a doubt on this new definition that changes the syntax/MR for directoryString to IA5. directoryString are 8bits (UTF-8) while IA5 7bits. So it may exists entries with gecos values that look incompatible with MR. It is the same for ipNetmaskNumber and macAdress -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 So we may have ipHost entries with 'o'/'ou'... that will not conform the schema 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 Does it mean iee802Device/bootableDevice (containing 'cn') will not conform the schema ? nisMap: +OID 1.3.6.1.1.1.2.9 -OID 1.3.6.1.1.1.2.13 I do not recall if we are using OID in table lookup but it could be a problem. Not sure that the replicated new definition will or not collide with the old one + 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
