Bug 1759941

Summary: Schema replication inconsistency with "user defined" appended to core schema definitions on consumer
Product: Red Hat Enterprise Linux 9 Reporter: Ming Davies <minyu>
Component: 389-ds-baseAssignee: mreynolds
Status: CLOSED ERRATA QA Contact: LDAP QA Team <idm-ds-qe-bugs>
Severity: unspecified Docs Contact: Evgenia Martynyuk <emartyny>
Priority: medium    
Version: 9.1CC: abobrov, bsmejkal, emartyny, gfialova, idm-ds-dev-bugs, mreynolds, msauton, nkinder, pasik, sgouvern, spichugi, tbordaz, tmihinto, vashirov
Target Milestone: rcKeywords: TestCaseNeeded, Triaged
Target Release: 9.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-2.3.4-2.el9 Doc Type: Bug Fix
Doc Text:
.Schema replication now works correctly in Directory Server Previously, when Directory Server replicated a schema to a new server, it added all the schema to the `99user.ldif` file on the remote replica. It seemed it was all custom schema because `X-ORIGIN` keyword was set to `user defined` for all definitions. As a result, it could cause issues with the web console and possibly for customers who monitor the schema and expect the `X-ORIGIN` keyword to have specific values. With this update, schema replication works as expected.
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-11-07 08:25:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Deadline: 2023-09-25   

Description Ming Davies 2019-10-09 13:06:54 UTC
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:

Comment 1 mreynolds 2019-10-09 13:15:25 UTC
What version of Directory Server is this?  This sounds like a known bug that was already fixed.

Comment 3 Viktor Ashirov 2019-10-09 13:21:13 UTC
sosreport shows 389-ds-base-1.3.9.1-10.el7.x86_64

Comment 5 mreynolds 2020-02-06 19:31:36 UTC
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.

Comment 15 mreynolds 2023-03-20 13:25:19 UTC
Upstream ticket:

https://github.com/389ds/389-ds-base/issues/1081

Comment 16 mreynolds 2023-03-22 13:10:38 UTC
Fixed upstream.

Comment 17 bsmejkal 2023-07-14 09:34:38 UTC
============================================================================================================ 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) =================================================================================================

Comment 20 bsmejkal 2023-07-14 10:13:44 UTC
As per comment #c17 marking as VERIFIED.

Comment 25 errata-xmlrpc 2023-11-07 08:25:17 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (389-ds-base bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6350