389-ds-base

#50934 Ticket 50933 - rfc2307compat.ldif
Closed by spichugi. Opened by firstyear.
firstyear/389-ds-base 50933-rfc2307-compat  into  master

Download 50934.patch

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

Fix Description: This adds rfc2307compat.ldif, which is a forward compatabile
expression of both rfc2307 and rfc2307bis, with the knowledge that 389 ds
does not enforce structural/auxillary rules.

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

Author: William Brown william@blackhats.net.au

Review by: ???

 
> diff -u ldap/schema/10rfc2307bis.ldif ldap/schema/10rfc2307compat.ldif
--- ldap/schema/10rfc2307bis.ldif   2018-12-30 09:52:58.000000000 +1000
+++ ldap/schema/10rfc2307compat.ldif    2020-03-05 14:49:27.000000000 +1000
@@ -1,6 +1,6 @@
-# New and improved RFC 2307 schema (aka RFC 2307 bis)
+# New and improved RFC 2307 schema that is forward compatable between
+# rfc2307 and rfc2307bis (aka RFC 2307 compat)
 #      "An Approach for Using LDAP as a Network Information Service"
-# This schema has not yet been approved.
 #
 dn: cn=schema
 attributeTypes: (
@@ -241,9 +241,9 @@
   )
 objectClasses: (
   1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top AUXILIARY
-  DESC 'Abstraction of a group of accounts'
+  DESC 'Abstraction of a group of accounts - +MAY cn'
   MUST gidNumber
-  MAY ( userPassword $ memberUid $
+  MAY ( cn $ userPassword $ memberUid $
         description )
   )
 objectClasses: (
@@ -278,9 +278,10 @@
   1.3.6.1.1.1.2.6 NAME 'ipHost' SUP top AUXILIARY
   DESC 'Abstraction of a host, an IP device. The distinguished
         value of the cn attribute denotes the hosts canonical
-        name. Device SHOULD be used as a structural class'
+        name. Device SHOULD be used as a structural class.
+        +MAY o $ ou $ owner $ seeAlso $ serialNumber'
   MUST ( cn $ ipHostNumber )
-  MAY ( userPassword $ l $ description $ manager )
+  MAY ( userPassword $ l $ description $ manager $ o $ ou $ owner $ seeAlso $ serialNumber )
   )
 objectClasses: (
   1.3.6.1.1.1.2.7 NAME 'ipNetwork' SUP top STRUCTURAL
@@ -310,14 +311,16 @@
 objectClasses: (
   1.3.6.1.1.1.2.11 NAME 'ieee802Device' SUP top AUXILIARY
   DESC 'A device with a MAC address; device SHOULD be
-        used as a structural class'
-  MAY macAddress
+        used as a structural class. +MAY cn $ description $
+        l $ o $ ou $ owner $ seeAlso $ serialNumber'
+  MAY ( macAddress $ cn $ description $ l $ o $ ou $ owner $ seeAlso $ serialNumber )
   )
 objectClasses: (
   1.3.6.1.1.1.2.12 NAME 'bootableDevice' SUP top AUXILIARY
   DESC 'A device with boot parameters; device SHOULD be
-        used as a structural class'
-  MAY ( bootFile $ bootParameter )
+        used as a structural class. +MAY cn $ description $
+        l $ o $ ou $ owner $ seeAlso $ serialNumber'
+  MAY ( bootFile $ bootParameter $ cn $ description $ l $ o $ ou $ owner $ seeAlso $ serialNumber )
   )
 objectClasses: (
   1.3.6.1.1.1.2.14 NAME 'nisKeyObject' SUP top AUXILIARY

Is the '- +MAY cn' part an oversight or intended part of the description?

If that's intended, it is just a bit confusing as there is no explanation in the commit message about these markers.

They are intended in the description to indicate how this diverges from rfc2307bis, but since they caused confusion, I need to make that clearer!

rebased onto 97a23705e619d1e5f26dce76ba83fab08d99c8c9

Updated to improve clarity of the description.

gecos is not compatible. It is directoryString in 2307 and become IA5 in 2307bis. It should not be part of this compat file

I have a doubt with nisNetgroupTriple. It goes from IA5 syntax to caseIgnoreIA5Match.
I think it should be possible to have an entry with values like 'FOO' and 'foo', that were different and are equal now.

similar doubt (ipServiceProtocol). It goes to dirstring syntax to caseIgnore (inherited from name).
Wonder if 'FOO' and 'foo' values are now equal
Edited by tbordaz

same as above (ipHostNumber)

same as above (ipNetworkNumber)

Same as above (ipNetmaskNumber)

same as above (macAddress)

same as above (nisMapName)

This change worth a test that new posixGroup will be replicated.
In theory the new definition is a superset of the old one, so it should be replicated

Good spotting, I'll fix these syntaxes up. I think leaving them as directoryString may be safer since it's a broader set of characters.

Also some quick research shows that nisnetgroups ARE case sensitive so I don't know why they were made insensitive in rfc2307bis ....

Anyway, Ithink you are right about these, so I have cleaned this up after reviewing my own rfc2307 and rfc2307bis diff.

rebased onto 73e373eb4efcfdb419c929ed538597b2e34e3fb9

@tbordaz ping to review this :)

I still think there are problems for

ipServiceProtocol, ipHostNumber, ipNetworkNumber, nisMapName (dirstring exact case to dirstring ignore case (inherited from name)), could you specify matching syntax/MR )

ipNetmaskNumber, macAddress (dirstring exact case to IA5 ignore case could you specify the MR)

Honestly, I feel a bit silly with those, I swear you pointed them out before, and I remember fixing them but apparently not. :)

