Bug 922538

moving all ON_QA bugs to MODIFIED in order to add them to the errata (can't add bugs in the ON_QA state to an errata).  When the errata is created, the bugs should be automatically moved back to ON_QA.

Hi Rich,

Few questions ::
What all have been fixed under this bug ::
===========================================
a. zero pad to some number of digits
b. Need to specify the rdn value for dbgen to use
c. Allow dbgen to output to stdout
d. -j is for zero pad, I used dbgen.pl -o /export/testdb.ldif -n 10 -j 4 -v but it did not give me desired uid as 00001.

Request you to please share one liner dbgen.pl command which can cover the fixes validation.

Thank you,
-Ami

Something is broken - reopening

changing to POST since 970750 is in POST now

Hi Noriko/Rich,

Request to please reply ::
Few questions ::
What all have been fixed under this bug ::
===========================================
a. zero pad to some number of digits
b. Need to specify the rdn value for dbgen to use
c. Allow dbgen to output to stdout
d. -j is for zero pad, I used dbgen.pl -o /export/testdb.ldif -n 10 -j 4 -v but it did not give me desired uid as 00001.

Request you to please share one liner dbgen.pl command which can cover the fixes validation.

Thanks,
Ami

(In reply to Amita Sharma from comment #6)
> Hi Noriko/Rich,
> 
> Request to please reply ::
> Few questions ::
> What all have been fixed under this bug ::
> ===========================================
> a. zero pad to some number of digits
> b. Need to specify the rdn value for dbgen to use
> c. Allow dbgen to output to stdout
> d. -j is for zero pad, I used dbgen.pl -o /export/testdb.ldif -n 10 -j 4 -v
> but it did not give me desired uid as 00001.
> 
> Request you to please share one liner dbgen.pl command which can cover the
> fixes validation.
> 
> Thanks,
> Ami

From looking at the patch, the zero padding option (-j) is only used when you are also specifying the begin number option (-b):

    -b beginning number for RDN (default 1 - ending number is -n value)

It seems like we should still allow zero padding even when a beginning number isn't explicitly specified.

(In reply to Nathan Kinder from comment #7)
> (In reply to Amita Sharma from comment #6)
> > Hi Noriko/Rich,
> > 
> > Request to please reply ::
> > Few questions ::
> > What all have been fixed under this bug ::
> > ===========================================
> > a. zero pad to some number of digits
> > b. Need to specify the rdn value for dbgen to use
> > c. Allow dbgen to output to stdout
> > d. -j is for zero pad, I used dbgen.pl -o /export/testdb.ldif -n 10 -j 4 -v
> > but it did not give me desired uid as 00001.
> > 
> > Request you to please share one liner dbgen.pl command which can cover the
> > fixes validation.
> > 
> > Thanks,
> > Ami
> 
> From looking at the patch, the zero padding option (-j) is only used when
> you are also specifying the begin number option (-b):
> 
>     -b beginning number for RDN (default 1 - ending number is -n value)
> 
> It seems like we should still allow zero padding even when a beginning
> number isn't explicitly specified.

The -b flag also means "use a numeric value for RDN".  We don't have another switch to say "use a numeric value for RDN".  So I guess if there is a bug here, it's that the -b usage text should not have a default value, since there is not a default value.  And, using -j is ignored if not also using -b.  Note that -n is for the number of entries, regardless of the RDN style.

Here is a one liner to test:

$ dbgen.pl -b 1 -j 4 -o - -n 1 -x -y|grep \^dn
dn: uid=0001,ou=People,dc=example,dc=com
$ dbgen.pl -b 1 -j 10 -o - -n 1 -x -y|grep \^dn
dn: uid=0000000001,ou=People,dc=example,dc=com

Finally, the main reason why these changes were done was to make dbgen.pl work much better with ldclt and other testing tools:
* ldclt wants zero padded numeric RDNs (unless you actually provide files containing rdn values)
* output to -o means you can output to stdout with -o -, which means you can pipe the output to ldapmodify or ldif2db or gzip/bzip2, which is really nice when you have a 100MB of ldif data

It's not really expected that the typical end user will use dbgen.pl, mostly people doing performance testing.

(In reply to Rich Megginson from comment #8)
> (In reply to Nathan Kinder from comment #7)
> 
> The -b flag also means "use a numeric value for RDN".  We don't have another
> switch to say "use a numeric value for RDN".  So I guess if there is a bug
> here, it's that the -b usage text should not have a default value, since
> there is not a default value.  And, using -j is ignored if not also using
> -b.  Note that -n is for the number of entries, regardless of the RDN style.
> 
> 
> It's not really expected that the typical end user will use dbgen.pl, mostly
> people doing performance testing.

A separate bug should be filed against RHEL 7.1 to improve the usage output.  I agree that this is really a low priority, so we should file it against RHEL 7.1 for now.  Amita - please file this bug.

This bug fix should be verified using the command mentioned in comment#8.

Thank you Rich and Nathan.

[root@dhcp201-149 ~]# dbgen.pl -b 1 -j 4 -o - -n 1 -x -y | grep -i "dn: uid=0001,ou=People,dc=example,dc=com"
dn: uid=0001,ou=People,dc=example,dc=com

[root@dhcp201-149 ~]# dbgen.pl -b 1 -j 10 -o - -n 1 -x -y | grep -i "dn: uid=0000000001,ou=People,dc=example,dc=com"
dn: uid=0000000001,ou=People,dc=example,dc=com

Hence, marking this bug as VERIFIED.

New bug for RHEL7.1 :: https://bugzilla.redhat.com/show_bug.cgi?id=1061572

[RHEL7]
[svrbld@dhcp201-149 basic]$ svn ci basic.sh -m "test case added for bug922538"
Sending        basic.sh
Transmitting file data .
Committed revision 8660.
[TET]
[amsharma@amsharma basic]$ svn ci basic.sh -m "test case added for bug922538"
Sending        basic.sh
Transmitting file data .
Committed revision 8661.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.