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.
On Wed, Jun 19, 2019 at 2:28 AM William Brown <wbrown@xxxxxxx> wrote:
> On 18 Jun 2019, at 21:19, Marc Sauton <msauton@xxxxxxxxxx> 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 <pengle@xxxxxxxx> 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
> pengle@xxxxxxxx
> 713-348-4702
> _______________________________________________
> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> _______________________________________________
> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
