- openldap-bugs - openldap.org

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

06 Sep '10

> masarati(a)aero.polimi.it wrote: >>> 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. > > Maybe sizelimit should not be by-passed in all cases. > How about letting the client choose which limits are by-passed? Michael, your idea sounds interesting. In the current implementation sizelimits are technically bypassed during the internal search. Since the operation returns only a (possibly successful) searchResultDone, it seems appropriate to return success when sizelimit would be violated, because from the client's perspective no sizelimit could be exceeded since no entry is being returned. The fact that the actual search would be exceeded is reflected in the additional response code in the control response's value. Could you be more precise about what you mean? One or two use cases or a not-so-formal specification would suffice. Thanks, p.

1 0

Re: objectClass index from slapd.conf is not working
by tim stone 06 Sep '10

06 Sep '10

Hello, the line "index objectClass eq" is the first index in my config and placed there before first filling the database. But I tried to rebuild this index with slapindex too and I also set up the hole database with slapcat/slapadd on a new testsystem. Every time the same behavior. kindly regards, Tim 2010/9/2 tim stone <timstone10001(a)googlemail.com> > > Hello Michael, > > the line > > "index objectClass eq" > > is the first index in my config and placed there before first filling the database. But I tried to rebuild this index with slapindex too and I also set up the hole database with slapcat/slapadd on a new testsystem. Every time the same behavior. > > kindly regards, Tim > > 2010/9/2 Michael Ströder <michael(a)stroeder.com> >> >> tim stone wrote: >> > >> > I've a strange behavior while using index objectClass for searching. >> >> Did you change the objectClass index *after* populating your database? >> >> http://www.openldap.org/faq/data/cache/136.html >> >> Ciao, Michael. >

2 1

Re: (ITS#6598) EXOP to return number of children of a (sub)tree
by michael＠stroeder.com 06 Sep '10

06 Sep '10

masarati(a)aero.polimi.it wrote: >> 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. Maybe sizelimit should not be by-passed in all cases. How about letting the client choose which limits are by-passed? Ciao, Michael.

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

Should now be fixed in HEAD; platform independent, on Linux was not failing but memory was being used incorrectly. ldapsearch-specific, no issue in client library. Please test. Thanks, p.

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

> --On Sunday, September 05, 2010 9:19 PM +0200 masarati(a)aero.polimi.it > wrote: > > >>> /opt/zimbra/openldap/bin/ldapsearch -LLL -D ... -w ... -H >>> ldap://...:3268 >>> -x -E >>> deref=member:mail "(CN=test)" mail > >>From the ITS. Only thing I removed was binddn, password, and hostname. > Note that the same search against OpenLDAP also segfaults, so it is not a > server side issue. It is clearly a client-side issue: the core dump appears while cooking the control's value. Your backtrace shows a failure on strlen() being passed an invalid string. The string appears invalid to gdb as well, as it fails to show the contents of the string's pointer. Using valgrind with Linux I notice a memory allocation error. Checking... p.

1 0

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

05 Sep '10

--On Sunday, September 05, 2010 9:19 PM +0200 masarati(a)aero.polimi.it wrote: >> /opt/zimbra/openldap/bin/ldapsearch -LLL -D ... -w ... -H ldap://...:3268 >> -x -E >> deref=member:mail "(CN=test)" mail >From the ITS. Only thing I removed was binddn, password, and hostname. Note that the same search against OpenLDAP also segfaults, so it is not a server side issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by masarati＠aero.polimi.it 05 Sep '10

05 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 Something seems to be wrong with the parsing of the deref control in ldapsearch.c; can you provide the command-line? Thanks, p. > 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

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

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

30 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 30 Aug '10

30 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 28 Aug '10

28 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 28 Aug '10

28 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 25 Aug '10

25 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 25 Aug '10

25 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 25 Aug '10

25 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 25 Aug '10

25 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 25 Aug '10

25 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 24 Aug '10

24 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 24 Aug '10

24 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 24 Aug '10

24 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 24 Aug '10

24 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 24 Aug '10

24 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 23 Aug '10

23 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 18 Aug '10

18 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 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. 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

(ITS#6623) segmentation fault
by nareshyathapu＠gmail.com 16 Aug '10

16 Aug '10

Full_Name: Naresh Reddy Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.166.63.98) Trying to connect to ldapserver and ldap server is down. Core dump is happening below is the code and gdb.. Code ------- u32_t rc=ldap_sasl_bind(ld, loginDN, LDAP_SASL_SIMPLE, &cred, NULL, NULL, &msgid); //asynchronous bind if (rc != LDAP_SUCCESS ) { ldapErrorLog(":connect: LDAP Bind send Failed:%s \n ", ldap_err2string(rc)); ldap_unbind_ext_s(ld, NULL,NULL); m_connInitialized = false; return(LDAPRC_FAIL); } GDB ----- warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4 Core was generated by `/usr/UMR/current/bin/ldapMgr --start=cold'. Program terminated with signal 11, Segmentation fault. #0 0x43b91cc9 in free () from /lib/libc.so.6 (gdb) bt #0 0x43b91cc9 in free () from /lib/libc.so.6 #1 0x080a6854 in ldap_free_select_info (sip=0x118) at os-ip.c:936 #2 0x080a29ab in ldap_ld_free (ld=0xf3ebec20, close=1, sctrls=0x0, cctrls=0x0) at unbind.c:131 #3 0x080a2aab in ldap_unbind_ext (ld=0xf3ebec20, sctrls=0x0, cctrls=0x0) at unbind.c:52 #4 0x0808368f in LdapConnection::connect (this=0xd252888, loginDN=0xd258ddc "bwLoginname=sms_ldap_bind", pwd=0xd258edd "metropcs_sms") at LdapConnection.cpp:159 #5 0x08051731 in LdapPeer::LdapWorkerProcess (this=0xd2586b0) at LdapPeer.cpp:322 #6 0x080827b2 in run (handle=0xd2586b0) at LdapCommonDefs.cpp:47 #7 0x43c5be49 in ?? () from /lib/libpthread.so.0

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

Doug Leavitt wrote: > I have been testing pretty consistently on Solaris this year, > most recent on HEAD versus RELEASE. thats how I noticed > the ITS 6621 issue. > > I may be able to do some specific testing on specific hardware > platforms, depending on what is desired, and what I can get > access to. I do regulary test on both x86 and sparc platforms. > > Also, I now have Oracle legal permission to pass OpenLDAP > enhancements and fixes upstream. > > I am almost ready to submit a proposed patch to libldap to deliver > a revised version of draft-zeilenga-ldap-c-api-concurrency-00.txt > functionality for OpenLDAP libldap. > > My proposed patch so far implements the ldap_dup and > ldap_destroy portions of the specification, but I have not > yet implemented the LDAP_OPT_SESSION_REFCNT or > added any LDAP_API_FEATURE* style macros. > > I would like some guidance if/what macros in ldap.h are desired. > > I am working on the assumption that some public discussion > and peer review will be expected before any patch submission > would be accepted. > > Should I start with a discussion on openldap-technical first? Other? Sounds very interesting; discussions of this nature (modifications to OpenLDAP code) are most appropriate for the -devel list. Looking forward to continuing this conversation there. > > Doug. > > > > On 08/12/10 06:21 PM, hyc(a)symas.com wrote: >> masarati(a)aero.polimi.it wrote: >>> Blind-fixed in HEAD. Thanks, p. >> By the way Ando, any more ideas about the devpoll implementation? Have you >> tested it against select on Solaris recently? >> > -- -- 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#6621) Compile time error in daemon.c 1.446
by doug.leavitt＠oracle.com 12 Aug '10

12 Aug '10

I have been testing pretty consistently on Solaris this year, most recent on HEAD versus RELEASE. thats how I noticed the ITS 6621 issue. I may be able to do some specific testing on specific hardware platforms, depending on what is desired, and what I can get access to. I do regulary test on both x86 and sparc platforms. Also, I now have Oracle legal permission to pass OpenLDAP enhancements and fixes upstream. I am almost ready to submit a proposed patch to libldap to deliver a revised version of draft-zeilenga-ldap-c-api-concurrency-00.txt functionality for OpenLDAP libldap. My proposed patch so far implements the ldap_dup and ldap_destroy portions of the specification, but I have not yet implemented the LDAP_OPT_SESSION_REFCNT or added any LDAP_API_FEATURE* style macros. I would like some guidance if/what macros in ldap.h are desired. I am working on the assumption that some public discussion and peer review will be expected before any patch submission would be accepted. Should I start with a discussion on openldap-technical first? Other? Doug. On 08/12/10 06:21 PM, hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >> Blind-fixed in HEAD. Thanks, p. > By the way Ando, any more ideas about the devpoll implementation? Have you > tested it against select on Solaris recently? >

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>> Blind-fixed in HEAD. Thanks, p. >> >> By the way Ando, any more ideas about the devpoll implementation? Have you >> tested it against select on Solaris recently? > > I haven't had access to Solaris in years... p. Me neither. Too bad, a Niagara might actually show more than a 1% gain from the multi-listener patch. -- -- 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#6621) Compile time error in daemon.c 1.446
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

> masarati(a)aero.polimi.it wrote: >> Blind-fixed in HEAD. Thanks, p. > > By the way Ando, any more ideas about the devpoll implementation? Have you > tested it against select on Solaris recently? I haven't had access to Solaris in years... p.

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

masarati(a)aero.polimi.it wrote: > Blind-fixed in HEAD. Thanks, p. By the way Ando, any more ideas about the devpoll implementation? Have you tested it against select on Solaris recently? -- -- 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#6621) Compile time error in daemon.c 1.446
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

Blind-fixed in HEAD. Thanks, p.

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

doug.leavitt(a)oracle.com wrote: > Full_Name: Doug Leavitt > Version: HEAD > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.18.43.225) > > > Two syntax errors were introduced into daemon.c as a result of: > the commits to change daemon.c 1.444 -> 1.445 -> 1.446 > > > Specifically two calls to SLAP_EVENT_MAX are missing the new (t) argument. > > > --- a/servers/slapd/daemon.c Thu Aug 12 10:55:06 2010 -0500 > +++ b/servers/slapd/daemon.c Thu Aug 12 15:19:02 2010 -0500 > @@ -521,7 +521,7 @@ > > # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ > int i; \ > - *(nsp) = select( SLAP_EVENT_MAX,&readfds, \ > + *(nsp) = select( SLAP_EVENT_MAX(t),&readfds, \ > nwriters> 0 ?&writefds : NULL, NULL, (tvp) ); \ > for ( i=0; i<readfds.fd_count; i++) { \ > int fd = slapd_sock2fd(readfds.fd_array[i]); \ > @@ -666,7 +666,7 @@ > # define SLAP_EVENT_CLR_WRITE(fd) FD_CLR((fd),&writefds) > > # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ > - *(nsp) = select( SLAP_EVENT_MAX,&readfds, \ > + *(nsp) = select( SLAP_EVENT_MAX(t),&readfds, \ > nwriters> 0 ?&writefds : NULL, NULL, (tvp) ); \ > } while (0) > # endif /* !HAVE_WINSOCK */ > > Nice catch, thanks. -- -- 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#6617) back-sql: 64-bit parent IDs get munged
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

> 64-bit values for (at least) parent IDs do not get resolved correctly - > only the > lower 32 bits are preserved. This leads up to a crash as it tries to > resolve a > non-existant ID: > > To reproduce: > ldap_entries has a row with an ID of 1000000000 with a parent of > 9999999999 (and > a row 9999999999 for the parent). When back-sql goes to resolve this, the > following shows in the ODBC trace: > > SELECT COUNT(*) FROM > ldap_entry_objclasses,ldap_entries,ldap_static_entries > WHERE ldap_static_entries.id=1410065407 AND > ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 > > (1410065407 = 32-bit rollover of 9999999999). A (blind) fix is in HEAD; you need to pull modifications related to this ITS and to ITS#6622. Please test and report. p.

1 0

(ITS#6622) Add support for [unsigned] long long parsing
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.199) Submitted by: ando A patch that adds support for parsing long long and unsigned long long is coming.

1 0

(ITS#6621) Compile time error in daemon.c 1.446
by doug.leavitt＠oracle.com 12 Aug '10

12 Aug '10

Full_Name: Doug Leavitt Version: HEAD OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.18.43.225) Two syntax errors were introduced into daemon.c as a result of: the commits to change daemon.c 1.444 -> 1.445 -> 1.446 Specifically two calls to SLAP_EVENT_MAX are missing the new (t) argument. --- a/servers/slapd/daemon.c Thu Aug 12 10:55:06 2010 -0500 +++ b/servers/slapd/daemon.c Thu Aug 12 15:19:02 2010 -0500 @@ -521,7 +521,7 @@ # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ int i; \ - *(nsp) = select( SLAP_EVENT_MAX, &readfds, \ + *(nsp) = select( SLAP_EVENT_MAX(t), &readfds, \ nwriters > 0 ? &writefds : NULL, NULL, (tvp) ); \ for ( i=0; i<readfds.fd_count; i++) { \ int fd = slapd_sock2fd(readfds.fd_array[i]); \ @@ -666,7 +666,7 @@ # define SLAP_EVENT_CLR_WRITE(fd) FD_CLR((fd), &writefds) # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ - *(nsp) = select( SLAP_EVENT_MAX, &readfds, \ + *(nsp) = select( SLAP_EVENT_MAX(t), &readfds, \ nwriters > 0 ? &writefds : NULL, NULL, (tvp) ); \ } while (0) # endif /* !HAVE_WINSOCK */

1 0

