BUILD TESTED: 389-ds-base-libs-debuginfo-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 389-ds-base-libs-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 389-ds-base-debuginfo-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 389-ds-base-devel-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 389-ds-base-snmp-debuginfo-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 389-ds-base-legacy-tools-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 RESULTS: From the usage the options in state are now available: --state STATE Change the backend state to: "database", "disabled", "referral", "referral on update" ==> I was able to validate "database", "disabled" worked but could not verify "referral", "referral on update" dsconf localhost backend suffix set --state backend userroot The backend configuration was successfully updated dsconf localhost backend suffix set --state backend "dc=example,dc=com" The backend configuration was successfully updated [root@ci-vm-10-0-139-92 4.module+el8dsrv+13893+84b6c18c]# dsconf localhost backend suffix set --state referral userroot Error: 10 - Referral - [] [root@ci-vm-10-0-139-92 4.module+el8dsrv+13893+84b6c18c]# dsconf localhost backend suffix set --state "referral on update" userroot Error: 10 - Referral - [] dsconf localhost backend suffix set --state "referral on update" dc=example1,dc=com Error: 10 - Referral - [] Marking test as FAILEDQA
(In reply to Gilbert Kimetto from comment #4) > BUILD TESTED: > > 389-ds-base-libs-debuginfo-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 > 389-ds-base-libs-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 > 389-ds-base-debuginfo-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 > 389-ds-base-devel-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 > 389-ds-base-snmp-debuginfo-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 > 389-ds-base-legacy-tools-1.4.3.22-4.module+el8dsrv+13893+84b6c18c.x86_64 > > > RESULTS: > From the usage the options in state are now available: > > --state STATE Change the backend state to: "database", "disabled", > "referral", "referral on update" > > ==> I was able to validate "database", "disabled" worked but could not > verify > "referral", "referral on update" > > > dsconf localhost backend suffix set --state backend userroot > The backend configuration was successfully updated > > dsconf localhost backend suffix set --state backend "dc=example,dc=com" > The backend configuration was successfully updated > > > > > [root@ci-vm-10-0-139-92 4.module+el8dsrv+13893+84b6c18c]# dsconf localhost > backend suffix set --state referral userroot > Error: 10 - Referral - [] > [root@ci-vm-10-0-139-92 4.module+el8dsrv+13893+84b6c18c]# dsconf localhost > backend suffix set --state "referral on update" userroot > Error: 10 - Referral - [] > > dsconf localhost backend suffix set --state "referral on update" > dc=example1,dc=com > Error: 10 - Referral - [] > > > Marking test as FAILEDQA This might be expected because you don't have any referrals set in the backend config entry. Need to look into it closer, perhaps the cli tool should not let you set the referral state if there are no referrals?
In master branch the UI and CLI reject the update: UI: Error updating suffix configuration - Server is unwilling to perform - need to set nsslapd-referral before moving to referral state CLI: # dsconf ldapi://%2fvar%2frun%2fslapd-localhost.socket backend suffix set dc=example,dc=com --state=referral Error: 103 - 9 - 53 - Server is unwilling to perform - [] - need to set nsslapd-referral before moving to referral state So there is a missing commit in 1.4.3 that blocks these update attempts. I will look into this.
There are no missing patches. When I looked at the test machine I could see that the server was started in referral mode: dirsrv 25147 1 0 14:15 ? 00:00:00 ns-slapd refer -D /etc/dirsrv/slapd-localhost/ -p 1389 -r ldap://localhost:1389/dc%3Dexample%2Cdc%3Dcom After restarting the server dsconf worked as expected: [root@ci-vm-10-0-136-74 ~]# dsconf ldapi://%2fvar%2frun%2fslapd-localhost.socket backend suffix set dc=example1,dc=com --state=referral Error: 103 - 9 - 53 - Server is unwilling to perform - [] - need to set nsslapd-referral before moving to referral state Perhaps a previous test was done that left the server in a weird state?
We initially were confused with the steps to follow to verify this Bz. So following these steps (server not being started in referral mode): 1 - # dsconf inst1 backend suffix set --add-referral ldap://localhost:2389/dc=example,dc=com 'dc=example,dc=com' The backend configuration was successfully updated 2 - # dsconf inst1 backend suffix set --state referral userroot Error: 103 - 9 - 53 - Server is unwilling to perform - [] - need to set nsslapd-referral before moving to referral state An error is returned, because the request in 1- updated the backend entry : "cn=userroot,cn=ldbm database,cn=plugins,cn=config" [09/Mar/2022:09:16:04.121513279 -0500] conn=2 fd=64 slot=64 connection from local to /var/run/slapd-inst1.socket [09/Mar/2022:09:16:04.122122316 -0500] conn=2 AUTOBIND dn="cn=Directory Manager" [09/Mar/2022:09:16:04.122128757 -0500] conn=2 op=0 BIND dn="cn=Directory Manager" method=sasl version=3 mech=EXTERNAL [09/Mar/2022:09:16:04.122176679 -0500] conn=2 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000162269 optime=0.000370045 etime=0.000531548 dn="cn=Directory Manager" [09/Mar/2022:09:16:04.131144956 -0500] conn=2 op=1 SRCH base="" scope=0 filter="(objectClass=*)" attrs="vendorVersion" [09/Mar/2022:09:16:04.131971902 -0500] conn=2 op=1 RESULT err=0 tag=101 nentries=1 wtime=0.000182746 optime=0.000841373 etime=0.001023053 [09/Mar/2022:09:16:04.134940882 -0500] conn=2 op=2 SRCH base="cn=ldbm database,cn=plugins,cn=config" scope=2 filter="(&(objectClass=nsBackendInstance))" attrs="distinguishedName" [09/Mar/2022:09:16:04.135440790 -0500] conn=2 op=2 RESULT err=0 tag=101 nentries=1 wtime=0.000162043 optime=0.000513884 etime=0.000673783 [09/Mar/2022:09:16:04.135765548 -0500] conn=2 op=3 SRCH base="cn=userroot,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="nsslapd-suffix" [09/Mar/2022:09:16:04.135939431 -0500] conn=2 op=3 RESULT err=0 tag=101 nentries=1 wtime=0.000072974 optime=0.000184143 etime=0.000255186 [09/Mar/2022:09:16:04.136287905 -0500] conn=2 op=4 SRCH base="cn=userroot,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="cn" [09/Mar/2022:09:16:04.136414771 -0500] conn=2 op=4 RESULT err=0 tag=101 nentries=1 wtime=0.000107270 optime=0.000140000 etime=0.000245918 [09/Mar/2022:09:16:04.136664072 -0500] conn=2 op=5 MOD dn="cn=userroot,cn=ldbm database,cn=plugins,cn=config" [09/Mar/2022:09:16:04.141418203 -0500] conn=2 op=5 RESULT err=0 tag=103 nentries=0 wtime=0.000072556 optime=0.004760709 etime=0.004829385 [09/Mar/2022:09:16:04.152417759 -0500] conn=2 op=6 UNBIND [09/Mar/2022:09:16:04.152451311 -0500] conn=2 op=6 fd=64 closed error - U1 When the request in 2- tries to update the mapping tree entry "cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" [09/Mar/2022:09:25:47.617930366 -0500] conn=3 fd=64 slot=64 connection from local to /var/run/slapd-inst1.socket [09/Mar/2022:09:25:47.618461399 -0500] conn=3 AUTOBIND dn="cn=Directory Manager" [09/Mar/2022:09:25:47.618467873 -0500] conn=3 op=0 BIND dn="cn=Directory Manager" method=sasl version=3 mech=EXTERNAL [09/Mar/2022:09:25:47.618509030 -0500] conn=3 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000163453 optime=0.000260926 etime=0.000423499 dn="cn=Directory Manager" [09/Mar/2022:09:25:47.626540704 -0500] conn=3 op=1 SRCH base="" scope=0 filter="(objectClass=*)" attrs="vendorVersion" [09/Mar/2022:09:25:47.627357182 -0500] conn=3 op=1 RESULT err=0 tag=101 nentries=1 wtime=0.000120943 optime=0.000826380 etime=0.000946463 [09/Mar/2022:09:25:47.630481992 -0500] conn=3 op=2 SRCH base="cn=ldbm database,cn=plugins,cn=config" scope=2 filter="(&(objectClass=nsBackendInstance))" attrs="distinguishedName" [09/Mar/2022:09:25:47.631017054 -0500] conn=3 op=2 RESULT err=0 tag=101 nentries=1 wtime=0.000138687 optime=0.000542372 etime=0.000678737 [09/Mar/2022:09:25:47.631458328 -0500] conn=3 op=3 SRCH base="cn=userroot,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="nsslapd-suffix" [09/Mar/2022:09:25:47.631627801 -0500] conn=3 op=3 RESULT err=0 tag=101 nentries=1 wtime=0.000107053 optime=0.000177376 etime=0.000282616 [09/Mar/2022:09:25:47.631962397 -0500] conn=3 op=4 SRCH base="cn=userroot,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="cn" [09/Mar/2022:09:25:47.632121196 -0500] conn=3 op=4 RESULT err=0 tag=101 nentries=1 wtime=0.000078678 optime=0.000170838 etime=0.000247462 [09/Mar/2022:09:25:47.632444857 -0500] conn=3 op=5 SRCH base="cn=userroot,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="nsslapd-suffix" [09/Mar/2022:09:25:47.632604976 -0500] conn=3 op=5 RESULT err=0 tag=101 nentries=1 wtime=0.000087934 optime=0.000168848 etime=0.000254865 [09/Mar/2022:09:25:47.632971299 -0500] conn=3 op=6 SRCH base="cn=mapping tree,cn=config" scope=2 filter="(&(&(objectClass=nsMappingTree))(|(cn=dc=example,dc=com)(nsslapd-backend=dc=example,dc=com)))" attrs="distinguishedName" [09/Mar/2022:09:25:47.633144234 -0500] conn=3 op=6 RESULT err=0 tag=101 nentries=1 wtime=0.000108454 optime=0.000179947 etime=0.000286091 - Invalid attribute in filter - results may not be complete. [09/Mar/2022:09:25:47.633573440 -0500] conn=3 op=7 SRCH base="cn=mapping tree,cn=config" scope=2 filter="(&(&(objectClass=nsds5Replica))(|(nsDS5ReplicaRoot=dc=example,dc=com)))" attrs="distinguishedName" [09/Mar/2022:09:25:47.633681730 -0500] conn=3 op=7 RESULT err=0 tag=101 nentries=0 wtime=0.000109376 optime=0.000114000 etime=0.000221293 [09/Mar/2022:09:25:47.633982289 -0500] conn=3 op=8 MOD dn="cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" [09/Mar/2022:09:25:47.634346390 -0500] conn=3 op=8 RESULT err=53 tag=103 nentries=0 wtime=0.000103464 It seems that "dsconf inst backend suffix set --add-referral" should add the nsslapd-referral attribute to the mapping tree entry, not to the backend entry, so that the mapping tree entry has both nsslapd-referral and nsslapd-state attribute cf https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html-single/configuration_command_and_file_reference/index?check_logged_in=1#Suffix_Configuration_Attributes_under_cnsuffixName BTW, as a workaround, using ldapmodify to add the nsslapd-referral attribute to "cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" solves the problem : # ldapmodify -D "cn=directory manager" -w secret12 -h localhost -p 1389 dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify add: nsslapd-referral nsslapd-referral: ldap://localhost:2389/dc=example,dc=com modifying entry "cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" # dsconf inst1 backend suffix set --state referral 'dc=example,dc=com' The backend configuration was successfully updated
Issue described above is actually an other issue than the one targetted by this Bz. An other Bz has been opened for it :https://bugzilla.redhat.com/show_bug.cgi?id=2063140 dsconf has now a option to set nsslapd-state : see https://bugzilla.redhat.com/show_bug.cgi?id=2040794#c4 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 (Moderate: redhat-ds:11.3 security and bug fix 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/RHSA-2022:0952