Re: (ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by hyc＠symas.com
jvcelak(a)redhat.com wrote:
> Full_Name: Jan Vcelak
> Version: 2.5.25
There is no OpenLDAP version 2.5.
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/jvcelak-20110622-ldif-split-indent-segfau...
> Submission from: (NULL) (209.132.186.34)
>
>
> Hello,
>
> input LDIF file with splitted lines which are indented incorrectly causes
> SEGFAULT of a client tool. Let me show:
>
> $ cat /tmp/invalid.ldif
> dn: cn=B,dc=my-domain,
> dc=com
> objectclass: inetOrgPerson
> objectclass: organizationalPerson
> objectclass: person
> objectclass: top
> cn: B
> sn: B
> uid: B
> mail: b(a)example.org
>
> $ ldapmodify -a -x -f /tmp/invalid.ldif -d2048
> ldif_parse_line: missing ':' after dc=com
> ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain,"
> Segmentation fault (core dumped)
>
>
> (gdb) bt full
> #0 __strcasecmp_l_ssse3 () at ../sysdeps/x86_64/strcmp.S:214
> No locals.
> #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0,
> linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1,
> ctx=0x0) at ldifutil.c:399
There is no file ldifutil.c in OpenLDAP 2.4.
I don't know what you're testing against, but this bug report appears invalid.
Closing.
> fv = 0
> line = 0x668627 "dc=com"
> dn = 0x668614 "cn=B,dc=my-domain,"
> rc = -9
> modop = 0
> expect_modop = 0
> expect_sep = 0
> ldapadd = 1
> new_entry = 1
> delete_entry = 0
> got_all = 0
> pmods = 0x6697e8
> version = 0
> pctrls = 0x0
> i = 1
> j = 0
> k = -1
> idn = 1
> nmods = 1
> bvl = 0x6697f8
> bv = {bv_len = 0, bv_val = 0x0}
> __PRETTY_FUNCTION__ = "ldap_parse_ldif_record_x"
> #2 0x000000000042e524 in ldap_parse_ldif_record (rbuf=0x7fffffffdbb0,
> linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1) at
> ldifutil.c:565
> No locals.
> #3 0x0000000000406ff8 in process_ldif_rec (rbuf=0x668610 "dn", linenum=1) at
> ldapmodify.c:404
> lr = {lr_op = 0, lr_dn = {bv_len = 18, bv_val = 0x668614
> "cn=B,dc=my-domain,"}, lr_ctrls = 0x0, ldif_ops = {lr_mods = 0x0, ldif_op_rename
> = {lr_newrdn = {bv_len = 0,
> bv_val = 0x0}, lr_newsuperior = {bv_len = 0, bv_val = 0x0},
> lr_deleteoldrdn = 0}, ldif_op_ext = {lr_extop_oid = {bv_len = 0, bv_val = 0x0},
> lr_extop_data = {
> bv_len = 0, bv_val = 0x0}}, ldif_op_cmp = {lr_cmp_attr = {bv_len
> = 0, bv_val = 0x0}, lr_cmp_bvalue = {bv_len = 0, bv_val = 0x0}}}, lr_ctx = 0x0,
> lr_lines = 2,
> lr_lm = 0x6697d0, lr_mops = 0x0, lr_freeval = 0x6699e0 "", lr_vals =
> 0x669930, lr_btype = 0x669880}
> lrflags = 1
> rc = 0
> rbuf_bv = {bv_len = 0,
> bv_val = 0x66862e "objectclass: inetOrgPerson\nobjectclass:
> organizationalPerson\nobjectclass: person\nobjectclass: top\ncn: B\nsn: B\nuid:
> B\nmail: b(a)example.org\n"}
> #4 0x0000000000406cb7 in main (argc=6, argv=0x7fffffffdd98) at
> ldapmodify.c:316
> rbuf = 0x668610 "dn"
> rejbuf = 0x0
> rejfp = 0x0
> ldiffp = 0x6600a0
> ldifdummy = {fp = 0x0, prev = 0x0}
> matched_msg = 0x448790 "H\211l$\330L\211d$\340H\215-\003\060!"
> error_msg = 0x8000<Address 0x8000 out of bounds>
> rc = 0
> retval = 0
> ldifrc = 1
> len = 4491152
> i = 0
> lineno = 1
> nextline = 11
> lmax = 4119
> c = {{ldctl_oid = 0x7fe0f05<Address 0x7fe0f05 out of bounds>,
> ldctl_value = {bv_len = 5044973646, bv_val = 0x0}, ldctl_iscritical = 0
> '\000'}}
> (gdb) frame 1
> #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0,
> linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1,
> ctx=0x0) at ldifutil.c:399
> 399 if ( !BV_CASEMATCH( lr->lr_btype+i,&bv )) {
> (gdb) p *(lr->lr_btype+1)
> $1 = {bv_len = 0, bv_val = 0x668627 "dc=com"}
> (gdb)
>
> bv_len is set incorrectly to zero and therefore the string will be compared
> against bv, which is a "null string".
>
> I have uploaded patch to address this issue.
>
> With the patch applied, the output is following:
>
> ./ldapmodify -a -x -f /tmp/invalid.ldif -d2048
> ldif_parse_line: missing ':' after dc=com
> ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain,"
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 3 months
Re: (ITS#6977) ldapwhoami minor verbose bugfix patch submission
by hyc＠symas.com
checker(a)d6.com wrote:
> Full_Name: Chris Hecker
> Version: 2.4.25
> OS: centos 5.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (98.248.126.162)
>
>
> Hi, ldapwhoami erroneously prints the "Result: Success (0)" string even if -v is
> not specified due to a minor bug in the code. Here is a fix. I am running
> 2.3.43, but just checked the latest repository version and the bug is still
> there (although at line 203 now), so I marked the version above as latest.
>
> Thanks,
> Chris
It seems to me the better fix would be to change ldap_parse_result() to not
populate matcheddn or text when their values are zero-length. Kurt, any
particular reason things should continue to work as they currently do?
>
> --- old/openldap-2.3.43/clients/tools/ldapwhoami.c 2008-02-11
> 17:24:07.000000000 -0600
> +++ openldap-2.3.43/clients/tools/ldapwhoami.c 2011-06-21 14:15:28.000000000
> -0500
> @@ -215,7 +215,7 @@
>
> skip:
> if ( verbose || ( code != LDAP_SUCCESS ) ||
> - matcheddn || text || refs || ctrls )
> + (matcheddn&& *matcheddn) || (text&& *text) || refs || ctrls )
> {
> printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code
> );
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 3 months
Re: (ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by hyc＠symas.com
jvcelak(a)redhat.com wrote:
> Full_Name: Jan Vcelak
> Version: 2.5.25
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/jvcelak-20110622-ldif-split-indent-segfau...
> Submission from: (NULL) (209.132.186.34)
>
>
> Hello,
>
> input LDIF file with splitted lines which are indented incorrectly causes
> SEGFAULT of a client tool. Let me show:
Your example doesn't SEGV for me. Anyway, I've committed a different patch to
master for this issue.
>
> $ cat /tmp/invalid.ldif
> dn: cn=B,dc=my-domain,
> dc=com
> objectclass: inetOrgPerson
> objectclass: organizationalPerson
> objectclass: person
> objectclass: top
> cn: B
> sn: B
> uid: B
> mail: b(a)example.org
>
> $ ldapmodify -a -x -f /tmp/invalid.ldif -d2048
> ldif_parse_line: missing ':' after dc=com
> ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain,"
> Segmentation fault (core dumped)
>
>
> (gdb) bt full
> #0 __strcasecmp_l_ssse3 () at ../sysdeps/x86_64/strcmp.S:214
> No locals.
> #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0,
> linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1,
> ctx=0x0) at ldifutil.c:399
> fv = 0
> line = 0x668627 "dc=com"
> dn = 0x668614 "cn=B,dc=my-domain,"
> rc = -9
> modop = 0
> expect_modop = 0
> expect_sep = 0
> ldapadd = 1
> new_entry = 1
> delete_entry = 0
> got_all = 0
> pmods = 0x6697e8
> version = 0
> pctrls = 0x0
> i = 1
> j = 0
> k = -1
> idn = 1
> nmods = 1
> bvl = 0x6697f8
> bv = {bv_len = 0, bv_val = 0x0}
> __PRETTY_FUNCTION__ = "ldap_parse_ldif_record_x"
> #2 0x000000000042e524 in ldap_parse_ldif_record (rbuf=0x7fffffffdbb0,
> linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1) at
> ldifutil.c:565
> No locals.
> #3 0x0000000000406ff8 in process_ldif_rec (rbuf=0x668610 "dn", linenum=1) at
> ldapmodify.c:404
> lr = {lr_op = 0, lr_dn = {bv_len = 18, bv_val = 0x668614
> "cn=B,dc=my-domain,"}, lr_ctrls = 0x0, ldif_ops = {lr_mods = 0x0, ldif_op_rename
> = {lr_newrdn = {bv_len = 0,
> bv_val = 0x0}, lr_newsuperior = {bv_len = 0, bv_val = 0x0},
> lr_deleteoldrdn = 0}, ldif_op_ext = {lr_extop_oid = {bv_len = 0, bv_val = 0x0},
> lr_extop_data = {
> bv_len = 0, bv_val = 0x0}}, ldif_op_cmp = {lr_cmp_attr = {bv_len
> = 0, bv_val = 0x0}, lr_cmp_bvalue = {bv_len = 0, bv_val = 0x0}}}, lr_ctx = 0x0,
> lr_lines = 2,
> lr_lm = 0x6697d0, lr_mops = 0x0, lr_freeval = 0x6699e0 "", lr_vals =
> 0x669930, lr_btype = 0x669880}
> lrflags = 1
> rc = 0
> rbuf_bv = {bv_len = 0,
> bv_val = 0x66862e "objectclass: inetOrgPerson\nobjectclass:
> organizationalPerson\nobjectclass: person\nobjectclass: top\ncn: B\nsn: B\nuid:
> B\nmail: b(a)example.org\n"}
> #4 0x0000000000406cb7 in main (argc=6, argv=0x7fffffffdd98) at
> ldapmodify.c:316
> rbuf = 0x668610 "dn"
> rejbuf = 0x0
> rejfp = 0x0
> ldiffp = 0x6600a0
> ldifdummy = {fp = 0x0, prev = 0x0}
> matched_msg = 0x448790 "H\211l$\330L\211d$\340H\215-\003\060!"
> error_msg = 0x8000<Address 0x8000 out of bounds>
> rc = 0
> retval = 0
> ldifrc = 1
> len = 4491152
> i = 0
> lineno = 1
> nextline = 11
> lmax = 4119
> c = {{ldctl_oid = 0x7fe0f05<Address 0x7fe0f05 out of bounds>,
> ldctl_value = {bv_len = 5044973646, bv_val = 0x0}, ldctl_iscritical = 0
> '\000'}}
> (gdb) frame 1
> #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0,
> linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1,
> ctx=0x0) at ldifutil.c:399
> 399 if ( !BV_CASEMATCH( lr->lr_btype+i,&bv )) {
> (gdb) p *(lr->lr_btype+1)
> $1 = {bv_len = 0, bv_val = 0x668627 "dc=com"}
> (gdb)
>
> bv_len is set incorrectly to zero and therefore the string will be compared
> against bv, which is a "null string".
>
> I have uploaded patch to address this issue.
>
> With the patch applied, the output is following:
>
> ./ldapmodify -a -x -f /tmp/invalid.ldif -d2048
> ldif_parse_line: missing ':' after dc=com
> ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain,"
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 3 months
(ITS#6979) test062 portability
by richton＠nbcs.rutgers.edu
Full_Name: Aaron Richton
Version: RE24
OS: irrelevant
URL:
Submission from: (NULL) (166.217.78.192)
It looks like checking the function exit isn't portable; maybe some kind of
bash-ism. It looks like the code was on the path to communicating the retval via
$RCOUT file already? As such, here's one quick workaround, although I'd love
something a bit more elegant:
--- test062-config-delete~ 2011-06-23 07:21:01.387583000 -0400
+++ test062-config-delete 2011-06-23 07:21:14.884787000 -0400
@@ -106,7 +106,7 @@
(
$LDAPSEARCH -D cn=config -H $URI1 -y $CONFIGPWF -bcn=config -E \!sync=rp
>/dev/null 2>&1
RC=$?
- touch $RCOUT
+ echo $RC > $RCOUT
exit $RC
) &
@@ -137,7 +137,7 @@
if test -f "$RCOUT" ; then
wait $SEARCHPID
- SEARCHRC=$?
+ SEARCHRC=`cat $RCOUT`
echo "Checking return code of backgrounded RefreshAndPersist search
..."
if test $SEARCHRC != 52 ; then
echo "Error: Backgrounded ldapsearch did return the wrong error
code: $SEARCHRC"
12 years, 3 months
(ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by jvcelak＠redhat.com
Full_Name: Jan Vcelak
Version: 2.5.25
OS: Linux
URL: ftp://ftp.openldap.org/incoming/jvcelak-20110622-ldif-split-indent-segfau...
Submission from: (NULL) (209.132.186.34)
Hello,
input LDIF file with splitted lines which are indented incorrectly causes
SEGFAULT of a client tool. Let me show:
$ cat /tmp/invalid.ldif
dn: cn=B,dc=my-domain,
dc=com
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
cn: B
sn: B
uid: B
mail: b(a)example.org
$ ldapmodify -a -x -f /tmp/invalid.ldif -d2048
ldif_parse_line: missing ':' after dc=com
ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain,"
Segmentation fault (core dumped)
(gdb) bt full
#0 __strcasecmp_l_ssse3 () at ../sysdeps/x86_64/strcmp.S:214
No locals.
#1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0,
linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1,
ctx=0x0) at ldifutil.c:399
fv = 0
line = 0x668627 "dc=com"
dn = 0x668614 "cn=B,dc=my-domain,"
rc = -9
modop = 0
expect_modop = 0
expect_sep = 0
ldapadd = 1
new_entry = 1
delete_entry = 0
got_all = 0
pmods = 0x6697e8
version = 0
pctrls = 0x0
i = 1
j = 0
k = -1
idn = 1
nmods = 1
bvl = 0x6697f8
bv = {bv_len = 0, bv_val = 0x0}
__PRETTY_FUNCTION__ = "ldap_parse_ldif_record_x"
#2 0x000000000042e524 in ldap_parse_ldif_record (rbuf=0x7fffffffdbb0,
linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1) at
ldifutil.c:565
No locals.
#3 0x0000000000406ff8 in process_ldif_rec (rbuf=0x668610 "dn", linenum=1) at
ldapmodify.c:404
lr = {lr_op = 0, lr_dn = {bv_len = 18, bv_val = 0x668614
"cn=B,dc=my-domain,"}, lr_ctrls = 0x0, ldif_ops = {lr_mods = 0x0, ldif_op_rename
= {lr_newrdn = {bv_len = 0,
bv_val = 0x0}, lr_newsuperior = {bv_len = 0, bv_val = 0x0},
lr_deleteoldrdn = 0}, ldif_op_ext = {lr_extop_oid = {bv_len = 0, bv_val = 0x0},
lr_extop_data = {
bv_len = 0, bv_val = 0x0}}, ldif_op_cmp = {lr_cmp_attr = {bv_len
= 0, bv_val = 0x0}, lr_cmp_bvalue = {bv_len = 0, bv_val = 0x0}}}, lr_ctx = 0x0,
lr_lines = 2,
lr_lm = 0x6697d0, lr_mops = 0x0, lr_freeval = 0x6699e0 "", lr_vals =
0x669930, lr_btype = 0x669880}
lrflags = 1
rc = 0
rbuf_bv = {bv_len = 0,
bv_val = 0x66862e "objectclass: inetOrgPerson\nobjectclass:
organizationalPerson\nobjectclass: person\nobjectclass: top\ncn: B\nsn: B\nuid:
B\nmail: b(a)example.org\n"}
#4 0x0000000000406cb7 in main (argc=6, argv=0x7fffffffdd98) at
ldapmodify.c:316
rbuf = 0x668610 "dn"
rejbuf = 0x0
rejfp = 0x0
ldiffp = 0x6600a0
ldifdummy = {fp = 0x0, prev = 0x0}
matched_msg = 0x448790 "H\211l$\330L\211d$\340H\215-\003\060!"
error_msg = 0x8000 <Address 0x8000 out of bounds>
rc = 0
retval = 0
ldifrc = 1
len = 4491152
i = 0
lineno = 1
nextline = 11
lmax = 4119
c = {{ldctl_oid = 0x7fe0f05 <Address 0x7fe0f05 out of bounds>,
ldctl_value = {bv_len = 5044973646, bv_val = 0x0}, ldctl_iscritical = 0
'\000'}}
(gdb) frame 1
#1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0,
linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1,
ctx=0x0) at ldifutil.c:399
399 if ( !BV_CASEMATCH( lr->lr_btype+i, &bv )) {
(gdb) p *(lr->lr_btype+1)
$1 = {bv_len = 0, bv_val = 0x668627 "dc=com"}
(gdb)
bv_len is set incorrectly to zero and therefore the string will be compared
against bv, which is a "null string".
I have uploaded patch to address this issue.
With the patch applied, the output is following:
./ldapmodify -a -x -f /tmp/invalid.ldif -d2048
ldif_parse_line: missing ':' after dc=com
ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain,"
12 years, 3 months
(ITS#6977) ldapwhoami minor verbose bugfix patch submission
by checker＠d6.com
Full_Name: Chris Hecker
Version: 2.4.25
OS: centos 5.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (98.248.126.162)
Hi, ldapwhoami erroneously prints the "Result: Success (0)" string even if -v is
not specified due to a minor bug in the code. Here is a fix. I am running
2.3.43, but just checked the latest repository version and the bug is still
there (although at line 203 now), so I marked the version above as latest.
Thanks,
Chris
--- old/openldap-2.3.43/clients/tools/ldapwhoami.c 2008-02-11
17:24:07.000000000 -0600
+++ openldap-2.3.43/clients/tools/ldapwhoami.c 2011-06-21 14:15:28.000000000
-0500
@@ -215,7 +215,7 @@
skip:
if ( verbose || ( code != LDAP_SUCCESS ) ||
- matcheddn || text || refs || ctrls )
+ (matcheddn && *matcheddn) || (text && *text) || refs || ctrls )
{
printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code
);
12 years, 3 months
Re: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by hyc＠symas.com
ctcard(a)hotmail.com wrote:
>> Don't send HTML emails to the ITS.Apologies.
>>
>> I'm unable to reproduce the error you're talking about. Please provide a
>> config that demonstrates the error, and the complete ldapsearch command
>> invocation.
> The original submission contained the ldapsearch command:
> ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E
> \!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10
I also asked for a server config that demonstrates the problem. When you omit
key details, particularly when they are specificly requested, you only slow
down the troubleshooting process.
From your description in this email, I'm guessing that you've configured
sssvlv as a global overlay instead of on a specific database. That's why the
overlay is running before fe_op_search. I was testing with the overlay on a
specific database. You should probably change your server configuration as a
workaround until this gets patched.
> (I just suppressed the bind dn, base dn and password)
> The important aspect of the search command is that it is doing a server-sidesort on the mail attribute, is asking for a virtual list view, but is letting the size default to zero (which should mean unlimited).
>>
>> Your patch cannot be correct since limits_check() is already called by the
>> frontend at the beginning of every search operation.
>
> Not in my experience.
> As far as I can see limits_check() is called only in fe_op_search() in search.c, and when debugging I found that fe_op_search() was being called from overlay_op_walk() in backover.c.
>
> When the ldapsearch command is run, it sends a search request to slapd, which returns the first 11 records found, in order of the mail attribute. Then ldapsearch prompts
> Press [before/after(/offset/count|:value)] Enter for the next window.
> and on hitting enter ldapsearch sends the next request to slapd. This time the request gets handled by sssvlv_op_search() before fe_op_search() is called, because there is an active session.
> int overlay_op_walk( Operation *op, SlapReply *rs, slap_operation_t which, slap_overinfo *oi, slap_overinst *on){ BI_op_bind **func; int rc = SLAP_CB_CONTINUE;
> for (; on; on=on->on_next ) { func =&on->on_bi.bi_op_bind; if ( func[which] ) { op->o_bd->bd_info = (BackendInfo *)on; rc = func[which]( op, rs ); /*<--- sssvlv_op_search() called here */ if ( rc != SLAP_CB_CONTINUE ) break; } } if ( rc == SLAP_CB_BYPASS ) rc = SLAP_CB_CONTINUE;
> func =&oi->oi_orig->bi_op_bind; if ( func[which]&& rc == SLAP_CB_CONTINUE ) { op->o_bd->bd_info = oi->oi_orig; rc = func[which]( op, rs ); /*<--- fe_op_search() called here */ }
> Chris
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 3 months
RE: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmail.com
> Don't send HTML emails to the ITS.Apologies.
>
> I'm unable to reproduce the error you're talking about. Please provide a
> config that demonstrates the error, and the complete ldapsearch command
> invocation.
The original submission contained the ldapsearch command:
ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E
\!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10
(I just suppressed the bind dn, base dn and password)
The important aspect of the search command is that it is doing a server-sidesort on the mail attribute, is asking for a virtual list view, but is letting the size default to zero (which should mean unlimited).
>
> Your patch cannot be correct since limits_check() is already called by the
> frontend at the beginning of every search operation.
Not in my experience.
As far as I can see limits_check() is called only in fe_op_search() in search.c, and when debugging I found that fe_op_search() was being called from overlay_op_walk() in backover.c.
When the ldapsearch command is run, it sends a search request to slapd, which returns the first 11 records found, in order of the mail attribute. Then ldapsearch prompts
Press [before/after(/offset/count|:value)] Enter for the next window.
and on hitting enter ldapsearch sends the next request to slapd. This time the request gets handled by sssvlv_op_search() before fe_op_search() is called, because there is an active session.
int overlay_op_walk( Operation *op, SlapReply *rs, slap_operation_t which, slap_overinfo *oi, slap_overinst *on){ BI_op_bind **func; int rc = SLAP_CB_CONTINUE;
for (; on; on=on->on_next ) { func = &on->on_bi.bi_op_bind; if ( func[which] ) { op->o_bd->bd_info = (BackendInfo *)on; rc = func[which]( op, rs ); /* <--- sssvlv_op_search() called here */ if ( rc != SLAP_CB_CONTINUE ) break; } } if ( rc == SLAP_CB_BYPASS ) rc = SLAP_CB_CONTINUE;
func = &oi->oi_orig->bi_op_bind; if ( func[which] && rc == SLAP_CB_CONTINUE ) { op->o_bd->bd_info = oi->oi_orig; rc = func[which]( op, rs ); /* <--- fe_op_search() called here */ }
Chris
12 years, 3 months
(ITS#6976) Build OpenLDAP on Solaris : error : could not locate usable POSIX Threads
by chathuraka.senaratne＠gmail.com
Full_Name: Samarasooriyage Gayan Chathuraka Senaratne
Version: 3
OS: Solaris 64bit
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (202.69.193.78)
When I try to configure OpenLDAP on Solaris I get the following error messages.
I think I've set the library path environment variable to include the location
of libpthread.
configure: WARNING: pthread.h: present but cannot be compiled
configure: WARNING: pthread.h: check for missing prerequisite headers?
configure: WARNING: pthread.h: see the Autoconf documentation
configure: WARNING: pthread.h: section "Present But Cannot Be Compiled"
configure: WARNING: pthread.h: proceeding with the preprocessor's result
configure: WARNING: pthread.h: in the future, the compiler will take precedence
configure: WARNING: ## --------------------------------------------- ##
configure: WARNING: ## Report this to <http://www.openldap.org/its/> ##
configure: WARNING: ## --------------------------------------------- ##
checking for pthread.h... yes
checking POSIX thread version... 6
checking for LinuxThreads pthread.h... no
checking for GNU Pth pthread.h... no
checking sched.h usability... yes
checking sched.h presence... yes
checking for sched.h... yes
checking for pthread_create in default libraries... no
checking for pthread link with -kthread... no
checking for pthread link with -pthread... no
checking for pthread link with -pthreads... no
checking for pthread link with -mthreads... no
checking for pthread link with -thread... no
checking for pthread link with -lpthread -lmach -lexc -lc_r... no
checking for pthread link with -lpthread -lmach -lexc... no
checking for pthread link with -lpthread -Wl,-woff,85... no
checking for pthread link with -lpthread... no
checking for pthread link with -lc_r... no
checking for pthread link with -threads... no
checking for pthread link with -lpthreads -lmach -lexc -lc_r... no
checking for pthread link with -lpthreads -lmach -lexc... no
checking for pthread link with -lpthreads -lexc... no
checking for pthread link with -lpthreads... no
configure: error: could not locate usable POSIX Threads
Please help to solve this.
Thanks Gayan
12 years, 3 months
