Description of problem: In a MMR scenario, we are seeing that "cn=schema" tree is replicated, however the core schema definitions on the consumer has "user defined" append to them. As an example: inst1: objectClasses: ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL MUST cn MAY ( uniqueMember $ businessCategory $ seeAlso $ owner $ ou $ o $ descripti on ) X-ORIGIN 'RFC 4519' ) inst2: objectClasses: ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL MUST cn MAY ( uniqueMember $ businessCategory $ seeAlso $ owner $ ou $ o $ descripti on ) X-ORIGIN ( 'RFC 4519' 'user defined' ) ) Same applies for the attributetypes: inst1: attributeTypes: ( 2.16.840.1.113730.3.1.604 NAME 'parentid' DESC 'internal ser ver defined attribute type' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115 .121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) inst2: attributeTypes: ( 2.16.840.1.113730.3.1.604 NAME 'parentid' DESC 'internal ser ver defined attribute type' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115 .121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN 'user defined' ) Version-Release number of selected component (if applicable): How reproducible: The issue can easily be reproduced. Steps to Reproduce: 1. Create two instances that replicate to each other 2. Create a customized attribute and objectclass via ldapmodify 3. Create a new entry using the customized attribute and objectclass created in the step3. <<<The schema replication starts when directory content is updated in the replicated tree, hence the step. 4. Dump out the cn=schema from the two instances respectively: #ldapsearch -h <DS hostname.FQDN> -p <port> -D "cn=directory manager" -W \ -b "cn=schema" "(objectclass=*)" objectClasses # ldapsearch -h <DS hostname.FQDN> -p <port> -D "cn=directory manager" -W \ -b "cn=schema" "(objectclass=*)" attributeTypes Actual results: This gives misleading impression that there is an inconsistency when replicating the "cn=schema" tree. Expected results: Additional info:
What version of Directory Server is this? This sounds like a known bug that was already fixed.
sosreport shows 389-ds-base-1.3.9.1-10.el7.x86_64
This is a very sensitiveness area of code, and nothing is technically broken. It is just too risky to try and get this into a maintenance release. We are going to have to move this bug to RHEL 8.
Upstream ticket: https://github.com/389ds/389-ds-base/issues/1081
Fixed upstream.
============================================================================================================ test session starts ============================================================================================================= platform linux -- Python 3.9.17, pytest-7.4.0, pluggy-0.13.1 -- /usr/bin/python3 cachedir: .pytest_cache metadata: {'Python': '3.9.17', 'Platform': 'Linux-5.14.0-333.el9.x86_64-x86_64-with-glibc2.34', 'Packages': {'pytest': '7.4.0', 'pluggy': '0.13.1'}, 'Plugins': {'metadata': '3.0.0', 'html': '3.2.0', 'libfaketime': '0.1.2', 'flaky': '3.7.0'}} 389-ds-base: 2.3.4-2.el9 nss: 3.79.0-18.el9_1 nspr: 4.34.0-18.el9_1 openldap: 2.6.3-1.el9 cyrus-sasl: 2.1.27-21.el9 FIPS: disabled rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests configfile: pytest.ini plugins: metadata-3.0.0, html-3.2.0, libfaketime-0.1.2, flaky-3.7.0 collected 9 items dirsrvtests/tests/suites/schema/schema_replication_test.py::test_schema_replication_one PASSED [ 11%] dirsrvtests/tests/suites/schema/schema_replication_test.py::test_schema_replication_two PASSED [ 22%] dirsrvtests/tests/suites/schema/schema_replication_test.py::test_schema_replication_three PASSED [ 33%] dirsrvtests/tests/suites/schema/schema_replication_test.py::test_schema_replication_four PASSED [ 44%] dirsrvtests/tests/suites/schema/schema_replication_test.py::test_schema_replication_five PASSED [ 55%] dirsrvtests/tests/suites/schema/schema_replication_test.py::test_schema_replication_six PASSED [ 66%] dirsrvtests/tests/suites/schema/schema_replication_test.py::test_schema_replication_seven PASSED [ 77%] dirsrvtests/tests/suites/schema/schema_replication_test.py::test_schema_replication_eight PASSED [ 88%] dirsrvtests/tests/suites/schema/schema_replication_test.py::test_schema_replication_nine PASSED [100%] ================================================================================================ 9 passed, 143 warnings in 133.63s (0:02:13) =================================================================================================
As per comment #c17 marking as VERIFIED.