Description of problem: dsconf accepts the "replica-id" option when setting a hub or a consumer. The replica configuration entry is correctly created ( replicaID is set to 65535 ). It would nice to prevent users setting the replicaID for hub and consumer roles because the value is set automatically anyway. Customers could try creating hubs and consumers using a replicaID different of 65535. Version-Release number of selected component (if applicable): $ rpm -qa | grep 389-ds-base-1 389-ds-base-1.4.3.22-1.module+el8dsrv+10501+8ce33e95.x86_64 $ How reproducible: Always. Steps to Reproduce: 1. Try to create a consumer using a replicaID different of 65535: $ dsconf -v -D "cn=Directory Manager" ldap://localhost:1389 replication enable --suffix="dc=test,dc=com" --role="consumer" --replica-id=1 2. Check the actual configured value: $ dsconf -D "cn=Directory Manager" ldap://localhost:1389 replication get --suffix="dc=test,dc=com" | grep -i replicaIDEnter password for cn=Directory Manager on ldap://localhost:1389: nsDS5ReplicaId: 65535 $ Actual results: One can pass the parameter "replica-id" to dsconf when creating hubs or consumers. Expected results: Don't allow to set the "replica-id" manually for hubs and consumers. Additional info: $ dsconf -v -D "cn=Directory Manager" ldap://localhost:1389 replication enable --suffix="dc=test,dc=com" --role="consumer" --replica-id=1 DEBUG: The 389 Directory Server Configuration Tool ... DEBUG: Checking "None" under None : {'cn': 'changelog5', 'nsslapd-changelogdir': '/var/lib/dirsrv/slapd-alps9/changelogdb'} DEBUG: Validated dn cn=changelog5,cn=config DEBUG: Creating cn=changelog5,cn=config DEBUG: updating dn: cn=changelog5,cn=config DEBUG: updated dn: cn=changelog5,cn=config with {'objectclass': [b'top', b'nsChangelogConfig']} DEBUG: updating dn: cn=changelog5,cn=config DEBUG: updated dn: cn=changelog5,cn=config with {'cn': [b'changelog5'], 'nsslapd-changelogdir': [b'/var/lib/dirsrv/slapd-alps9/changelogdb']} DEBUG: Checking "None" under cn=mapping tree,cn=config : {'cn': 'replica', 'nsDS5ReplicaRoot': 'dc=test,dc=com', 'nsDS5Flags': '0', 'nsDS5ReplicaType': '2', 'nsDS5ReplicaId': '65535'} DEBUG: Using first property cn: replica as rdn DEBUG: _gen_selector filter = (&(&(objectclass=nsMappingTree))(|(cn=dc=test,dc=com)(nsslapd-backend=dc=test,dc=com))) DEBUG: Validated dn cn=replica,cn=dc\3Dtest\2Cdc\3Dcom,cn=mapping tree,cn=config DEBUG: Creating cn=replica,cn=dc\3Dtest\2Cdc\3Dcom,cn=mapping tree,cn=config DEBUG: updating dn: cn=replica,cn=dc\3Dtest\2Cdc\3Dcom,cn=mapping tree,cn=config DEBUG: updated dn: cn=replica,cn=dc\3Dtest\2Cdc\3Dcom,cn=mapping tree,cn=config with {'objectclass': [b'top', b'nsds5Replica']} DEBUG: updating dn: cn=replica,cn=dc\3Dtest\2Cdc\3Dcom,cn=mapping tree,cn=config DEBUG: updated dn: cn=replica,cn=dc\3Dtest\2Cdc\3Dcom,cn=mapping tree,cn=config with {'cn': [b'replica'], 'nsDS5ReplicaRoot': [b'dc=test,dc=com'], 'nsDS5Flags': [b'0'], 'nsDS5ReplicaType': [b'2'], 'nsDS5ReplicaId': [b'65535']} DEBUG: Created entry cn=replica,cn=dc\3Dtest\2Cdc\3Dcom,cn=mapping tree,cn=config : {'objectclass': [b'top', b'nsds5Replica'], 'cn': [b'replica'], 'nsDS5ReplicaRoot': [b'dc=test,dc=com'], 'nsDS5Flags': [b'0'], 'nsDS5ReplicaType': [b'2'], 'nsDS5ReplicaId': [b'65535']} INFO: Replication successfully enabled for "dc=test,dc=com" INFO: Command successful. $
This bz is in POST, but I see it was already included in the latest 11.8 build 389-ds-base-1.4.3.37-1.module+el8dsrv+19621+efe8bde6.x86_64 This introduced a regression: I can no longer create consumer or hub, it fails with: /usr/sbin/dsconf -j ldapi://%2fvar%2frun%2fslapd-M2.socket replication enable --suffix=dc=example,dc=com --role=consumer --bind-dn="cn=replication manager,cn=config" { "desc": "Replica ID cannot be specified for consumer and hub roles" } https://github.com/389ds/389-ds-base/blob/bacf80754cf883af96d4bd319399502a2c1e561f/src/lib389/lib389/cli_conf/replication.py#L189 I think or should be replaced with and, because if args.replica_id is None, the second part of the condition will evaluate to True: (Pdb) print(args.replica_id) None (Pdb) print(args.replica_id != 65535) True (Pdb) print(args.replica_id is not None or args.replica_id != 65535) True Moving to ASSIGNED.
Automated tests passed: ============================================================= test session starts ============================================================= platform linux -- Python 3.9.18, pytest-6.2.2, py-1.10.0, pluggy-0.13.1 -- /usr/bin/python3 cachedir: .pytest_cache 389-ds-base: 2.3.6-4.module+el9dsrv+19950+6ff0d0d4 nss: 3.90.0-3.el9_2 nspr: 4.35.0-3.el9_2 openldap: 2.6.3-1.el9 cyrus-sasl: not installed FIPS: disabled rootdir: /mnt/tests/rhds/install/ds/dirsrvtests, configfile: pytest.ini collected 9 items dirsrvtests/tests/suites/clu/dsconf_test.py::test_backend_referral PASSED [ 11%] dirsrvtests/tests/suites/clu/dsconf_test.py::test_dsconf_with_ldaps[ldapfile] PASSED [ 22%] dirsrvtests/tests/suites/clu/dsconf_test.py::test_dsconf_with_ldaps[dsrfile] PASSED [ 33%] dirsrvtests/tests/suites/clu/dsconf_test.py::test_check_replica_id_rejected_hub_consumer[consumer] PASSED [ 44%] dirsrvtests/tests/suites/clu/dsconf_test.py::test_check_replica_id_rejected_hub_consumer[hub] PASSED [ 55%] dirsrvtests/tests/suites/clu/dsconf_test.py::test_check_replica_id_accepted_hub_consumer[consumer-None] PASSED [ 66%] dirsrvtests/tests/suites/clu/dsconf_test.py::test_check_replica_id_accepted_hub_consumer[hub-None] PASSED [ 77%] dirsrvtests/tests/suites/clu/dsconf_test.py::test_check_replica_id_accepted_hub_consumer[consumer-65535] PASSED [ 88%] dirsrvtests/tests/suites/clu/dsconf_test.py::test_check_replica_id_accepted_hub_consumer[hub-65535] PASSED [100%] ================================================== 9 passed, 2 warnings in 171.27s (0:02:51) ================================================== 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 (redhat-ds:12 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/RHEA-2023:7429