Please forgive me taking your precious time on silly mistakes!

HAHAHAH you know what I did ... I fixed them in 10rfc2307bis.ldif not 10rfc2307compat.ldif >.<

Time to check to make sure the commit is sane then ....

rebased onto 004e78ee4ec19f8b82de0776886764aa6de02fcd

Okay, thank you again @tbordaz for the review, and thanks for your patience - I have checked properly and I edited the correct file this time!

I think we should not specify caseIgnore (just remove equality MR).

idem as above.

Except definition eq=caseIgnoreIA5Match for ipNetmaskNumber and macAddress the rest of the patch looks good

No both of these are correct actually. The case ignore means we accept mac addresses of AA:BB:CC ... and aa:bb:cc as the same, so regardless of how they were input, they'll match properly. Similar with the ip addresses if you use hex notation of the ipaddress.

Yes with caseignore AA:BB:CC and aa:bb:cc are now equal with the patch. My concern is that they were not equal in the previous definition (dirstring). So the following entry was valid

cn: cn=foo,cn=hosts,<suffix>
...
macAddress: aa:bb:cc:
macAddress: AA:BB:CC:

But with caseignore, the entry will contain duplicate values

Not only duplicate values but changing the matching rule, I think normalization will change and then we need to reindex the attributes.

That's true. I think that it's unlikely people use these attributes anyway, so this behaviour has been known for a while, so I'll update that ldif.

rebased onto cfebef966cc03e731df95954d0e79ff209ef5b79

Thanks for the changes and your patience. ACK

rebased onto 0683bcde1b667b6d0ca6e8d1ef605f17c51ea2f7

Pull-Request has been merged by firstyear

One thing that was found by testing is that 389-ds now has two nisDomain definitions (in 60nis.ldif and in the new file) but they are using different OIDs. FreeIPA uses older 389-ds' OID for nisDomain since 2013. With this pull request merged, FreeIPA cannot be installed anymore:
https://bugzilla.redhat.com/show_bug.cgi?id=1820176

Errghhh of course there is some cursed extra nis schema that only freeipa uses that would conflict here.

So it looks like 60nis.ldif conflicts with 10rfc2307bis.ldif anyway, on nisPublicKey, nisSecretKey and nisDomain. Even better, they use different syntaxes (1.3.6.1.4.1.1466.115.121.1.26 caseinsensitive in 60nis.ldif vs 1.3.6.1.4.1.1466.115.121.1.40 from 2307bis. ). Thankfully the nisDomain types seem to agree at least (60nis.ldif adds a substr mr though). Even better, it appears that whoever made 10rfc2307bis.ldif and 60nis.ldif, well, there isn't an agreed set of oids, they just kept allocating in sequence from the original rfc2307. So there is no actual guidance on what the values should look like.

Right now, the only one of these two that looks "more" legitimate is rfc2307bis' definition, as it's actually associated to an rfc, and more widely used thanks to openldap - and openldap to 389-ds migration is what I care about.

So:

  • Does freeipa use nisPublickey or nisSecretkey or nisDomain?

My current suggested course of action:

  • remove nisPublicKey, nisSecretKey and nisDomain from 60nis.ldif
  • Add substr caseIgnoreIA5SubstringsMatch to nisDomain in 2307compat.ldif

This seems like the safest way to progress since on an rpm upgrade, we'll replace the content of 60nis.ldif and 2307compat.ldif so it should make the 389-ds upgrade process seamless. Most installs outside of freeipa won't be affected because they probably don't use 60nis.ldif anyway.

The other option is:

  • remove nisPublicKey, nisSecretKey and nisDomain from 10rfc2307bis.ldif
  • rename 60nis.ldif to 09nis.ldif
  • make 09nis.ldif a default system schema rather than a sample.

I don't like this option as much, it's a bit more invasive.

I think that regardless, freeipa will need to do some work or make changes to account for this regardless of what we choose, as I suspect you have copied 60nis.ldif to the /etc/dirsrv/slapd-instance/schema dir (perhaps in the future, symlinking that to the sample data would allow us to have safer upgrade options ....). So if we change 60nis.ldif, you need to account for that. If we rename it, you need to account for that. IMO you're best bet is the first option and to then change 60nis.ldif in your /etc schema dir to a symlink to the sample data.

Perhaps long term to prevent people using the /etc schema dir with our sample schema data so much, we should consider putting all system supplied schema in the main dir and making it always active, so that people don't have to copy the sample data or mess about with /etc schema unless it really is custom .....

I checked FreeIPA and there is no usage of nisSecretKey and nisPublicKey attributes. nisDomain is used in a single place at the base DN level.

FreeIPA does not install 60nis.ldif at all. Commit https://pagure.io/freeipa/c/1eec34393b8a7ccd420a7fa540462f5d8779977c?branch=master shows that this variant of 2307bis schema was merged to FreeIPA about the same time (month before) it was merged to Fedora Directory.

I looked around for any application that might be using nisDomain and haven't been able to find any. We use nisDomainName attribute in slapi-nis and many other places but that comes from IPA itself. autofs doesn't need nisDomain. SUDO doesn't need nisDomain.

So your first proposal would seem to work OK if it is not going to break replication. How can we ensure that?

On DS side, 60nis.ldif is buggy and needs to be fixed the way @firstyear recommended.
On Freeipa side the script RFC2307bis.update should be modified.

Regarding schema replication there is a risk that a definition of nisDomain with OID 1.3.6.1.4.1.1.1.1.12 land in 99user.ldif. In that case it will conflict with rfc2307compat and prevent DS restart. Options I can think of, move rfc2307compat to 'data', improve schema replication to check duplicate OID, document release note to do manual cleanup.

Currently master branch is broken for me. New instances fail to start because of this change.

We might need to revert this commit if it there is no speedy resolution...

In your dev environment, you need to remove 10rfc2307.ldif from schema in your installed dir IE rm /opt/dirsrv/share/dirsrv/schema/10rfc2307.ldif because the make install can't remove it for you. This won't affect RPM's because they get a clean build root, and the rpm well remove the file as it's not longer in the file list.

Ill look at and comment on the 60nis.ldif later :)

@mreynolds I'm going to submit a fix for the 60nis.ldif issue today, but like I said, remove the extra file. If it's still an issue, we can revert and then work out abetter plan. :)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3987

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.

Pull-Request has been closed by spichugi
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.