Bug 1400997

Summary:	ldif2db.pl script shows wrong usage for -n as instance, instead of database
Product:	Red Hat Enterprise Linux 6	Reporter:	Sankar Ramalingam <sramling>
Component:	389-ds-base	Assignee:	Noriko Hosoi <nhosoi>
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	low	Docs Contact:
Priority:	low
Version:	6.9	CC:	mreynolds, nkinder, rmeggins, tlavigne
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	389-ds-base-1.2.11.15-86.el6	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-03-21 10:24:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Sankar Ramalingam 2016-12-02 14:14:39 UTC

Description of problem: Running ldif2db.pl --help shows -n instance, instead of -n backend database name.


Version-Release number of selected component (if applicable): 389-ds-base-1.2.11.15-85


How reproducible: Consistently with RHEL-6.9


Steps to Reproduce:
1. Install 389-ds-base-1.2.11.15-85 build on RHEL-6.9
2. Create an instance and run ldif2db.pl script to check usage, with --help
3. ldif2db.pl displays wrong usage for -n option.

Actual results: It shows Instance name to be supplied for -n option. Where as it is expected to be "backend database name".


Expected results: -n backend    - Backend database name.  Example: userRoot

Additional info: This is working with 389-ds-base-1.3.5.10 builds on RHEL7.3.

Comment 1 Sankar Ramalingam 2016-12-02 14:20:03 UTC

Actual output from the command line...

[root@auto-hv-02-guest09 389ds-replica]# /usr/lib64/dirsrv/slapd-Inst1/ldif2db.pl -D "cn=Directory Manager" -w Secret123 -n userRoot -s "dc=example,dc=com" -i /export/100k.ldif 
adding new entry "cn=import_2016_12_2_9_4_6, cn=import, cn=tasks, cn=config"

[root@auto-hv-02-guest09 389ds-replica]# /usr/lib64/dirsrv/slapd-Inst1/ldif2db.pl -D "cn=Directory Manager" -w Secret123  -n Inst1 -s "dc=example,dc=com" -i /export/100k.ldif 
adding new entry "cn=import_2016_12_2_9_4_19, cn=import, cn=tasks, cn=config"
ldap_add: No such object (32)

From the error logs...
[02/Dec/2016:09:04:18 -0500] - can't import to nonexistent backend Inst1

Comment 4 mreynolds 2016-12-16 21:04:54 UTC

Upstream ticket:
https://fedorahosted.org/389/ticket/49070

Comment 5 mreynolds 2016-12-19 17:46:19 UTC

Fixed upstream.

Comment 7 Sankar Ramalingam 2017-01-10 13:15:43 UTC

I ran ldif2db.pl and it showed the correct usage. Hence, marking the bug as Verified

[0 root@qeos-158 export]# /usr/lib64/dirsrv/slapd-Inst1/ldif2db.pl --help |more
Usage: /usr/lib64/dirsrv/slapd-Inst1/ldif2db.pl [-v] -D rootdn { -w password | 
     : -j filename   - Read Directory Manager's password from file
     : -n backend    - Backend database name to be imported to

[0 root@qeos-158 export]# rpm -qa |grep -i 389-ds-base
389-ds-base-libs-1.2.11.15-86.el6.x86_64
389-ds-base-debuginfo-1.2.11.15-86.el6.x86_64
389-ds-base-devel-1.2.11.15-86.el6.x86_64
389-ds-base-1.2.11.15-86.el6.x86_64

Comment 9 errata-xmlrpc 2017-03-21 10:24:07 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-0667.html