Hide Forgot
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.
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
Upstream ticket: https://fedorahosted.org/389/ticket/49070
Fixed upstream.
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
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