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 1859219 - rfc2307 and rfc2307bis compat schema
Summary: rfc2307 and rfc2307bis compat schema
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: 389-ds-base
Version: 8.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.4
Assignee: mreynolds
QA Contact: RHDS QE
URL:
Whiteboard: sync-to-jira
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-07-21 13:34 UTC by mreynolds
Modified: 2021-05-18 15:45 UTC (History)
5 users (show)

Fixed In Version: 389-ds-1.4-8040020201125182123.866effaa
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-18 15:45:18 UTC
Type: ---
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 3986 0 None closed rfc2307 and rfc2307bis compat schema 2021-01-28 09:46:42 UTC

Description mreynolds 2020-07-21 13:34:07 UTC 
This bug is created as a clone of upstream ticket:
https://pagure.io/389-ds-base/issue/50933

#### Issue Description
rfc2307 is the original schema for posix and other related attributes. rfc2307bis was a draft propsed by a member of the openldap team that fixed a number of deficiencies in rfc2307. However, rfc2307bis is not completely forward compatible - replacing them may introduce possible data errors or other subtle issues.

In the interest of allowing easier openldap to 389 migrations ( https://pagure.io/389-ds-base/issue/50544 ) I propose a rfc2307compat, which is a forward compatible version combining rfc2307 and rfc2307bis. This would allow items from both to be considered "valid' without changing the semantics of either.
Comment 3 Viktor Ashirov 2020-11-10 13:29:04 UTC 
Build tested: 389-ds-base-1.4.3.14-1.module+el8.4.0+8664+a8ec484f.x86_64

Test dirsrvtests/tests/suites/replication/rfc2307compat.py fails due to missing 10rfc2307compat.ldif schema:

E       FileNotFoundError: [Errno 2] No such file or directory: '/etc/dirsrv/slapd-master2/schema/10rfc2307compat.ldif'

Marking as ASSIGNED.
Comment 4 mreynolds 2020-11-10 13:56:48 UTC 
(In reply to Viktor Ashirov from comment #3)
> Build tested: 389-ds-base-1.4.3.14-1.module+el8.4.0+8664+a8ec484f.x86_64
> 
> Test dirsrvtests/tests/suites/replication/rfc2307compat.py fails due to
> missing 10rfc2307compat.ldif schema:
> 
> E       FileNotFoundError: [Errno 2] No such file or directory:
> '/etc/dirsrv/slapd-master2/schema/10rfc2307compat.ldif'
> 
> Marking as ASSIGNED.

Hmm looking at the 1.4.3.14 source code, it is there.  I wonder if the test case needs to be updated?   I'll look into...
Comment 5 Viktor Ashirov 2020-11-10 17:18:38 UTC 
I've also noticed just now that it was never executed in the nightlies, because it doesn't have _test postfix in the name :/
Comment 6 Viktor Ashirov 2020-11-10 17:34:03 UTC 
It's a test issue, failure is the same in the master branch. Moving back to MODIFIED.
Comment 14 sgouvern 2020-11-23 09:55:02 UTC 
Test dirsrvtests/tests/suites/replication/rfc2307compat.py is failing, investigation on-going, moving to ITM4.
Comment 16 sgouvern 2020-11-24 15:18:34 UTC 
With 389-ds-base-1.4.3.16-2.module+el8.4.0+8803+fd0f8fe3.x86_64 :

# PYTHONPATH=src/lib389/ py.test -s -v dirsrvtests/tests/suites/replication/rfc2307compat.py 
re-exec with libfaketime dependencies
========================================================= test session starts ==========================================================
platform linux -- Python 3.6.8, pytest-6.1.2, py-1.9.0, pluggy-0.13.1 -- /usr/bin/python3.6
cachedir: .pytest_cache
metadata: {'Python': '3.6.8', 'Platform': 'Linux-4.18.0-249.el8.x86_64-x86_64-with-redhat-8.4-Ootpa', 'Packages': {'pytest': '6.1.2', 'py': '1.9.0', 'pluggy': '0.13.1'}, 'Plugins': {'metadata': '1.10.0', 'html': '3.0.0', 'libfaketime': '0.1.2'}}
389-ds-base: 1.4.3.16-2.module+el8.4.0+8803+fd0f8fe3
nss: 3.53.1-11.el8_2
nspr: 4.25.0-2.el8_2
openldap: 2.4.46-16.el8
cyrus-sasl: 2.1.27-5.el8
FIPS: disabled
rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests, configfile: pytest.ini
plugins: metadata-1.10.0, html-3.0.0, libfaketime-0.1.2
collected 1 item                                       

=============================================================== FAILURES ===============================================================
__________________________________________________________ test_rfc2307compat __________________________________________________________

topo_m2 = <lib389.topologies.TopologyMain object at 0x7f27093dd5c0>

    def test_rfc2307compat(topo_m2):
        """ Test to verify if 10rfc2307compat.ldif does not prevent replication of schema
            - Create 2 masters and a test entry
            - Move 10rfc2307compat.ldif to be private to M1
            - Move 10rfc2307.ldif to be private to M2
            - Add 'objectCategory' to the schema of M1
            - Force a replication session
            - Check 'objectCategory' on M1 and M2
        """
        m1 = topo_m2.ms["master1"]
        m2 = topo_m2.ms["master2"]
    
        m1.config.loglevel(vals=(ErrorLog.DEFAULT, ErrorLog.REPLICA))
        m2.config.loglevel(vals=(ErrorLog.DEFAULT, ErrorLog.REPLICA))
    
        m1.add_s(Entry((
            TEST_ENTRY_DN, {
                "objectClass": "top",
                "objectClass": "extensibleObject",
                'uid': TEST_ENTRY_NAME,
                'cn': TEST_ENTRY_NAME,
                'sn': TEST_ENTRY_NAME,
            }
        )))
    
        entries = get_repl_entries(topo_m2, TEST_ENTRY_NAME, ["uid"])
        assert all(entries), "Entry {} wasn't replicated successfully".format(TEST_ENTRY_DN)
    
        # Clean the old locations (if any)
        m1_temp_schema = os.path.join(m1.get_config_dir(), 'schema')
        m2_temp_schema = os.path.join(m2.get_config_dir(), 'schema')
        m1_schema = os.path.join(m1.get_data_dir(), 'dirsrv/schema')
        m1_opt_schema = os.path.join(m1.get_data_dir(), 'dirsrv/data')
        m1_temp_backup = os.path.join(m1.get_tmp_dir(), 'schema')
    
        # Does the system schema exist?
        if os.path.islink(m1_schema):
            # Then we need to put the m1 schema back.
            os.unlink(m1_schema)
            shutil.copytree(m1_temp_backup, m1_schema)
        if not os.path.exists(m1_temp_backup):
            shutil.copytree(m1_schema, m1_temp_backup)
    
        shutil.rmtree(m1_temp_schema, ignore_errors=True)
        shutil.rmtree(m2_temp_schema, ignore_errors=True)
    
        # Build a new copy
        shutil.copytree(m1_schema, m1_temp_schema)
        shutil.copytree(m1_schema, m2_temp_schema)
        # Ensure 99user.ldif exists
        with open(os.path.join(m1_temp_schema, '99user.ldif'), 'w') as f:
            f.write('dn: cn=schema')
    
        with open(os.path.join(m2_temp_schema, '99user.ldif'), 'w') as f:
            f.write('dn: cn=schema')
    
        # m1 has compat, m2 has legacy.
>       os.unlink(os.path.join(m2_temp_schema, '10rfc2307compat.ldif'))
E       FileNotFoundError: [Errno 2] No such file or directory: '/etc/dirsrv/slapd-master2/schema/10rfc2307compat.ldif'

dirsrvtests/tests/suites/replication/rfc2307compat.py:93: FileNotFoundError
---------------------------------------------------------- Captured log setup ----------------------------------------------------------



To be noted that on a fresh install, 10rfc2307compat.ldif is not present in /usr/share/dirsrv/schema/

# ls /usr/share/dirsrv/schema/
00core.ldif               25java-object.ldif     60mozilla.ldif
01core389.ldif            28pilot.ldif           60nss-ldap.ldif
02common.ldif             30ns-common.ldif       60pam-plugin.ldif
05rfc2927.ldif            50ns-admin.ldif        60posix-winsync-plugin.ldif
05rfc4523.ldif            50ns-certificate.ldif  60pureftpd.ldif
05rfc4524.ldif            50ns-directory.ldif    60rfc2739.ldif
06inetorgperson.ldif      50ns-mail.ldif         60rfc3712.ldif
10automember-plugin.ldif  50ns-value.ldif        60sabayon.ldif
10dna-plugin.ldif         50ns-web.ldif          60sudo.ldif
10mep-plugin.ldif         60acctpolicy.ldif      60trust.ldif
10rfc2307.ldif            60autofs.ldif
20subscriber.ldif         60eduperson.ldif

Marking FailedQA / ASSIGNED
Comment 19 sgouvern 2020-11-30 08:38:29 UTC 
With build 389-ds-base-1.4.3.16-3.module+el8.4.0+8869+55706461.x86_64, dirsrvtests/tests/suites/replication/rfc2307compat_test.py::test_rfc2307compat is still failing.
Test failure to be investigated
-> moving to ITM 6
Comment 20 mreynolds 2020-11-30 14:31:34 UTC 
(In reply to sgouvern from comment #19)
> With build 389-ds-base-1.4.3.16-3.module+el8.4.0+8869+55706461.x86_64,
> dirsrvtests/tests/suites/replication/rfc2307compat_test.py::
> test_rfc2307compat is still failing.
> Test failure to be investigated
> -> moving to ITM 6

I thought it was determined by Viktor that this test case never worked (it was always broken even on master).  Perhaps it should be rewritten or sanity tested?
Comment 21 sgouvern 2020-12-14 14:58:01 UTC 
Missed the ITM 6 milestone -> moving to ITM 7
Comment 22 sgouvern 2021-01-11 10:34:45 UTC 
Verified SanityOnly that fixes for https://pagure.io/389-ds-base/c/9ede55d and https://pagure.io/389-ds-base/c/79d5f2cf are present in the build

dirsrvtests/tests/suites/replication/rfc2307compat_test.py has test problems at the moment and is being fixed 

=> marking as verified:tested
Comment 26 sgouvern 2021-01-18 14:13:43 UTC 
wrong build attached to the errata -> moving to ITM12
Comment 27 sgouvern 2021-01-18 14:45:42 UTC 
Correct build now attached to the errata : as per comment 22, marking as VERIFIED and moving back to ITM11
Comment 29 errata-xmlrpc 2021-05-18 15:45:18 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:1.4 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-2021:1835
Note You need to log in before you can comment on or make changes to this bug.