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@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
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
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
