> On 19 Jun 2019, at 15:41, Paul Engle <pen...@rice.edu> wrote: > > Both files are in the distribution: > > /usr/share/dirsrv/schema/10rfc2307.ldif > /usr/share/dirsrv/data/10rfc2307bis.ldif > > The primary incompatibility is that the former has 'nisMap' as OID > 1.3.6.1.1.1.2.13 and the latter has it as 1.3.6.1.1.1.2.9. > Conveniently, both files have a gap where the other one's OID is, so there is > no actual OID conflict with another objectclass. It's just that this one > moves, so trying to load both results in two OIDs for the same objectclass. > > There are some other differences in syntax declarations and one objectclass > (posixGroup) that flips from structural to auxiliary in 2307bis.
Indeed - this does present a problem. Especially because on an upgrade, the file will keep being "re-added" to the system schema directory. As a result I have opened the following issue. https://pagure.io/389-ds-base/issue/50457 > > -- > Paul Engle > Office of Information Technology > pen...@rice.edu > 713-348-4702 > > > On Wed, Jun 19, 2019 at 2:28 AM William Brown <wbr...@suse.de> wrote: > > > > On 18 Jun 2019, at 21:19, Marc Sauton <msau...@redhat.com> wrote: > > > > the RHDS-10 custom schema is in /etc/dirsrv/slapd-*/schema/99user.ldif > > while the "core" schema files have now been located in > > /usr/share/dirsrv/schema/ > > you can till use the /etc/dirsrv/slapd-instance_name/schema/ directory , > > but see the caveat in the online doc at: > > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/extending_the_directory_schema#default-schema > > 12.1.5. Schema Replication > > " > > Schema files other than /etc/dirsrv/slapd-instance_name/schema/99user.ldif > > are used. > > Directory Server enables you to add additional schema files in the > > /etc/dirsrv/slapd-instance_name/schema/ directory. However, only the CSN in > > the 99user.ldif file is updated. For this reasons, other schema file are > > only used locally and are not automatically transferred to replication > > partners. Copy the updated schema file manually to the consumers and reload > > the schema. For details, see Section 12.7, “Dynamically Reloading Schema”. > > " > > > > that may be confusing when used to the previous schema files and location, > > and the reasons are documented in the upstream ticket: > > https://pagure.io/389-ds-base/issue/48163 / If /etc/dirsrv/schema is > > version-specific, it should not live in /etc > > > > > > On Tue, Jun 18, 2019 at 11:42 AM Paul Engle <pen...@rice.edu> wrote: > > > > All, > > Specifically, I'm referring to the two incompatible schemas for rfc2307 > > vs rfc2307bis. In the past, it was possible to just delete 10rfc2307.ldif > > from /etc/dirsrv/<instance>/schema and replace it with the file supplied > > from /usr/share/dirsrv/data/10rfc2307bis.ldif. > > > > Now, with the new directory layout in 1.3.8.4, there is nothing to delete > > in /etc/dirsrv/<instance>/schema. And since the two schemas are > > incompatible, I can't load the other one by dropping it in there. > > > > It seems the only thing I'm able to do is remove > > /usr/share/dirsrv/schema/10rfc2307.ldif to get the other file to load. > > That's global for all instances on the server, though. Is there any way to > > make this change for just one instance? > > Hi there, > > Are they incompatible because they re-use the same names or OIDS? Would you > mind sending a copy of the schema file you plan to use so that I can examine > it? > > Thanks, > > > > > > > paul > > > > -- > > Paul Engle > > Office of Information Technology > > pen...@rice.edu > > 713-348-4702 > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > 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-users@lists.fedoraproject.org > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > 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-users@lists.fedoraproject.org > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > 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-users@lists.fedoraproject.org > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > 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-users@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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-users@lists.fedoraproject.org
