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?
paul
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/ht... 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@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?
paul
-- Paul Engle Office of Information Technology pengle@rice.edu 713-348-4702 _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
On 18 Jun 2019, at 21:19, Marc Sauton msauton@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/ht... 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@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 pengle@rice.edu 713-348-4702 _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
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 19 Jun 2019, at 15:41, Paul Engle pengle@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 pengle@rice.edu 713-348-4702
On Wed, Jun 19, 2019 at 2:28 AM William Brown wbrown@suse.de wrote:
On 18 Jun 2019, at 21:19, Marc Sauton msauton@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/ht... 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@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 pengle@rice.edu 713-348-4702 _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
389-users@lists.fedoraproject.org
-
Marc Sauton -
Paul Engle -
William Brown