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-base | Assignee: | mreynolds |
| Status: | CLOSED ERRATA | QA Contact: | LDAP QA Team <idm-ds-qe-bugs> |
| Severity: | unspecified | Docs Contact: | Evgenia Martynyuk <emartyny> |
| Priority: | medium | ||
| Version: | 9.1 | CC: | abobrov, bsmejkal, emartyny, gfialova, idm-ds-dev-bugs, mreynolds, msauton, nkinder, pasik, sgouvern, spichugi, tbordaz, tmihinto, vashirov |
| Target Milestone: | rc | Keywords: | TestCaseNeeded, Triaged |
| Target Release: | 9.3 | Flags: | pm-rhel:
mirror+
|
| 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
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. 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 |