openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6598) EXOP to return number of children of a (sub)tree
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

> masarati(a)aero.polimi.it wrote: >>> quanah(a)zimbra.com wrote: >>>> Full_Name: Quanah Gibson-Mount >>>> Version: NA >>>> OS: NA >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (75.111.45.108) >>>> >>>> >>>> It would be extremely useful to have an extended operation that allows >>>> querying >>>> the number of children of a given (sub)tree, so that one can avoid >>>> iterating >>>> through the entire subtree to determine this number. >>>> >>> Might as well ask for the numSubordinates operational attribute to be >>> implemented instead, this doesn't seem to merit a new exop. And for >>> numSubordinates, see the -devel archives for why we chose not to >>> implement >>> it. >>> >>> In either case, the server still needs to iterate over all entries >>> internally, >>> and the result has to take ACLs and entry disclosure into account. >> >> An exop would allow to easily discriminate between intentional and >> "catchall" requests, like "+". Moreover, it might make sense to >> discriminate at least between subtree and onelevel number of >> subordinates; >> this would require two distinct operational attributes, or a parameter >> in >> the exop. >> >> I'm not endorsing either solution, I'm just pointing out possible pros >> and >> cons. > > If you want to be able to distinguish results based on scope then it makes > more sense to just define a Search control. Like No-op - count the entries > that would be returned, instead of returning them. (And bypassing the > sizelimit too, but probably not bypassing timelimit.) I'm drafting the code to implement this no-op search. The semantics consists in a control request in a search request that results in returning no intermediate responses, only a final response with a control response that contains summary information on what the search would have done. The request control value is empty. The response control value contains: - the error that the search would have returned if it were performed regularly (should differ from the one actually returned only in case of sizelimit exceeded) - the number of entries that would be returned - the number of search references that would be returned The search request should request no attributes (in any case no attributes will be returned); I'm not sure whether it is preferable to simply ignore requested attrs or the control must require that no attrs ("1.1") be explicitly requested; I favor the first (ignore req attrs) to ease interoperability; similarly, attrsOnly can be safely ignored. The rest of the search should be dealt with as usual (base, scope, filter, alias dereferencing and so on), as well as ACL. This allows, for example, to count immediate children (scope=onelevel), to count subtrees (scope=subtree); the filter allows to select what is counted; and so on. The code is almost done; am I missing anything? In case, let me know so I can fix it before committing. Thanks, p.

1 0

ITS#6636
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

The ITS is intended to track software bugs (see the charter for details). Software usage requests should be directed to openldap-technical(a)openldap.org (see the charter for details). This ITS will be closed. p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

> Hello, > >> Hi. I don't have time to work at this right now, but I think the >> solution >> would be to modify slapo-chain(5) so that when a referral's DN is "" and >> the DN in the original request is not "", to use that DN instead. The >> original request DN can be found in op->o_req_dn. > > we tested the following - with success: > > Just replace in servers/slapd/back-ldap/chain.c, function > ldap_chain_op(), line 485-486: > > op->o_req_dn = pdn; > op->o_req_ndn = ndn; > > With: > > if (pdn.bv_len > 0) { > op->o_req_dn = pdn; > } > if (ndn.bv_len > 0) { > op->o_req_ndn = ndn; > } > > It would be great if this came into the official code. This issue was fixed consistently in HEAD code more than a month ago, please test it and report, so in case it works the ITS can be closed and the fix released. Thanks, p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by jochen＠keutel.de 05 Sep '10

05 Sep '10

Hello, > Hi. I don't have time to work at this right now, but I think the solution > would be to modify slapo-chain(5) so that when a referral's DN is "" and > the DN in the original request is not "", to use that DN instead. The > original request DN can be found in op->o_req_dn. we tested the following - with success: Just replace in servers/slapd/back-ldap/chain.c, function ldap_chain_op(), line 485-486: op->o_req_dn = pdn; op->o_req_ndn = ndn; With: if (pdn.bv_len > 0) { op->o_req_dn = pdn; } if (ndn.bv_len > 0) { op->o_req_ndn = ndn; } It would be great if this came into the official code. Regards, Jochen.

1 0

Re: (ITS#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 03 Sep '10

03 Sep '10

--On Friday, September 03, 2010 01:23:17 AM -0700 Bill MacAllister <whm(a)stanford.edu> wrote: The problem with the database was only coincidental. Restoring the database got the failing replica past the problem replication event. In the replica pool of 6 servers we have seen the problem on there of the servers. In thinking about this more it is unlikely that it is a slave problem since the slaves have been in use for about 6 weeks and we did not see the problem. Only when we changed the master to 2.4.23 did we see the problem. I have captured a master debug log of the problem event. It is at http://www.stanford.edu/~whm/files/master-debug.txt. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 03 Sep '10

03 Sep '10

Worked on this a bit more and in the end rebooted the server just to be sure I had a clean environment. When the system came back up slapd refused to start, the bdb database was corrupt. I reloaded from the master and replication is again working. Not sure why a reboot was required to uncover the error. I had stopped and started slapd multiple times without an errors being reported. Sorry for the inbox pollution. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

(ITS#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 02 Sep '10

02 Sep '10

Full_Name: Bill MacAllister Version: 2.4.23-1 OS: Debian Lenny URL: http://www.stanford.edu/~whm/files/ldap-replication-error.txt Submission from: (NULL) (99.55.172.208) I just replaced a 2.3.43 OpenLDAP master with a 2.4.23-1 master. There are 6 slaves all running 2.4.23-1. After reloading the master database, I confirmed that replication was working my making some changes and then examining contextCSNs. Sometime later replication stopped on one of the servers. Looking at the log on the failing slave I saw: Sep 2 22:12:53 directory3 slapd[7005]: do_syncrep2: rid=000 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Sep 2 22:12:53 directory3 slapd[7005]: do_syncrep2: rid=000 (-1) Can't contact LDAP server Sep 2 22:12:53 directory3 slapd[7005]: do_syncrepl: rid=000 rc -1 retrying On the master I saw: Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 fd=38 ACCEPT from IP=171.67.218.156:44519 (IP=0.0.0.0:389) Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=0 BIND dn="" method=163 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=1 BIND dn="" method=163 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 BIND dn="" method=163 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 BIND authcid="ldap/directory3.stanford.edu(a)stanford.edu" authzid="ldap/directory3.stanford.edu(a)stanford.edu" Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 BIND dn="cn=directory3,cn=ldap,cn=operational,dc=stanford,dc=edu" mech=GSSAPI sasl_ssf=56 ssf=56 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 RESULT tag=97 err=0 text= Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=3 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=3 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 fd=38 closed (connection lost on write) Running slapd on the failing slave with -d -1 I saw: =>do_syncrep2 rid=000 ldap_result ld 0x1c07000 msgid 4 wait4msg ld 0x1c07000 msgid 4 (timeout 0 usec) wait4msg continue ld 0x1c07000 msgid 4 all 0 ** ld 0x1c07000 Connections: * host: directory-master.stanford.edu port: 389 (default) refcnt: 2 status: Connected last used: Thu Sep 2 22:12:53 2010 ** ld 0x1c07000 Outstanding Requests: * msgid 4, origid 4, status InProgress outstanding referrals 0, parent count 0 ld 0x1c07000 request count 1 (abandoned 0) ** ld 0x1c07000 Response Queue: Empty ld 0x1c07000 response count 0 ldap_chkResponseList ld 0x1c07000 msgid 4 all 0 ldap_chkResponseList returns ld 0x1c07000 NULL ldap_int_select read1msg: ld 0x1c07000 msgid 4 all 0 ber_get_next sasl_generic_read: want=4, got=4 0000: 00 00 00 78 ...x sasl_generic_read: want=120, got=120 ... lots of output ... sasl_generic_read: want=45833, got=0 ldap_read: want=8, got=0 ber_get_next failed. ldap_err2string do_syncrep2: rid=000 (-1) Can't contact LDAP server I am including a pointer to the complete debug log. Looks like something in the sasl support is unhappy. We are using libsasl2-modules-gssapi-heimdal 2.1.23.dfsg1-5~sbp50+2. Strange to me that this one server is having a problem. There are actually 5 slaves that are working just fine. Here are current contextCSNs for the systems. directory-master contextCSN: 20100903060040.713677Z#000000#000#000000 directory1 contextCSN: 20100903060040.713677Z#000000#000#000000 directory2 contextCSN: 20100903060040.713677Z#000000#000#000000 directory3 contextCSN: 20100903015531.064407Z#000000#000#000000 directory4 contextCSN: 20100903060040.713677Z#000000#000#000000 directory11 contextCSN: 20100903060040.713677Z#000000#000#000000 directory12 contextCSN: 20100903060040.713677Z#000000#000#000000 What else should I look at? Bill

1 0

(ITS#6638) ldapseach segfault on OSX
by quanah＠zimbra.com 02 Sep '10

02 Sep '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Mac OSX 10.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When querying AD from a mac, we found that we can segfault ldapsearch. This segfault does not happen when running the same query from linux. Here is the backtrace: (gdb) thr apply all bt full Thread 1 (core thread 0): #0 0x00007fff80697180 in strlen () No symbol table info available. #1 0x000000010008ae22 in ber_put_string (ber=0x100401480, str=0x686372616573 <Address 0x686372616573 out of bounds>, tag=18446744073709551615) at encode.c:273 No locals. #2 0x000000010008be20 in ber_printf (ber=0x100401480, fmt=0x10005f5e4 "s{") at encode.c:575 ap = {{ gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7fff5fbfeb00, reg_save_area = 0x7fff5fbfea40 }} s = 0x686372616573 <Address 0x686372616573 out of bounds> ss = (char **) 0x0 bv = (struct berval *) 0x0 bvp = (struct berval **) 0x7fff8069dc3b rc = 0 i = 584234 len = 140734799800880 #3 0x00000001000586d8 in ldap_create_deref_control_value (ld=0x100401130, ds=0x100400130, value=0x100016a20) at deref.c:68 j = 1 ber = (BerElement *) 0x100401480 tag = 18 i = 1 __func__ = "\000\000\000\000\000\000\000Critical extension is una" #4 0x0000000100003a28 in main (argc=13, argv=0x7fff5fbff4f8) at ldapsearch.c:1090 i = 0 filtpattern = 0x7fff5fbff739 "(CN=SE-EMEA-OEM)" attrs = (char **) 0x7fff5fbff558 line = '\0' <repeats 504 times>, "ï¿œï¿œï¿œ_ï¿œ\000\000ï¿œï¿œ_ï¿œ\000\000\006\003ï¿œï¿œï¿œ\000\000\000ï¿œ_ï¿œ\000\000ï¿œ&ï¿œ_ï¿œ", '\0' <repeats 18 times>, "ï¿œï¿œï¿œ_ï¿œ\000\000\020ï¿œ_ï¿œ\000\000ï¿œï¿œ_ï¿œ\000\000ï¿œ\005ï¿œ_ï¿œ\000\000ï¿œï¿œ~L\000\000\000\000=ï¿œ\002\000ï¿œ\000\000ï¿œ\000\000\000Ì¹ï¿œT\035ï¿œ_ï¿œï¿œdYhMï¿œ6T{ï¿œbjï¿œ\033\020v:ï¿œ*ï¿œb7\003a/ï¿œMï¿œï¿œï¿œï¿œï¿œï¿œ8ï¿œLï¿œï¿œXï¿œ\025Cï¿œÔ¶&Úxï¿œ6cï¿œOï¿œï¿œDpb*\030\tdï¿œï¿œï¿œ^biï¿œ}ï¿œï¿œ&ï¿œyï¿œfï¿œq"... fp = (FILE *) 0x0 rc = 0 rc1 = 0 i = 0 first = 0 ld = (LDAP *) 0x100401130 seber = (BerElement *) 0x0 vrber = (BerElement *) 0x0 syncber = (BerElement *) 0x0 syncbvalp = (struct berval *) 0x0 err = 0 Search was: /opt/zimbra/openldap/bin/ldapsearch -LLL -D ... -w ... -H ldap://...:3268 -x -E deref=member:mail "(CN=test)" mail Segmentation fault (core dumped)

1 0

objectClass index from slapd.conf is not working
by tim stone 02 Sep '10

02 Sep '10

Hello, I've a strange behavior while using index objectClass for searching. In my slapd.conf I have defined the index in the database section: index objectClass eq Other indexes follows in the config. All of them working fine. If I search via ldapsearch like: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(objectclass=Guest)" I can find following Message in the syslog (loglevel -1): Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read: failed (-30989) Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=0, first=0, last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=0 first=0 last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_filter_candidates Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read 355545 candidates Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=-1, first=228, last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: <= test_filter 5 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search: 112277 does not match filter Sep 1 14:02:52 LDAP01 slapd[17856]: entry_decode: "cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= entry_decode(cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_dn2id("cn=aaa,cn=bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_dn2id: got id=0x1b696 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856] ... all other entires following... As result, the entires are found, but not in the index and the search takes a very long time. Afther this, I have rebuild the complete database via slapcat/slapadd, rebuild the index for objetClass, but nothing helped. In tried the test above on: * OpenSuSE 11.1 and openLDAP 2.4.21 and 2.4.23 (linked against libdb-4.5) * OpenSuSE 11.0 and openLDAP 2.4.9 (linked against libdb-4.5) * Debian Lenny and openLDAP 2.4.11 (linked against libdb-4.2) with different databases and a search against a objectClass. If I try another index (not objectClass) from the slapd.conf the index works, example: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(Pk=1234-234)" Sep 1 14:03:44 LDAP01 slapd[17856]: => bdb_equality_candidates (Pk) Sep 1 14:03:44 LDAP01 slapd[17856]: => key_read Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_index_read 1 candidates Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=1, first=112838, last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: bdb_search_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: => test_filter Sep 1 14:03:44 LDAP01 slapd[17856]: EQUALITY Sep 1 14:03:44 LDAP01 slapd[17856]: <= test_filter 6 Sep 1 14:03:44 LDAP01 slapd[17856]: => send_search_entry: conn 1002 dn="cn=Fff,cn=Eee,... Sep 1 14:03:44 LDAP01 slapd[17856]: <= send_search_entry: conn 1002 exit. Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_result: conn=1002 op=1 p=3 Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_response: msgid=2 tag=101 err=0 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_get(12): got connid=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_read(12): checking for input on id=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: op tag 0x42, time 1283342624 Sep 1 14:03:44 LDAP01 slapd[17856]: conn=1002 op=2 do_unbind Sep 1 14:03:44 LDAP01 slapd[17856]: connection_close: conn=1002 sd=12 Why does only the objectClass index not work? The only difference I can see, is that all other indexes are based on "normal" attributes. I don't know, if it is necessary, but for objectClass I can't find a attribute definition in the schema. In the core.schema is the attribute definition for objectClass deactivated (aka #)... Kindly regards Tim Stone

2 1

Re: (ITS#6637) valgrind issues in SSL code
by hyc＠symas.com 30 Aug '10

30 Aug '10

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Linux 2.6 > URL: http://www.stanford.edu/~quanah/valgrind.txt > Submission from: (NULL) (75.111.45.108) > > > Numerous > ==30949== Conditional jump or move depends on uninitialised value(s) > and > Use of uninitialised value of size 8 > > errors. See: > http://www.stanford.edu/~quanah/valgrind.txt All irrelevant. OpenSSL is intentionally written to use uninit'd bytes in its random number generators etc., and none of this is an OpenLDAP issue anyway. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs