Bug 1334455 - db2ldif is not taking into account multiple suffixes or backends
Summary: db2ldif is not taking into account multiple suffixes or backends
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-09 16:18 UTC by German Parente
Modified: 2016-11-03 20:41 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-1.3.5.4-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 20:41:55 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2594 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2016-11-03 12:11:08 UTC

Description German Parente 2016-05-09 16:18:30 UTC
Description of problem:

db2ldif -s <suffix1> -s <suffix2>

or 

db2ldif -n <backend1> -n <backend2> 

is not considering all the parameters.

The reason is rather obvious:

================
while getopts "hZ:vd:D:ENa:rs:x:CSut:n:UmMo1qc:" flag
do
    case $flag in
        h) usage
           exit 0;;
        Z) servid=$OPTARG;;
        n) benameopt="-n $OPTARG"
           required_param="yes";;
        s) includeSuffix="-s \"$OPTARG\""
           required_param="yes";;
        x) excludeSuffix="-x \"$OPTARG\"";;
=================

should be:
================
while getopts "hZ:vd:D:ENa:rs:x:CSut:n:UmMo1qc:" flag
do
    case $flag in
        h) usage
           exit 0;;
        Z) servid=$OPTARG;;
        n) benameopt=$benameopt" -n $OPTARG"
           required_param="yes";;
        s) includeSuffix=$includeSuffix" -s \"$OPTARG\""
           required_param="yes";;
        x) excludeSuffix=$excludeSuffix" -x \"$OPTARG\"";;
=================

Version-Release number of selected component (if applicable): 389-ds-base-1.3.4.0-29.el7.x86_64


(this is only RHEL7 issue. RHEL6 is doing the right way by passing the full command line to ns-slapd db2ldif).



How reproducible: always


Steps to Reproduce: use multiple suffix in export, for instance

Workaround:

 change the script shown before.

Comment 1 Noriko Hosoi 2016-05-09 16:26:32 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/48828

Comment 2 Noriko Hosoi 2016-05-09 16:28:51 UTC
Hi German,

Your patch looks good to me.  Could you please generate a git patch and attach it to the ticket 48828?
https://fedorahosted.org/389/ticket/48828

I'll push it for you.  Thanks!
--noriko

Comment 6 Punit Kundal 2016-06-27 08:50:19 UTC
DS builds:
[root@ds ~]# rpm -qa | grep 389
389-ds-base-1.3.5.6-1.el7.x86_64
389-ds-base-libs-1.3.5.6-1.el7.x86_64

Steps Performed:

On a standalone DS instance,

1. Created a new backend named "userData" and a new root suffix "dc=redhat,dc=com"

2. Added some entries to the root suffix "dc=redhat,dc=com" as below:

[root@ds ~]# ldapadd -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 -f new_suffix.ldif
adding new entry "dc=redhat,dc=com"

adding new entry "ou=Users,dc=redhat,dc=com"

adding new entry "uid=tuser0,ou=Users,dc=redhat,dc=com"

adding new entry "uid=tuser1,ou=Users,dc=redhat,dc=com"

adding new entry "uid=tuser2,ou=Users,dc=redhat,dc=com"

adding new entry "uid=tuser3,ou=Users,dc=redhat,dc=com"

adding new entry "uid=tuser4,ou=Users,dc=redhat,dc=com"

adding new entry "uid=tuser5,ou=Users,dc=redhat,dc=com"

adding new entry "uid=tuser6,ou=Users,dc=redhat,dc=com"

adding new entry "uid=tuser7,ou=Users,dc=redhat,dc=com"

adding new entry "uid=tuser8,ou=Users,dc=redhat,dc=com"

adding new entry "uid=tuser9,ou=Users,dc=redhat,dc=com"

3. Exported both root suffixes at once using db2ldif as below:

[root@ds ~]# /usr/lib64/dirsrv/slapd-ds/db2ldif -s "dc=example,dc=com" -s "dc=redhat,dc=com"
Exported ldif file: /var/lib/dirsrv/slapd-ds/ldif/ds-example-redhat-2016_06_27_133919.ldif
[27/Jun/2016:13:39:19.295507690 +051800] Backend Instance(s): 
[27/Jun/2016:13:39:19.397681216 +051800] 	userRoot
[27/Jun/2016:13:39:19.414418295 +051800] 	UserData
ldiffile: /var/lib/dirsrv/slapd-ds/ldif/ds-example-redhat-2016_06_27_133919.ldif
[27/Jun/2016:13:39:19.444080681 +051800] export userRoot: Processed 9 entries (100%).
[27/Jun/2016:13:39:19.464472276 +051800] All database threads now stopped
ldiffile: /var/lib/dirsrv/slapd-ds/ldif/ds-example-redhat-2016_06_27_133919.ldif
[27/Jun/2016:13:39:19.493176052 +051800] export UserData: Processed 12 entries (100%).
[27/Jun/2016:13:39:19.514742424 +051800] All database threads now stopped

4. Checked the /var/lib/dirsrv/slapd-ds/ldif directory

[root@ds ~]# ll /var/lib/dirsrv/slapd-ds/ldif/ds-example-redhat-2016_06_27_133919.ldif 
-rw-------. 1 dirsrv dirsrv 9305 Jun 27 13:39 /var/lib/dirsrv/slapd-ds/ldif/ds-example-redhat-2016_06_27_133919.ldif

as can be seen above, an ldif file containing the data of both root suffixes is created

5. Exported both backends at once using db2ldif as below:

[root@ds ~]# /usr/lib64/dirsrv/slapd-ds/db2ldif -n userRoot -n userData
Exported ldif file: /var/lib/dirsrv/slapd-ds/ldif/ds-userRoot-userData-2016_06_27_134234.ldif
WARNING: several backends are being exported to a single ldif file
         use option -M to export to multiple ldif files
ldiffile: /var/lib/dirsrv/slapd-ds/ldif/ds-userRoot-userData-2016_06_27_134234.ldif
[27/Jun/2016:13:42:34.764595457 +051800] export userRoot: Processed 9 entries (100%).
[27/Jun/2016:13:42:34.920198735 +051800] All database threads now stopped
ldiffile: /var/lib/dirsrv/slapd-ds/ldif/ds-userRoot-userData-2016_06_27_134234.ldif
[27/Jun/2016:13:42:34.940199101 +051800] export UserData: Processed 12 entries (100%).
[27/Jun/2016:13:42:34.970829119 +051800] All database threads now stopped

6. Checked the /var/lib/dirsrv/slapd-ds/ldif directory

[root@ds ~]# ll /var/lib/dirsrv/slapd-ds/ldif/ds-userRoot-userData-2016_06_27_134234.ldif 
-rw-------. 1 dirsrv dirsrv 9305 Jun 27 13:42 /var/lib/dirsrv/slapd-ds/ldif/ds-userRoot-userData-2016_06_27_134234.ldif

as can be seen above, an ldif file containing the data of both backends is created

Additional info:
I've performed the same steps with db2ldif.pl perl script and it works correctly as well.

Comment 9 errata-xmlrpc 2016-11-03 20:41:55 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/RHSA-2016-2594.html


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