Bug 1070720

The problem here is that a NULL gets added onto the end of the search filter in the rsearch code:

-------------------------------------------------------------
390	        sprintf(filterBuffer, "%s%s", filter, s);
(gdb) p s
$5 = 0x0
(gdb) p filter
$6 = 0x7fffffffe356 "(ou=people)"
(gdb) n
391	        pFilter = filterBuffer;
(gdb) p filterBuffer
$7 = "(ou=people)(null)", '\000' <repeats 80 times>"\367, ", <incomplete sequence \365>
-------------------------------------------------------------

The fix is simple:

--- a/ldap/servers/slapd/tools/rsearch/searchthread.c
+++ b/ldap/servers/slapd/tools/rsearch/searchthread.c
@@ -387,7 +387,7 @@ static int st_search(SearchThread *st)
             sprintf(num, "%d", get_large_random_number() % numeric);
             s = num;
         }
-        sprintf(filterBuffer, "%s%s", filter, s);
+        sprintf(filterBuffer, "%s%s", filter, s ? s : "");
         pFilter = filterBuffer;
     } else {
         pFilter = filter;

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

I was told by Martin Poole that rsearch filter syntax is different (than what is in [1]). Instead of:

rsearch -D "cn=Directory Manager" -w admin123 -s "dc=brq,dc=redhat,dc=com" -f "ou=people"

there should be command:

echo people > people.txt
rsearch -D "cn=Directory Manager" -w admin123 -s "dc=brq,dc=redhat,dc=com" -f "ou=" -i people.txt

Option -f should be used together with -i <table_file> or -n <number>
(both documentation and "rsearch --help" say -n is reserved, but apparently it works)

Nathan's fix allows to provide the value directly in the filter, i.e.

-f "ou=123"

to work as

-f "ou=" -n 123
(or equivalently with -i file_with_123)


Not sure if that improvement is desired (from my perspective yes, it simplifies rsearch usage). In either case, documentation [1] needs to be updated:

1) examples there that dont work either with our without the fix.
2) without the fix, I would like to see there "if -f is used, use -i"
3) clarify if -n is supported or not (it is "reserved" per docs but apparently works..)


