Introduced by https://pagure.io/389-ds-base/issue/51115

Looks there there are many duplicate definitions in freeipa's samba.ldif and DS's samba3.ldif

From freeipa:

install/share/60samba.ldif:objectClasses: ( 1.3.6.1.4.1.7165.2.2.10 NAME 'sambaConfig' SUP top AUXILIARY DESC 'Samba Configuration Section' MAY ( description ) )
install/share/60samba.ldif:objectClasses: ( 1.3.6.1.4.1.7165.2.2.12 NAME 'sambaConfigOption' SUP top STRUCTURAL DESC 'Samba Configuration Option' MUST ( sambaOptionName ) MAY ( sambaBoolOption $ sambaIntegerOption $ sambaStringOption $ sambaStringListOption $ description ) )
...
...

The problem is 389-ds OID for 'sambaConfig' is 1.3.6.1.4.1.7165.1.2.2.10, while freeipa '60samba.ldif' delivers the same definition with 1.3.6.1.4.1.7165.2.2.10

It looks there is a typo in freeipa 60samba.ldif as the valid OID for 'sambaConfig' is https://ldapwiki.com/wiki/1.3.6.1.4.1.7165.1.2.2.10

I think 389-ds version is incorrect. The canonical source is what is in Samba: https://git.samba.org/?p=samba.git;a=tree;f=examples/LDAP;hb=HEAD

The task is not easy though because there are multiple sources there ;) But at least with regards to sambaConfig they all agree on what is in FreeIPA except NDS schema:

$ git grep sambaConfig examples/LDAP/
examples/LDAP/samba-nds.schema:objectClasses: ( 1.3.6.1.4.1.7165.1.2.2.10 NAME 'sambaConfig' DESC 'Samba Configuration Section' SUP top AUXILIARY MAY ( description ))
examples/LDAP/samba-nds.schema:objectClasses: ( 1.3.6.1.4.1.7165.2.2.12 NAME 'sambaConfigOption' DESC 'Samba Configuration Option' SUP top STRUCTURAL MUST ( sambaOptionName ) MAY ( sambaBoolOption $ sambaIntegerOption $ sambaStringOption $ sambaStringListoption $ description ))
examples/LDAP/samba-schema-FDS.ldif:objectClasses: ( 1.3.6.1.4.1.7165.2.2.10 NAME 'sambaConfig' SUP top AUXILIARY DESC 'Samba Configuration Section' MAY ( description ) )
examples/LDAP/samba-schema-FDS.ldif:objectClasses: ( 1.3.6.1.4.1.7165.2.2.12 NAME 'sambaConfigOption' SUP top STRUCTURAL DESC 'Samba Configuration Option' MUST ( sambaOptionName ) MAY ( sambaBoolOption $ sambaIntegerOption $ sambaStringOption $ sambaStringListoption $ description ) )
examples/LDAP/samba.ldif:olcObjectClasses: {8}( 1.3.6.1.4.1.7165.2.2.10 NAME 'sambaConfig' DESC 'Samba 
examples/LDAP/samba.ldif:olcObjectClasses: {10}( 1.3.6.1.4.1.7165.2.2.12 NAME 'sambaConfigOption' DESC 
examples/LDAP/samba.schema:objectclass ( 1.3.6.1.4.1.7165.2.2.10 NAME 'sambaConfig' SUP top AUXILIARY
examples/LDAP/samba.schema:objectclass ( 1.3.6.1.4.1.7165.2.2.12 NAME 'sambaConfigOption' SUP top STRUCTURAL
examples/LDAP/samba.schema.oc.IBM-DS:objectclasses=( 1.3.6.1.4.1.7165.2.2.10 NAME 'sambaConfig' SUP top AUXILIARY DESC 'Samba Configuration Section' MAY ( description ) )
examples/LDAP/samba.schema.oc.IBM-DS:objectclasses=( 1.3.6.1.4.1.7165.2.2.12 NAME 'sambaConfigOption' SUP top STRUCTURAL DESC 'Samba Configuration Option' MUST ( sambaOptionName ) MAY ( sambaBoolOption $ sambaIntegerOption $ sambaStringOption $ sambaStringListoption $ description ) )

@abbra, looking like samba-nds.schema contains the 389-ds OID, while samba.ldif contains freeipa one. Do you know what 'nds' stands for ?

nds == Netscape Directory Server

I'd say that because it is the only outlier, it might be wrong one. ;)

@abbra I'm not sure if this would work for IPA, but what if DS takes ownership of your samba schema file (then we would drop ours in favor of IPA's). @firstyear would that a problem for what you were trying to accomplish?

@mreynolds Sounds fine by me. Can you send me the schema file they are using or a link to it?

@firstyear IPA's location for the schema file is https://pagure.io/freeipa/blob/master/f/install/share/60samba.ldif

Once 389-ds with the change is released and is in Fedora updates, we can remove it from IPA. Right now we copy 60samba.ldif unconditionally to the instance schema directory.

The only difference between freeipa 60samba.ldif and 389-ds 60samba3.ldif (default schema) is 'sambaConfig' OID.

Changing the OID in 60samba3.ldif to 1.3.6.1.4.1.7165.2.2.10 looks to be the only required change. @abbra any concern if we keep the file name 60samba3.ldif rather than 60samba.ldif ?

It sounds like the fix is "freeipa needs to remove their 60samba.ldif" and then everything would just work. especially because freeipa will be putting 60samba.ldif in their /etc/dirsrv/slapd-inst/schema dir, it's up to them to resolve that if they want us to manage the 60samba3.ldif schema instead.

Also the OID doesn't matter, because nothing really uses oids except to check that attributes are somewhat unique in schema.

It sounds like the fix is "freeipa needs to remove their 60samba.ldif" and then everything would just work. especially because freeipa will be putting 60samba.ldif in their /etc/dirsrv/slapd-inst/schema dir, it's up to them to resolve that if they want us to manage the 60samba3.ldif schema instead.
Also the OID doesn't matter, because nothing really uses oids except to check that attributes are somewhat unique in schema.

Correct, yeah we don't need to swap anything. FreeIPA just needs to drop that file from their installation.

The next question, are there more schema files that should be moved from IPA into DS?

IMO all of them, because it would make upgrades easier, and prevent basically every schema replication problem, and let us test the schema's are always compatible all the time. But then they'd have to work with us to make changes to them. So that's a question for IPA tbh.

Samba schema is not really used by FreeIPA and was included probably when we thought still rely on it before it became clear it is not fitting the needs (that was before I came on board). When ipasam PASSDB backend for Samba was added to FreeIPA in October 2011, it already used FreeIPA-specific LDAP schema and not the Samba schema.

We have, however, quite some community of FreeIPA users who actually rely on the Samba schema in their deployments. So having proper classes and attributes available would be good. Once you fix 60samba3.ldif and make sure it is installed by default, we can remove it from IPA and make a dependency to the new 389-ds release, as I said already.

I'm kind of a maintainer for pdb_ldap and LDAP schema in Samba these days (apparently ;)), so as long as there is no discrepancy with Samba project's version of the schema, we should be OK. Having the schema in 389-ds installed by default would allow me to add a simple test to ensure pdb_ldap continues to work against 389-ds. I'll fix the NDS schema file upstream.

I don't understand why IPA-specific schema files should be moved to 389-ds as a whole. We do maintain our OIDs ourselves, update the schema definitions over time and so on. Why they should be moved to the project which doesn't use them and doesn't maintain them? It seems to be a stretch.

Having a commit gating CI test that makes sure new commits do not introduce issues with a distribution-provided version of FreeIPA might be a better solution to ensure compatibility. This would catch other issues too.

If you have concrete examples of FreeIPA-installed schema files that are duplicates with default installed 389-ds schema, then please open a separate ticket to FreeIPA to handle that.

The OID are important because of replication, there is always a risk to fail to propagate the schema in the topology. 389-ds needs to fix sambaConfig in 60samba3.ldif with the correct OID (1.3.6.1.4.1.7165.2.2.10).

It would be better if freeipa abandon the delivery of 60samba.ldif but as long as it is compatible with 60samba3.ldif there should not be any issue if it is present.

Commit c6405714 relates to this ticket

@abbra I fully agree we don't need IPA's custom schema in DS, I was just curious if there were non-specific IPA schema files we should take over. I just don't want to keep running into similar issues as the openldap migration work continues.

I changed the OID in our schema right now, and it does ship by default. @abbra when you are ready I can do a new upstream build for F33

I don't understand why IPA-specific schema files should be moved to 389-ds as a whole. We do maintain our OIDs ourselves, update the schema definitions over time and so on. Why they should be moved to the project which doesn't use them and doesn't maintain them? It seems to be a stretch.

Because on upgrade we add the schema straight into /usr/schema, it get's tested with every 389-ds build. Schema is there, it works, everything is happy. Even modifying a schema, a simple "dnf/zypper upgrade" and you get the new schemas, no need for upgrade tooling. It just works. We would find issues and conflicts faster as an upstream if we make changes. We can even backport the new files to older releases for compatibility if needed.

Where as with freeipa, you have a routine of needing to add custom schema on an install (/etc/dirsrv/slapd-inst/schema), wait for it to replicate, you need to then manage all your schema files on disk every upgrade and more. You have to handle inplace upgrades by checking things in those files. By putting the ipa schema in 389-ds, you never need to think about or see a single schema step again in your installer or upgrade, because then it's up to us to manage that, and our infra to manage that is much simpler because we own the rpm.

That's why ipa schema in 389-ds is a good idea, because it means you can literally delete a stack of schema management code from freeipa, and then /etc/dirsrv/slapd-inst/schema/ really does become "custom user schema" rather than a hybrid "ipa schema and custom user stuff"

Going beyond that, it means that 389-ds is able to import ipa databases and do tests with that data, we can begin to reproduce issues in isolated and targeted ways that we couldn't before.

I understand what you are trying to say for a common schema.

Given that 389-ds does not do any automated testing of pull requests against FreeIPA, moving core IPA schema to 389-ds does not make any sense to me.

Can you please explain me why should we put the schema for FreeIPA OIDs in 389-ds? I do not understand that -- we own our schema and we control what is added there. If you add something that overlaps with IPA own schema, this means you are doing it on a purpose and it is not a nice thing to do without coordination anyway.

I think I made my case around upgrade simplicity and coordination, but otherwise, it's not my problem and I don't care enough to really pursue/argue for it. Closing now as the main issue is resolved.

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 issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/4208

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.