Bug 1414677
| Summary: | (un)register/migration/remove may fail if there is no suffix on 'userRoot' backend | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jaroslav Reznik <jreznik> |
| Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> |
| Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
| Severity: | urgent | Docs Contact: | Marc Muehlfeld <mmuehlfe> |
| Priority: | urgent | ||
| Version: | 7.4 | CC: | msauton, nhosoi, nkinder, rmeggins, sramling, tbordaz |
| Target Milestone: | rc | Keywords: | ZStream |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 389-ds-base-1.3.5.10-17.el7_3 | Doc Type: | Bug Fix |
| Doc Text: |
Previously, if the suffix of the "userRoot" default back end was not found in the "nsslapd-suffix" attribute, Directory Server scripts used for registering and unregistering back ends lost the suffix information and failed. A patch has been applied and Directory Server now ignores the empty suffix in the mentioned situation.
|
Story Points: | --- |
| Clone Of: | 1391204 | Environment: | |
| Last Closed: | 2017-03-02 17:13:03 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1391204 | ||
| Bug Blocks: | |||
|
Description
Jaroslav Reznik
2017-01-19 08:45:54 UTC
Based on the description i Bug #1391204, I removed the cn=userRoot database and tried running remove-ds.pl and migrate-ds.pl scripts to check if its running fine. Is that all required to verify? Request you to add additional steps to verify, if required. Sankar, The bug appears when none of the backends are named 'userRoot', so you may test with both environments (with and without 'userRoot' backend). The commands to test are the ones you tested but you may also test *-admin.pl scripts (register-ds-admin.pl, setup-ds-admin.pl if possible to create an instance without 'userRoot' but I doubt it is possible). Hi Thierry, thanks for clarification. 1. Installed 389-ds-base, 389-admin, 389-ds-console and idm-console-framework packages. 2. Created two instances, one with admin console and other one without. [0 root@qeos-84 389ds-replica]# ldapsearch -x -p 1389 -h localhost -D "cn=Directory Manager" -w Secret123 -b "" -s base + |grep -i nsBackendSuffix nsBackendSuffix: userRoot:dc=lab,dc=eng,dc=rdu2,dc=redhat,dc=com [0 root@qeos-84 389ds-replica]# ldapsearch -x -p 1489 -h localhost -D "cn=Directory Manager" -w Secret123 -b "" -s base + |grep -i nsBackendSuffix nsBackendSuffix: userRoot:dc=lab,dc=eng,dc=rdu2,dc=redhat,dc=com nsBackendSuffix: NetscapeRoot:o=netscaperoot nsBackendSuffix: example1489:dc=example,dc=com nsBackendSuffix: example11489:dc=example1,dc=com nsBackendSuffix: example21489:dc=example2,dc=com 3. Then, registered the instance to admin server using register-ds-admin.pl. The registration completed successfully. 4. Removed userRoot db from the instance where admin server is registered. [0 root@qeos-84 389ds-replica]# ldapdelete -rx -p 1489 -h localhost -D "cn=Directory Manager" -w Secret123 "cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [0 root@qeos-84 389ds-replica]# ldapsearch -x -p 1489 -h localhost -D "cn=Directory Manager" -w Secret123 -b "" -s base + |grep -i nsBackendSuffix nsBackendSuffix: NetscapeRoot:o=netscaperoot nsBackendSuffix: example1489:dc=example,dc=com nsBackendSuffix: example11489:dc=example1,dc=com nsBackendSuffix: example21489:dc=example2,dc=com 5. Created new instance with setup-ds-admin.pl to create as well as register with the existing admin server. Creation and registration of instance completed successfully. 6. Created a new instance with setup-ds.pl script and then registered using register-ds-admin.pl script. Creation and registration of instance completed successfully. Creation and registration of instances successfully completed with setup-ds-admin.pl and register-ds-admin.pl scripts. Also tested remove-ds.pl and remove-ds-admin.pl scripts. No issues encountered. Hence, marking the bug as Verified. Tested environment: [0 root@qeos-84 389ds-replica]# rpm -qa |egrep '389-|redhat-ds' 389-console-1.1.18-2.el7dsrv.noarch 389-ds-base-1.3.5.10-17.el7_3.x86_64 389-ds-base-libs-1.3.5.10-17.el7_3.x86_64 389-ds-console-1.2.16-1.el7dsrv.noarch redhat-ds-admin-10.1.0-2.el7dsrv.x86_64 redhat-ds-10.1.0-2.el7dsrv.x86_64 389-admin-1.1.46-1.el7dsrv.x86_64 redhat-ds-base-10.1.0-2.el7dsrv.x86_64 redhat-ds-console-doc-10.1.0-2.el7dsrv.noarch 389-adminutil-1.1.23-2.el7dsrv.x86_64 redhat-ds-console-10.1.0-2.el7dsrv.noarch 389-ds-console-doc-1.2.16-1.el7dsrv.noarch 389-admin-console-1.1.12-2.el7dsrv.noarch 389-admin-console-doc-1.1.12-2.el7dsrv.noarch 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, 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://rhn.redhat.com/errata/RHBA-2017-0385.html |