- openldap-bugs - openldap.org

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 23 Oct '07

23 Oct '07

As discussed on committers, I have disabled the failing part of the test for now in RE24. (Should be re-enabled when the root-cause of this problem is fixed) -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 23 Oct '07

23 Oct '07

On Dienstag, 23. Oktober 2007, ando(a)sys-net.it wrote: > For the records: I seem to be ble to consistently reproduce the issue when > running slapd under valgrind; Thanks, that seems to do the trick for me as well. > I haven't seen it yet when running the test > regularly (single CPU i386, recently). -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠suretecsystems.com 23 Oct '07

23 Oct '07

Ralf Haferkamp wrote: > Btw, could you attach your pcache configuration to this bug? It's on the ticket already Ralf: ftp://ftp.openldap.org/incoming/testrun-test020-proxycache-failing.tar.gz -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#5191) Corrupted control value when using pagedresults with subordinate database
by ando＠sys-net.it 23 Oct '07

23 Oct '07

> When using pagedresults with a subordinate database, the control value of > the > returned searchResDone is corrupted. AFAIK, paged results is not supposed to work with glued databases, as its current implementation in both back-bdb/back-hdb and back-sql relies on internal properties of the storage to keep track of the state of a search. The most appropriate behavior would be to ignore the control, if not critical, or reject the operation, if critical. I take this ITS as an action to prevent paged results from working when impacting more than one glued database. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ando＠sys-net.it 23 Oct '07

23 Oct '07

For the records: I seem to be ble to consistently reproduce the issue when running slapd under valgrind; I haven't seen it yet when running the test regularly (single CPU i386, recently). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 23 Oct '07

23 Oct '07

Btw, could you attach your pcache configuration to this bug? On Mittwoch, 17. Oktober 2007, ghenry(a)suretecsystems.com wrote: [..] > > > > I just did the same on my x86_64 dual core. Result: 1 failure and 99 > > passes. > > Might be that this bug is better reproducable on a single core machine. > > But at > > least I was able to reproduce it now. > > I can run the same command above on a x86_64 dual core on Monday, as I'm > away on business the rest of the week. > > >> Very strange.... > > > > I have fixed a very similar issue recently (at least I thought I fixed > > it :| ). I'll take a closer look tomorrow. -- Ralf

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by hyc＠symas.com 22 Oct '07

22 Oct '07

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> Just reproduced it. Out of locks (so of course configure more), then >> "Accessing a corrupted shared library". Will file a separate ITS, it >> doesn't sound like slapadd in a clean directory should need 1000+ locks. > > ...yes it should, it was a case of writing an entry with many values > in an indexed attribute - after the index was big enough that presumably > few of the new values' hashes ended up on the same DB page. So, it's > just a spurious scary error message afterwards from BerkeleyDB. > The "Accessing a corrupted shared library" message occurs on Linux because it's logging an LDAP result code (80, LDAP_OTHER) as a system errno code. Probably ought to change that... -- -- Howard Chu Chief Architect, 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#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no 22 Oct '07

22 Oct '07

I wrote: > Just reproduced it. Out of locks (so of course configure more), then > "Accessing a corrupted shared library". Will file a separate ITS, it > doesn't sound like slapadd in a clean directory should need 1000+ locks. ...yes it should, it was a case of writing an entry with many values in an indexed attribute - after the index was big enough that presumably few of the new values' hashes ended up on the same DB page. So, it's just a spurious scary error message afterwards from BerkeleyDB. -- Regards, Hallvard

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no 22 Oct '07

22 Oct '07

hyc(a)symas.com writes: > These are backend-specific considerations. Feel free to file an ITS > against the slapd-bdb(5) manpage if you wish. Might as well be this one. "Need to document what you are explaining here." Probably mostly in the Admin Guide with a few notes in the manpage. > Any operation will acquire a lock for every single DB page it > touches. (...) I don't think that can be quite right. A search which traverses the database would need an awful lot of locks. Unless for the entries it acquires and then releases the locks for one entry at a time. > The more work that an operation needs to do, the more pages > it will touch, the more locks it will need. (...) Another item would be entries needed to evaluate access controls, I assume. >> Sleepycat messages can be scary. I came from the slapadd "wrong dynamic >> library" or message or whatever it was which the mailinglist says is >> cured with more locks & lockers, so I increased those and just got >> another error message (this ITs). So apparently, something still wrong. > > I'm not familiar with that message or advice. Just reproduced it. Out of locks (so of course configure more), then "Accessing a corrupted shared library". Will file a separate ITS, it doesn't sound like slapadd in a clean directory should need 1000+ locks. http://www.openldap.org/lists/openldap-software/200607/msg00305.html >> "Not configured for the locking subsystem" sounded like a permanent >> problem with the database build, not that it would get "reconfigured" >> to support locking when needed. Hence this report. Oh well. > > The message said The Environment is not configured for locking. It > didn't say the BDB library. Yes, that's what I meant. The database, with its enviroment, I just built with slapadd. > Really there's nothing mystical or spooky here, and if you've actually > read the BDB documentation you'll know what The Environment refers > to. If you're using back-[bh]db without having read the BDB > documentation, despite all the recommendations to do so, you deserve > to be scared. I've read it. -- Regards, Hallvard

1 0

(ITS#5196) Documentation should indicate that slurpd is deprecated
by bgmilne＠staff.telkomsa.net 22 Oct '07

22 Oct '07

Full_Name: Buchan Milne Version: REL_ENG_2_3 (post-2.3.38) OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.15.129.131) It is well known that slurpd is deprecated, and it has been removed from 2.4. However, many questions arise in various support fora (case in point, #ldap on irc.freenode.net) about setting up slurpd, and the documentation still covers slurpd, without noting that it is deprecated (which probably contributes to continued use of slurpd, even on 2.3). A notice should be placed at least in the following places to this effect: -slurpd(8) -Admin guide chapter 14 -replica section of slapd.conf(5) -slapd.replog(5)

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by hyc＠symas.com 22 Oct '07

22 Oct '07

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> quanah(a)zimbra.com writes: >>>> You have to run slapd at least once before using the db_stat tool >>>> after using slapadd -q. This is a known feature of using -q. >>> Ah, need doc fix in slapadd.8 then. >> What exactly are you trying to do? > > Playing around, mostly. > >> slapadd -q disables locking, > > I don't see that in the doc. It's reasonable to infer, except I have no > idea why even slapadd (without -q) needs so many. I couldn't find an > explanation of what does use locks and lockers (FAQ file 893 doesn't > say), thus not how many I will need and which of these limits is fatal > if I have too few. Can experiment to find out the latter, of course. These are backend-specific considerations. Feel free to file an ITS against the slapd-bdb(5) manpage if you wish. In back-[bh]db there are typically up to two transactions per operation, and each transaction uses a single locker. There's also a single reader locker per thread. So at most you need 3 lockers per configured server thread. The BDB default of 1000 is generally more than enough. Any operation will acquire a lock for every single DB page it touches. The more work that an operation needs to do, the more pages it will touch, the more locks it will need. If you write an entry that has many indexed attributes, or if you have substring indices on attributes with lengthy values, you will need many locks in a single operation. While the number of pages simultaneously held open will depend on the actual distribution of data in the database, an operation will generally need at least one lock per DB file. So, one for a dn2id lookup, one for an id2entry lookup, and one for each defined index. In most cases that's all, but substring indices will generally need a number of locks proportional to the length of the strings being indexed. > Sleepycat messages can be scary. I came from the slapadd "wrong dynamic > library" or message or whatever it was which the mailinglist says is > cured with more locks & lockers, so I increased those and just got > another error message (this ITs). So apparently, something still wrong. I'm not familiar with that message or advice. > "Not configured for the locking subsystem" sounded like a permanent > problem with the database build, not that it would get "reconfigured" to > support locking when needed. Hence this report. Oh well. The message said The Environment is not configured for locking. It didn't say the BDB library. Really there's nothing mystical or spooky here, and if you've actually read the BDB documentation you'll know what The Environment refers to. If you're using back-[bh]db without having read the BDB documentation, despite all the recommendations to do so, you deserve to be scared. >> so of course there's nothing for db_stat -c to report. There's no >> breakage here. > -- -- Howard Chu Chief Architect, 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#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no 21 Oct '07

21 Oct '07

hyc(a)symas.com writes: >h.b.furuseth(a)usit.uio.no wrote: >> quanah(a)zimbra.com writes: >>> You have to run slapd at least once before using the db_stat tool >>> after using slapadd -q. This is a known feature of using -q. >> >> Ah, need doc fix in slapadd.8 then. > > What exactly are you trying to do? Playing around, mostly. > slapadd -q disables locking, I don't see that in the doc. It's reasonable to infer, except I have no idea why even slapadd (without -q) needs so many. I couldn't find an explanation of what does use locks and lockers (FAQ file 893 doesn't say), thus not how many I will need and which of these limits is fatal if I have too few. Can experiment to find out the latter, of course. Sleepycat messages can be scary. I came from the slapadd "wrong dynamic library" or message or whatever it was which the mailinglist says is cured with more locks & lockers, so I increased those and just got another error message (this ITs). So apparently, something still wrong. "Not configured for the locking subsystem" sounded like a permanent problem with the database build, not that it would get "reconfigured" to support locking when needed. Hence this report. Oh well. > so of course there's nothing for db_stat -c to report. There's no > breakage here. -- Hallvard

1 0

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 19 Oct '07

19 Oct '07

russell-openldap(a)stuart.id.au wrote: > I am trying to insist that connections during sasl auth operations are > encrypted. Ie, that this works: > > access to attrs=userPassword > by tls_ssf=128 ssf=128 anonymous auth > by * none > > It does work for a simple bind. But for a sasl bind it fails, and this telltale > appears in the log: > > slapd[26499]: <= check a_authz.sai_ssf: ACL 128 > OP 0 > > I fixed the issue using this patch, which applies to 2.4.5, 2.3.38 and 2.3.30: I suppose that may be a legitimate bug, but this isn't really the correct fix. slap_auxprop_lookup is doing an internal search, so there is no network to speak of. In SSF terms it would have an SSF of "infinity". > diff -Nur openldap2.3-2.3.30/servers/slapd/sasl.c > openldap2.3-2.3.30.new/servers/slapd/sasl.c > --- openldap2.3-2.3.30/servers/slapd/sasl.c 2007-10-19 15:27:53.000000000 > +1000 > +++ openldap2.3-2.3.30.new/servers/slapd/sasl.c 2007-10-19 15:29:18.000000000 > +1000 > @@ -384,6 +384,7 @@ > op.ors_slimit = 1; > op.ors_filter = &generic_filter; > op.ors_filterstr = generic_filterstr; > + op.o_authz = conn->c_authz; > /* FIXME: we want all attributes, right? */ > op.ors_attrs = NULL; > > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 19 Oct '07

19 Oct '07

Full_Name: Russell Stuart Version: 2.3.30 OS: Debian Etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.15.201.110) I am trying to insist that connections during sasl auth operations are encrypted. Ie, that this works: access to attrs=userPassword by tls_ssf=128 ssf=128 anonymous auth by * none It does work for a simple bind. But for a sasl bind it fails, and this telltale appears in the log: slapd[26499]: <= check a_authz.sai_ssf: ACL 128 > OP 0 I fixed the issue using this patch, which applies to 2.4.5, 2.3.38 and 2.3.30: diff -Nur openldap2.3-2.3.30/servers/slapd/sasl.c openldap2.3-2.3.30.new/servers/slapd/sasl.c --- openldap2.3-2.3.30/servers/slapd/sasl.c 2007-10-19 15:27:53.000000000 +1000 +++ openldap2.3-2.3.30.new/servers/slapd/sasl.c 2007-10-19 15:29:18.000000000 +1000 @@ -384,6 +384,7 @@ op.ors_slimit = 1; op.ors_filter = &generic_filter; op.ors_filterstr = generic_filterstr; + op.o_authz = conn->c_authz; /* FIXME: we want all attributes, right? */ op.ors_attrs = NULL;

1 0

(ITS#5194) tpool lockup in RE_24
by quanah＠zimbra.com 18 Oct '07

18 Oct '07

Full_Name: Quanah Gibson-Mount Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) Using latest RE_24, test050 locked up on me. slapd backtrace shows: (gdb) info threads 1 Thread 46912516103168 (LWP 8947) 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038dcc087c4 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038dcc08263 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002aaaaaabc72e in ldap_pvt_thread_pool_resume (tpool=<value optimized out>) at tpool.c:703 #4 0x000000000041d8d5 in config_back_modify (op=0x7fffeb28cc50, rs=0x7fffeb28cdc0) at bconfig.c:4710 #5 0x00002aaaac3d5944 in syncprov_checkpoint (op=0x7fffeb28cec0, rs=<value optimized out>, on=0x1b8df9d0) at syncprov.c:1318 #6 0x00002aaaac3d5f02 in syncprov_db_close (be=0x1b7a6440, cr=<value optimized out>) at syncprov.c:2660 #7 0x0000000000485578 in over_back_response (op=0x1b7c57c0, rs=0x1b7c57c0) at backover.c:234 #8 0x0000000000000000 in ?? () (gdb) frame 3 #3 0x00002aaaaaabc72e in ldap_pvt_thread_pool_resume (tpool=<value optimized out>) at tpool.c:703 703 ldap_pvt_thread_mutex_lock(&pool->ltp_mutex); (gdb) l 698 pool = *tpool; 699 700 if (pool == NULL) 701 return(0); 702 703 ldap_pvt_thread_mutex_lock(&pool->ltp_mutex); 704 pool->ltp_pause = 0; 705 if (pool->ltp_state == LDAP_INT_THREAD_POOL_RUNNING) 706 ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); 707 ldap_pvt_thread_mutex_unlock(&pool->ltp_mutex);

1 0

Re: (ITS#5193) defines.sh error
by hyc＠symas.com 18 Oct '07

18 Oct '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.202.148.128) > > > make[2]: Entering directory `/usr/local/build/ldap-rel-eng-2-4/tests' > Initiating LDAP tests for BDB... > ./scripts/defines.sh: line 55: cd: ./schema: No such file or directory > Running ./scripts/all... >>>>>> Executing all LDAP tests for bdb > > > SCHEMADIR=${USER_SCHEMADIR-./schema} > ABS_SCHEMADIR=`(cd $SCHEMADIR; pwd)` > > Should that be ../schema? Why do we need to cd to it? Nothing is failing so > far by not doing so. That'll only happen the first time. We cd into it so that pwd will tell us the absolute path. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5193) defines.sh error
by quanah＠zimbra.com 18 Oct '07

18 Oct '07

Full_Name: Quanah Gibson-Mount Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) make[2]: Entering directory `/usr/local/build/ldap-rel-eng-2-4/tests' Initiating LDAP tests for BDB... ./scripts/defines.sh: line 55: cd: ./schema: No such file or directory Running ./scripts/all... >>>>> Executing all LDAP tests for bdb SCHEMADIR=${USER_SCHEMADIR-./schema} ABS_SCHEMADIR=`(cd $SCHEMADIR; pwd)` Should that be ../schema? Why do we need to cd to it? Nothing is failing so far by not doing so.

1 0

(ITS#5192) MMR refresh and persist broken
by quanah＠zimbra.com 18 Oct '07

18 Oct '07

Full_Name: Quanah Gibson-Mount Version: 2.4.5 beta OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) Refresh and persist MMR mode is broken in 2.4.5 beta. ITS filed for tracking purposes, already fixed in HEAD.

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by hyc＠symas.com 17 Oct '07

17 Oct '07

h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: >> You have to run slapd at least once before using the db_stat tool >> after using slapadd -q. This is a known feature of using -q. > > Ah, need doc fix in slapadd.8 then. What exactly are you trying to do? slapadd -q disables locking, so of course there's nothing for db_stat -c to report. There's no breakage here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5191) Corrupted control value when using pagedresults with subordinate database
by mspeder＠syrtis.net 17 Oct '07

17 Oct '07

Full_Name: Matthieu Speder Version: 2.3.38 & Latest HEAD OS: Linux URL: Submission from: (NULL) (82.224.96.182) When using pagedresults with a subordinate database, the control value of the returned searchResDone is corrupted. * Config part database ldap suffix "dc=test,dc=com" subordinate uri "ldap://ldap2.test.com:389" lastmod off overlay rwm rwm-rewriteEngine on rwm-suffixmassage "dc=test,dc=com" "dc=mainldap,dc=com" * Query : ldapsearch -x -b 'dc=test,dc=com' '(objectclass=*)' -E pr=10 (...) # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MAUCAQAEAA== pagedresults: cookie= control:: IGZhbHNlIE1Ba0NBUUFFQkFzQUFBQT0= * Packet decode : Lightweight-Directory-Access-Protocol LDAPMessage searchResDone(2) [0 results] messageID: 2 protocolOp: searchResDone (5) controls: 2 items Item pagedResultsControl controlType: 1.2.840.113556.1.4.319 (pagedResultsControl) SearchControlValue size: 0 cookie: <MISSING> Item controlType: \300\3371\b840.113556.1.4.319 controlValue: 300902010004040B000000 0000 00 0c 29 06 cc dd 00 0c 29 1b ea e9 08 00 45 00 ..).....).....E. 0010 00 8e 7b fd 40 00 40 06 a7 ca 0a 00 01 5d 0a 00 ..{.@.@......].. 0020 01 46 01 85 a8 92 c0 a3 d0 9d 5e c3 30 b0 80 18 .F........^.0... 0030 05 a8 2b 24 00 00 01 01 08 0a 01 16 bf 7a 00 00 ..+$.........z.. 0040 1a e9 30 58 02 01 02 65 07 0a 01 00 04 00 04 00 ..0X...e........ 0050 a0 4a 30 21 04 16 31 2e 32 2e 38 34 30 2e 31 31 .J0!..1.2.840.11 0060 33 35 35 36 2e 31 2e 34 2e 33 31 39 04 07 30 05 3556.1.4.319..0. 0070 02 01 00 04 00 30 25 04 16 c0 df 31 08 38 34 30 .....0%....1.840 0080 2e 31 31 33 35 35 36 2e 31 2e 34 2e 33 31 39 04 .113556.1.4.319. 0090 0b 30 09 02 01 00 04 04 0b 00 00 00 .0..........

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no 17 Oct '07

17 Oct '07

quanah(a)zimbra.com writes: > You have to run slapd at least once before using the db_stat tool > after using slapadd -q. This is a known feature of using -q. Ah, need doc fix in slapadd.8 then. -- Hallvard

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by quanah＠zimbra.com 17 Oct '07

17 Oct '07

--On Wednesday, October 17, 2007 1:29 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.3.38 > OS: Linux (x86_64) > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard You have to run slapd at least once before using the db_stat tool after using slapadd -q. This is a known feature of using -q. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠suretecsystems.com 17 Oct '07

17 Oct '07

<quote who="Ralf Haferkamp"> > On Mittwoch, 17. Oktober 2007, ghenry(a)suretecsystems.com wrote: >> >> ldapsearch failed (4) >> >> Query 10 not answerable >> > >> > ^^^^^^^^^^^^^^^^^^^^^^^^^ >> > This on seems to be the problem it should be "answerable". Does the >> test >> > fail >> > for you reproducably? I am asking because it doesn't fail for me. >> Neither >> > in >> > RE24 nor in HEAD. >> >> I've just run the test by hand again on the same machine 10 times. It >> passed 3 times and failed 7. >> >> I also just ran: >> >> for i in `seq 1 100`; do ./run test020 >> test_results.log; done; >> >> and grepped the log file for "Error" and -i "succeed". >> >> Results: >> >> 12 Passes >> 88 Fails > I just did the same on my x86_64 dual core. Result: 1 failure and 99 > passes. > Might be that this bug is better reproducable on a single core machine. > But at > least I was able to reproduce it now. I can run the same command above on a x86_64 dual core on Monday, as I'm away on business the rest of the week. > >> Very strange.... > I have fixed a very similar issue recently (at least I thought I fixed > it :| ). I'll take a closer look tomorrow. Cool, thanks.

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 17 Oct '07

17 Oct '07

On Mittwoch, 17. Oktober 2007, ghenry(a)suretecsystems.com wrote: > >> ldapsearch failed (4) > >> Query 10 not answerable > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > This on seems to be the problem it should be "answerable". Does the test > > fail > > for you reproducably? I am asking because it doesn't fail for me. Neither > > in > > RE24 nor in HEAD. > > I've just run the test by hand again on the same machine 10 times. It > passed 3 times and failed 7. > > I also just ran: > > for i in `seq 1 100`; do ./run test020 >> test_results.log; done; > > and grepped the log file for "Error" and -i "succeed". > > Results: > > 12 Passes > 88 Fails I just did the same on my x86_64 dual core. Result: 1 failure and 99 passes. Might be that this bug is better reproducable on a single core machine. But at least I was able to reproduce it now. > Very strange.... I have fixed a very similar issue recently (at least I thought I fixed it :| ). I'll take a closer look tomorrow. -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠suretecsystems.com 17 Oct '07

17 Oct '07

>> ldapsearch failed (4) >> Query 10 not answerable > ^^^^^^^^^^^^^^^^^^^^^^^^^ > This on seems to be the problem it should be "answerable". Does the test > fail > for you reproducably? I am asking because it doesn't fail for me. Neither > in > RE24 nor in HEAD. > I've just run the test by hand again on the same machine 10 times. It passed 3 times and failed 7. I also just ran: for i in `seq 1 100`; do ./run test020 >> test_results.log; done; and grepped the log file for "Error" and -i "succeed". Results: 12 Passes 88 Fails Very strange.... Gavin.

1 0

Re: (ITS#5188) ldap_get_option documentation
by ando＠sys-net.it 17 Oct '07

17 Oct '07

senarvi2007(a)gmail.com wrote: > The manual page for ldap_get_option is inaccurate regarding LDAP_OPT_TIMEOUT and > LDAP_OPT_NETWORK_TIMEOUT. It says > > outvalue and invalue must be a struct timeval * > > while in fact outvalue has to be a struct timeval **. Also, it is only said in > the source code that the caller has to free outvalue. Fixed in HEAD/re24; not in re23 thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no 17 Oct '07

17 Oct '07

Full_Name: Hallvard B Furuseth Version: 2.3.38 OS: Linux (x86_64) URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard With db-4.2.52 + their 5 patches, built with --enable-umrw --disable-cryptography: bash$ cat test.conf database bdb directory ./test-data suffix cn=test bash$ rm test-data/* bash$ cp /ldap/usr/etc/openldap/DB_CONFIG.example test-data/DB_CONFIG bash$ slapadd -q -f test.conf -l /dev/null bash$ db_stat -c -h test-data db_stat: DB_ENV->lock_stat interface requires an environment configured for the locking subsystem db_stat: Invalid argument It works without '-q': bash$ rm test-data/* bash$ cp /ldap/usr/etc/openldap/DB_CONFIG.example test-data/DB_CONFIG bash$ slapadd -f test.conf -l /dev/null bash$ db_stat -c -h test-data 6 Last allocated locker ID. 2147M Current maximum unused locker ID. 9 Number of lock modes. 1000 Maximum number of locks possible. 1000 Maximum number of lockers possible. 1000 Maximum number of lock objects possible. 0 Number of current locks. 3 Maximum number of locks at any one time. 0 Number of current lockers. 6 Maximum number of lockers at any one time. 0 Number of current lock objects. 3 Maximum number of lock objects at any one time. 9 Total number of locks requested. 9 Total number of locks released. 0 Total number of lock requests failing because DB_LOCK_NOWAIT was set. 0 Total number of locks not immediately available due to conflicts. 0 Number of deadlocks. 0 Lock timeout value. 0 Number of locks that have timed out. 0 Transaction timeout value. 0 Number of transactions that have timed out. 648KB The size of the lock region.. 0 The number of region locks granted after waiting. 50 The number of region locks granted without waiting.

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠suretecsystems.com 17 Oct '07

17 Oct '07

<quote who="Pierangelo Masarati"> > ando(a)sys-net.it wrote: >> ghenry(a)suretecsystems.com wrote: >> >>> All tests pass in HEAD. test048 still failing in RE24. >> >> The difference consists in James A Jones 2 not being deleted from the >> slave when deleted from the master. I'm investigating... > > re24 was missing the syncrepl portion of the fix for ITS#5168. Fixed. All tested on that machine. Everything passes. Thanks. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠suretecsystems.com 17 Oct '07

17 Oct '07

<quote who="Ralf Haferkamp"> > On Mittwoch, 17. Oktober 2007, ghenry(a)openldap.org wrote: >> Full_Name: Gavin Henry >> Version: RE_2_4 >> OS: FC7 - i386 >> URL: >> ftp://ftp.openldap.org/incoming/testrun-test020-proxycache-failing.tar.gz >> Submission from: (NULL) (212.159.59.85) >> Submitted by: ghenry >> >> >> [ghenry@suretec tests]$ ./run test020 > [..] >> Successfully verified cacheability >> Query 10: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid >> Query 11: filter:(sn=Smith) attrs:cn sn title uid >> Query 12: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn >> uid Query 13: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn >> title >> uid Query 14: filter:(mail=*example.com) attrs:cn sn title uid >> ldapsearch failed (4) >> Query 15: filter:(uid=b*) attrs:mail >> ldapsearch failed (4) >> Query 10 not answerable > ^^^^^^^^^^^^^^^^^^^^^^^^^ > This on seems to be the problem it should be "answerable". Does the test > fail > for you reproducably? I am asking because it doesn't fail for me. Neither > in > RE24 nor in HEAD. > On the i386 at my home office, everytime. At our main office, a AMD 64 Dual Core test machine passes ok. Will try home office again later today. Thanks.

1 0

(ITS#5188) ldap_get_option documentation
by senarvi2007＠gmail.com 17 Oct '07

17 Oct '07

Full_Name: Seppo Enarvi Version: OpenLDAP 2.4.5beta OS: N/A URL: Submission from: (NULL) (193.208.185.178) The manual page for ldap_get_option is inaccurate regarding LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT. It says outvalue and invalue must be a struct timeval * while in fact outvalue has to be a struct timeval **. Also, it is only said in the source code that the caller has to free outvalue.

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 17 Oct '07

17 Oct '07

On Mittwoch, 17. Oktober 2007, ghenry(a)openldap.org wrote: > Full_Name: Gavin Henry > Version: RE_2_4 > OS: FC7 - i386 > URL: > ftp://ftp.openldap.org/incoming/testrun-test020-proxycache-failing.tar.gz > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > [ghenry@suretec tests]$ ./run test020 [..] > Successfully verified cacheability > Query 10: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid > Query 11: filter:(sn=Smith) attrs:cn sn title uid > Query 12: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn > uid Query 13: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title > uid Query 14: filter:(mail=*example.com) attrs:cn sn title uid > ldapsearch failed (4) > Query 15: filter:(uid=b*) attrs:mail > ldapsearch failed (4) > Query 10 not answerable ^^^^^^^^^^^^^^^^^^^^^^^^^ This on seems to be the problem it should be "answerable". Does the test fail for you reproducably? I am asking because it doesn't fail for me. Neither in RE24 nor in HEAD. > Query 11 answerable > Query 12 answerable > Query 13 not answerable > Query 14 not answerable > Query 15 answerable > Error in verifying answerability -- Ralf

1 0

(ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠OpenLDAP.org 17 Oct '07

17 Oct '07

Full_Name: Gavin Henry Version: RE_2_4 OS: FC7 - i386 URL: ftp://ftp.openldap.org/incoming/testrun-test020-proxycache-failing.tar.gz Submission from: (NULL) (212.159.59.85) Submitted by: ghenry [ghenry@suretec tests]$ ./run test020 Cleaning up test run directory leftover from previous run. Running ./scripts/test020-proxycache... Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to populate the master directory... Starting proxy cache on TCP/IP port 9012... Using ldapsearch to check that proxy slapd is running... Making queries on the proxy cache... Query 1: filter:(sn=Jon) attrs:all (expect nothing) Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid Query 3: filter:(sn=Smith*) attrs:cn sn uid Query 4: filter:(sn=Doe*) attrs:cn sn title uid Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn uid Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid Query 7: filter:(mail=*) attrs:cn sn title uid Query 8: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 9: filter:(uid=b*) attrs:mail ldapsearch failed (4) Query 1 not cacheable Query 2 cacheable Query 3 cacheable Query 4 cacheable Query 5 cacheable Query 6 cacheable Query 7 not cacheable Query 8 cacheable Query 9 cacheable Successfully verified cacheability Query 10: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid Query 11: filter:(sn=Smith) attrs:cn sn title uid Query 12: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn uid Query 13: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid Query 14: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 15: filter:(uid=b*) attrs:mail ldapsearch failed (4) Query 10 not answerable Query 11 answerable Query 12 answerable Query 13 not answerable Query 14 not answerable Query 15 answerable Error in verifying answerability

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠OpenLDAP.org 17 Oct '07

17 Oct '07

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> ghenry(a)suretecsystems.com wrote: >> >>> All tests pass in HEAD. test048 still failing in RE24. >> The difference consists in James A Jones 2 not being deleted from the >> slave when deleted from the master. I'm investigating... > > re24 was missing the syncrepl portion of the fix for ITS#5168. Fixed. OK, I'll update that machine and retest to double check ;-) Thanks. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > > -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ando＠sys-net.it 17 Oct '07

17 Oct '07

ando(a)sys-net.it wrote: > ghenry(a)suretecsystems.com wrote: > >> All tests pass in HEAD. test048 still failing in RE24. > > The difference consists in James A Jones 2 not being deleted from the > slave when deleted from the master. I'm investigating... re24 was missing the syncrepl portion of the fix for ITS#5168. Fixed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ando＠sys-net.it 17 Oct '07

17 Oct '07

ghenry(a)suretecsystems.com wrote: > All tests pass in HEAD. test048 still failing in RE24. The difference consists in James A Jones 2 not being deleted from the slave when deleted from the master. I'm investigating... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5186) problem with olcsuffix
by gfa＠zumbi.com.ar 14 Oct '07

14 Oct '07

Full_Name: gustavo panizzo Version: 2.3.38 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.82.42.251) sldapd shouldn't accept the duplication of attr olcSuffix when the backend is hdb/bdb later, slapd don't accept childs from the new suffix, and if is stoped slapd don't start again until remove the ofender entry

1 0

Re: (ITS#5184) pkg-config file for libraries
by ghenry＠OpenLDAP.org 13 Oct '07

13 Oct '07

ando(a)sys-net.it wrote: > mccann(a)jhu.edu wrote: >> Full_Name: William Jon McCann Version: 2.3.34 OS: URL: >> ftp://ftp.openldap.org/incoming/ Submission from: (NULL) >> (128.220.146.19) >> >> >> It would be really helpful for openldap to ship a pkg-config (.pc) >> file for libldap. >> >> http://en.wikipedia.org/wiki/Pkg-config > > Quoting from the above link: > >> When a library is installed (say from an RPM, deb or other binary >> packaging system) > > OpenLDAP only distributes source code > >> If one installs from source, often there will be no .pc file >> generated, and one may need to be manually written to reflect the >> install. > > No comment. > > Having noted this, I think generating a .pc file from "make install" > would probably do no harm and probably bring some benefit to people that > want to use pkg-config to configure software dependent on OpenLDAP. > > But I guess most packagers and distributors would still either provide > their alternate means to configure packages, or provide specific .pc > files, thus possibly breaking configurations based on OpenLDAP's .pc file. > And most are still far behind and "do their own thing" anyway. Ours would get ignored either way. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5185) assertion failure in back-meta when the remote directory does not answer a bind request within the time allotted
by ando＠sys-net.it 13 Oct '07

13 Oct '07

Matthew Hardin wrote: > Thanks for the prompt response, Ando. I've put the fix into production and > I'll let you know how it goes. This problem only surfaces every few days > when AD doesn't respond to a bind request, so will be at least Thursday or > Friday before I can confirm it did the trick. FWIW, the issue you indicated could be easily reproduced by either adding a slapo-retcode in front of the remote server with a sleep longer than the proxy's timeout, or simply by running the remote server under gdb, stopping at do_bind long enough to see the timeout expire. I did the latter, and I could 100% reproduce that issue before patching, while it disappeared after. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

RE: (ITS#5185) assertion failure in back-meta when the remote directory does not answer a bind request within the time allotted
by mhardin＠symas.com 13 Oct '07

13 Oct '07

> -----Original Message----- > From: Pierangelo Masarati [mailto:ando@sys-net.it] > Sent: Saturday, October 13, 2007 2:19 AM > To: mhardin(a)symas.com > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#5185) assertion failure in back-meta when the remote > directory does not answer a bind request within the time allotted > > ando(a)sys-net.it wrote: > > > Does this happen when binding as the rootdn of the back-meta instance, > > or as a regular user? If it occurs when binding as the rootdn, then I > > think I know where the problem is. In that case, apart from me fixing > > the problem (working at it...), you should also use > > "pseudoroot-bind-defer yes". > > I partially take it back: the above recommendation is correct; however, > the problem I suspected for the rootdn case is also present for regular > binds. I've committed to HEAD a fix for this problem. Please test. Thanks for the prompt response, Ando. I've put the fix into production and I'll let you know how it goes. This problem only surfaces every few days when AD doesn't respond to a bind request, so will be at least Thursday or Friday before I can confirm it did the trick. I've also taken your advice and set pseudoroot-bind-defer yes. Thanks, -Matt Matthew Hardin Symas Corporation- The LDAP Guys http://www.symas.com > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > ---------------------------------------

1 0

Re: (ITS#5183) Index problem with ;x- attributes.
by ando＠sys-net.it 13 Oct '07

13 Oct '07

Magnus.Jonsson(a)umdac.umu.se wrote: > Full_Name: Magnus Jonsson > Version: 2.3.38 > OS: Debian GNU/linux ”Etch” > URL: http://foo.fot.nu/reproduce.txt > Submission from: (NULL) (130.239.200.171) > > > We are using ;x- attributes in a specific appliation to group some attributes. > > When removing a ;x- attrbute all the indexs for that attribute disapears. > > example: > > cn: index > cn;x-f-1: index > cn;x-f-2: index > > If a remove the cn;x-f-1 attribute I can't search for (cn=index) anymore. I confirm your report, except that if the type and all subtypes have the same value, and if I remove the "cn;x-f-1" value, I can no longer search for "cn" equality, but I can still search for "cn;x-f-2". p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5184) pkg-config file for libraries
by ando＠sys-net.it 13 Oct '07

13 Oct '07

mccann(a)jhu.edu wrote: > Full_Name: William Jon McCann Version: 2.3.34 OS: URL: > ftp://ftp.openldap.org/incoming/ Submission from: (NULL) > (128.220.146.19) > > > It would be really helpful for openldap to ship a pkg-config (.pc) > file for libldap. > > http://en.wikipedia.org/wiki/Pkg-config Quoting from the above link: > When a library is installed (say from an RPM, deb or other binary > packaging system) OpenLDAP only distributes source code > If one installs from source, often there will be no .pc file > generated, and one may need to be manually written to reflect the > install. No comment. Having noted this, I think generating a .pc file from "make install" would probably do no harm and probably bring some benefit to people that want to use pkg-config to configure software dependent on OpenLDAP. But I guess most packagers and distributors would still either provide their alternate means to configure packages, or provide specific .pc files, thus possibly breaking configurations based on OpenLDAP's .pc file. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5185) assertion failure in back-meta when the remote directory does not answer a bind request within the time allotted
by ando＠sys-net.it 13 Oct '07

13 Oct '07

ando(a)sys-net.it wrote: > Does this happen when binding as the rootdn of the back-meta instance, > or as a regular user? If it occurs when binding as the rootdn, then I > think I know where the problem is. In that case, apart from me fixing > the problem (working at it...), you should also use > "pseudoroot-bind-defer yes". I partially take it back: the above recommendation is correct; however, the problem I suspected for the rootdn case is also present for regular binds. I've committed to HEAD a fix for this problem. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5185) assertion failure in back-meta when the remote directory does not answer a bind request within the time allotted
by ando＠sys-net.it 13 Oct '07

13 Oct '07

mhardin(a)symas.com wrote: > Remote directory servers that do not answer a bind request within the timeout > period will cause an assertion failure in back-meta. > > Analysis: > The meta_back_bind() function calls either meta_back_proxy_authz_bind() if the > bind is taking place with back_meta's rootdn or meta_back_single_bind() if it's > not. > > Once they make the appropriate bind function call, each of these functions calls > meta_back_bind_op_result() to process the result of the bind. Neither > meta_back_proxy_authz_bind() or meta_back_single_bind() set the > LDAP_BACK_CONN_BINDING state. Because it's meta_back_getconn() that's supposed to set that flag when appropriate. > When meta_back_bind_op_result() calls ldap_result(), one of the possible return > codes is 0, and meta_back_bind_op_result() will repeat the ldap_result() call, > provided the timeout hasn't been exceeded or back-meta has been told not to > retry. > > If the wait time has been exceeded the code falls through to an > assert(LDAP_BACK_CONN_BINDING(msc)) statement. This assert is only valid when > meta_back_do_bind() has made the function call, and it will fail if either > meta_back_proxy_authz_bind() or meta_back_single_bind() made the function call. The assert **should** always be valid. Its execution indicates that there's an error somewhere else. Does this happen when binding as the rootdn of the back-meta instance, or as a regular user? If it occurs when binding as the rootdn, then I think I know where the problem is. In that case, apart from me fixing the problem (working at it...), you should also use "pseudoroot-bind-defer yes". p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5185) assertion failure in back-meta when the remote directory does not answer a bind request within the time allotted
by mhardin＠symas.com 13 Oct '07

13 Oct '07

Full_Name: Matthew Hardin Version: 2.3.38 OS: RHEL4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.43) Remote directory servers that do not answer a bind request within the timeout period will cause an assertion failure in back-meta. Analysis: The meta_back_bind() function calls either meta_back_proxy_authz_bind() if the bind is taking place with back_meta's rootdn or meta_back_single_bind() if it's not. Once they make the appropriate bind function call, each of these functions calls meta_back_bind_op_result() to process the result of the bind. Neither meta_back_proxy_authz_bind() or meta_back_single_bind() set the LDAP_BACK_CONN_BINDING state. When meta_back_bind_op_result() calls ldap_result(), one of the possible return codes is 0, and meta_back_bind_op_result() will repeat the ldap_result() call, provided the timeout hasn't been exceeded or back-meta has been told not to retry. If the wait time has been exceeded the code falls through to an assert(LDAP_BACK_CONN_BINDING(msc)) statement. This assert is only valid when meta_back_do_bind() has made the function call, and it will fail if either meta_back_proxy_authz_bind() or meta_back_single_bind() made the function call. Possible Fixes: The correct fix would seem to be to remove the assert(), since in two out of three cases the meta_back_bind_op_result() function is being called with the LDAP_BACK_CONN_BINDING state not set. It is also possible to set and clear the LDAP_BACK_CONN_BINDING state as appropriate from the other two funcions that call it, but this seems incorrect, as the LDAP_BACK_CONN_BINDING state is only manipulated in the meta_back_single_dobind() direct bind function.

1 0

(ITS#5184) pkg-config file for libraries
by mccann＠jhu.edu 12 Oct '07

12 Oct '07

Full_Name: William Jon McCann Version: 2.3.34 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.220.146.19) It would be really helpful for openldap to ship a pkg-config (.pc) file for libldap. http://en.wikipedia.org/wiki/Pkg-config

1 0

Re: (ITS#5183) Index problem with ;x- attributes.
by quanah＠zimbra.com 12 Oct '07

12 Oct '07

--On Thursday, October 11, 2007 12:37 PM +0000 Magnus.Jonsson(a)umdac.umu.se wrote: > Full_Name: Magnus Jonsson > Version: 2.3.38 > OS: Debian GNU/linux ?Etch? > URL: http://foo.fot.nu/reproduce.txt > Submission from: (NULL) (130.239.200.171) > > > We are using ;x- attributes in a specific appliation to group some > attributes. > > When removing a ;x- attrbute all the indexs for that attribute disapears. > > example: > > cn: index > cn;x-f-1: index > cn;x-f-2: index > > If a remove the cn;x-f-1 attribute I can't search for (cn=index) anymore. > > I have tested with bdb and ldbm. > > Berkeley v4.3 is used. Did you fail to note how OpenLDAP's configure specifically is designed to abort when building against BDB 4.3? BDB 4.3 is known to be a bad release. I suggest using 4.2.52+patchs, 4.4+patches, or 4.5+patches. Not that this necessarily will resolve the issue you are reporting. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5183) Index problem with ;x- attributes.
by Magnus.Jonsson＠umdac.umu.se 11 Oct '07

11 Oct '07

Full_Name: Magnus Jonsson Version: 2.3.38 OS: Debian GNU/linux Etch URL: http://foo.fot.nu/reproduce.txt Submission from: (NULL) (130.239.200.171) We are using ;x- attributes in a specific appliation to group some attributes. When removing a ;x- attrbute all the indexs for that attribute disapears. example: cn: index cn;x-f-1: index cn;x-f-2: index If a remove the cn;x-f-1 attribute I can't search for (cn=index) anymore. I have tested with bdb and ldbm. Berkeley v4.3 is used. A small example with all you need to reproduce the symtoms is available in the provided link.

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠suretecsystems.com 10 Oct '07

10 Oct '07

<quote who="ghenry(a)suretecsystems.com"> > <quote who="ghenry(a)OpenLDAP.org"> >> Full_Name: Gavin Henry >> Version: OPENLDAP_REL_ENG_2_4 >> OS: Fedora 7 >> URL: http://www.suretec.org/our_docs/test048.tar.gz >> Submission from: (NULL) (80.229.93.1) >> Submitted by: ghenry >> >> >> I'm getting a fail at: >> >> "master and R1 slave databases differ" >> >> I'd like to learn how to debug this. Any tips? >> >> This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. >> >> Thanks. > > I'll double check this in HEAD now too. Should have done that first. > All tests pass in HEAD. test048 still failing in RE24. Gavin.

1 0

Re: (ITS#5172) slash in dn
by hyc＠symas.com 10 Oct '07

10 Oct '07

reinhold.may(a)gmx.de wrote: > Raphael, > >> My new crystal ball tells me that you are not saying the >> essential part of the problem: you are using back-ldif, isn't >> it ? > > It is! Did I miss a hint which would have told me not to use > back-ldif or use it differently? back-ldif is really not meant for general use. It does no caching or indexing, so it will perform very poorly in general. It was only written to provide a base for cn=config. -- -- Howard Chu Chief Architect, 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#5172) slash in dn
by reinhold.may＠gmx.de 10 Oct '07

10 Oct '07

Pierangelo, > This output is not useful. I'm sorry. > First of all, can you tell what ldapadd you're using? Please > make sure you run the version of ldapadd that comes with > OpenLDAP sources you built. I can confirm that ldapadd was built alongside slapd whose version I stated in my original post (2.3.35). As I'm not at home at the moment, the only thing I can do is extract the syslog of that import in question which admittedly doesn't say much, however, here it goes: Oct 10 02:16:19 mm slapd[9746]: slapd starting Oct 10 02:16:31 mm slapd[9746]: conn=0 fd=8 ACCEPT from IP=192.168.0.3:40394 (IP =0.0.0.0:389) Oct 10 02:16:31 mm slapd[9746]: conn=0 op=0 BIND dn="cn=root,dc=somedomain,dc=or g" method=128 Oct 10 02:16:31 mm slapd[9746]: failed to open file "/var/lib/openldap-data/dc=s omedomain,dc=org/cn=root.ldif": No such file or directory Oct 10 02:16:31 mm slapd[9746]: conn=0 op=0 BIND dn="cn=root,dc=somedomain,dc=or g" mech=SIMPLE ssf=0 Oct 10 02:16:31 mm slapd[9746]: conn=0 op=0 RESULT tag=97 err=0 text= Oct 10 02:16:31 mm slapd[9746]: conn=0 op=1 ADD dn="dc=somedomain,dc=org" Oct 10 02:16:31 mm slapd[9746]: conn=0 op=1 RESULT tag=105 err=0 text= Oct 10 02:16:31 mm slapd[9746]: conn=0 op=2 ADD dn="ou=My address book,dc=somedo main,dc=org" Oct 10 02:16:31 mm slapd[9746]: conn=0 op=2 RESULT tag=105 err=0 text= Oct 10 02:16:31 mm slapd[9746]: conn=0 op=3 ADD dn="cn=With/Slash,ou=My address book,dc=somedomain,dc=org" Oct 10 02:16:31 mm slapd[9746]: conn=0 op=3 RESULT tag=105 err=32 text=Parent do es not exist Oct 10 02:16:31 mm slapd[9746]: conn=0 op=4 UNBIND Oct 10 02:16:31 mm slapd[9746]: conn=0 fd=8 closed Raphael, > My new crystal ball tells me that you are not saying the > essential part of the problem: you are using back-ldif, isn't > it ? It is! Did I miss a hint which would have told me not to use back-ldif or use it differently? Reinhold

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs