search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
211 stars 93 forks source link

rfc2307 and rfc2307bis compat schema #3986

Closed 389-ds-bot closed 4 years ago

389-ds-bot commented 4 years ago

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/50933

Issue Description

rfc2307 is the original schema for posix and other related attributes. rfc2307bis was a draft propsed by a member of the openldap team that fixed a number of deficiencies in rfc2307. However, rfc2307bis is not completely forward compatible - replacing them may introduce possible data errors or other subtle issues.

In the interest of allowing easier openldap to 389 migrations ( https://pagure.io/389-ds-base/issue/50544 ) I propose a rfc2307compat, which is a forward compatible version combining rfc2307 and rfc2307bis. This would allow items from both to be considered "valid' without changing the semantics of either.

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-08-12 02:31:30

The problem with allowing dup OIDS is that all versions need to ignore OID duplicates. This is hard to enforce in a replicated env, and replication can not unexpectedly break after updating a package. Instead, since OID's don't really do anything, why don't we make them (the OIDs) the same in DS (in both files), then this problem just goes away. Why do the OID's have to be different? Am I missing something?

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2020-08-12 03:08:13

The problem with allowing dup OIDS is that all versions need to ignore OID duplicates. This is hard to enforce in a replicated env, and replication can not unexpectedly break after updating a package. Instead, since OID's don't really do anything, why don't we make them (the OIDs) the same in DS (in both files), then this problem just goes away. Why do the OID's have to be different? Am I missing something?

It's not about allowing duplicate oids, it's about where names diverge from the associated oids. So my suggestion and thierry's diff are about using the name/aliases as the primary key for schema, rather than oid + name. AKA an attribute or classes, OID can change, and we don't care.

OID duplication would still be forbidden though.

I think I'm just a bit nervous that even if we fix up the oid's in 60nis.ldif, that we'll still hit some error somewher, like someone who has included 60nis.ldif in their /etc/dirsrv/slapd/schema/ dir where we can touch it or fix it.

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2020-08-12 03:35:59

I think the other question would be what happens if we learn some attribute X via replication, and that has a different oid to the system schema directory?

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2020-08-12 03:48:53

I think after a bit of thought that @mreynolds389 suggestion to change the oids in 60nis.ldif is the one to go with, because:

But I would like to hear @tbordaz's thoughts first :)

389-ds-bot commented 4 years ago

Comment from tbordaz (@tbordaz) at 2020-08-12 14:50:03

My understanding is that nisMap in 60nis.ldif contains an invalid OID. IMHO it should be fix and the risk is limited as it is a 'data' schema.

The problem is that IPA used a former defintion of nisMap with invalid OID also. So introducing nisMap in rfc2307compat (standard schema) break IPA deployement. I am correct ? DO we really need to deliver nis definitions in rfc2307compat ?

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-08-12 18:50:31

Commit 5afcbb0d fixes this issue

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2020-08-17 02:29:50

Thanks @mreynolds389 I appreciate the change you made here. I think that @tbordaz makes a good point here that a simpler solution could just be to put 60nis.ldif back into data rather than the default schema too if it remains an issue.

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2020-08-17 02:29:50

Metadata Update from @Firstyear:

mreynolds389 commented 3 years ago

Pushed these commits to 1.4.3

commit 3d9ced9e340678cc02b1a36c2139492c95ef15a6 commit 826a1bb4ea88915ac492828d1cc4a901623f7866

mreynolds389 commented 3 years ago

Found an issue with UI and the new compat schema file (it does not have x-origins set which is breaking the UI). There is nothing wrong with this, but the UI needs to handle that condition. Using this ticket to track that fix.

mreynolds389 commented 3 years ago

Fix UI schema page crash

c87084de6..d6f730608 master -> master 54c9db06f..2dd89149d 389-ds-base-1.4.4 -> 389-ds-base-1.4.4 a9f53e995..ec347edde 389-ds-base-1.4.3 -> 389-ds-base-1.4.3 f7bfc9a96..51d3a85c2 389-ds-base-1.4.2 -> 389-ds-base-1.4.2