> 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
