- openldap-bugs - openldap.org

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 04 Sep '10

04 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 03 Sep '10

03 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 31 Aug '10

31 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

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by matheus.morais＠gmail.com 31 Aug '10

31 Aug '10

--0016364ec88477ac37048f173de5 Content-Type: text/plain; charset=ISO-8859-1 Hi there, <quote> That's... bizarre. Even slapd doesn't behave that way. Nor any other program comes immediately to mind. </quote> Even sounds like an strange behave, as Quanah said, this information should be included on ldapsearch man page IMHO. I believe that the following patch could close this BUG: --- openldap/doc/man/man1/ldapsearch.1.orig 2010-08-31 01:25:23.000000000 -0300 +++ openldap/doc/man/man1/ldapsearch.1 2010-08-31 01:37:50.000000000 -0300 @@ -7,6 +7,8 @@ .SH SYNOPSIS .B ldapsearch [\c +.BR \-V [ V ]] +[\c .BR \-n ] [\c .BR \-c ] @@ -107,6 +109,11 @@ Option \fI\-L\fP controls the format of the output. .SH OPTIONS .TP +.BR \-V [ V ] +Prints the ldapsearch version and proceeds with the search. +.B \-VV +Prints the ldapsearch version and quit. +.TP .B \-n Show what would be done, but don't actually perform the search. Useful for debugging in conjunction with \fB\-v\fP. Please review it. Thanks, Matheus Morais --0016364ec88477ac37048f173de5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi there, <quote> That's... bizarre. Even slapd doesn&#39= ;t behave that way. Nor any other program comes immediately to mind. </= quote> Even sounds like an strange behave, as Quanah said, this i= nformation should be included on ldapsearch man page IMHO. I believe that the following patch could close this BUG: --- ope= nldap/doc/man/man1/ldapsearch.1.orig=A0=A0=A0 2010-08-31 01:25:23.000000000= -0300 +++ openldap/doc/man/man1/ldapsearch.1=A0=A0=A0 2010-08-31 01:37:= 50.000000000 -0300 @@ -7,6 +7,8 @@ =A0.SH SYNOPSIS =A0.B ldapsearch =A0[\c +.BR \-= V [ V ]] +[\c =A0.BR \-n ] =A0[\c =A0.BR \-c ] @@ -107,6 +10= 9,11 @@ =A0Option \fI\-L\fP controls the format of the output. =A0.SH= OPTIONS =A0.TP +.BR \-V [ V ] +Prints the ldapsearch version and proceeds wit= h the search. +.B \-VV +Prints the ldapsearch version and quit. +.= TP =A0.B \-n =A0Show what would be done, but don't actually perfo= rm the search.=A0 Useful for =A0debugging in conjunction with \fB\-v\fP. Please review it. <br= >Thanks, Matheus Morais --0016364ec88477ac37048f173de5--

1 0

(ITS#6637) valgrind issues in SSL code
by quanah＠OpenLDAP.org 31 Aug '10

31 Aug '10

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 --Quanah

1 0

Re: (ITS#6633) test030-relay: Passwd ExOp failed (1)!
by michael＠stroeder.com 29 Aug '10

29 Aug '10

Seems to be fixed now.

1 0

Re: (ITS#6634) potential leak when ARG_BERVAL|ARG_OFFSET
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

> Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.72.165.149) > Submitted by: ando > > > config_get_vals() in the above case first duplicates the berval from the > pointer; then assigns it to "bv"; finally, it calls value_add_one(), which > further duplicates the berval. When ARG_STRING, instead, after the string > is > turned into a berval, ber_bvarray_add() is called. > > As far as I could tell, this only occurs for olcDbDirectory of back-ldif. Things seem to be a little bit more complicated: - when ARG_OFFSET && ARG_STRING, copy the string, then ber_bvarray_add() - when ARG_MAGIC && ARG_STRING, ber_bvarray_add() - when ARG_OFFSET && ARG_BERVAL, don't copy the string, value_add_one() - when ARG_MAGIC && ARG_BERVAL, value_add_one() A fix is coming. p.

1 0

(ITS#6635) when an undefined attribute is used in a presence filter, the temporary description can leak
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.149) Submitted by: ando A fix is coming. p.

1 0

(ITS#6634) potential leak when ARG_BERVAL|ARG_OFFSET
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.149) Submitted by: ando config_get_vals() in the above case first duplicates the berval from the pointer; then assigns it to "bv"; finally, it calls value_add_one(), which further duplicates the berval. When ARG_STRING, instead, after the string is turned into a berval, ber_bvarray_add() is called. As far as I could tell, this only occurs for olcDbDirectory of back-ldif. p.

1 0

Re: (ITS#6633) test030-relay: Passwd ExOp failed (1)!
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

*should* be fixed. Unnoticed side effect of ITS#6632 hack. Thanks, p.

1 0

(ITS#6633) test030-relay: Passwd ExOp failed (1)!
by michael＠stroeder.com 29 Aug '10

29 Aug '10

Full_Name: Michael Ströder Version: HEAD OS: Linux URL: Submission from: (NULL) (84.163.34.243) Please let me know if you need logs. $ ./run -b bdb test030 Cleaning up test run directory leftover from previous run. Running ./scripts/test030-relay for bdb... running defines.sh Testing virtual naming context mapping with relay ldap meta backend(s)... Using relay backend... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Searching base="o=Esempio,c=IT"... Searching base="o=Beispiel,c=DE"... Modifying database "o=Beispiel,c=DE"... Modifying database "o=Example,c=US"... Searching base="o=Example,c=US"... Searching base="o=Esempio,c=IT"... Searching filter="(objectClass=referral)" attrs="'*' ref" base="dc=example,dc=com"... base="o=Example,c=US"... base="o=Esempio,c=IT"... Searching filter="(seeAlso=cn=all staff,ou=Groups,o=Example,c=US)" attrs="seeAlso" base="o=Example,c=US"... Searching filter="(uid=example)" attrs="uid" base="o=Example,c=US"... Searching filter="(member=cn=Another Added Group,ou=Groups,o=Example,c=US)" attrs="member" base="o=Example,c=US"... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Changing password to database "o=Example,c=US"... Passwd ExOp failed (1)!

1 0

Re: (ITS#6632) Core dump in test030 when using back-ldap
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

It is clearly slapo-rwm(5), whose cleanup function is not executed early enough when dealing with extended operations, since the latter delegate successful return to the frontend: modified logging... conn=1000 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=1000 op=1 PASSMOD id="cn=Added User,ou=Alumni Association,ou=People,o=Example,c=US" new ### conn=1000 op=1: passwd_extop: setting dn="cn=Added User,ou=Alumni Association,ou=People,o=Example,c=US" (0x4972608) ### conn=1000 op=1: rwm_extended: setting dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4972ed0) conn=1001 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=1001 op=1 PASSMOD id="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" new ### conn=1001 op=1: passwd_extop: setting dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4975ba8) ### conn=1001 op=1: passwd_extop: freeing dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4975ba8) ### conn=1000 op=1: passwd_extop: freeing dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4972ed0) ### conn=1000 op=1: rwm_op_rollback: freeing dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4972ed0) conn=1000 op=1 RESULT oid= err=0 text= ==23914== Thread 3: ==23914== Invalid read of size 1 ==23914== at 0x4006238: strlen (mc_replace_strmem.c:246) ==23914== by 0xCB184D: vfprintf (in /lib/libc-2.5.so) ==23914== by 0xCD1FD3: vsnprintf (in /lib/libc-2.5.so) ==23914== by 0x826B0C6: lutil_debug (debug.c:66) ==23914== by 0x80C8C85: do_extended (extended.c:185) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972608 is 0 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== ==23914== Invalid read of size 1 ==23914== at 0x4006243: strlen (mc_replace_strmem.c:246) ==23914== by 0xCB184D: vfprintf (in /lib/libc-2.5.so) ==23914== by 0xCD1FD3: vsnprintf (in /lib/libc-2.5.so) ==23914== by 0x826B0C6: lutil_debug (debug.c:66) ==23914== by 0x80C8C85: do_extended (extended.c:185) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972609 is 1 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== ==23914== Invalid read of size 4 ==23914== at 0xCE232C: mempcpy (in /lib/libc-2.5.so) ==23914== by 0xCB1375: vfprintf (in /lib/libc-2.5.so) ==23914== by 0xCD1FD3: vsnprintf (in /lib/libc-2.5.so) ==23914== by 0x826B0C6: lutil_debug (debug.c:66) ==23914== by 0x80C8C85: do_extended (extended.c:185) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972608 is 0 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ### conn=1000 op=1: do_extended: freeing dn="cn=Added User,ou=Alumni Association,ou=People,o=Example,c=US" (0x4972608) ==23914== ==23914== Invalid free() / delete / delete[] ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80C8CE6: do_extended (extended.c:187) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972608 is 0 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== A fix (a hack, at least) is coming. p.

1 0

(ITS#6632) Core dump in test030 when using back-ldap
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.166.16) Submitted by: ando When compiled with -DSLAP_NO_SL_MALLOC=1 test030 cores when performing passwd extop with back-ldap; a gdb stack backtrace is provided below. (gdb) bt #0 0x00115402 in __kernel_vsyscall () #1 0x001c4d20 in raise () from /lib/libc.so.6 #2 0x001c6631 in abort () from /lib/libc.so.6 #3 0x001fce6b in __libc_message () from /lib/libc.so.6 #4 0x00204b16 in _int_free () from /lib/libc.so.6 #5 0x00208070 in free () from /lib/libc.so.6 #6 0x0826ae7a in ber_memfree_x (p=0x8b84fe0, ctx=0x0) at ../../../ldap-src/libraries/liblber/memory.c:152 #7 0x080f537c in slap_sl_free (ptr=0x8b84fe0, ctx=0x8b15138) at ../../../ldap-src/servers/slapd/sl_malloc.c:481 #8 0x080c8c58 in do_extended (op=0x8b2cde0, rs=0xb79820e4) at ../../../ldap-src/servers/slapd/extended.c:184 #9 0x0808acba in connection_operation (ctx=0xb79821d0, arg_v=0x8b2cde0) at ../../../ldap-src/servers/slapd/connection.c:1109 #10 0x0808b1fa in connection_read_thread (ctx=0xb79821d0, argv=0xd) at ../../../ldap-src/servers/slapd/connection.c:1245 #11 0x08234cc9 in ldap_int_thread_pool_wrapper (xpool=0x8a53b28) at ../../../ldap-src/libraries/libldap_r/tpool.c:685 #12 0x0011b46b in start_thread () from /lib/libpthread.so.0 #13 0x0026cdbe in clone () from /lib/libc.so.6 The issue, according to valgrind, consists in a double-free, which does not surface when dealt with by the slab. conn=1021 fd=17 ACCEPT from IP=127.0.0.1:45744 (IP=127.0.0.1:9011) conn=1021 op=0 BIND dn="cn=Manager,o=Example,c=US" method=128 conn=1022 fd=22 ACCEPT from IP=127.0.0.1:45745 (IP=127.0.0.1:9011) conn=1022 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 conn=1022 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 conn=1022 op=0 RESULT tag=97 err=0 text= conn=1021 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 conn=1021 op=0 RESULT tag=97 err=0 text= conn=1021 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=1021 op=1 PASSMOD id="cn=Added User,ou=Alumni Association,ou=People,o=Example,c=US" new conn=1022 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=1022 op=1 PASSMOD id="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" new conn=1021 op=1 RESULT oid= err=0 text= ==4946== ==4946== Thread 7: ==4946== Invalid free() / delete / delete[] ==4946== at 0x4004FDA: free (vg_replace_malloc.c:233) ==4946== by 0x826AE79: ber_memfree_x (memory.c:152) ==4946== by 0x80F537B: slap_sl_free (sl_malloc.c:481) ==4946== by 0x80C8C57: do_extended (extended.c:184) ==4946== by 0x808ACB9: connection_operation (connection.c:1109) ==4946== by 0x808B1F9: connection_read_thread (connection.c:1245) ==4946== by 0x8234CC8: ldap_int_thread_pool_wrapper (tpool.c:685) ==4946== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==4946== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==4946== Address 0x45DD018 is 0 bytes inside a block of size 62 free'd ==4946== at 0x4004FDA: free (vg_replace_malloc.c:233) ==4946== by 0x826AE79: ber_memfree_x (memory.c:152) ==4946== by 0x80F537B: slap_sl_free (sl_malloc.c:481) ==4946== by 0x80CA323: passwd_extop (passwd.c:321) ==4946== by 0x80C8E6E: fe_extended (extended.c:222) ==4946== by 0x80C8C05: do_extended (extended.c:177) ==4946== by 0x808ACB9: connection_operation (connection.c:1109) ==4946== by 0x808B1F9: connection_read_thread (connection.c:1245) ==4946== by 0x8234CC8: ldap_int_thread_pool_wrapper (tpool.c:685) ==4946== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==4946== by 0xD42DBD: clone (in /lib/libc-2.5.so) The issue *might* be related to slapo-rwm playing with the rewriting of the request dn/ndn, but it does not surface when the same test is performed using back-relay, which also uses slapo-rwm. p.

1 0

Re: (ITS#6612) Back SQL / Mysql / InnoDB
by masarati＠aero.polimi.it 28 Aug '10

28 Aug '10

The requested feature has been added to HEAD code; please test and report. Thanks, p.

1 0

Re: (ITS#6631) back-sql attribute order incorrect
by masarati＠aero.polimi.it 28 Aug '10

28 Aug '10

> Also, that portion of the code has been recently modified (to allow 64-bit > integer keys); could you test with back-sql code from HEAD? It should > build and work straight with 2.3.43 code. I need to partly amend myself: that improvement requires long long parsing capabilities that were added to liblutil, so you'll probably be better off pulling the entire HEAD from the CVS to test it. p.

1 0

ITS#6630 dupent
by masarati＠aero.polimi.it 28 Aug '10

28 Aug '10

I've recently committed an overlay that implements the (expired) <draft-ietf-ldapext-ldapv3-dupent-08.txt> (ITS#6630); it's in contrib/slapd-modules/dupent/; configuration is pretty straightforward: load the module, and add overlay dupent in the database you want dupent to be enabled. I've only tested it as database specific, although it should also work as a global overlay. Could anybody with access to a dupent-capable client please test it and report (through the ITS, in case)? I'm not 100% sure about the request/response encoding/decoding. Thanks, p.

1 0

Re: (ITS#6631) back-sql attribute order incorrect
by masarati＠aero.polimi.it 27 Aug '10

27 Aug '10

> slapd log: > backsql_add_attr("radiuslogin=xyzzy2,ou=Dialup,ou=External,o=Integra"): > executing "UPDATE radiusaccount SET radiuslogin=? WHERE id=?" val[0], id=1411 > > MySQL log: > 173 Query UPDATE radiusaccount SET radiuslogin=1411 WHERE id='xyzzy2' > Note that this appears to be a logging issue rather than a functional one. > = > The parameter order changes according to the param_order field, but the > sl= > apd log always indicates the order as if param_order=3D0 I'm not sure I understand this report. Can you please make the example more esplicative? Also, please note that "id" in the update procedure is the name of a specific field in the RDBMS, while "id" in slapd's log is a generic name for the key that is being used. The name coincidence is purely incidental. Also, that portion of the code has been recently modified (to allow 64-bit integer keys); could you test with back-sql code from HEAD? It should build and work straight with 2.3.43 code. Thanks, p.

1 0

Re: (ITS#6631) back-sql attribute order incorrect
by david.stults＠integratelecom.com 26 Aug '10

26 Aug '10

Note that this appears to be a logging issue rather than a functional one. = The parameter order changes according to the param_order field, but the sl= apd log always indicates the order as if param_order=3D0 On Aug 26, 2010, at 11:38 AM, <openldap-its(a)OpenLDAP.org> <openldap-its@Ope= nLDAP.org> wrote: >=20 > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** >=20 > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6631. >=20 > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. >=20 > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6631) > in the subject will automatically be attached to the issue report. >=20 > mailto:openldap-its@openldap.org?subject=3D(ITS#6631) >=20 > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D6631 >=20 > Please remember to retain your issue tracking number (ITS#6631) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. >=20 > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. >=20 > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ >=20 > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >=20

1 0

(ITS#6631) back-sql attribute order incorrect
by david.stults＠integratelecom.com 26 Aug '10

26 Aug '10

Full_Name: David Stults Version: 2.4.23 OS: CentOS 5.5 URL: Submission from: (NULL) (64.122.164.12) When executing the add_proc SQL query, back-sql claims to provide the attributes in a particular order, but reality is reversed: slapd log: backsql_add_attr("radiuslogin=xyzzy2,ou=Dialup,ou=External,o=Integra"): executing "UPDATE radiusaccount SET radiuslogin=? WHERE id=?" val[0], id=1411 MySQL log: 173 Query UPDATE radiusaccount SET radiuslogin=1411 WHERE id='xyzzy2'

1 0

Re: (ITS#6629) send_search_entry() does not clear controls
by h.b.furuseth＠usit.uio.no 26 Aug '10

26 Aug '10

hyc(a)symas.com writes: > If these two behaviors are related, that says to me that we should > just go the rest of the way with the slab allocator and allocate > additional slabs when the current one is exhausted. By itself that solves one problem, but introduces another. The slab allocator does almost no garbage collection until the memory context is reset. So a task could use up an arbitrary number of slabs, slap_sl_free()ing almost all memory in each, before it ends and its slabs are all reset. The fallback to plain malloc() avoids this. A fix would be for extra slabs to manage their memory with a proper malloc algorithm. The first slab can use the current fast algorithm. Or, would it get too fragile to require slapd to track whether a memory block comes from plain malloc() or one of the OpenLDAP malloc functions? That would allow each slapd memory block to identify the slab it came from, if any. A two-byte header would allow 65535 slabs, if 8 bytes for a ctx pointer per sl_malloced block is too much. > The purpose of the slab allocator was two-fold - to provide > thread-local memory that needs no locking, and also to provide > local memory that needs no housekeeping/explicit frees. And #3: to avoid memory fragmentation from plain malloc. -- Hallvard

1 0

Re: (ITS#6629) send_search_entry() does not clear controls
by hyc＠symas.com 26 Aug '10

26 Aug '10

quanah(a)zimbra.com wrote: > --On August 26, 2010 3:44:02 AM +0000 masarati(a)aero.polimi.it wrote: > >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (129.72.175.5) >> Submitted by: ando >> >> >> REP_CTRLS_MUSTBEFREED is only honored by send_ldap_response(); when >> response controls are attached to slap_send_search_entry() it is not >> honored. This does not surface because controls must be malloc'ed on the >> slab; however, it clearly appears when built with SLAP_NO_SL_MALLOC. > > Interesting -- I'm seeing an issue where I can get slapd to consume all > available memory on the system by using paged results. It takes a while to > do so (depending on how much memory is available), but it's 100% > repeatable. The more mixes of paged and non paged results there are with > large result sets, the more quickly it happens. However, I do not build > with SLAP_NO_SL_MALLOC (or at least, not intentionally ;) ). If these two behaviors are related, that says to me that we should just go the rest of the way with the slab allocator and allocate additional slabs when the current one is exhausted. The purpose of the slab allocator was two-fold - to provide thread-local memory that needs no locking, and also to provide local memory that needs no housekeeping/explicit frees. -- -- 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

Re: (ITS#6629) send_search_entry() does not clear controls
by masarati＠aero.polimi.it 26 Aug '10

26 Aug '10

> > > --On August 26, 2010 3:44:02 AM +0000 masarati(a)aero.polimi.it wrote: > >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (129.72.175.5) >> Submitted by: ando >> >> >> REP_CTRLS_MUSTBEFREED is only honored by send_ldap_response(); when >> response controls are attached to slap_send_search_entry() it is not >> honored. This does not surface because controls must be malloc'ed on >> the >> slab; however, it clearly appears when built with SLAP_NO_SL_MALLOC. > > Interesting -- I'm seeing an issue where I can get slapd to consume all > available memory on the system by using paged results. It takes a while > to > do so (depending on how much memory is available), but it's 100% > repeatable. The more mixes of paged and non paged results there are with > large result sets, the more quickly it happens. pagedResults only sends a control response with the searchResultDone response, which uses send_ldap_response() and thus clears the controls; moreover, we are talking about few bytes, so I don't think this is the issue. There might be something else related to slab allocation that runs out of slab memory and starts using the heap without freeing it. The present issue might affect syncrepl, since in that case a control is attached to each entry/intermediate response (afaik). It might even be intentional; in fact, often when a control is attached to an entry in a searchResultEntry the same control needs to be applied to many entries returned by the same operation. However, in this case we should probably define a specific API for slap_add_ctrls() that does not set the REP_CTRLS_MUSTBEFREED, or something like that. > However, I do not build > with SLAP_NO_SL_MALLOC (or at least, not intentionally ;) ). I occasionally do (you only need to recompile slapd/sl_malloc.c) to trace possible leaks when developing something. Since we make an intensive use of slab mallocs, usual minimal tests with valgrind do not show leaks otherwise. p.

1 0

Re: (ITS#6629) send_search_entry() does not clear controls
by quanah＠zimbra.com 26 Aug '10

26 Aug '10

--On August 26, 2010 3:44:02 AM +0000 masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.72.175.5) > Submitted by: ando > > > REP_CTRLS_MUSTBEFREED is only honored by send_ldap_response(); when > response controls are attached to slap_send_search_entry() it is not > honored. This does not surface because controls must be malloc'ed on the > slab; however, it clearly appears when built with SLAP_NO_SL_MALLOC. Interesting -- I'm seeing an issue where I can get slapd to consume all available memory on the system by using paged results. It takes a while to do so (depending on how much memory is available), but it's 100% repeatable. The more mixes of paged and non paged results there are with large result sets, the more quickly it happens. However, I do not build with SLAP_NO_SL_MALLOC (or at least, not intentionally ;) ). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6630) Support for draft-ietf-ldapext-ldapv3-dupent-08.txt
by masarati＠aero.polimi.it 26 Aug '10

26 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.68) Submitted by: ando I've just committed (to contrib/slapd-modules/dupent/) a nearly complete support for draft-ietf-ldapext-ldapv3-dupent-08.txt (expired) in form of an overlay. I'm not 100% sure about the format of the control request/response values, and I couldn't check interoperability with other software; I only tested it with ldapsearch passing it -E '2.16.840.1.113719.1.27.101.1=:<control request value>', so please use with care (and report). p.

1 0

(ITS#6629) send_search_entry() does not clear controls
by masarati＠aero.polimi.it 26 Aug '10

26 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.175.5) Submitted by: ando REP_CTRLS_MUSTBEFREED is only honored by send_ldap_response(); when response controls are attached to slap_send_search_entry() it is not honored. This does not surface because controls must be malloc'ed on the slab; however, it clearly appears when built with SLAP_NO_SL_MALLOC. p.

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by quanah＠zimbra.com 25 Aug '10

25 Aug '10

--On Wednesday, August 25, 2010 3:12 AM +0200 masarati(a)aero.polimi.it wrote: >> --On Tuesday, August 24, 2010 5:47 PM -0700 Howard Chu <hyc(a)symas.com> >> wrote: >> >>> quanah(a)zimbra.com wrote: >>>> Full_Name: Quanah Gibson-Mount >>>> Version: 2.4.23 >>>> OS: Linux 2.6 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (75.111.45.108) >>>> >>>> >>>> With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of >>>> at 1 >>> >>> No. cvs log shows that this was patched about a year ago and first >>> released in 2.4.20. Not a bug, closing this ITS. >> >> Connections starting at 1000 is clearly a bug, regardless of when it was >> introduced. > > That was intended, to store connections as unsigned and reserve lower > numbers for special connections (e.g. internal operations and so). I > don't see how using an arbitrary offset in logs can be considered a bug. > 1000 is much like 10, 1024, 666 or 0xbad. Eh, I just need to re-write some scripts to start some things at 1000 then. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by masarati＠aero.polimi.it 25 Aug '10

25 Aug '10

> --On Tuesday, August 24, 2010 5:47 PM -0700 Howard Chu <hyc(a)symas.com> > wrote: > >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.23 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.45.108) >>> >>> >>> With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of >>> at 1 >> >> No. cvs log shows that this was patched about a year ago and first >> released in 2.4.20. Not a bug, closing this ITS. > > Connections starting at 1000 is clearly a bug, regardless of when it was > introduced. That was intended, to store connections as unsigned and reserve lower numbers for special connections (e.g. internal operations and so). I don't see how using an arbitrary offset in logs can be considered a bug. 1000 is much like 10, 1024, 666 or 0xbad. p.

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by quanah＠zimbra.com 25 Aug '10

25 Aug '10

--On Tuesday, August 24, 2010 5:47 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.23 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.45.108) >> >> >> With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of >> at 1 > > No. cvs log shows that this was patched about a year ago and first > released in 2.4.20. Not a bug, closing this ITS. Connections starting at 1000 is clearly a bug, regardless of when it was introduced. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by hyc＠symas.com 25 Aug '10

25 Aug '10

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of at 1 No. cvs log shows that this was patched about a year ago and first released in 2.4.20. Not a bug, 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

(ITS#6628) Connection numbering starts at 1000
by quanah＠zimbra.com 25 Aug '10

25 Aug '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of at 1 Aug 24 16:10:03 zre-ldap001 slapd[10200]: @(#) $OpenLDAP: slapd 2.4.23 (Aug 6 2010 12:44:14) $#012#011root@zre-ubuntu10-64:/home/build/p4/GNR/ThirdParty/openldap/openldap-2.4.23.2z/servers /slapd Aug 24 16:10:03 zre-ldap001 slapd[10201]: slapd starting Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 fd=12 ACCEPT from IP=10.137.242.51:40585 (IP=10.137.242.51:389) Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=0 BIND dn="" method=128 Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=0 RESULT tag=97 err=0 text= Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=2 UNBIND Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 fd=12 closed Aug 24 16:13:43 zre-ldap001 slapd[10201]: daemon: shutdown requested and initiated. Aug 24 16:13:43 zre-ldap001 slapd[10201]: slapd shutdown: waiting for 0 operations/tasks to finish Aug 24 16:13:43 zre-ldap001 slapd[10201]: slapd stopped. Aug 24 16:14:14 zre-ldap001 slapd[10305]: @(#) $OpenLDAP: slapd 2.4.23 (Aug 6 2010 12:44:14) $#012#011root@zre-ubuntu10-64:/home/build/p4/GNR/ThirdParty/openldap/openldap-2.4.23.2z/servers /slapd Aug 24 16:14:14 zre-ldap001 slapd[10306]: slapd starting Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 fd=12 ACCEPT from IP=10.137.242.51:55960 (IP=10.137.242.51:389) Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=0 BIND dn="" method=128 Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=0 RESULT tag=97 err=0 text= Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=2 UNBIND Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 fd=12 closed Aug 24 16:15:57 zre-ldap001 slapd[10306]: daemon: shutdown requested and initiated. Aug 24 16:15:57 zre-ldap001 slapd[10306]: slapd shutdown: waiting for 0 operations/tasks to finish Aug 24 16:15:57 zre-ldap001 slapd[10306]: slapd stopped. Aug 24 16:17:02 zre-ldap001 slapd[10554]: @(#) $OpenLDAP: slapd 2.4.23 (Aug 6 2010 12:44:14) $#012#011root@zre-ubuntu10-64:/home/build/p4/GNR/ThirdParty/openldap/openldap-2.4.23.2z/servers /slapd Aug 24 16:17:02 zre-ldap001 slapd[10555]: slapd starting Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 fd=12 ACCEPT from IP=10.137.242.51:55961 (IP=10.137.242.51:389) Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=0 BIND dn="" method=128 Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=0 RESULT tag=97 err=0 text= Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=2 UNBIND Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 fd=12 closed

1 0

Re: (ITS#6626) NDB Backend with Syncrepl failure
by mhardin＠symas.com 24 Aug '10

24 Aug '10

This was an error on my part and I was promptly corrected by Howard Chu = (Thanks, Howard!). syncrepl is supported for back-ndb and did work when = the code was contributed. We don't know what's happened in the = intervening time, though. Perhaps George will open an ITS? Sorry for any confusion this may have caused. Cheers, -Matt Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com On Aug 24, 2010, at 12:13 AM, gtzanetis(a)pylones.gr wrote: > I've received a confirmation from Symas, which is the back_ndb = developer th=3D > at replication does not apply to this backend. They explained that by = desig=3D > n each slapd instance is intended to connect directly to the NDB = cluster by=3D > way of back-ndb. High availability is handled by the cluster. >=20 >=20

1 0

RE: (ITS#6626) NDB Backend with Syncrepl failure
by gtzanetis＠pylones.gr 24 Aug '10

24 Aug '10

I've received a confirmation from Symas, which is the back_ndb developer th= at replication does not apply to this backend. They explained that by desig= n each slapd instance is intended to connect directly to the NDB cluster by= way of back-ndb. High availability is handled by the cluster.

1 0

RE: (ITS#6626) NDB Backend with Syncrepl failure
by gtzanetis＠pylones.gr 23 Aug '10

23 Aug '10

I forgot to state that the operating system is Red Hat 5 Enterprise 64 bit -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: Friday, August 20, 2010 4:24 PM To: George Tzanetis Subject: Re: (ITS#6626) NDB Backend with Syncrepl failure *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#6626. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#6626) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#6626) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D6626 Please remember to retain your issue tracking number (ITS#6626) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

Re: (ITS#6627) Empty suffix and dn for root node should be avoided
by masarati＠aero.polimi.it 20 Aug '10

20 Aug '10

> Full_Name: SEAK T.F. > Version: 2.4.18 > OS: Windows XP/7 & Ubuntu 9 > URL: > Submission from: (NULL) (213.41.124.254) > > > Currently it is possible to create a DIT with empty suffix and empty dn > for root > node! Side-note: Such DIT can be used for redirection. > > I've no idea what LDAP standards state, but common sense tells me that > name-less > node doesn't make sense. It's as meaningless as creating a name-less > directory > or name-less file. > > So, when such incorrect parameters are supplied in the conf file, OpenLDAP > service should not start and should exit with error. This issue should be discussed on openldap-technical rather than on the ITS, and should focus on the latest release. In any case, OpenLDAP allows to create an object with empty suffix for a specific technical reason, in two steps: 1) it allows the empty DN ("") to be used as the suffix of a database; the database cannot contain an entry with the empty DN, but it can contain immediate children of it. 2) in some versions, the database may technically contain an empty entry in order to store replication-related information (the contextCSN). I think this is now superseded by the use of a "cn=ldapsync" subentry of "" for this specific purpose. In any case, this ITS will be closed. p.

1 0

(ITS#6627) Empty suffix and dn for root node should be avoided
by lapsap7+bug＠gmail.com 20 Aug '10

20 Aug '10

Full_Name: SEAK T.F. Version: 2.4.18 OS: Windows XP/7 & Ubuntu 9 URL: Submission from: (NULL) (213.41.124.254) Currently it is possible to create a DIT with empty suffix and empty dn for root node! Side-note: Such DIT can be used for redirection. I've no idea what LDAP standards state, but common sense tells me that name-less node doesn't make sense. It's as meaningless as creating a name-less directory or name-less file. So, when such incorrect parameters are supplied in the conf file, OpenLDAP service should not start and should exit with error.

1 0

(ITS#6626) NDB Backend with Syncrepl failure
by gtzanetis＠pylones.gr 20 Aug '10

20 Aug '10

Full_Name: George Tzanetis Version: 2.4.23 OS: Red Hat Enterprise 5 URL: (I've attached outputs from slapd in the above box) Submission from: (NULL) (62.169.213.126) Your e-mail address: Subject: Your full name: OpenLDAP version: OS you are using: Major Security Issue? yes no I ve configured Openldap-2.4.23, which I downloaded from openldap.org, with only back_ndb support (using /configure --enable-ndb --disable-hdb --disable-bdb --prefix=/usr/local/openldap ) And the binaries of MySQL Cluster 7.1.5 (the latest) With the following slapd.conf the slapd worked perfectly: include /usr/local/openldap/etc/openldap/schema/core.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args ####################################################################### # NDB database definitions ####################################################################### #NDB database defintions database ndb suffix "dc=test,dc=org" rootdn "cn=root,dc=test,dc=org" rootpw secret1 dbconnect 192.168.2.175 dbhost 192.168.2.174 dbname openldap dbuser root dbpass "" dbconnections 1 dbsocket /tmp/mysql.sock i.e. I was able to ldapadd, slapadd ldapsearch etc. I then tried to configure this instance of openldap as the PROVIDER of a SYNCREPL replication by adding overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 in the slapd.conf, bellow the database configurations. When I tried to start the slapd service I get: <<< dnNormalize: <cn=root,dc=test,dc=org> *** glibc detected *** slapd: free(): invalid pointer: 0x000000000506c938 *** ======= Backtrace: ========= /lib64/libc.so.6[0x314a27230f] /lib64/libc.so.6(cfree+0x4b)[0x314a27276b] slapd(ber_bvarray_free_x+0x58)[0x4f4be8] slapd(ndb_entry_get+0x1d5)[0x4ad475] slapd(overlay_entry_get_ov+0xfa)[0x49414a] slapd[0x4bf1bf] slapd[0x493ec7] slapd(backend_startup_one+0xb9)[0x441039] slapd(backend_startup+0x1eb)[0x4412fb] slapd(main+0xf13)[0x41bb53] /lib64/libc.so.6(__libc_start_main+0xf4)[0x314a21d994] slapd[0x41a7a9] ======= Memory map: ======== 00400000-00569000 r-xp 00000000 fd:00 1998969 /usr/local/openldap/libexec/slapd 00768000-00771000 rw-p 00168000 fd:00 1998969 /usr/local/openldap/libexec/slapd 00771000-007d6000 rw-p 00771000 00:00 0 04f08000-051b2000 rw-p 04f08000 00:00 0 [heap] 40fd4000-40fd5000 ---p 40fd4000 00:00 0 40fd5000-419d5000 rw-p 40fd5000 00:00 0 419d5000-419d6000 ---p 419d5000 00:00 0 419d6000-419f6000 rw-p 419d6000 00:00 0 419f6000-419f7000 ---p 419f6000 00:00 0 419f7000-41a17000 rw-p 419f7000 00:00 0 41a17000-41a18000 ---p 41a17000 00:00 0 41a18000-41a38000 rw-p 41a18000 00:00 0 41a38000-41a39000 ---p 41a38000 00:00 0 41a39000-41a59000 rw-p 41a39000 00:00 0 41a59000-41a5a000 ---p 41a59000 00:00 0 41a5a000-41a7a000 rw-p 41a5a000 00:00 0 3149e00000-3149e1c000 r-xp 00000000 fd:00 1212420 /lib64/ld-2.5.so 314a01b000-314a01c000 r--p 0001b000 fd:00 1212420 /lib64/ld-2.5.so 314a01c000-314a01d000 rw-p 0001c000 fd:00 1212420 /lib64/ld-2.5.so 314a200000-314a34e000 r-xp 00000000 fd:00 1212427 /lib64/libc-2.5.so 314a34e000-314a54d000 ---p 0014e000 fd:00 1212427 /lib64/libc-2.5.so 314a54d000-314a551000 r--p 0014d000 fd:00 1212427 /lib64/libc-2.5.so 314a551000-314a552000 rw-p 00151000 fd:00 1212427 /lib64/libc-2.5.so 314a552000-314a557000 rw-p 314a552000 00:00 0 314a600000-314a682000 r-xp 00000000 fd:00 1212453 /lib64/libm-2.5.so 314a682000-314a881000 ---p 00082000 fd:00 1212453 /lib64/libm-2.5.so 314a881000-314a882000 r--p 00081000 fd:00 1212453 /lib64/libm-2.5.so 314a882000-314a883000 rw-p 00082000 fd:00 1212453 /lib64/libm-2.5.so 314aa00000-314aa02000 r-xp 00000000 fd:00 1212433 /lib64/libdl-2.5.so 314aa02000-314ac02000 ---p 00002000 fd:00 1212433 /lib64/libdl-2.5.so 314ac02000-314ac03000 r--p 00002000 fd:00 1212433 /lib64/libdl-2.5.so 314ac03000-314ac04000 rw-p 00003000 fd:00 1212433 /lib64/libdl-2.5.so 314ae00000-314ae16000 r-xp 00000000 fd:00 1212435 /lib64/libpthread-2.5.so 314ae16000-314b015000 ---p 00016000 fd:00 1212435 /lib64/libpthread-2.5.so 314b015000-314b016000 r--p 00015000 fd:00 1212435 /lib64/libpthread-2.5.so 314b016000-314b017000 rw-p 00016000 fd:00 1212435 /lib64/libpthread-2.5.so 314b017000-314b01b000 rw-p 314b017000 00:00 0 314b200000-314b214000 r-xp 00000000 fd:00 461719 /usr/lib64/libz.so.1.2.3 314b214000-314b413000 ---p 00014000 fd:00 461719 /usr/lib64/libz.so.1.2.3 314b413000-314b414000 rw-p 00013000 fd:00 461719 /usr/lib64/libz.so.1.2.3 314ba00000-314ba3b000 r-xp 00000000 fd:0Aborted If I delete the database from the mysql cluster and restart the opendap it starts fine but if I use LdapAdd I get: ndb_modify_internal: replace contextCSN Segmentation fault

1 0

(ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 19 Aug '10

19 Aug '10

Full_Name: Douglas Leavitt Version: 2.4.23 (HEAD) OS: OpenSolaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.18.43.225) I would like to propose a patch to the OpenLDAP C APIs to support the operation thread safe features described in the draft-zeilenga-ldap-c-api-concurrency drafts. The enhancements add upwardly compatible interfaces and should have no behavioral regressions w.r.t. any existing libldap interfaces. The new concurrency APIs include: ldap_dup and ldap_destroy They are described in more detail in the concurrency draft and in the applicable man paged. The related feature options are also provided. Additionally I would like to propose 1 new public error API ldap_get_lderror which returns all three ldap_get_option results: LDAP_OPT_MATCHED_DN LDAP_OPT_DIAGNOSTIC_MESSAGE LDAP_OPT_RESULT_CODE in a single API, and 1 new depreciated public API: ldap_get_lderrno which performs almost the same function as ldap_get_error but does so in a mt-unsafe manner, but that is compatible with Mozilla's libldap API of the same name. The point of the two new error APIs is to provide a transition path from Mozilla libldap users that still use ldap_get_lderrno to either a similar API that obeys OpenLDAP like practices (ldap_get_error) or as a transition until any existing code can be converted away from ldap_get_lderrno to just using ldap_get_options as needed. The patch includes a new test case to test the new functionality and man pages. The new test case needs additional work for some of the threading models. Any input here is requested, since I do not have testing resources for all the threading combination and do not have the ability to test the Windows model. I am looking forward to any and all comments. I plan to submit a formal ITS with a finalized version of changes once any and all issues are thrashed out and resolved to a level that they are acceptable for integration. For the record: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Oracle Corporation.Oracle Corporation has not assigned rights and/or interest in this work to any party. I, Douglas Leavitt am authorized by Oracle Corporation, my employer, to release this work under the following terms. The initial version of my proposed patch can be found here: http://cr.opensolaris.org/~djl/openldap-codereview This includes a diff -U of the full patch (/diffU) http://cr.opensolaris.org/~djl/openldap-codereview/diffU a webrev diff (/webrev) for on-line review http://cr.opensolaris.org/~djl/openldap-codereview/webrev/index.html and a tar ball image of the OpenLDAP HEAD as of 8/13/10 with the current patch applied. http://cr.opensolaris.org/~djl/openldap-codereview/openldap-cr1.tar.gz Thank you for you consideration, and I look forward to any and all comments.

1 0

Re: ITS#6611
by leonardo＠ngdn.org 17 Aug '10

17 Aug '10

On Mon, Aug 16, 2010 at 8:06 PM, <masarati(a)aero.polimi.it> wrote: >> On Fri, Jul 30, 2010 at 11:34 PM, =A0<masarati(a)aero.polimi.it> wrote: >>> Likely your ACL is exceeding ACLBUF_MAXLEN (8192, defined in >>> servers/slapd/aclparse.c); you can workaround this issue by increasing >>> that value to something *very* large, while the code is fixed. >>> =3DA0However=3D >> , >>> you should fix your configuration by assigning those DNs to a group, an= d >>> using a group ACL instead. >> >> Thanks for the suggestion. We're now using group ACLs to workaround the >> problem. > > The issue should now be fixed in HEAD; please test and report, if you can= . I just tested and confirmed it's fixed. Thanks a lot! Leonardo

1 0

Re: ITS#6611
by masarati＠aero.polimi.it 17 Aug '10

17 Aug '10

> On Fri, Jul 30, 2010 at 11:34 PM, <masarati(a)aero.polimi.it> wrote: >> Likely your ACL is exceeding ACLBUF_MAXLEN (8192, defined in >> servers/slapd/aclparse.c); you can workaround this issue by increasing >> that value to something *very* large, while the code is fixed. >> =A0However= > , >> you should fix your configuration by assigning those DNs to a group, and >> using a group ACL instead. > > Thanks for the suggestion. We're now using group ACLs to workaround the > problem. The issue should now be fixed in HEAD; please test and report, if you can. Thanks, p.

1 0

Re: (ITS#6624) cn=config support for back_null
by masarati＠aero.polimi.it 16 Aug '10

16 Aug '10

Technically, the contribution looks fine. Personally, I favor the "magic" variant. Kurt, unless there is any IPR issue, I'd commit it. Thanks, p.

1 0

Re: ITS#6611
by leonardo＠ngdn.org 16 Aug '10

16 Aug '10

On Fri, Jul 30, 2010 at 11:34 PM, <masarati(a)aero.polimi.it> wrote: > Likely your ACL is exceeding ACLBUF_MAXLEN (8192, defined in > servers/slapd/aclparse.c); you can workaround this issue by increasing > that value to something *very* large, while the code is fixed. =A0However= , > you should fix your configuration by assigning those DNs to a group, and > using a group ACL instead. Thanks for the suggestion. We're now using group ACLs to workaround the problem.

1 0

(ITS#6624) cn=config support for back_null
by ondrej.kuznik＠acision.com 16 Aug '10

16 Aug '10

Full_Name: Ondrej Kuznik Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.168.56.1) Back-null database currently does not support cn=config. Although there is only one directive (bind allowed), it could be useful to support it once openldap no longer uses slapd.conf. The following patches represent two alternatives that attempt to add this capability, adding a new attribute type (OLcfgDbAt:8.1 'olcDbBindAllowed') and one objectclass (OLcfgDbOc:8.1 'olcNullConfig') to the schemas. They are two as I am new to slapd internals and do not know which approach is more preferable. ftp://ftp.openldap.org/incoming/ondrej-kuznik-20100624-back_null_simple.pat… The first patch adds the functionality using only bconfig.c config_{check,set}_vals (through flags ARG_ON_OFF|ARG_OFFSET) but a modify that deletes the attribute leaves the value of ni_bind_allowed intact. ftp://ftp.openldap.org/incoming/ondrej-kuznik-20100624-back_null_magic.patch The second one uses a callback function like any other backend so it does not suffer from this issue. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondřej Kuzník am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#6623) segmentation fault
by michael＠stroeder.com 16 Aug '10

16 Aug '10

nareshyathapu(a)gmail.com wrote: > Full_Name: Naresh Reddy > Version: 2.4.11 Current release is 2.4.23. There have been a lot of changes since then including fixes for crashes. So if you suspect OpenLDAP server software to crash could you please try to reproduce this with the current release? > Trying to connect to ldapserver and ldap server is down. Core dump is happening > below is the code and gdb.. Is slapd crashing? > warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at > ffffe0b4 > Core was generated by `/usr/UMR/current/bin/ldapMgr --start=cold'. Could you please elaborate on what kind of software /usr/UMR/current/bin/ldapMgr is? I'm not a OpenLDAP core developer but that does not look like an OpenLDAP component to me. Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs