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