Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1414677 - (un)register/migration/remove may fail if there is no suffix on 'userRoot' backend
Summary: (un)register/migration/remove may fail if there is no suffix on 'userRoot' ba...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.4
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
Marc Muehlfeld
URL:
Whiteboard:
Depends On: 1391204
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-19 08:45 UTC by Jaroslav Reznik
Modified: 2017-03-02 17:13 UTC (History)
6 users (show)

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.
Clone Of: 1391204
Environment:
Last Closed: 2017-03-02 17:13:03 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0385 0 normal SHIPPED_LIVE 389-ds-base bug fix update 2017-03-02 22:06:04 UTC

Description Jaroslav Reznik 2017-01-19 08:45:54 UTC
This bug has been copied from bug #1391204 and has been proposed
to be backported to 7.3 z-stream (EUS).

Comment 4 Sankar Ramalingam 2017-02-07 15:14:08 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.

Comment 5 thierry bordaz 2017-02-07 15:56:30 UTC
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).

Comment 6 Sankar Ramalingam 2017-02-08 15:55:24 UTC
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.

Comment 7 Sankar Ramalingam 2017-02-08 15:57:42 UTC
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

Comment 9 errata-xmlrpc 2017-03-02 17:13:03 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, 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


Note You need to log in before you can comment on or make changes to this bug.