RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1759941 - Schema replication inconsistency with "user defined" appended to core schema definitions on consumer
Summary: Schema replication inconsistency with "user defined" appended to core schema ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Deadline: 2023-09-25
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: 389-ds-base
Version: 9.1
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: 9.3
Assignee: mreynolds
QA Contact: LDAP QA Team
Evgenia Martynyuk
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-09 13:06 UTC by Ming Davies
Modified: 2024-01-03 13:57 UTC (History)
14 users (show)

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.
Clone Of:
Environment:
Last Closed: 2023-11-07 08:25:17 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1081 0 None closed All standard schema definitions are present in 99user.ldif when the schema is updated in MMR 2023-06-20 21:47:16 UTC
Red Hat Issue Tracker IDMDS-3351 0 None None None 2023-07-12 05:45:50 UTC
Red Hat Product Errata RHBA-2023:6350 0 None None None 2023-11-07 08:25:47 UTC

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
Note You need to log in before you can comment on or make changes to this bug.