Bug 245779

Created attachment 157919 [details]
result email with the 0% completion report

The test probably needs to be ported to RHDS8.0/FDS1.1.  Most all of the paths
to config files, db files, etc. has changed.  You might want to first ask
Chandra how to get the intermediate test output, where the temp files used to
hold the output are, etc.  and start from there.

 
I've got a fix for this already. I'm working on figuring out how to get the
checkin reviewed right now, so I can check it in.

I am working with Chandra on this.

To get the checkin reviewed, follow the procedures listed at
https://idmwiki.sfbay.redhat.com/export/idmwiki/DirSecEngGuidelines#Overview_2

Basically - do a cvs diff -u8 of the code, attach to this bug as a patch
attachment.  Send an email to ldap-devel-list requesting a review.

Created attachment 157967 [details]
diff to fix the largefiles stress test

This patch fixes the largefiles stress test, and cleans up some formatting
problems with the code.

Created attachment 157969 [details]
final result email showing 100% pass on largefiles test

Under finding ldif, I think there is similar logic to find executables elsewhere
in the test code.  You should probably use that logic instead.  Also, you should
not use fedora or fedora-ds.  There is some logic in the tests to define a
$brand or $BRAND variable that should be used in place of fedora or redhat in
path names.

Otherwise, looks good.

Created attachment 158033 [details]
patch to fix the largefiles test version 2

This is the diff with the updated changes. 
After looking through the code I found a few similar instances of the if ->
elif -> fi method of finding files. Some of them revolved around being
dependant on different OS's, but this method should cover linux, solaris, and
hp-ux well. The only case where this code will fail is when the test is run on
fedora, but that doesn't seem to be a needed.

(In reply to comment #8)
> This is the diff with the updated changes. 
> After looking through the code I found a few similar instances of the if ->
> elif -> fi method of finding files. Some of them revolved around being
> dependant on different OS's, but this method should cover linux, solaris, and
> hp-ux well. The only case where this code will fail is when the test is run on
> fedora, but that doesn't seem to be a needed.

Looks good.  Why would it fail on fedora?  It should find /usr/bin/ldif on fedora.

On fedora, the ldif utility gets installed to /opt/fedora-ds/bin/slapd/server/ldif

from what I'm told, on fedora, $PREFIX is "", and $IROOT is /opt/fedora-ds

So, the first test will look in "$IROOT/../bin/slapd/server/ldif" ie,
"/opt/bin/slapd/server/ldif"

the second test will look in /usr/bin/ldif, and the third in /usr/bin/ldif.

none of these will match the install path to the ldif utility. 

If we wanted to support running the stress tests on fedora, I would probably
throw in a test for looking in $LDAPTOOLS/ldif, but I'm told that running these
stress tests isn't something we want to do, so I left it out.

(In reply to comment #10)
> On fedora, the ldif utility gets installed to /opt/fedora-ds/bin/slapd/server/ldif

Ok.  That's Fedora DS 1.0.x.  Fedora DS 1.1 (which is what we are currently
testing - fedora-ds-base) will install in /usr/bin.

> 
> from what I'm told, on fedora, $PREFIX is "", and $IROOT is /opt/fedora-ds

IROOT should be a server instance directory e.g. /opt/fedora-ds/slapd-localhost
> 
> So, the first test will look in "$IROOT/../bin/slapd/server/ldif" ie,
> "/opt/bin/slapd/server/ldif"
> 
> the second test will look in /usr/bin/ldif, and the third in /usr/bin/ldif.
> 
> none of these will match the install path to the ldif utility. 
> 
> If we wanted to support running the stress tests on fedora, I would probably
> throw in a test for looking in $LDAPTOOLS/ldif, but I'm told that running these
> stress tests isn't something we want to do, so I left it out.

Ok.

Created attachment 158057 [details]
result from cvs commit

I'm closing this bug. 

I'll send out a update to the ldap-devel-list.

Thanks for the review Rich.

Bug already CLOSED. setting screened+ flag