[1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/rsearch.html#rsearch-usage

Created attachment 868988 [details]
patch for rsearch filter bug

Ok, this is fixed upstream.  I've follow Martin's direction for the new fix.  The main difference is that I removed all the fixed size buffers, instead of expanding them.

Actually it is working fine, but the documentation is wrong.

The "-i" option has a very specific usage.

So the name file(lista-de-emails), is only supposed to contain the filter value:

user1
user2

And it only works with filters (-f) that end in "="

uid=
sn=
someAttr=

This also means that you can not use compound filters when using "-i".  Internally all it does is append the value from the file to the end of the filter.

Note that the print formatting does not work, so using %s doesn't do anything, in fact it also gets appended as well:

-f "uid=%s" gets converted to "uid=%suser1".

So the usage must be:

-f 'uid=' which will get converted to 'uid=user1'

Correct usage:

rsearch -D "cn=directory manager" -w password -s "dc=example,dc=com" -f 'uid=' -i /tmp/filter.txt

Verification steps:

[1] Create file (/tmp/filter.txt) with these contents:
user1
user2
user3

[2]  rsearch -D "cn=directory manager" -w password -s "dc=example,dc=com" -f 'uid=' -i /tmp/filter.txt

[3]  There should not bey errors like:  error=0xFFFFFFF9

Hey Mark,

I am getting the error while executing given steps with below bits::

[root@dhcp201-155 ~]# rpm -qa | grep 389
389-admin-1.1.34-1.el6.x86_64
389-adminutil-1.1.17-1.el6.x86_64
389-ds-console-1.2.7-1.el6.noarch
389-ds-base-debuginfo-1.2.11.15-35.el6.x86_64
389-ds-base-libs-1.2.11.15-35.el6.x86_64
389-ds-console-doc-1.2.7-1.el6.noarch
389-ds-base-1.2.11.15-35.el6.x86_64

rsearch -D -h dhcp201-155.englab.pnq.redhat.com -p 389 -D cn=directory manager -w Secret123 -s dc=example,dc=com -f 'uid=' -i /RHEL66/data/DS/6.0/filter/en/bug1070720.txt
T1: failed to bind, ldap_simple_bind_s(cn=directory, Secret123) returned 0x20 (errno 0)
T1: failed to bind, ldap_simple_bind_s(cn=directory, Secret123) returned 0x20 (errno 0)
T1: failed to bind, ldap_simple_bind_s(cn=directory, Secret123) returned 0x20 (errno 0)

Error Logs
============
[root@dhcp201-155 ~]# tail -f /var/log/dirsrv/slapd-dhcp201-155/errors
[23/Jun/2014:03:57:51 -0400] - slapd started.  Listening on All Interfaces port 389 for LDAP requests

[23/Jun/2014:03:59:04 -0400] - Not listening for new connections - too many fds open
[23/Jun/2014:03:59:12 -0400] - Listening for new connections again

[root@dhcp201-155 ~]# cat /RHEL66/data/DS/6.0/filter/en/bug1070720.txt
amsharma
mreynolds
nhosoi
nkinder

Bug is automated in TET as bug1070720 in /RHEL66/testcases/DS/6.0/filter/filter.sh

Can you please check what has gone wrong.

Amita,

You need to quote "cn=directory manager"

T1: failed to bind, ldap_simple_bind_s(cn=directory, Secret123) returned 0x20 (errno 0)

0x20 = 32 (no such object)  The access log would also of shown you the bind error message.  You should really be checking both log sets.  You can also see how the bind dn was truncated because it was not quoted:  (cn=directory) instead of (cn=directory manager)

The error log shows that too many file descriptors are open, probably because you ran the script over and over.   This can probably be ignored.

For future reference when using "cn=directory manager" from the command line it will always need to be quoted because of the space.

This should work for you:

rsearch -D -h dhcp201-155.englab.pnq.redhat.com -p 389 -D "cn=directory manager" -w Secret123 -s dc=example,dc=com -f 'uid=' -i /RHEL66/data/DS/6.0/filter

Thanks,
Mark

Hi Mark,

The error was coming due to DS instance was killed/crashed in quickinstall of tet. 
ofcourse, I know in the command line it should always be "cn=directory manager" 
Command in above comment, I have pasted from the automation log ..

Please Check ::
================= 
http://dhcp201-155.englab.pnq.redhat.com/qa/output/Linux/20140624-005816/filter/filter.startup.out.5363
AND
http://dhcp201-155.englab.pnq.redhat.com/qa/output/Linux/20140624-005816/filter/filter.run.out.5363

Manual Execution running fine:
==================================
[root@dhcp201-155 yum.repos.d]# rsearch -D -h dhcp201-155.englab.pnq.redhat.com -p 32626 -D "cn=directory manager" -w Secret123 -s dc=example,dc=com -f 'uid=' -i /RHEL66/tet/../data/DS/6.0/filter/en/bug1070720.txt
rsearch: 1 threads launched.

20140624 01:48:12 - Rate: 65721.00/thr (6572.10/sec = 0.1522ms/op), total: 65721 (1 thr)
20140624 01:48:22 - Rate: 73257.00/thr (7325.70/sec = 0.1365ms/op), total: 73257 (1 thr)
20140624 01:48:32 - Rate: 71005.00/thr (7100.50/sec = 0.1408ms/op), total: 71005 (1 thr)
20140624 01:48:42 - Rate: 75688.00/thr (7568.80/sec = 0.1321ms/op), total: 75688 (1 thr)
20140624 01:48:52 - Rate: 76120.00/thr (7612.00/sec = 0.1314ms/op), total: 76120 (1 thr)
20140624 01:49:02 - Rate: 72142.00/thr (7214.20/sec = 0.1386ms/op), total: 72142 (1 thr)
20140624 01:49:12 - Rate: 75292.00/thr (7529.20/sec = 0.1328ms/op), total: 75292 (1 thr)

TET automation still fails, I am investigating it.
Thanks for your inputs. We can mark this bug as VERIFIED.

Regards,
Ami

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.

http://rhn.redhat.com/errata/RHBA-2014-1385.html