Re: (ITS#6618) Add support for unbind requests in perl backend
by masarati＠aero.polimi.it 11 Aug '10

11 Aug '10

>> Full_Name: Gareth Palmer >> Version: CVS HEAD >> OS: Ubuntu 9.04 >> URL: >> http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch >> Submission from: (NULL) (202.21.137.14) >> >> >> Hello, >> >> This patch adds support for passing through unbind requests to the >> underlying >> module when using the perl backend. > > In this patch, the unbind operation is bypassed if requested by the > rootdn. You seem to consider "unbind" as the opposite of "bind", while it > is a request to shutdown a connection between client and server. As such, > it should be honored also when the connection is bound as the rootdn. Also, unbind operations are not supposed to return any response (see RFC4511 for details; note that no unbind response tag is defined). p.

1 0

Re: (ITS#6618) Add support for unbind requests in perl backend
by Kurt＠OpenLDAP.org 11 Aug '10

11 Aug '10

On Aug 11, 2010, at 8:29 AM, masarati(a)aero.polimi.it wrote: >> Full_Name: Gareth Palmer >> Version: CVS HEAD >> OS: Ubuntu 9.04 >> URL: >> = http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch >> Submission from: (NULL) (202.21.137.14) >>=20 >>=20 >> Hello, >>=20 >> This patch adds support for passing through unbind requests to the >> underlying >> module when using the perl backend. >=20 > In this patch, the unbind operation is bypassed if requested by the > rootdn. You seem to consider "unbind" as the opposite of "bind", = while it > is a request to shutdown a connection between client and server. As = such, > it should be honored also when the connection is bound as the rootdn. More to the point, backends should not be dependent on close (nor open) = connection events. Hence this patch ought to be rejected. -- Kurt=

1 0

Re: (ITS#6618) Add support for unbind requests in perl backend
by masarati＠aero.polimi.it 11 Aug '10

11 Aug '10

> Full_Name: Gareth Palmer > Version: CVS HEAD > OS: Ubuntu 9.04 > URL: > http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch > Submission from: (NULL) (202.21.137.14) > > > Hello, > > This patch adds support for passing through unbind requests to the > underlying > module when using the perl backend. In this patch, the unbind operation is bypassed if requested by the rootdn. You seem to consider "unbind" as the opposite of "bind", while it is a request to shutdown a connection between client and server. As such, it should be honored also when the connection is bound as the rootdn. p.

1 0

(ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by m.d.t.evans＠qmul.ac.uk 11 Aug '10

11 Aug '10

Full_Name: Martin Evans Version: 2.4.20 OS: CentOS 5.X URL: Submission from: (NULL) (138.37.8.59) I've attached a proposed patch to fix an error that sometimes occurs when attempting to delete a userPassword attribute from an entry whilst the ppolicy overlay is active. The OL 2.4.20 code seems to assume that this operational attribute always exists (but it clearly cannot always exist otherwise the error would not occur). I think it can be reproduced by adding a fresh entry that contains a userPassword. Then simply deleting the userPassword fails resulting in: ldap_modify: No such attribute (16) additional info: modify/delete: pwdChangedTime: no such attribute Further experiments show that if the userPassword is modified before then deleted the error does not occur (presumably because something else sets pwdChangedTime on a mod operation but not when the attribute is added in an entire new entry). I've modified our OL 2.4.20 test systems with the patch below and the problem goes away: Cheerio! Martin. -bash-3.2# diff -u servers/slapd/overlays/ppolicy.c.0 servers/slapd/overlays/ppolicy.c --- servers/slapd/overlays/ppolicy.c.0 2009-08-26 00:07:41.000000000 +0100 +++ servers/slapd/overlays/ppolicy.c 2010-08-11 14:28:53.000000000 +0100 @@ -1880,22 +1880,31 @@ slap_timestamp( &now, &timestamp ); mods = (Modifications *) ch_calloc( sizeof( Modifications ), 1 ); - mods->sml_desc = ad_pwdChangedTime; + + /* MDTE PATCH 20100811: modify to not do delete non existing pwdChangedTime */ if (pwmop != LDAP_MOD_DELETE) { + mods->sml_desc = ad_pwdChangedTime; mods->sml_op = LDAP_MOD_REPLACE; mods->sml_numvals = 1; mods->sml_values = (BerVarray) ch_malloc( 2 * sizeof( struct berval ) ); ber_dupbv( &mods->sml_values[0], &timestamp ); BER_BVZERO( &mods->sml_values[1] ); assert( !BER_BVISNULL( &mods->sml_values[0] ) ); - + mods->sml_flags = SLAP_MOD_INTERNAL; + mods->sml_next = NULL; + modtail->sml_next = mods; + modtail = mods; } else { - mods->sml_op = LDAP_MOD_DELETE; + if (attr_find(e->e_attrs, ad_pwdChangedTime )) { + mods->sml_desc = ad_pwdChangedTime; + mods->sml_op = LDAP_MOD_DELETE; + mods->sml_flags = SLAP_MOD_INTERNAL; + mods->sml_next = NULL; + modtail->sml_next = mods; + modtail = mods; + } } - mods->sml_flags = SLAP_MOD_INTERNAL; - mods->sml_next = NULL; - modtail->sml_next = mods; - modtail = mods; + /* END OF MDTE PATCH */ if (attr_find(e->e_attrs, ad_pwdGraceUseTime )) { mods = (Modifications *) ch_calloc( sizeof( Modifications ), 1 );

1 0

(ITS#6619) CSN too old
by heinz.hoelzl＠gvcc.net 11 Aug '10

11 Aug '10

Full_Name: Heinz Hölzl Version: 2.4.23 OS: Linux Ubuntu Hardy LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.18.132.37) If i sync a part of my DIT with syncrepl, the first sync works fine. Then if i modify some objects on the provider, on the consumer appears: "do_syncrep2: rid=105 CSN too old, ignoring 20100811125159.871757Z#000000#001#000000" If i sync the hole DIT all works fine. If i use openldap 2.4.19 for syncing only a part of the DIT all works fine too. The version of the provider is 2.4.23 too. slapd.conf on the provider: ...snip.... database ldap lastmod on suffix "dc=krb" rootdn "cn=admin,dc=krb" uri "ldaps://lbackend.s2.dc.gvcc.net:10636" readonly on ...snip... slapd.conf on the consumer: # Schema and objectClass definitions include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/sgv.schema include /etc/openldap/schema/mozillaOrgPerson.schema include /etc/openldap/schema/kerberos.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args allow bind_v2 # Schema check allows for forcing entries to # match schemas for their objectClasses's #schemacheck on loglevel none ####################################################################### # ldbm database definitions ####################################################################### modulepath /usr/lib/ldap moduleload back_hdb moduleload rwm sizelimit unlimited tool-threads 1 access to * by * write include /etc/openldap/tls.conf backend hdb # KERBEROS database hdb dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 lastmod on suffix "dc=krb" checkpoint 512 30 directory "/var/lib/ldap/krb" rootdn "cn=admin,dc=krb" rootpw blabla include /etc/openldap/slapd.replica.consumer-krb index objectClass eq index krbPrincipalName eq,pres,sub index krbPwdPolicyReference eq,pres index entryUUID,aliasedObjectName eq index default sub ############################################################################### /etc/openldap/slapd.replica.consumer-krb: # syncrepl syncrepl rid=101 searchbase="dc=krb" scope=base provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncrepl rid=102 searchbase="cn=princs,dc=krb" scope=base provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncrepl rid=103 searchbase="cn=krbcontainer,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default syncrepl rid=104 searchbase="o=zid,cn=princs,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default syncrepl rid=105 searchbase="o=klingons,cn=princs,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default ################################################################## buid-options for both versions (2.4.19 and 2.4.23) used on the consumer an on the provider: ./configure --prefix=${prefix} --bindir=${prefix}/bin --sbindir=${prefix}/sbin --libexecdir=${prefix}/lib --libdir=${prefix}/lib --sysconfdir=/etc --localstatedir=/var --mandir=${prefix}/share/man --enable-debug --enable-dynamic --enable-syslog --enable-proctitle --enable-ipv6 --enable-local --enable-slapd --enable-aci --enable-cleartext --enable-crypt --disable-lmpasswd --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups --enable-slapi --enable-slp --enable-wrappers --enable-backends=mod --disable-ndb --enable-overlays=mod --with-subdir=ldap --with-cyrus-sasl --with-threads --with-tls=openssl --with-odbc=unixodbc --build x86_64-linux-gnu

1 0

(ITS#6618) Add support for unbind requests in perl backend
by gareth＠acsdata.co.nz 10 Aug '10

10 Aug '10

Full_Name: Gareth Palmer Version: CVS HEAD OS: Ubuntu 9.04 URL: http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch Submission from: (NULL) (202.21.137.14) Hello, This patch adds support for passing through unbind requests to the underlying module when using the perl backend. Regards Gareth

1 0

Re: (ITS#6616) back-sql crashing
by masarati＠aero.polimi.it 08 Aug '10

08 Aug '10

> masarati(a)aero.polimi.it wrote: >>> Attempting to create an inetOrgPerson interface to a proprietary >>> database >>> schema. >>> Obviously something wrong at this stage, causes slapd to SEGV. >>> >>> gdb tells me that in >>> servers/slapd/back-sql/entry-id.c:backsql_id2entry() >>> bsi->bsi_oc is null going into this call. >>> >>> rc = attr_merge_normalize_one( bsi->bsi_e, >>> slap_schema.si_ad_objectClass, >>> &bsi->bsi_oc->bom_oc->soc_cname, >>> bsi->bsi_op->o_tmpmemctx ); >>> >>> Without any time to absorb any implications, adding this just before >>> the >>> above >>> call >>> >>> // added without any clue... Rex >>> if ( eid->eid_oc == NULL ) >>> return LDAP_NO_SUCH_OBJECT; >>> >>> fixes the SEGV, but not my interface. >>> >> >> This should not happen, since that objectClass mapping is explicitly >> obtained few lines above if missing, and if the entry's OC was known by >> ID >> it must be available in the ID to OC mapping. I suspect something like >> ITS#6617, where the obejctClass' ID overflows the unsigned long. Can >> you >> investigate? >> >> A backtrace and a description of the expected and actual values would >> help >> (e.g. what ID has the "offending" objectClass, and what ID is >> backsql_id2entry() actually trying to fetch). >> >> It should be OK, at this point, to give up, but a clear indication that >> mapping did not succeed needs to be returned. >> >> p. >> >> > > I've finished my interface and i'm reluctant to share the mess it was in > when it caused the server to crash. > > What i found was that the call to avl_find() in backsql_id2oc() returned > NULL, which got passed back up the > stack, used as a pointer and boom. > > Without spending a long time trying to decipher the code, i could only > guess what any of this means, i'm not > an LDAP expert (or even really all that familiar with it). Please keep replies in CC to the ITS. In principle, avl_find() must return a valid objectClass; logically, we should assert() that a non-NULL pointer is returned. Determining why this occurs could help fixing the issue. Right now, you're just wiping it under the carpet, by returning a generic error instead of the expected data. p.

1 0

Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> Tentatively, the "right" patch would be like this > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-its6600.1.patch> This patch, although apparently fixing this specific case, breaks test020; investigating... p.

1 0

Re: (ITS#6616) back-sql crashing
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> Attempting to create an inetOrgPerson interface to a proprietary database > schema. > Obviously something wrong at this stage, causes slapd to SEGV. > > gdb tells me that in servers/slapd/back-sql/entry-id.c:backsql_id2entry() > bsi->bsi_oc is null going into this call. > > rc = attr_merge_normalize_one( bsi->bsi_e, > slap_schema.si_ad_objectClass, > &bsi->bsi_oc->bom_oc->soc_cname, > bsi->bsi_op->o_tmpmemctx ); > > Without any time to absorb any implications, adding this just before the > above > call > > // added without any clue... Rex > if ( eid->eid_oc == NULL ) > return LDAP_NO_SUCH_OBJECT; > > fixes the SEGV, but not my interface. This should not happen, since that objectClass mapping is explicitly obtained few lines above if missing, and if the entry's OC was known by ID it must be available in the ID to OC mapping. I suspect something like ITS#6617, where the obejctClass' ID overflows the unsigned long. Can you investigate? A backtrace and a description of the expected and actual values would help (e.g. what ID has the "offending" objectClass, and what ID is backsql_id2entry() actually trying to fetch). It should be OK, at this point, to give up, but a clear indication that mapping did not succeed needs to be returned. p.

1 0

Re: (ITS#6617) back-sql: 64-bit parent IDs get munged
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> 64-bit values for (at least) parent IDs do not get resolved correctly - > only the > lower 32 bits are preserved. This leads up to a crash as it tries to > resolve a > non-existant ID: > > To reproduce: > ldap_entries has a row with an ID of 1,000,000,000 with a parent of > 9,999,999,999 (and > a row 9,999,999,999 for the parent). When back-sql goes to resolve this, the > following shows in the ODBC trace: > > SELECT COUNT(*) FROM > ldap_entry_objclasses,ldap_entries,ldap_static_entries > WHERE ldap_static_entries.id=1410065407 AND > ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 > > (1,410,065,407 = 32-bit rollover of 9,999,999,999). Currently, IDs are hardcoded as 32-bit unsigned (unsigned long) for internal use. In back-sql, we used the same type. I wonder whether it makes sense to allow to customize them (I think using 64-bit regardless of the arch is not a choice). p.

1 0

(ITS#6617) back-sql: 64-bit parent IDs get munged
by 7003＠blargh.com 06 Aug '10

06 Aug '10

Full_Name: Andrew Gray Version: 2.4.23 OS: Debian 5 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.216.14.1) 64-bit values for (at least) parent IDs do not get resolved correctly - only the lower 32 bits are preserved. This leads up to a crash as it tries to resolve a non-existant ID: To reproduce: ldap_entries has a row with an ID of 1000000000 with a parent of 9999999999 (and a row 9999999999 for the parent). When back-sql goes to resolve this, the following shows in the ODBC trace: SELECT COUNT(*) FROM ldap_entry_objclasses,ldap_entries,ldap_static_entries WHERE ldap_static_entries.id=1410065407 AND ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 (1410065407 = 32-bit rollover of 9999999999).

1 0

(ITS#6616) back-sql crashing
by rex.johnston＠gmail.com 06 Aug '10

06 Aug '10

Full_Name: Rex Johnston Version: cvs OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.255.40.107) Attempting to create an inetOrgPerson interface to a proprietary database schema. Obviously something wrong at this stage, causes slapd to SEGV. gdb tells me that in servers/slapd/back-sql/entry-id.c:backsql_id2entry() bsi->bsi_oc is null going into this call. rc = attr_merge_normalize_one( bsi->bsi_e, slap_schema.si_ad_objectClass, &bsi->bsi_oc->bom_oc->soc_cname, bsi->bsi_op->o_tmpmemctx ); Without any time to absorb any implications, adding this just before the above call // added without any clue... Rex if ( eid->eid_oc == NULL ) return LDAP_NO_SUCH_OBJECT; fixes the SEGV, but not my interface.

1 0

Re: (ITS#6615) objectClass definition and error 65
by quanah＠zimbra.com 04 Aug '10

04 Aug '10

--On Tuesday, August 03, 2010 10:43 PM +0000 philippe.eychart(a)mail.pf wrote: > Full_Name: Philippe EYCHART > Version: 2.4.21 > OS: Ubuntu 9.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.50.86.106) This is a question better suited to openldap-technical(a)openldap.org, but inheritance works by having included the previous parent. I.e., person <- organizationalPerson <- inetOrgPerson, as in, inetOrgPerson inherits from organizationalPerson, which inherits from person. person <- organizationalPerson and person <- referencePerson are different inheritance trees. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6614) Checking Pre-Requisities
by quanah＠zimbra.com 04 Aug '10

04 Aug '10

--On Tuesday, August 03, 2010 9:06 PM +0000 tcssuneelkumar(a)gmail.com wrote: > Full_Name: Suneel > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.95.226.224) The ITS system is for reporting bugs. For help with building the software, etc, use the openldap-technical(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6615) objectClass definition and error 65
by philippe.eychart＠mail.pf 03 Aug '10

03 Aug '10

Full_Name: Philippe EYCHART Version: 2.4.21 OS: Ubuntu 9.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.86.106) Hi, Two structural (top) classes are not allowed in the same entry. (a person is not a posixGroup ...) Multiple inheritance is not allowed. (although "oc_sup_oids" is a "char **" in the structure "LDAPObjectClass" ... 8-| ) But, why "organisationalPerson" and "residentialPerson" are they not allowed (error returned: 65) in the same entry of type "person"? Yet, they both inherit from the same objectClass "person"?!... (And these two concepts are not incompatible...) Is this fact a misinterpretation of the "simple inheritance" or this return is correct?... (On the other hand, it's true that "person" and "posixGroup" inherit both from the same -abstract- objectClass : "top" ...) None of my research does the answer (Is this a bugg in the server or must I implement it like that?), so I turn to you ... Regards. PE <http://home.gna.org/ldapcppei/Frontends/Howto-7.fr.html#ss7.2>

1 0

(ITS#6614) Checking Pre-Requisities
by tcssuneelkumar＠gmail.com 03 Aug '10

03 Aug '10

Full_Name: Suneel Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.95.226.224) Hi, I am not a experienced unix admin, but i need to setup OpenLdap 2.4.23 on RedHat Linux environments. As per the Admin guide, There are pre-requisites before we install the openldap. Could you please help me to identify if i have the required pre-install libraries / packages. 1. 4.2.1. Transport Layer Security: [root@tmp]# rpm -q openssl openssl-0.9.8e-12.el5_4.6 2. 4.2.2. Simple Authentication and Security Layer [root@tmp]# rpm -qa | grep -i cyr xorg-x11-drv-cyrix-1.1.0-4 cyrus-sasl-devel-2.1.22-5.el5_4.3 cyrus-sasl-lib-2.1.22-5.el5_4.3 cyrus-sasl-plain-2.1.22-5.el5_4.3 cyrus-sasl-2.1.22-5.el5_4.3 3. Kerberos Authentication Service [root@astro tmp]# rpm -qa | grep krb krb5-devel-1.6.1-36.el5_4.1 krb5-auth-dialog-0.7-1 krb5-libs-1.6.1-36.el5_4.1 pam_krb5-2.2.14-15 krb5-workstation-1.6.1-36.el5_4.1 4. Database Software I have downloaded the latest Oracle Berkley DB (5.0.26) and set it up as per the Berkley install guide. IS this good enough to continue with OpenLdap installation ? Are the 2nd and 3rd pre-requisites are good enough to continue ? Could you also please let me know how to check if the specified pre-requisite is already existing in the server or not. Your help is much appreciated. Thanks

1 0

Re: (ITS#6586) PASSMOD operations are not getting chained correctly
by moenoel＠informatik.uni-bremen.de 31 Jul '10

31 Jul '10

Am 31.07.2010 04:46, schrieb masarati(a)aero.polimi.it: >> Every other write gets chained just fine when a slave is in this >> condition. It's only the PASSMOD operations that are stuck. > > One quick question: can you tell the parameters of the offending PASSMOD > operations? I mean: old/new password, password generated automatically or > provided, operation performed for self or by a privileged identity, and > so? > > Thanks, p. > > The PASSMODs are done by Linux 'passwd', using pam_ldap (mostly on Debian Lenny, if that matters). The new passwords are provided by the user and the operation is perfomed as "self". I don't know if pam_ldap provides the old password as a parameter to the PASSMOD operation. Binding is done with 'simple bind'. The whole SASL/Kerberos stuff is configured and working, but not yet deployed. I could add the client config (PAM, ldap.conf and so on) to the server related stuff in the linked directory, if you need it. Regards, Christian Manal

1 0

Re: (ITS#6612) Back SQL / Mysql / InnoDB
by f.bosch＠genkgo.nl 31 Jul '10

31 Jul '10

This is a multi-part message in MIME format. --------------020601050300000509070509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I did some more research on this issue. I found that the problem can be solved more addequately by adding a configuration option called transaction_model with the following options default|read_committed|read_uncommitted|repeatable_read|serialize. The option default uses the database default, current OpenLDAP implementation, while the other 4 options set the transaction level explicitly. Since InnoDB has repeatable read as default, this prevents from updating resultsets. "For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read." http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html SQL 2000 by Microsoft and PostgreSQL have read committed as default option. http://msdn.microsoft.com/en-us/library/aa259216%28SQL.80%29.aspx http://www.postgresql.org/docs/8.1/static/transaction-iso.html -- * Frederik Bosch* Partner - Genkgo email: f.bosch(a)genkgo.nl <mailto:f.bosch@genkgo.nl> tel: +31(0)6 241 97 443 *Genkgo V.o.f.* <http://www.genkgo.nl> adres: Rooseveltlaan 162-II postcode : 1078 NT Amsterdam web: www.genkgo.nl <http://www.genkgo.nl> Genkgo logo <http://www.genkgo.nl> Dit e-mailbericht is bestemd voor de geadresseerde(n) en kan vertrouwelijk zijn. Gebruik door anderen dan de geadresseerde(n) is verboden. Als dit bericht niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de afzender te melden en het bericht te vernietigen. Genkgo staat geregistreerd bij de Kamer van Koophandel onder nummer 24296168 --------------020601050300000509070509 Content-Type: multipart/related; boundary="------------040401040908020101090801" --------------040401040908020101090801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#ffffff" text="#000000"> I did some more research on this issue. I found that the problem can be solved more addequately by adding a configuration option called transaction_model with the following options default|read_committed|read_uncommitted|repeatable_read|serialize. The option default uses the database default, current OpenLDAP implementation, while the other 4 options set the transaction level explicitly. Since InnoDB has repeatable read as default, this prevents from updating resultsets. "For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read." <a class="moz-txt-link-freetext" href="http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html">http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html</a> SQL 2000 by Microsoft and PostgreSQL have read committed as default option. <a class="moz-txt-link-freetext" href="http://msdn.microsoft.com/en-us/library/aa259216%28SQL.80%29.aspx">http://msdn.microsoft.com/en-us/library/aa259216%28SQL.80%29.aspx</a> <a class="moz-txt-link-freetext" href="http://www.postgresql.org/docs/8.1/static/transaction-iso.html">http://www.postgresql.org/docs/8.1/static/transaction-iso.html</a> <div class="moz-signature">-- <div class="vcard" style="border-top: 1px dotted rgb(153, 153, 153) ! important; padding: 8px ! important; line-height: 14px ! important; font-family: 'Lucida Grande',Verdana,Arial,Sans-Serif ! important; font-size: 10px ! important; color: rgb(85, 85, 85) ! important;"> <div style="border-bottom: 1px dotted rgb(153, 153, 153) ! important; margin: 6px 0pt ! important; width: 420px ! important;"> Frederik Bosch Partner - Genkgo email: <a class="email" href="mailto:f.bosch@genkgo.nl" style="color: rgb(0, 170, 173) ! important; text-decoration: none ! important;">f.bosch(a)genkgo.nl</a> tel: +31(0)6 241 97 443 <a class="organization-name" href="http://www.genkgo.nl" style="color: rgb(0, 170, 173) ! important; text-decoration: none ! important;">Genkgo V.o.f.</a> adres: Rooseveltlaan 162-II postcode : 1078 NT Amsterdam web: <a href="http://www.genkgo.nl" style="color: rgb(0, 170, 173) ! important; text-decoration: none ! important;">www.genkgo.nl</a> <a href="http://www.genkgo.nl"><img class="logo" src="cid:part1.09000506.03080001@genkgo.nl" alt="Genkgo logo" style="border: 0pt none ! important;"></a> </div> <div class="note" style="width: 420px ! important; line-height: 14px; font-family: 'Lucida Grande',Verdana,Arial,Sans-Serif ! important; font-size: 10px ! important; color: rgb(85, 85, 85) ! important;"> Dit e-mailbericht is bestemd voor de geadresseerde(n) en kan vertrouwelijk zijn. Gebruik door anderen dan de geadresseerde(n) is verboden. Als dit bericht niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de afzender te melden en het bericht te vernietigen. Genkgo staat geregistreerd bij de Kamer van Koophandel onder nummer 24296168 </div> </div> </div> </body> </html> --------------040401040908020101090801 Content-Type: image/png; name="genkgo_signature_logo.png" Content-Transfer-Encoding: base64 Content-ID: <part1.09000506.03080001(a)genkgo.nl> Content-Disposition: attachment; filename="genkgo_signature_logo.png" iVBORw0KGgoAAAANSUhEUgAAAF4AAAAYCAMAAABEDbotAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAAKhQTFRFIh8fAKqs////WVdXyMfHv+rqkI+P8fHxEK+xQL/B MC0tYMrLg4GBz+/v7/r6TElJr+TlILW2Z2VlrKur3/T1dXNzPjs7f9TVnp2dMLq8n9/gcM/Q UMXGurm5gNXW4+Pj1dXVj9rbDXZ3BJmaAqGjF0pLICgoFVNUEWVm1tXVCYeJGkJCHDk5C3+A BpCSS0lJodbXE1xdU3FxHjAxKZKTsdzcgszN////7KRBsQAAADh0Uk5T//////////////// /////////////////////////////////////////////////////////wA7XBHKAAADR0lE QVR42qyW6ZbbNgyFQVGUZO3raLOssWfLLEnbLOX7v1kvSEnj9CSe+pzih0hr+QACl6BJL+ZP Hqy71VdZLGV16TnZYW5osRvPvwJ/Q+R9iPdjotfTFyHEy1/fKJz+Ox7xfBi9n9HbixB97qid EKdHiq/Bux/gQX9C4EXqwCIh7t4uL/hKfGPo4sB054jZ/dvlb67Cu/QqIqUOBj8UtVNHXx5v 1ue3ZUgUNhBVpTsZkkTlPSljt4QKqgUP/cgpR2JFP7ZtpNM2ECKIasZLuosAzkfHSRwhEsz7 T2vBJtrMy+yY+RIO7dw1+ArXMhKbJYUdg0TTTA8GWQTwnu/FkV3dU2bxwGRux3qV0GDoQWIU S+MFv4nl7M780p/AjWrPC9jxMiJ2V2iq6GTwxwE3+nrPBVbiwe4Hjg4bDYkobaDaA4qjd43m 2ZHmn3OLj7VOwRxyXJTWA4acPLpDVaM9qOkhcPJgcJy9+GQrxkyfi0+lx0zXrAQ8iYdySZoJ AfidxauRw4Zh3uJdDDsBzSs4cA5IHfx+tviZc2GcdJLO7QxvXtGsuJydiGRnPGndI12MDwDk kIsxT/BagMq8LHqL11bh/xYf8lOd9ktdI73ioZ4Ia7sfkRbgByfpxeEQ1bVYk2NyzTRfLxnR lrvg2UNnw093Riyt1uOCN8np6DMkeTR7yqlFwDUoxBPZxgbNNa47L+sw7dSff8Zz4REMRHNU KsV9ZCjAqDhRdEtPQZ1EFu8UA1978Zhtu1JOqKjrz6abul0cloCWZ3if0/PDCBOWaCxe7FUe GGHqDNLp0XBSlmfuGF2eqNt0v1i1tWzKbBde8Wbvfd02VZCO61QBX2Ff4eYu4AQdolwN4v4x XJr+9M5fy5xV0uJX3Zt9Qd83fqS5J6AAiWlpEhsLW21XA59gDMTrGrwfhxSj35QG47tT5/7m sEkgvLZtx8LWFVmq14Yc0kk57/b3AzXLR+V6GCG7FztnjXgNT3H0Px8ntyFNZ/h4o3Nls2n2 uT02F/HKlDOth4J3178PQ/mHv9Gfw/fD5Kycl0/gNNhSP/ziKK/KeHKfnWe3apr57HFnu3BZ fXSu1JFxEETqV/8UkKGuwaEQV77+P+0fAQYAR9P6f2qWAZwAAAAASUVORK5CYII= --------------040401040908020101090801-- --------------020601050300000509070509--

1 0

(ITS#6613) Back SQL / Mysql / InnoDB
by frederik.bosch＠gmail.com 31 Jul '10

31 Jul '10

Full_Name: Frederik Bosch Version: openldap_2.4.11-1+lenny1 OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.56.158.179) http://www.openldap.org/lists/openldap-technical/201007/msg00390.html Problem Description: using InnoDB as MySQL table engine prevents records from updating. This is due to the autocommit=0 implementation in InnoDB. There are two possible solutions. 1. Execute COMMIT before every SELECT statement 2. Disable autocommit My suggestion is to use the latter one by adding a configuration option for slapd.conf to enable autocommit. Something like disable_autocommit no|yes, which defaults to yes (current implementation). Perhaps, this will have issues for write mode (INSERT), but this backend is intended for read only usage, isn't it? My C knowledge is too limited to add a patch myself. More details can be found in pasted mailing list thread.

1 0

(ITS#6612) Back SQL / Mysql / InnoDB
by frederik.bosch＠gmail.com 31 Jul '10

31 Jul '10

Full_Name: Frederik Bosch Version: openldap_2.4.11-1+lenny1 OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.56.158.179) http://www.openldap.org/lists/openldap-technical/201007/msg00390.html Problem Description: using InnoDB as MySQL table engine prevents records from updating. This is due to the autocommit=0 implementation in InnoDB. There are two possible solutions. 1. Execute COMMIT before every SELECT statement 2. Disable autocommit My suggestion is to use the latter one by adding a configuration option for slapd.conf to enable autocommit. Something like disable_autocommit no|yes, which defaults to yes (current implementation). Perhaps, this will have issues for write mode (INSERT), but this backend is intended for read only usage, isn't it? My C knowledge is too limited to add a patch myself. More details can be found in pasted mailing list thread.

1 0

Re: (ITS#6586) PASSMOD operations are not getting chained correctly
by masarati＠aero.polimi.it 30 Jul '10

30 Jul '10

> Every other write gets chained just fine when a slave is in this > condition. It's only the PASSMOD operations that are stuck. One quick question: can you tell the parameters of the offending PASSMOD operations? I mean: old/new password, password generated automatically or provided, operation performed for self or by a privileged identity, and so? Thanks, p.

1 0

ITS#6611
by masarati＠aero.polimi.it 30 Jul '10

30 Jul '10

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. However, you should fix your configuration by assigning those DNs to a group, and using a group ACL instead. p.

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by masarati＠aero.polimi.it 30 Jul '10

30 Jul '10

> Hey Pierangelo, > > I just noticed http://www.openldap.org/its/index.cgi?findid=6574 - this > looks like it fixes the issue I mentioned in > http://www.openldap.org/its/index.cgi?findid=6540? Is that assertion > correct? I couldn't specifically look at your issue (apart from the simple fix to allow cn=config to work). ITS#6574 should have nothing to do with your issue, as it affects back-meta in a part that has no code commonality with back-ldap, and slapo-chain is built on top of back-ldap. I'm sorry I went back through this thread and got somehow lost; what's the exact topic now? I infer (from followup #14) that there seems to be an issue about chaining because slapo-chain seems not to rebind as expected. Could you isolate the problem in a minimal setup (slapd.conf or the corresponding back-config's LDIF, a database and a simple operation that can be performed with ldapmodify/ldappasswd or so) to clearly reproduce the issue? Thanks, p.

1 0

(ITS#6611) slapd: segmentation fault caused by large ACL
by leonardo＠ngdn.org 30 Jul '10

30 Jul '10

Full_Name: Leonardo Chiquitto Version: 2.4.23 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (189.101.104.29) Setting up a large ACL entry (as the example below) in slapd.conf will make slapd crash with a segmentation fault when starting up. access to dn.subtree="ou=autofs,ou=l,dc=ngdn,dc=org" by dn.base="cn=1,ou=autofs,ou=l,dc=ngdn,dc=org" read by dn.base="cn=2,ou=autofs,ou=l,dc=ngdn,dc=org" read (...) by dn.base="cn=149,ou=autofs,ou=l,dc=ngdn,dc=org" read by dn.base="cn=150,ou=autofs,ou=l,dc=ngdn,dc=org" read Here's the back trace: Program terminated with signal 11, Segmentation fault. #0 0x00007fd98e223b68 in avl_find (root=0x3d63642c6c3d756f, data=0x7fffa163d0c0, fcmp=0x7fd98e1400e0 <attr_index_name_cmp>) at avl.c:545 545 while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { (gdb) bt #0 0x00007fd98e223b68 in avl_find (root=0x3d63642c6c3d756f, data=0x7fffa163d0c0, fcmp=0x7fd98e1400e0 <attr_index_name_cmp>) at avl.c:545 #1 0x00007fd98e13ef9f in at_bvfind (name=0x7fffa163d0c0) at at.c:126 #2 0x00007fd98e13d61d in slap_bv2ad (bv=0x7fd98e5b7880, ad=0x7fffa163d5a8, text=0x7fffa163d5a0) at ad.c:201 #3 0x00007fd98e10c81b in LDAPRDN_rewrite (rdn=0x7fd98e5b78c0, flags=<value optimized out>, ctx=0x0) at dn.c:285 #4 0x00007fd98e10c970 in LDAPDN_rewrite (dn=<value optimized out>, flags=0, ctx=0x0) at dn.c:406 #5 0x00007fd98e10e495 in dnNormalize (use=<value optimized out>, syntax=<value optimized out>, mr=<value optimized out>, val=0x7fd98e4bc1e8, out=0x7fd98e4bc1f8, ctx=0x0) at dn.c:446 #6 0x00007fd98e0ea70d in read_config ( fname=0x7fd98e535030 "/etc/openldap/slapd.conf", dir=0x0) at bconfig.c:4101 #7 0x00007fd98e0dbbf9 in main (argc=13, argv=0x7fffa163d8c8) at main.c:767

1 0

Re: (ITS#6532) Support for common orderingMatching rules in extensible match filters
by daniel＠pluta.biz 30 Jul '10

30 Jul '10

The patch can be downloaded from here: ftp://ftp.openldap.org/incoming/servers-slapd-schema_init.patch.2 passive ftp rules - sorry for the confusion

1 0

Re: (ITS#6610) Client receives SIGPIPE when connected via ldapi with TLS
by hyc＠symas.com 29 Jul '10

29 Jul '10

jzeleny(a)redhat.com wrote: > Full_Name: Jan Zeleny > Version: 2.4.23 > OS: Linux > URL: http://jzeleny.fedorapeople.org/debug/openldap/sigpipe-traces.tar.bz2 > Submission from: (NULL) (209.132.186.34) > > > When running slapd listening on local socket (ldapi:///), clients connecting to > it will sometimes SIGPIPE when using TLS. This happens in about 70% times. > > How to reproduce: > generate a pem certificate > slapd -h ldapi:/// > ldapsearch -H ldapi:/// -ZZ -x -d -1 > > I'm attaching straces from both slapd and ldapsearch. What seems to be happening > is that slapd receives EAGAIN during the read from socket, marks it for another > read, but then terminates a reading thread and closes the connection, while > client still wants to write some data. When doing ldapsearch, it does this after > result was returned, that's why it can be seen probably only in debugging mode. > > The issue was originally reported on 2.3.43, but I successfully reproduced it on > newer versions, including 2.4.23. The only exception was Fedora rawhide version > (currently 2.4.22), which is built with NSS instead of OpenSSL. NSS (and NSPR) > doesn't seem to support local sockets at all, so it is not possible to use ldapi > with -ZZ any more. Not sure this is worth investigating, since there's no reason to use TLS on ldapi://, and as you already said, it won't even be possible with the upcoming (rawhide) packages. > I'm attaching straces from both successful and unsuccessful run. For complete > information here is URL of relevant redhat bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=564108 In regards to the original report, just leave ssl off in the nss_ldap config. Use the starttls URL extension instead. ldap://host/????starttls -- -- 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#6532) Support for common orderingMatching rules in extensible match filters
by daniel＠pluta.biz 29 Jul '10

29 Jul '10

Howard Chu schrieb: > The patch in the URL you specified appears to be empty. Although I'm pretty sure I've successfully uploaded the patch as I (think I) always check the URLs twice right after posting I just tried to upload it again some minutes ago using the filename: servers-slapd-schema_init_2.patch The ftp-server let me successfully log in but does not allow me to upload anything into /incoming: "425 Can't build data connection: Connection refused." Possibly this is also the cause the patch file currently seems to be empty after your download? I've tried the upload from different hosts and networks (IPv6 with IPv4 fallback) without success. Have not investigated in deep but I think it does not seem to be a problem of my/our firewalls. daniel@tingletangle:~$ ftp ftp.openldap.org Connected to www.openldap.org. 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (ftp.openldap.org:daniel): anonymous 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd incoming 250 CWD command successful. ftp> ascii 200 Type set to A. ftp> put servers-slapd-schema_init_2.patch local: servers-slapd-schema_init_2.patch remote: servers-slapd-schema_init_2.patch 200 PORT command successful. 425 Can't build data connection: Connection refused. ftp> quit

1 0

(ITS#6610) Client receives SIGPIPE when connected via ldapi with TLS
by jzeleny＠redhat.com 28 Jul '10

28 Jul '10

Full_Name: Jan Zeleny Version: 2.4.23 OS: Linux URL: http://jzeleny.fedorapeople.org/debug/openldap/sigpipe-traces.tar.bz2 Submission from: (NULL) (209.132.186.34) When running slapd listening on local socket (ldapi:///), clients connecting to it will sometimes SIGPIPE when using TLS. This happens in about 70% times. How to reproduce: generate a pem certificate slapd -h ldapi:/// ldapsearch -H ldapi:/// -ZZ -x -d -1 I'm attaching straces from both slapd and ldapsearch. What seems to be happening is that slapd receives EAGAIN during the read from socket, marks it for another read, but then terminates a reading thread and closes the connection, while client still wants to write some data. When doing ldapsearch, it does this after result was returned, that's why it can be seen probably only in debugging mode. The issue was originally reported on 2.3.43, but I successfully reproduced it on newer versions, including 2.4.23. The only exception was Fedora rawhide version (currently 2.4.22), which is built with NSS instead of OpenSSL. NSS (and NSPR) doesn't seem to support local sockets at all, so it is not possible to use ldapi with -ZZ any more. I'm attaching straces from both successful and unsuccessful run. For complete information here is URL of relevant redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=564108

1 0

(ITS#6609) Admin Guide Documentation typo's
by paul＠mawsonlakes.org 28 Jul '10

28 Jul '10

Full_Name: Paul Schulz Version: CVS OS: Linux/Ubuntu URL: Submission from: (NULL) (116.212.217.6) Patch.. diff --git a/admin/access-control.sdf b/admin/access-control.sdf index f18dba3..1ff6815 100644 --- a/admin/access-control.sdf +++ b/admin/access-control.sdf @@ -826,7 +826,7 @@ This ACL grants read permissions to authenticated users while denying others H3: Controlling rootdn access -You could specify the {{rootdn}} in {{slapd.conf}}(5) or {[slapd.d}} without +You could specify the {{rootdn}} in {{slapd.conf}}(5) or {{slapd.d}} without specifying a {{rootpw}}. Then you have to add an actual directory entry with the same dn, e.g.: @@ -876,7 +876,7 @@ One can then grant access to the members of this this group by adding appropriat > by group.exact="cn=Administrators,dc=example,dc=com" write > by * auth -Like by {[dn}} clauses, one can also use {{expand}} to expand the group name +Like by {{dn}} clauses, one can also use {{expand}} to expand the group name based upon the regular expression matching of the target, that is, the to {{dn.regex}}). For instance, diff --git a/admin/appendix-common-errors.sdf b/admin/appendix-common-errors.sdf index b285cd2..be901f1 100644 --- a/admin/appendix-common-errors.sdf +++ b/admin/appendix-common-errors.sdf @@ -11,7 +11,7 @@ H2: Common causes of LDAP errors H3: ldap_*: Can't contact LDAP server -The {[B:Can't contact LDAP server}} error is usually returned when the LDAP +The {{B:Can't contact LDAP server}} error is usually returned when the LDAP server cannot be contacted. This may occur for many reasons: * the LDAP server is not running; this can be checked by running, for example,

1 0

Re: (ITS#6531) Modify updateref to generate referrals on the backend
by hyc＠symas.com 28 Jul '10

28 Jul '10

Rein Tollevik wrote: > On 04/25/2010 12:49 AM, hyc(a)symas.com wrote: > >> Also in terms of logical abstraction the current behavior is wrong; the >> frontend should of course generate the default_referral responses but >> updateref is a per-backend item and should be generated at the backend layer. >> Ideally this would all have been fixed to behave correctly by moving all >> replication support into an overlay, where it properly belongs. As an interim >> step it would be trivial to write an updateref overlay that supersedes the >> current updateref behavior. > > Updateref processing should imo be kept out of any replication modules, > it is needed in databases where syncrepl isn't configured too. I'm > using it on my subordinate databases (with an artificial updatedn so > that slapd accepts it..) when syncrepl is configured on the superior > glue database without managing all of the subordinate databases. I.e, > the infamous test058... > > I was having the same "chain only on some of the databases" requirement > and is using a patch that allows it. I consider this patch more of a > hack than a correct solution, which is why I haven't contributed it. A > separate updateref overlay apear to me as the best solution. But for > what it's worth, my patch is now in: > > ftp://ftp.openldap.org/incoming/rein-ITS6531.patch > > An advantage with this patch over a new overlay is that it should be > usable without any configuration changes (provided the chain overlay > have already been configured in the databases and found to not work as > expected there that is ... ;-). I didn't quite follow the intended usage for this patch. Are other overlays expected to override the default over_mod_ref() handler? -- -- 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#6532) Support for common orderingMatching rules in extensible match filters
by Howard Chu 28 Jul '10

28 Jul '10

The patch in the URL you specified appears to be empty.

1 0

Re: (ITS#6607) forwarded bind failure messages cause success
by hyc＠symas.com 28 Jul '10

28 Jul '10

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: RE24 > OS: > URL: > Submission from: (NULL) (76.88.107.46) > > > As noted in > > http://www.openldap.org/lists/openldap-technical/201004/msg00247.html > > setting up a chain overlay on the frontend and then configuring ppolicy with > ppolicy_forward_updates causes BIND operations with invalid credentials to > return success, apparently from the result of the chain operation. > > This is independent of the value of chain-return-error. > > WHOAMI reports anonymous after these "successful" BINDs with invalid passwords, > so there is no security compromise within the directory itself, however this has > (as noted in the above email) catastrophic results for external apps trying to > authenticate with BIND. > > This was already fixed in HEAD by back-ldap/chain.c rev 1.77 (apparently fixed for unrelated reasons). -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs