- openldap-bugs - openldap.org

Re: (ITS#4837)
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

--On Thursday, June 14, 2007 9:23 PM +0000 quanah(a)zimbra.com wrote: > Kurt, > > Zimbra has run into this issue in helping a customer who was running > SunDS migrate to OpenLDAP. It does not work at all, unfortunately. > Changing code to use an 8-bit salt does work. Never mind, the 8-bit salt works just fine. I had bad data in my cut & paste buffer last night when I tried this. Trying with the correct data works just fine. yeah! I'll mark this ITS as invalid, and note in the comments that 8-bit salted SSHA passwords work just fine. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4936) default modulepath
by ando＠sys-net.it 14 Jun '07

14 Jun '07

ando(a)sys-net.it wrote: > Yes, I figured that out. I'll fix this later. Fixed; 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#4837)
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

Kurt, Zimbra has run into this issue in helping a customer who was running SunDS migrate to OpenLDAP. It does not work at all, unfortunately. Changing code to use an 8-bit salt does work. So, I'd be happy to fix this, but a general design question -- (a) Should this be implemented as a "ssha-salt" option in slapd.conf or (b) Should OpenLDAP try decrypting the password first as a 4-bit salt, and then try an 8-bit salt, then fail? (a) would be fairly portable across many salt settings, but AFAIK we've only hit 4 & 8 (b) would allow mixed salt values to be in userPassword, and I'd think that over time as people changed their passwords, it would allow the 8-bit salts to go away. Thoughts welcome. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5014) syncrepl failure syslog
by ando＠sys-net.it 14 Jun '07

14 Jun '07

donn(a)u.washington.edu wrote: > Hard to tell why syncrepl isn't working, if it discards error messages. This patch was not submitted according to the guidelines of usual contributions, which makes it hard to apply. In any case, it appears to be incorrect, since the response code should not be extracted that early, namely before getting the message type. AFAIK, only an LDAP_RES_SEARCH_RESULT could contain an error, and that value is already parsed out and stored in "err". What's missing is a log in case "err" indicates an error. So what's really relevant in your patch, and missing from the code, is a test for "err" after the "done" label. I have applied something along those lines to the code. 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

(ITS#5019) slapd: ldbm/gdbm, cache.c core dump
by asedlack＠mailfoundry.com 14 Jun '07

14 Jun '07

Full_Name: Aron Sedlack Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.18.18.14) Platform: Linux, OpenLDAP-2.3.35 Compiled with: ./configure --enable-dynamic --enable-wrappers --enable-bdb=no --enable-hdb=no --enable-ldbm --enable-ldbm-api=gdbm --with-threads --with-tls --with-threads=no gcc version 3.3.4, gdbm 1.8.3, OpenSSL 0.9.8e slapd core dumps with a corrupted stack, SIGABRT. slapd: cache.c:111: cache_return_entry_rw: Assertion `e->e_private != (( void *)0)' failed.. Happens every time ldif is loaded... $ ldapmodify -a -f ./mf.ldif -D "cn=Root,dc=mf" -w secret adding new entry "dc=mf" adding new entry "dc=iana,dc=mf" ldap_result: Can't contact LDAP server (-1)

1 0

Re: (ITS#5018) memory leak
by h.b.furuseth＠usit.uio.no 14 Jun '07

14 Jun '07

niloulili(a)hotmail.com writes: > if ( (ld = ldap_init("192.xxx.xxx.xxx",389 ))== NULL ) > return 1; > if ( ldap_simple_bind_s( ld,"CN=nina > wang,CN=Users,DC=ldap,DC=qtier,DC=com","0000" ) != LDAP_SUCCESS ) > { > ldap_perror( ld, "ldap_simple_bind_s" ); insert "ldap_unbind( ld );" here. Does that fix the problem? That's how to free the LDAP* structure. In LDAP, "unbind" is the "disconnect" command, it's not the opposite of "bind". The misleading name came about because originally one had to bind after connect. > return 1; > } > ldap_msgfree( res ); res == NULL here in this particular code, so you can drop this and the declaration of 'res'. > /* close and free connection resources */ > ldap_unbind( ld ); > return 0; > } -- Regards, Hallvard

1 0

Re: (ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ando＠sys-net.it 14 Jun '07

14 Jun '07

ali.pouya(a)free.fr wrote: > What bothers me is that the regular client requests to the consumer receive > (scarcely and randomly) "Time Limit Exceeded" at checkpoint time. Would it be possible to get, from the consumer's log, what was the actually requested time limit in those cases? This means: track down what connection/operation was concluded by a "Time Limit Exceeded" response; then find out the corresponding request, and see what was the requested time limit. You need "args" debug level for this purpose, and you need to look at the second of the three numbers that end the SRCH line in the logs; for example: SRCH "dc=example,dc=com" 2 0 20 5 0 filter: (uid=foobar) attrs: 1.1 means: search "dc=example,dc=com" with scope subtree (2) and never deref aliases (0), using a size limit of 20, a timelimit of 5 and no attrsonly (0). 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#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 14 Jun '07

14 Jun '07

Howard Chu writes: > Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >>> h.b.furuseth(a)usit.uio.no wrote: >>>> * When a thread is finishing, make it go active for context_reset(). >>>> Should make slapi module destructors safer, and I don't see that it >>>> can hurt. >>> I don't understand this. >> >> Let me dig a bit back in the ITS... >> "context_reset() can call connection_fake_destroy(), which via >> slapi_int_free_object_extensions() calls slapi module destructors, >> which can do who-knows-what." > > context_reset() can only be called from the main thread. It can (must) > never be called by anything running from the pool. It's called from pool_wrapper(). pool_wrapper() could go active so there can be no pause while that context_reset() call is running. >>>> * Scheduling: If several threads call pool_pause(), (...) (need to check out how it should work...) >>>> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can >>>> represent the same thread ID: TID_HASH() would give different hashes >>>> for the same thread, and pool_context() stops searching when it hits >>>> a slot with ctx == NULL. (My previous bug report was a bit wrong.) >>> >>> How can a single thread ID be represented by multiple bit patterns? >> >> A struct/union with padding bytes seems the least unlikely possibility. Note that I did say "least unlikely" rather than "most likely": It's not that I expect to encounter it, more that I'd prefer not to be surprised in the form of a slapd malfuntion. So in that respect, my preference (not for RE23) is to cast to an integer for the hash, and also to add pthread_<set/get>specific() so thread_keys[] and its hash will only be a fallback solution. > Any implementation that leaves uninitialized padding bytes would be a > bug. Tools like valgrind would barf all over them. No. Valid compiler, valid code. Therefore valgrind is silent about copying uninitialized values, it only complains when you use them for something - like write() or arithmetic. So a valgrind complaint about an uninitialized _value_ isn't necessary at the point the uninitialized _variable_ is read. E.g. this complains in printf(), not in foo(): int foo() { struct { char c; /*maybe padding here*/ int j; } s; s.c = 1; s.j = 2; return ((unsigned char *)&s)[1]; /* maybe padding byte */ } int main() { printf("%d\n", foo()); } >> A pointer in hardware where several address representations map to the >> same physical address, and the compiler handles that by normalizing >> pointers when they are compared/subtracted. Like DOS "huge" pointers >> would have been if the compiler normalized them when comparing them >> instead of when incrementing/decrementing them. 20-bit address bus, >> 32-bit pointers, physical address = 16 * <segment half of pointer> + >> <offset half of pointer>. > > Nobody voluntarily uses such memory models today. The very mention of "DOS" > invalidates this discussion since there is no threading environment there. Right, at this point I answered how it _can_ happen, not why I expect to encounter it. I could see the demands of hardware design cause strange memory models to proliferate again, but I'm not holding my breath. I'd be a bit less surprised to encounter integers with padding bits again, but not for a simple ID type, and hashing an integer instead of its bytes would fix it anyway. >>> The best fix may be to just use the address of the thread's stack as the >>> thread ID. That's actually perfect for our purpose. >> >> How does a function called from somewhere inside the thread know that >> address? That's almost what the user context is, and thus what >> thread_keys[] maps the thread ID to. > > It requires some degree of machine-dependence, which is why I never > bothered to code it. The principle is simple though - all of our thread > stacks are some multiple of 1MB in size. Take the address of any local > variable, mask off the low 20 bits, and you have a unique thread ID (+/- > some additional masking/shifting based on the actual thread stack size). I'm not sure how to determine _which_ multiple of 1MB - start two threads and compare their stack addresses, maybe? In any case, I agree it sounds rather more machine-dependent than the current code. -- Regards, Hallvard

1 0

Re: (ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ali.pouya＠free.fr 14 Jun '07

14 Jun '07

Selon Pierangelo Masarati <ando(a)sys-net.it>: > ali.pouya(a)free.fr wrote: > > > Hi, > > I use openldap 2.3.35 with the following bdb configuration. > > > > database bdb > > .... > > checkpoint 1000000 10 > > > > In my DB_CONFIG file I have : > > > > set_flags DB_LOG_AUTOREMOVE > > > > There ise a great LDAP read/write activity on my server. > > > > I notice that every 10 minutes some of my search requests receive randomly > an > > error 3 (Time Limit Exceeded) within one or two seconds while I'm using the > > slapd default timelimit (3600 seconds). > > > > I think a relation exists between this error and the checkpoint activity > (slapd > > is inclined to generate unjustified error 3 at checkpoint time) . > > Is it possible to study this problem ? > > > > I can send more information if required. > > > Do you mean that regular requests (to the producer or to the consumer?) > often receive "Time Limit Exceeded", or that the replication requests > issued by the consumer receive "Time Limit Exceeded" from the producer? > > 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 > --------------------------------------- > > > Hi Pierangelo; What bothers me is that the regular client requests to the consumer receive (scarcely and randomly) "Time Limit Exceeded" at checkpoint time. The replication requests to the master also receive this error after 3600 seconds when I'm synchronizing a new empty replica (as though I set timelimit unlimited for the sync client), but this is not a problem for me because the syncrepl client makes a new connection to the master and everything works well. Best regards Ali

1 0

Re: (ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ando＠sys-net.it 14 Jun '07

14 Jun '07

ali.pouya(a)free.fr wrote: > Hi, > I use openldap 2.3.35 with the following bdb configuration. > > database bdb > .... > checkpoint 1000000 10 > > In my DB_CONFIG file I have : > > set_flags DB_LOG_AUTOREMOVE > > There ise a great LDAP read/write activity on my server. > > I notice that every 10 minutes some of my search requests receive randomly an > error 3 (Time Limit Exceeded) within one or two seconds while I'm using the > slapd default timelimit (3600 seconds). > > I think a relation exists between this error and the checkpoint activity (slapd > is inclined to generate unjustified error 3 at checkpoint time) . > Is it possible to study this problem ? > > I can send more information if required. Do you mean that regular requests (to the producer or to the consumer?) often receive "Time Limit Exceeded", or that the replication requests issued by the consumer receive "Time Limit Exceeded" from the producer? 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#5018) memory leak
by niloulili＠hotmail.com 14 Jun '07

14 Jun '07

Full_Name: nina wang Version: 2.2.19 OS: Vxworks mips URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (222.68.187.35) I remove these code from linux to gcc. a computer equipmented os win 2000 server acts as server setting up AD . i start a thread to init a ldap connection and bind them with a valid account and password,configured in server. then unbind them every several seconds. through special tools ,i can see that free memory always being decreasing. if i only do action ldap_init,without bind to server,no the said scene . THE CODE IS : { LDAP *ld; LDAPMessage *res=NULL, *e; int i; char *a, *dn; BerElement *ptr; char **vals; /* open a connection */ if ( (ld = ldap_init("192.xxx.xxx.xxx",389 ))== NULL ) return 1; if ( ldap_simple_bind_s( ld,"CN=nina wang,CN=Users,DC=ldap,DC=qtier,DC=com","0000" ) != LDAP_SUCCESS ) { ldap_perror( ld, "ldap_simple_bind_s" ); return 1; } ldap_msgfree( res ); /* close and free connection resources */ ldap_unbind( ld ); return 0; } Hope to receive your response soon. Thank you .

1 0

Re: (ITS#5017) slapd generates unjustified error 3 (Time Limit Exceeded) at check
by ali.pouya＠free.fr 13 Jun '07

13 Jun '07

This ITS is a duplicate of ITS 5016. It is to be destroyed. Sorry for mis handling. Ali

1 0

(ITS#5017) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ali.pouya＠free.fr 13 Jun '07

13 Jun '07

Full_Name: Ali Pouya Version: 2.3.35 OS: Linux RedHat AS4 (kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.3.30) Hi, I use openldap 2.3.35 with the following bdb configuration. database bdb .... checkpoint 1000000 10 In my DB_CONFIG file I have : set_flags DB_LOG_AUTOREMOVE There ise a great LDAP read/write activity on my server. I notice that every 10 minutes some of my search requests receive randomly an error 3 (Time Limit Exceeded) within one or two seconds while I'm using the slapd default timelimit (3600 seconds). I think a relation exists between this error and the checkpoint activity (slapd is inclined to generate unjustified error 3 at checkpoint time) . Is it possible to study this problem ? I can send more information if required. Thanks for your help Best regards Ali Pouya

1 0

(ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ali.pouya＠free.fr 13 Jun '07

13 Jun '07

Full_Name: Ali Pouya Version: 2.3.35 OS: Linux RedHat AS4 (kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.3.30) Hi, I use openldap 2.3.35 with the following bdb configuration. database bdb .... checkpoint 1000000 10 In my DB_CONFIG file I have : set_flags DB_LOG_AUTOREMOVE There ise a great LDAP read/write activity on my server. I notice that every 10 minutes some of my search requests receive randomly an error 3 (Time Limit Exceeded) within one or two seconds while I'm using the slapd default timelimit (3600 seconds). I think a relation exists between this error and the checkpoint activity (slapd is inclined to generate unjustified error 3 at checkpoint time) . Is it possible to study this problem ? I can send more information if required. Thanks for your help Best regards Ali Pouya

1 0

(ITS#5015) pcache caches results of aborted searches
by rhafer＠suse.de 13 Jun '07

13 Jun '07

Full_Name: Ralf Haferkamp Version: RE23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.165.45) Pcache will store the results of a search that got aborted (e.g. by hitting Ctrl+c during ldapsearch, oder using ldap_abandon) in it database. The next time the some query is issued it will answer the query from the cache, resulting in a incomplete result set. HEAD doesn't show this problem. Applying the changes from result.c r.1.289 to RE23 seems to fix this problem.

1 0

RE: Native Win32 build with WGCC/Interix (ITS#4825)
by Markus.Duft＠salomon.at 13 Jun '07

13 Jun '07

Hi! First thanks for reviewing the patch! Howard Chu <mailto:openldap-its@OpenLDAP.org> wrote: > I have not tested this patch, but it does not appear to be correct. > > In ldap_cdefs.h, you should not be testing the PIC macro since that > controls whether the current source file is being built as > position-independent. The macro you actually need to test is > LDAP_LIBS_DYNAMIC, just as the regular WIN32 case tests. Note that > the current macros work fine for both MSVC and MinGW/gcc; I don't see > why you've chosen to change the LBER_F definitions for your wgcc. Uh.. I'd have to look into that again ;o) Still this works fine since some time now, and the libraries are under heavy usage at our company... > > Likewise, your hack to portable.hin should not be necessary, as all > of the places that use sockets or timevals already include the > appropriate header files. Again, i'd have to look at this again... > > The patch to ure.h seems unnecessary, since the file exists at both > locations (the original, and via symlink). Smylinks are not supported when windows building on interix ;o// This caused some troubles as far as i remember. > > Finally, unless you're using a flag to force all symbols to be > exported, I think omitting slapd.exp in the slapd/Makefile.in is a > mistake. WGCC automatically exports/imports correctly. > > Really, the comments in ldap_cdefs.h are pretty explicit about why > each piece of the current Windows support is as it is. Your patch > seems to preclude some of the combinations of DLL/static linking that > we went to great pains to support. WGCC claims to support (with this patch) *all* possible static/shared combinations (without pain ;o)). WGCC generates code to support static libraries, even if it was compiled like a shared library (with __declspec(dllimport)'s, etc.), so most of the painfull stuff is not needed. On the other hand to support *all* configurations, one needs to allway dllimport, so both shared and static work ... > > For the include/Makefile.in it would probably have made more sense to > define a WINPATH macro to either "cygpath -w" or "unixpath2win" and > use that, rather than repeating all of the SED invocations. Yes, it would have been better, but it's a long time since i wrote the patch, and now i'd propably do more things differently ;o) > > These days I wonder whether it wouldn't be smarter to just remove all > of the special casing for braindead backslash directory separators. > Since Windows now supports forward slashes everywhere, it would make > life easier to just use forward slashes consistently throughout. Would be cool, but still path handling functions from windows return paths with backslashes, so those would need to be handled too.. Cheers, Markus -- 20. Juni 2007 Salomon Automation am 2. Schweizerischen Supply Chain Management Forum der GS1 Schweiz in Baden. Tagungsort: Trafohalle Baden, Schweiz 20. Juni 2007 MoveRetail-Handelstag, Hamburg Die MoveRetail Partner, Salomon Automation, maxess systemhaus, Superdata, Remira, POS Systemhaus und Mosaic veranstalten den 1. MoveRetail-Handelstag. Tagungsort: Steigenberger Hotel, Hamburg 28. Juni 2007 6. BVL Logistiktag Steiermark in der WAMAS City, Friesach bei Graz "Trends in der Logistik ": hoch automatisierte Systeme, mobile Waren- und Leergutverfolgung im Lebensmittelhandel und Generalunternehmerschaft versus Einzelprojekte. Termin: 28. Juni 2007, ab 15.00 Uhr Ort: Salomon Automation, Friesachstra?e 15, 8114 Friesach bei Graz, Osterreich Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz Sitz der Gesellschaft: Friesach bei Graz UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 12 Jun '07

12 Jun '07

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> * When a thread is finishing, make it go active for context_reset(). >>> Should make slapi module destructors safer, and I don't see that it >>> can hurt. >> I don't understand this. > > Let me dig a bit back in the ITS... > "context_reset() can call connection_fake_destroy(), which via > slapi_int_free_object_extensions() calls slapi module destructors, > which can do who-knows-what." context_reset() can only be called from the main thread. It can (must) never be called by anything running from the pool. >>> * Scheduling: If several threads call pool_pause(), then once there is a >>> pause tpool does not schedule them all. They could get handled then, >>> or another thread could undo the pause so tpool would wait to pause >>> again. Is that deliberate? >> I don't understand the question. The point of the pause is to prevent >> any other thread (in the pool) from running. Why should tpool schedule >> any other threads at this point? > > Two threads call pool_pause(). Eventually the pool gets paused, and one > pool_pause() call returns. When that thread calls pool_resume(), the > other thread waiting in pool_pause() may or may not get scheduled. OK, that sounds like a bug. >>> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can >>> represent the same thread ID: TID_HASH() would give different hashes >>> for the same thread, and pool_context() stops searching when it hits >>> a slot with ctx == NULL. (My previous bug report was a bit wrong.) >> How can a single thread ID be represented by multiple bit patterns? > > A struct/union with padding bytes seems the least unlikely possibility. Any implementation that leaves uninitialized padding bytes would be a bug. Tools like valgrind would barf all over them. > A pointer in hardware where several address representations map to the > same physical address, and the compiler handles that by normalizing > pointers when they are compared/subtracted. Like DOS "huge" pointers > would have been if the compiler normalized them when comparing them > instead of when incrementing/decrementing them. 20-bit address bus, > 32-bit pointers, physical address = 16 * <segment half of pointer> + > <offset half of pointer>. Nobody voluntarily uses such memory models today. The very mention of "DOS" invalidates this discussion since there is no threading environment there. >>> The best fix would be to use use real thread-specific data instead. >>> Just one key with the ctx for now, that minimizes the changes. OTOH >>> it also means we'll do thread-specific key lookup twice - first in >>> pthread to get the ctx, and then in ltu_key[] to find our data. >>> Anyway, I said I'd do that later but might as well get on with it, >>> at least for pthreads. Except I don't know if that's OS-dependent >>> enough that it should wait for RE24? >> The best fix may be to just use the address of the thread's stack as the >> thread ID. That's actually perfect for our purpose. > > How does a function called from somewhere inside the thread know that > address? That's almost what the user context is, and thus what > thread_keys[] maps the thread ID to. It requires some degree of machine-dependence, which is why I never bothered to code it. The principle is simple though - all of our thread stacks are some multiple of 1MB in size. Take the address of any local variable, mask off the low 20 bits, and you have a unique thread ID (+/- some additional masking/shifting based on the actual thread stack size). -- -- 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#4983) libldap_r/tls.c compile failure
by h.b.furuseth＠usit.uio.no 12 Jun '07

12 Jun '07

I wrote: > For whatever isn't handled above, my suggestion for now is to keep the > failure if ldap_pvt_thread_t is a struct/union or wider than long, and > see if anyone still complains. Done. Compiles unless pointers are wider than long, but the basic problem remains. -- Regards, Hallvard

1 0

Re: (ITS#5010) broken ber_encode_oid/ber_decode_oid()
by h.b.furuseth＠usit.uio.no 12 Jun '07

12 Jun '07

I wrote: > Finally, libldap/tls.c does not check if ber_decode_oid() fails. Fixed that. Waiting for the other stuff, depends on the code's intent. -- Regards, Hallvard

1 0

(ITS#5014) syncrepl failure syslog
by donn＠u.washington.edu 12 Jun '07

12 Jun '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat RHEL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) Hard to tell why syncrepl isn't working, if it discards error messages. *** servers/slapd/syncrepl.c.dist 2007-02-15 17:53:39.000000000 -0800 --- servers/slapd/syncrepl.c 2007-06-12 13:35:22.000000000 -0700 *************** *** 688,694 **** struct sync_cookie syncCookie_req = { NULL }; struct berval cookie = BER_BVNULL; ! int rc, err; ber_len_t len; struct berval *psub; --- 688,694 ---- struct sync_cookie syncCookie_req = { NULL }; struct berval cookie = BER_BVNULL; ! int rc, err, rrc; ber_len_t len; struct berval *psub; *************** *** 704,709 **** --- 704,710 ---- BerVarray syncUUIDs = NULL; ber_tag_t si_tag; + rrc = LDAP_SUCCESS; if ( slapd_shutdown ) { rc = -2; goto done; *************** *** 727,732 **** --- 728,734 ---- while ( ( rc = ldap_result( si->si_ld, LDAP_RES_ANY, LDAP_MSG_ONE, tout_p, &res ) ) > 0 ) { + ldap_parse_result( si->si_ld, res, &rrc, 0, 0, 0, 0, 0 ); if ( slapd_shutdown ) { rc = -2; goto done; *************** *** 1061,1066 **** --- 1063,1076 ---- } done: + if ( rrc != LDAP_SUCCESS ) { + const char *errstr; + ldap_get_option( si->si_ld, LDAP_OPT_ERROR_NUMBER, &rrc ); + errstr = ldap_err2string( rrc ); + + Debug( LDAP_DEBUG_ANY, + "syncrepl %s result: %s\n", si->si_ridtxt, errstr, 0 ); + } slap_sync_cookie_free( &syncCookie, 0 ); slap_sync_cookie_free( &syncCookie_req, 0 );

1 0

Re: (ITS#4996) Use SRV records to locate local server for command-line clients
by rra＠stanford.edu 11 Jun '07

11 Jun '07

ando <ando(a)sys-net.it> writes: > Committed to HEAD. Command-line clients now use DNS SRV to look up the > host names related to a DN and build a list of URIs for subsequent use. > To trigger, use -H "<proto>:///DN". The <host> portion must be empty, > and a DN must be present. The DN must be in the "dc=<component>" form; > it's turned into a domain and the host list is looked up using DNS SRV. > After that, a list of URIs is built using the returned host/ports, and > using <proto> as the LDAP scheme. Thank you! I've forwarded this information to the original Debian bug reporter who was interested in the feature in the hopes that he'll be able to test and provide feedback on the implementation. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5011) loglevel packet doesn't work
by ando＠sys-net.it 11 Jun '07

11 Jun '07

ando(a)sys-net.it wrote: > ... it's "packets". The man page (or the code) is wrong. ... but the man page is correct in HEAD; so it was fixed, but not backported. 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#5011) loglevel packet doesn't work
by ando＠sys-net.it 11 Jun '07

11 Jun '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.35 > OS: mac os x > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.92.25.194) > > > The slapd.conf man page says: > > loglevel <integer> [...] > 2 (0x2 packet) debug packet handling > > but if you specify packet, slapd refuses to start, stating: > > /opt/zimbra/openldap-2.3.35.7/etc/openldap/slapd.conf: line 53: <loglevel> > unknown level "packet" ... it's "packets". The man page (or the code) is wrong. 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#5011) loglevel packet doesn't work
by quanah＠zimbra.com 11 Jun '07

11 Jun '07

Full_Name: Quanah Gibson-Mount Version: 2.3.35 OS: mac os x URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.92.25.194) The slapd.conf man page says: loglevel <integer> [...] 2 (0x2 packet) debug packet handling but if you specify packet, slapd refuses to start, stating: /opt/zimbra/openldap-2.3.35.7/etc/openldap/slapd.conf: line 53: <loglevel> unknown level "packet" --Quanah

1 0

Re: (ITS#5008) Do you have the win32 version of OpenLDAP
by h.b.furuseth＠usit.uio.no 11 Jun '07

11 Jun '07

caojunliang(a)huawei.com writes: > I want to know whether or not the win32 version of OpenLDAP exsits. Please take this to the mailinglist openldap-software(a)openldap.org. The Issue Tracking System is for bug reports etc, not for help requests. This ITS will be closed. -- Regards, Hallvard

1 0

(ITS#5010) broken ber_encode_oid/ber_decode_oid()
by h.b.furuseth＠usit.uio.no 11 Jun '07

11 Jun '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: http://folk.uio.no/hbf/OpenLDAP/oid-encdec.txt Submission from: (NULL) (129.240.202.105) Submitted by: hallvard The 40*X+Y rule for first 2 components is decoded wrong, it should be X = val < 80 ? val/40 : 2 # X = 0, 1 or 2 Y = val - 40*X # Y is unlimited when X==2, <40 otherwise See X.690 8.19.4: ... (X*40) + Y: NOTE - This packing of the first two object identifier components recognizes that only three values are allocated from the root node, and at most 39 subsequent values from nodes reached by X = 0 and X = 1. 40*X+Y can take more than one octet. The functions allow buffer overruns. ber_decode_oid() if the oid has many small components. ber_encode_oid() for negative input (which becomes a large ulong), or if sizeof(long) == 8. The latter can just as easily be avoided by producing the bytes backwards and then reversing. They do not check much for invalid input or too large values. Possibly they ought to be a bit paranoid about that since they are used for certificates, I don't know. E.g. check that the BER encoding has "fewest possible octets" (X.690 8.19.2), i.e. no initial 0x80 in subidentifiers. ber_encode_oid() seems a bit strange about which errors it accepts and which ones it rejects. E.g. garbage after first 2 components is OK. The "assert(foo != NULL)"s are after "der = foo->bv_val":-) I enclose untested new versions. Will test and commit when I have time if someone says OK, but it depends e.g. on how paranoid the routines should or should not be. Or if they should trust the ber values to end with \0, for that matter. Finally, libldap/tls.c does not check if ber_decode_oid() fails.

1 0

Re: (ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

Thinking about this further, it looks like the manpage is really deferring to 'ldapsearch --help' since that is where the meat of the documentation is. There is some potential confusion here I think. What if the manpage just refers the reader to 'ldapsearch --help' for complete information? -- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author: "Best Practices for Managing Linux and UNIX Servers" "Spam Fighting and Email Security in the 21st Century" Download your free copies: http://www.puryear-it.com/pubs/ebooks/

1 0

Re: (ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

By the way, I did verify that -C does work. It simply isn't in the manpage. Also, a quick grep of the binary: [root@samba openldap]# strings /usr/bin/ldapsearch | grep -- -C -C chase referrals (anonymously) This is a low priority documentation bug only. The binary works fine. -- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author: "Best Practices for Managing Linux and UNIX Servers" "Spam Fighting and Email Security in the 21st Century" Download your free copies: http://www.puryear-it.com/pubs/ebooks/

1 0

(ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

Full_Name: Dustin Puryear Version: 2.213-7 OS: CentOS 4.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.242.176.166) The -C flag is not in the ldapsearch manpage. # rpm -q -a | grep openldap openldap-2.2.13-7.4E openldap-devel-2.2.13-7.4E openldap-servers-2.2.13-7.4E openldap-clients-2.2.13-7.4E # # man ldapsearch | grep -- -C # Alias info is there: # man ldapsearch | grep -- -a [-s base|one|sub] [-a never|always|search|find] [-l timelimit] ldapsearch is a shell-accessible interface to the ldap_search(3) -a never|always|search|find audio:< file:///tmp/ldapsearch-audio-a19924 jpegPhoto:< file:///tmp/ldapsearch-jpegPhoto-a19924 # # man ldapsearch | tail The OpenLDAP Project <http://www.openldap.org/> ACKNOWLEDGEMENTS OpenLDAP is developed and maintained by The OpenLDAP Project (http://www.openldap.org/). OpenLDAP is derived from University of Michigan LDAP 3.3 Release. OpenLDAP 2.2.13 2004/06/10 LDAPSEARCH(1) # # cat /etc/redhat-release CentOS release 4.3 (Final) #

1 0

Re: (ITS#5005) test017 fails
by ando＠sys-net.it 11 Jun '07

11 Jun '07

dieter(a)dkluenter.de wrote: > the patch fails, this is the patch reject file: That's probably because you cut'n'pasted from the email, where the tabs were probably replaced by whitespaces. I'll apply that fix if anyone confirms that cookie is legal at all. Cheers, 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#5005) test017 fails
by dieter＠dkluenter.de 10 Jun '07

10 Jun '07

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > --On June 8, 2007 6:43:50 PM +0000 dieter(a)dkluenter.de wrote: > >> Full_Name: Dieter Kluenter >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.196.121) >> >> >> here the output of test017 logfiles >> >> ---slapd.1.log---------------- >> ber_scanf fmt (}) ber: >> <= get_ctrls: n=1 rc=2 err="Sync control : cookie parsing error" >> send_ldap_result: conn=7 op=1 p=3 >> send_ldap_result: err=2 matched="" text="Sync control : cookie parsing >> error" send_ldap_response: msgid=2 tag=101 err=2 > > Hm, is this possibly related to the fix for ITS#4977? If you revert > that checkin for syncprov.c today, does the test pass? > > > <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov.c.…> Unfortunately no chance, still the same error. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5005) test017 fails
by dieter＠dkluenter.de 10 Jun '07

10 Jun '07

Pierangelo Masarati <ando(a)sys-net.it> writes: > dieter(a)dkluenter.de wrote: > > The problem is in slap_parse_sync_cookie(); when no cookie is passed, a > string containing "rid=001" is parsed. The parser expects it to end > with a comma. If passing "rid=001" is correct, the fix is trivial: > instead of checking for (*next != ','), check for (*next && *next != ','). > > Index: servers/slapd/ldapsync.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/ldapsync.c,v > retrieving revision 1.42 > diff -u -r1.42 ldapsync.c > --- servers/slapd/ldapsync.c 18 May 2007 12:46:52 -0000 1.42 > +++ servers/slapd/ldapsync.c 9 Jun 2007 09:42:24 -0000 > @@ -180,7 +180,10 @@ > if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { > rid_ptr = next; > cookie->rid = strtoul( &rid_ptr[ STRLENOF( > "rid=" ) ], &next, 10 ); > - if ( next == rid_ptr || next > end || *next != > ',' ) { > + if ( next == rid_ptr > + || next > end > + || ( *next && *next != ',' ) ) > + { > return -1; > } > if ( *next == ',' ) { > @@ -194,7 +197,10 @@ > if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { > rid_ptr = next; > cookie->sid = strtoul( &rid_ptr[ STRLENOF( > "sid=" ) ], &next, 16 ); > - if ( next == rid_ptr || next > end || *next != > ',' ) { > + if ( next == rid_ptr > + || next > end > + || ( *next && *next != ',' ) ) > + { > return -1; > } > if ( *next == ',' ) { > > I'm not committing this fix because I'm not sure it doesn't break > anything else. the patch fails, this is the patch reject file: ---ldapsync.c.rej ------------------------------- *************** *** 180,186 **** if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { rid_ptr = next; cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 ); - if ( next == rid_ptr || next > end || *next != ',' ) { return -1; } if ( *next == ',' ) { --- 180,189 ---- if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { rid_ptr = next; cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 ); + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { *************** *** 194,200 **** if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { rid_ptr = next; cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ]. &next, 16 ); - if ( next == rid_ptr || next > end || *next != ',' ) { return -1; } if ( *next == ',' ) { --- 197,206 ---- if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { rid_ptr = next; cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ]. &next, 16 ); + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#4629) slapd failure on HP-UX 11.23/IA 64-bit
by h.b.furuseth＠usit.uio.no 10 Jun '07

10 Jun '07

Fixed in cvs (RE23 and HEAD) with a somewhat different patch. It should be more comprehensive than the old one, but testing on various systems is welcome anyway. -- Regards, Hallvard

1 0

Re: (ITS#4936) default modulepath
by ando＠sys-net.it 10 Jun '07

10 Jun '07

> No, they are installed in $(moduledir), which depends on LDAP_LIBEXECDIR > and --with-subdir. So, put that in some C variable or #define. Yes, I figured that out. I'll fix this later. 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#4936) default modulepath
by h.b.furuseth＠usit.uio.no 10 Jun '07

10 Jun '07

I wrote: > Use LDAP_LIBEXECDIR/openldap/, that's where modules get installed. > Try with ./configure --enable-overlays=mod --enable-monitor=mod. No, they are installed in $(moduledir), which depends on LDAP_LIBEXECDIR and --with-subdir. So, put that in some C variable or #define. -- Regards, Hallvard

1 0

(ITS#5007) Compilation problems
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: HP-UX, OSF1, non-gcc URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard HEAD/RE23: liblber/sockbuf.c uses pointer arithmetic on void*, a gcc extension. HEAD: OSF1 pthread.h defines "leave" as an exception keyword, which breaks slapd and bdb. I'll rename "leave" labels to "done" or "finish". liblutil/getpeereid.c breaks if LDAP_PF_LOCAL_SENDMSG is defined but MSG_WAITALL is not. (Not sure why that's compiled at all after the ldapi trouble, but that's another matter.) I'll fix it by #ifdeffing MSG_WAITALL in getpeereid.c rather than where LDAP_PF_LOCAL_SENDMSG is defined, since we need LDAP_PF_LOCAL_SENDMSG to decide whether to send a dummy abandon to previous OpenLDAP server versions.

1 0

Re: (ITS#4936) default modulepath
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

ando(a)sys-net.it writes: > It would be pretty straightforward to call lt_dlsetsearchpath() > (actually, the module_path() wrapper) from module_init() with a default > value. This could be, for example, LDAP_LIBEXECDIR, where slapd itself > gets installed by default. Use LDAP_LIBEXECDIR/openldap/, that's where modules get installed. Try with ./configure --enable-overlays=mod --enable-monitor=mod. -- Regards, Hallvard

1 0

Re: (ITS#4996) Use SRV records to locate local server for command-line clients
by ando＠sys-net.it 09 Jun '07

09 Jun '07

Committed to HEAD. Command-line clients now use DNS SRV to look up the host names related to a DN and build a list of URIs for subsequent use. To trigger, use -H "<proto>:///DN". The <host> portion must be empty, and a DN must be present. The DN must be in the "dc=<component>" form; it's turned into a domain and the host list is looked up using DNS SRV. After that, a list of URIs is built using the returned host/ports, and using <proto> as the LDAP scheme. 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#4936) default modulepath
by ando＠sys-net.it 09 Jun '07

09 Jun '07

It would be pretty straightforward to call lt_dlsetsearchpath() (actually, the module_path() wrapper) from module_init() with a default value. This could be, for example, LDAP_LIBEXECDIR, where slapd itself gets installed by default. Comments? 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#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

I wrote: > I'll just make [the hash table] chained. (...) > Solves the multi-pool problem too. No it doesn't. pool_pause() would stilll only pause one pool, while purgekey() needs all pools to be paused. I guess I'll chain it anyway. I forgot one bug in my summary: Slapd does not always check if pool_submit() and pool_setkey() succeed, even though failure is not a bug. (They can run into some limits.) pool_submit(): daemon.c:slapd_daemon_task() with rtask->routine connection.c:connections_shutdown() with c_clientfunc connection.c:connection_read() with c_clientfunc back-bdb/tools.c:bdb_tool_entry_open() with trickle and index tasks pool_setkey(): connection.c:connection_fake_init2() for slapi object extensions backend.c:be_isroot_pw() for SLAPD_SPASSWD passwd.c:slap_passwd_check() for SLAPD_SPASSWD sl_malloc.c:slap_sl_mem_create() back-bdb/search.c:search_stack() back-meta/conn.c:meta_back_candidates_get() slapd-modules/smbk5pwd/smbk5pwd.c:smbk5pwd_op_bind() -- Regards, Hallvard

1 0

Re: (ITS#4986) manageDSAit might control cause problems in database selection
by ando＠sys-net.it 09 Jun '07

09 Jun '07

A tentative fix is in HEAD (servers/slapd/backend.c 1.377 -> 1.378). 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#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

hyc(a)symas.com writes: > h.b.furuseth(a)usit.uio.no wrote: >> * When a thread is finishing, make it go active for context_reset(). >> Should make slapi module destructors safer, and I don't see that it >> can hurt. > > I don't understand this. Let me dig a bit back in the ITS... "context_reset() can call connection_fake_destroy(), which via slapi_int_free_object_extensions() calls slapi module destructors, which can do who-knows-what." >> * I'd like to rename thread contexts to tasks(?) and user contexts back >> to contexts (as in RE23). The current terminology is confusing. > > I don't care about this either way. Then I will. I still confuse myself sometimes, and I certainly would if I came back to this code next year. >> (...) > Never use malloc unless absolutely necessary. We have enough problems > with heap fragmentation already. Aha. OK. >> * Scheduling: If several threads call pool_pause(), then once there is a >> pause tpool does not schedule them all. They could get handled then, >> or another thread could undo the pause so tpool would wait to pause >> again. Is that deliberate? > > I don't understand the question. The point of the pause is to prevent > any other thread (in the pool) from running. Why should tpool schedule > any other threads at this point? Two threads call pool_pause(). Eventually the pool gets paused, and one pool_pause() call returns. When that thread calls pool_resume(), the other thread waiting in pool_pause() may or may not get scheduled. >> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can >> represent the same thread ID: TID_HASH() would give different hashes >> for the same thread, and pool_context() stops searching when it hits >> a slot with ctx == NULL. (My previous bug report was a bit wrong.) > > How can a single thread ID be represented by multiple bit patterns? A struct/union with padding bytes seems the least unlikely possibility. A pointer in hardware where several address representations map to the same physical address, and the compiler handles that by normalizing pointers when they are compared/subtracted. Like DOS "huge" pointers would have been if the compiler normalized them when comparing them instead of when incrementing/decrementing them. 20-bit address bus, 32-bit pointers, physical address = 16 * <segment half of pointer> + <offset half of pointer>. Or, not that I take this too seriously: A pthread implementation which uses e.g. a 32-bit integer type for thread IDs but just ignores the top 22 bits. The Posix spec seems to allow that, and thread IDs are to be compared with pthread_equal(). >> The best fix would be to use use real thread-specific data instead. >> Just one key with the ctx for now, that minimizes the changes. OTOH >> it also means we'll do thread-specific key lookup twice - first in >> pthread to get the ctx, and then in ltu_key[] to find our data. >> Anyway, I said I'd do that later but might as well get on with it, >> at least for pthreads. Except I don't know if that's OS-dependent >> enough that it should wait for RE24? > > The best fix may be to just use the address of the thread's stack as the > thread ID. That's actually perfect for our purpose. How does a function called from somewhere inside the thread know that address? That's almost what the user context is, and thus what thread_keys[] maps the thread ID to. >> - thread_keys is a poor hash table implementation with a poor hash >> function. > > Ideally it would not be a hash table at all, but a direct lookup based > on the thread ID. If we can. See above. Anyway, I don't know why I keep kvetching about the hash table implementation. I'll just make it chained. As I finally figured out, that can be done without mallocs. Solves the multi-pool problem too. >> * I wonder if there are long-lived ldap_pvt_thread_cond_wait(), >> [r]mutex_lock() or rdwr_[rw]lock() calls which should make the thread >> go inactive first (after waiting for any pause to finish), so that >> (a) a pool_pause() will not block waiting for them, and >> (b) all threads in the pool can't be blocked in long waits without >> tpool knowing about it. > > Long-lived lock calls would be a quite noticeable bug. This seems to be > a non-issue. Well, it'd have to be with code which is very rarely executed, or unusual configurations. But yes, I feel relaxed enough about it. >> * back-bdb/tools.c uses pool_submit() to start long-lived threads: >> (...) > Tool threads are completely separate from slapd threads. This is not an > issue. Fine. I don't understand that in this context, but I'll take your word for it:-) >> * slapd/bconfig.c maintains its own idea of the max number of threads >> in connection_pool_max and slap_tool_thread_max, which does not match >> tpool's idea if the limit is <=0 or larger than LDAP_MAXTHR. >> >> Since slapd acts on its own count, I imagine that can cause breakage. >> Simplest fix might be to set max #threads and then read it back, >> I haven't checked. Would need to return LDAP_MAXTHR instead of 0 >> for "as many as allowed". Note however also the issue above: >> tpool's idea of actually available threads can be too high too. > > The practical limits are actually pretty low. Even if you're on a 1024 > processor machine with many terabytes of RAM, it's not a good idea to > have many thousands of threads... Scheduler overhead would overshadow > any useful work. OK. I forgot how much RAM a slapd thread requires. But then it won't hurt to give slapd a max limit lower than LDAP_MAXTHR either. >> * I said my new ltp_pause waits might be too aggressive. Maybe I should >> clarify: I don't see any instances where they can be dropped, but it's >> possible that slapd expects pauses to be less aggressive somewhere. > > I don't understand this comment. Clarifying the clarification: I don't know slapd well enough to know if the extra pauses do something bad to it. >> Oh, the comment /* no open threads at all?!? */: That's not strange. >> Happens in the first pool_submit() call(s) if thread_create() fails. >> Though in that case there was no danger of removing the wrong ctx >> from ltp_pending_list after all (fixed in rev 1.63). > > (Sure, but thread_create() should never fail if you have a sane > configuration.) And if the rest of the machine doesn't run wild. I imagine thread_create() can fail when fork() can fail on some OSes. -- Regards, Hallvard

1 0

Re: (ITS#5003) issue about upper_needs_cast
by ando＠sys-net.it 09 Jun '07

09 Jun '07

caojunliang(a)huawei.com wrote: > when I set the option upper_needs_cast as Yes.It only takes effect on id_query > when adding an entry,but does not take effect on child id query when deleting an > entry. > > I found that in the src file back-sql/init.c > > line 374 --379 > > there are not operation about upper cast. > > I want to know if what I think is right. Not clear what's your point. "upper_needs_cast" is a hack to work around the fact that some RDBMSes need an explicit cast before passing a literal into whatever "uppercase" function they provide. Can you point out what's the problem and what's the expected behavior? I don't see any literal passed to the query that looks up the parent's and that needs any special treatment. A log of the offending operation, and an example of what you'd consider correct, would help. 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#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 09 Jun '07

09 Jun '07

This is now made consistent in HEAD: the inability to register custom monitor stuff always results in a failure. Note that the software provides different means to prevent this feature: a) allow anonymous read access to the monitor database b) define a rootdn (even without any possibility to auth) for the monitor database c) disable monitoring for all bdb/hdb databases 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#5005) test017 fails
by ando＠sys-net.it 09 Jun '07

09 Jun '07

dieter(a)dkluenter.de wrote: The problem is in slap_parse_sync_cookie(); when no cookie is passed, a string containing "rid=001" is parsed. The parser expects it to end with a comma. If passing "rid=001" is correct, the fix is trivial: instead of checking for (*next != ','), check for (*next && *next != ','). Index: servers/slapd/ldapsync.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/ldapsync.c,v retrieving revision 1.42 diff -u -r1.42 ldapsync.c --- servers/slapd/ldapsync.c 18 May 2007 12:46:52 -0000 1.42 +++ servers/slapd/ldapsync.c 9 Jun 2007 09:42:24 -0000 @@ -180,7 +180,10 @@ if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { rid_ptr = next; cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 ); - if ( next == rid_ptr || next > end || *next != ',' ) { + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { @@ -194,7 +197,10 @@ if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { rid_ptr = next; cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ], &next, 16 ); - if ( next == rid_ptr || next > end || *next != ',' ) { + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { I'm not committing this fix because I'm not sure it doesn't break anything else. 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#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 09 Jun '07

09 Jun '07

ando(a)sys-net.it wrote: > The difference is that if the monitor database comes first, it's already > open when the bdb tries to register its custom monitor stuff. So it can > barf out when the addition fails because of no enough permissions. > > If it comes later, back-bdb's custom monitor stuff ends up in the limbo, > which is then flushed when the monitor database starts up. At this > point, a failure in flushing the limbo is not considered critical. > > I see two/three solutions: > > 1) allow databases to fail monitor info registration without aborting > > 2) make startup fail also when limbo flushing fails > > 3) let the monitor database have a default rootdn. > > I'm not oriented towards any of the above, yet. I think the point is: if one explicitly requests monitoring support (by default on) in back-bdb, then it must either succeed or slapd should not start. If one does not explicitly request it, giving up monitoring with a warning should be fine. This is complicated by the need to support run-time configuration: in fact, if monitoring is explicitly requested but it cannot be registered, the creation of that database should fail, but the daemon should not stop. 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#4943) tpool.c pause vs. finish
by hyc＠symas.com 08 Jun '07

08 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > OK, here's where we stand now, with my TODOs, questions and some > new issues. 3+ pages. I thought this would be a brief message:-( > Hopefully I'll get to some of it this weekend, but no promises. > > > TODOs (unless someone protests) and questions: > > * When a thread is finishing, make it go active for context_reset(). > Should make slapi module destructors safer, and I don't see that it > can hurt. I don't understand this. > * I'd like to rename thread contexts to tasks(?) and user contexts back > to contexts (as in RE23). The current terminology is confusing. I don't care about this either way. > > * Save and restore the old data for key slap_sasl_bind, and just in case > (I can't tell if it is needed) smbk5pwd. > > Might as well do it everywhere we have setkey - do something - delete > key in one function call. Since setkey(non-null) isn't supposed to > overwrite existing keys, the change should not be able to hurt. It > could protect something I didn't think of or a future slapd change. > > API: the smallest change would be to call pool_getkey() first, > but I prefer a pool_swapkey(ctx, key, &data, &kfree) function. > Then in RE24, maybe remove the &kfree parameter to pool_getkey(). > > Could omit the &kfree parameter to swapkey() if new data was > guaranteed non-NULL, but that'd require a malloc in bdb (silly says > Howard) or passing data in a &union{integer, ptr} (cumbersome say I). Never use malloc unless absolutely necessary. We have enough problems with heap fragmentation already. > * Axe semaphore code in tpool.c, the ldap_lazy_sem_init() call in > slapd/daemon.c, and with them LDAP_PVT_THREAD_POOL_SEM_LOAD_CONTROL > in ldap_pvt_thread.h and SLAP_SEM_LOAD_CONTROL in slap.h. OK. > * Is the ldap_pvt_thread_pool_context_reset() call in slapd/init.c > indeed safe - ie. its slap_sl_mem_destroy() call? That's not during > startup, but in slap_destroy(). Slapd does various stuff after that. Yes. > * API changes: > > Do we include the assert(no multiple pools) in the import to RE23? > Remove keys from ltu_key[] _before_ calling ltk_free() with them? > That prevents functions called from ltk_free from seeing freed thread > data, but it can also break ltk_free functions that call such > functions _before_ freeing it. Probably not for RE23. > > * Scheduling: If several threads call pool_pause(), then once there is a > pause tpool does not schedule them all. They could get handled then, > or another thread could undo the pause so tpool would wait to pause > again. Is that deliberate? I don't understand the question. The point of the pause is to prevent any other thread (in the pool) from running. Why should tpool schedule any other threads at this point? > Dubious code, new issues, old ones I'm not sure we finished with: > > * thread_keys[] still has problems. > > - pool_context() breaks if several ldap_pvt_thread_t bit patterns can > represent the same thread ID: TID_HASH() would give different hashes > for the same thread, and pool_context() stops searching when it hits > a slot with ctx == NULL. (My previous bug report was a bit wrong.) How can a single thread ID be represented by multiple bit patterns? > The best fix would be to use use real thread-specific data instead. > Just one key with the ctx for now, that minimizes the changes. OTOH > it also means we'll do thread-specific key lookup twice - first in > pthread to get the ctx, and then in ltu_key[] to find our data. > Anyway, I said I'd do that later but might as well get on with it, > at least for pthreads. Except I don't know if that's OS-dependent > enough that it should wait for RE24? The best fix may be to just use the address of the thread's stack as the thread ID. That's actually perfect for our purpose. > When that's not implemented, I'd prefer to cast the thread ID to an > integer when that is safe, and hash that instead of its bytes. > Won't work for structs/unions, and is not formally guaranteed for > pointers or in case of pthreads even integers. BTW, when it doesn't > work, we've got a problem in ITS#4983 (tls.c id_callback) as well. > > When that's not possible, we could search the entire table before > giving up. Could make thread_keys[] smaller and reduce the maximum > allowed #threads on such hosts. (What should the limit be?) > > - thread_keys is a poor hash table implementation with a poor hash > function. Ideally it would not be a hash table at all, but a direct lookup based on the thread ID. > Oops - for caching, maybe I shouldn't have removed the thread id > from thread_keys[]. Or maybe the hash value should be stored there > instead, so we can compare with == instead of ldap_pvt_thread_equal. > > * I wonder if there are long-lived ldap_pvt_thread_cond_wait(), > [r]mutex_lock() or rdwr_[rw]lock() calls which should make the thread > go inactive first (after waiting for any pause to finish), so that > (a) a pool_pause() will not block waiting for them, and > (b) all threads in the pool can't be blocked in long waits without > tpool knowing about it. Long-lived lock calls would be a quite noticeable bug. This seems to be a non-issue. > * back-bdb/tools.c uses pool_submit() to start long-lived threads: > bdb_tool_trickle_task() and bdb_tool_index_task(). They don't exit > until slapd is stopping, so they'll block slapd if a thread requests > a pause. Also the pool thinks its has more available threads that it > does, so scheduled tasks might never be executed. > > Possibly that's not a problem with slaptools. As complex as slapd is > now with overlays and plugins and whatnot, I have no idea. Tool threads are completely separate from slapd threads. This is not an issue. > * slapd/bconfig.c maintains its own idea of the max number of threads > in connection_pool_max and slap_tool_thread_max, which does not match > tpool's idea if the limit is <=0 or larger than LDAP_MAXTHR. > > Since slapd acts on its own count, I imagine that can cause breakage. > Simplest fix might be to set max #threads and then read it back, > I haven't checked. Would need to return LDAP_MAXTHR instead of 0 > for "as many as allowed". Note however also the issue above: > tpool's idea of actually available threads can be too high too. The practical limits are actually pretty low. Even if you're on a 1024 processor machine with many terabytes of RAM, it's not a good idea to have many thousands of threads... Scheduler overhead would overshadow any useful work. > * I said my new ltp_pause waits might be too aggressive. Maybe I should > clarify: I don't see any instances where they can be dropped, but it's > possible that slapd expects pauses to be less aggressive somewhere. I don't understand this comment. > > About pool_submit() and the ltp_mutex unlock-relock: > > Some history and notes, just to finish up previous discussion. > Some possible TODOs, but they are not needed since it's not broken: > > Originally, pool_submit() unlocked ltp_mutex before thread_create() > and re-locked it afterwards for further maintenance. That was not > because of the semaphore code. It looks like it could work even in > non-threaded mode where thread_create(,,fn,arg) just called fn(arg), > though tpool.c was always wrapped in an #ifndef <--without-threads>. > > I don't think non-threaded would have worked anyway since rev 1.24 > (apr 2003), which introduced thread_keys[]. Caller and callee would > have gotten the same thread ID, so tpool would have confused their > contexts. Previously the new context was pushed onto ltp_active_list, > and would have temporarily hid the old context. > > That's also when thread_create() was moved after the ltp_mutex > re-lock, which would mean the mutex was locked while pool_wrapper() > was running and tried to re-lock the mutex. And now, my rev.171 has > removed the unlock-relock. > > With that I can also remove the search for ctx in ltp_pending_list > when backing out of pool_submit, it will be at the head of that list. > > With tpool only supporting threaded mode, another cleanup could be for > pool_submit to start a thread before inserting ctx in ltp_pending_list > instead of after. That done, it can fail if ltp_open_count is still > 0, and we won't need the code for backing out of pool_submit(). OK. > Oh, the comment /* no open threads at all?!? */: That's not strange. > Happens in the first pool_submit() call(s) if thread_create() fails. > Though in that case there was no danger of removing the wrong ctx > from ltp_pending_list after all (fixed in rev 1.63). (Sure, but thread_create() should never fail if you have a sane configuration.) -- -- 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#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 08 Jun '07

08 Jun '07

OK, here's where we stand now, with my TODOs, questions and some new issues. 3+ pages. I thought this would be a brief message:-( Hopefully I'll get to some of it this weekend, but no promises. TODOs (unless someone protests) and questions: * When a thread is finishing, make it go active for context_reset(). Should make slapi module destructors safer, and I don't see that it can hurt. * I'd like to rename thread contexts to tasks(?) and user contexts back to contexts (as in RE23). The current terminology is confusing. * Save and restore the old data for key slap_sasl_bind, and just in case (I can't tell if it is needed) smbk5pwd. Might as well do it everywhere we have setkey - do something - delete key in one function call. Since setkey(non-null) isn't supposed to overwrite existing keys, the change should not be able to hurt. It could protect something I didn't think of or a future slapd change. API: the smallest change would be to call pool_getkey() first, but I prefer a pool_swapkey(ctx, key, &data, &kfree) function. Then in RE24, maybe remove the &kfree parameter to pool_getkey(). Could omit the &kfree parameter to swapkey() if new data was guaranteed non-NULL, but that'd require a malloc in bdb (silly says Howard) or passing data in a &union{integer, ptr} (cumbersome say I). * Axe semaphore code in tpool.c, the ldap_lazy_sem_init() call in slapd/daemon.c, and with them LDAP_PVT_THREAD_POOL_SEM_LOAD_CONTROL in ldap_pvt_thread.h and SLAP_SEM_LOAD_CONTROL in slap.h. * Is the ldap_pvt_thread_pool_context_reset() call in slapd/init.c indeed safe - ie. its slap_sl_mem_destroy() call? That's not during startup, but in slap_destroy(). Slapd does various stuff after that. * API changes: Do we include the assert(no multiple pools) in the import to RE23? Remove keys from ltu_key[] _before_ calling ltk_free() with them? That prevents functions called from ltk_free from seeing freed thread data, but it can also break ltk_free functions that call such functions _before_ freeing it. Probably not for RE23. * Scheduling: If several threads call pool_pause(), then once there is a pause tpool does not schedule them all. They could get handled then, or another thread could undo the pause so tpool would wait to pause again. Is that deliberate? Dubious code, new issues, old ones I'm not sure we finished with: * thread_keys[] still has problems. - pool_context() breaks if several ldap_pvt_thread_t bit patterns can represent the same thread ID: TID_HASH() would give different hashes for the same thread, and pool_context() stops searching when it hits a slot with ctx == NULL. (My previous bug report was a bit wrong.) The best fix would be to use use real thread-specific data instead. Just one key with the ctx for now, that minimizes the changes. OTOH it also means we'll do thread-specific key lookup twice - first in pthread to get the ctx, and then in ltu_key[] to find our data. Anyway, I said I'd do that later but might as well get on with it, at least for pthreads. Except I don't know if that's OS-dependent enough that it should wait for RE24? When that's not implemented, I'd prefer to cast the thread ID to an integer when that is safe, and hash that instead of its bytes. Won't work for structs/unions, and is not formally guaranteed for pointers or in case of pthreads even integers. BTW, when it doesn't work, we've got a problem in ITS#4983 (tls.c id_callback) as well. When that's not possible, we could search the entire table before giving up. Could make thread_keys[] smaller and reduce the maximum allowed #threads on such hosts. (What should the limit be?) - thread_keys is a poor hash table implementation with a poor hash function. For the hash function, I'll insert a variant of Paul Hsieh's SuperFastHash() instead, or something simpler if we hash an integer. For the hash table, the real fix would be to grab a proper hash table implementation and use that. We might find use for it elsewhere too. Though simple fixes will handle all but some rare cases, and I don't know how much we care: The table is never resized and will slow down lookup when it gets full. A quick fix would be to allow max (70% table size) threads or something. And double the size of the table, if we still want to allow 1024 threads. However if the admin experiments with ltp_max_count for a while so many threads stop/start/stop/start, the table slowly fills up with DELETED_THREAD_CTX entries. Longer search chains, longer thread ID lookup time. Should happen rarely, but we don't advise against it in the docs either. Do we care, beyond documenting it? If yes, we need a real hash table implementation, or at least to re-hash the table when there are too many DELETED_THREAD_CTX entries. Or use a chained hash table. No malloc needed, use the thread's stack space. For open addressing, I was thinking quadric probing would be better than linear, but maybe not with a proper hash function. I don't know what that does to cache issues. Oops - for caching, maybe I shouldn't have removed the thread id from thread_keys[]. Or maybe the hash value should be stored there instead, so we can compare with == instead of ldap_pvt_thread_equal. * I wonder if there are long-lived ldap_pvt_thread_cond_wait(), [r]mutex_lock() or rdwr_[rw]lock() calls which should make the thread go inactive first (after waiting for any pause to finish), so that (a) a pool_pause() will not block waiting for them, and (b) all threads in the pool can't be blocked in long waits without tpool knowing about it. * back-bdb/tools.c uses pool_submit() to start long-lived threads: bdb_tool_trickle_task() and bdb_tool_index_task(). They don't exit until slapd is stopping, so they'll block slapd if a thread requests a pause. Also the pool thinks its has more available threads that it does, so scheduled tasks might never be executed. Possibly that's not a problem with slaptools. As complex as slapd is now with overlays and plugins and whatnot, I have no idea. If it's a problem, it is not enough for them to regularly reschedule themselves and exit: They have long-lived waits. See previous issue. * slapd/bconfig.c maintains its own idea of the max number of threads in connection_pool_max and slap_tool_thread_max, which does not match tpool's idea if the limit is <=0 or larger than LDAP_MAXTHR. Since slapd acts on its own count, I imagine that can cause breakage. Simplest fix might be to set max #threads and then read it back, I haven't checked. Would need to return LDAP_MAXTHR instead of 0 for "as many as allowed". Note however also the issue above: tpool's idea of actually available threads can be too high too. * I said my new ltp_pause waits might be too aggressive. Maybe I should clarify: I don't see any instances where they can be dropped, but it's possible that slapd expects pauses to be less aggressive somewhere. About pool_submit() and the ltp_mutex unlock-relock: Some history and notes, just to finish up previous discussion. Some possible TODOs, but they are not needed since it's not broken: Originally, pool_submit() unlocked ltp_mutex before thread_create() and re-locked it afterwards for further maintenance. That was not because of the semaphore code. It looks like it could work even in non-threaded mode where thread_create(,,fn,arg) just called fn(arg), though tpool.c was always wrapped in an #ifndef <--without-threads>. I don't think non-threaded would have worked anyway since rev 1.24 (apr 2003), which introduced thread_keys[]. Caller and callee would have gotten the same thread ID, so tpool would have confused their contexts. Previously the new context was pushed onto ltp_active_list, and would have temporarily hid the old context. That's also when thread_create() was moved after the ltp_mutex re-lock, which would mean the mutex was locked while pool_wrapper() was running and tried to re-lock the mutex. And now, my rev.171 has removed the unlock-relock. With that I can also remove the search for ctx in ltp_pending_list when backing out of pool_submit, it will be at the head of that list. With tpool only supporting threaded mode, another cleanup could be for pool_submit to start a thread before inserting ctx in ltp_pending_list instead of after. That done, it can fail if ltp_open_count is still 0, and we won't need the code for backing out of pool_submit(). Oh, the comment /* no open threads at all?!? */: That's not strange. Happens in the first pool_submit() call(s) if thread_create() fails. Though in that case there was no danger of removing the wrong ctx from ltp_pending_list after all (fixed in rev 1.63). -- Regards, Hallvard

1 0

Re: (ITS#5005) test017 fails
by quanah＠zimbra.com 08 Jun '07

08 Jun '07

--On June 8, 2007 6:43:50 PM +0000 dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.196.121) > > > here the output of test017 logfiles > > ---slapd.1.log---------------- > ber_scanf fmt (}) ber: > <= get_ctrls: n=1 rc=2 err="Sync control : cookie parsing error" > send_ldap_result: conn=7 op=1 p=3 > send_ldap_result: err=2 matched="" text="Sync control : cookie parsing > error" send_ldap_response: msgid=2 tag=101 err=2 Hm, is this possibly related to the fix for ITS#4977? If you revert that checkin for syncprov.c today, does the test pass? <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov.c.…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5005) test017 fails
by dieter＠dkluenter.de 08 Jun '07

08 Jun '07

Full_Name: Dieter Kluenter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.196.121) here the output of test017 logfiles ---slapd.1.log---------------- >>> slap_listener(ldap://localhost:9011/) conn=7 fd=13 ACCEPT from IP=127.0.0.1:13352 (IP=127.0.0.1:9011) connection_get(13) connection_get(13): got connid=7 connection_read(13): checking for input on id=7 ber_get_next ber_get_next: tag 0x30 len 46 contents: ber_get_next do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=manager,dc=example,dc=com> => ldap_bv2dn(cn=manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: <cn=manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> do_bind: version=3 dn="cn=manager,dc=example,dc=com" method=128 conn=7 op=0 BIND dn="cn=manager,dc=example,dc=com" method=128 ==> bdb_bind: dn: cn=manager,dc=example,dc=com conn=7 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 do_bind: v3 bind: "cn=manager,dc=example,dc=com" to "cn=Manager,dc=example,dc=com" send_ldap_result: conn=7 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 13 conn=7 op=0 RESULT tag=97 err=0 text= connection_get(13) connection_get(13): got connid=7 connection_read(13): checking for input on id=7 ber_get_next ber_get_next: tag 0x30 len 109 contents: ber_get_next do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=example,dc=com> => ldap_bv2dn(dc=example,dc=com,0) <= ldap_bv2dn(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> SRCH "dc=example,dc=com" 2 0 0 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.3.6.1.4.1.4203.1.9.1.1" (noncritical) ber_scanf fmt ({i) ber: ber_scanf fmt (m) ber: ber_scanf fmt (b) ber: ber_scanf fmt (}) ber: <= get_ctrls: n=1 rc=2 err="Sync control : cookie parsing error" send_ldap_result: conn=7 op=1 p=3 send_ldap_result: err=2 matched="" text="Sync control : cookie parsing error" send_ldap_response: msgid=2 tag=101 err=2 ber_flush2: 49 bytes to sd 13 conn=7 op=1 SEARCH RESULT tag=101 err=2 nentries=0 text=Sync control : cookie parsing error do_search: get_ctrls failed connection_get(13) connection_get(13): got connid=7 connection_read(13): checking for input on id=7 ber_get_next ber_get_next: tag 0x30 len 5 contents: ber_get_next ber_get_next on fd 13 failed errno=0 (Success) connection_closing: readying conn=7 sd=13 for close connection_close: deferring conn=7 sd=13 do_unbind conn=7 op=2 UNBIND connection_resched: attempting closing conn=7 sd=13 connection_close: conn=7 sd=13 conn=7 fd=13 closed daemon: shutdown requested and initiated. --------------------------------------- ---- slapd.2.log ---------------------- >>> slap_listener(ldap://localhost:9012/) conn=1 fd=13 ACCEPT from IP=127.0.0.1:3877 (IP=127.0.0.1:9012) connection_get(13) connection_get(13): got connid=1 connection_read(13): checking for input on id=1 ber_get_next ber_get_next: tag 0x30 len 46 contents: ber_get_next do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=Manager,dc=example,dc=com> => ldap_bv2dn(cn=Manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=Manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> do_bind: version=3 dn="cn=Manager,dc=example,dc=com" method=128 conn=1 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 ==> bdb_bind: dn: cn=Manager,dc=example,dc=com bdb_dn2entry("cn=manager,dc=example,dc=com") => bdb_dn2id("dc=example,dc=com") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=1 op=0 p=3 send_ldap_result: err=49 matched="" text="" send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 13 conn=1 op=0 RESULT tag=97 err=49 text= connection_get(13) connection_get(13): got connid=1 connection_read(13): checking for input on id=1 ber_get_next ber_get_next on fd 13 failed errno=0 (Success) connection_closing: readying conn=1 sd=13 for close connection_close: conn=1 sd=13 conn=1 fd=13 closed (connection lost) daemon: shutdown requested and initiated. slapd shutdown: waiting for 0 threads to terminate lt-slapd shutdown: initiated ====> bdb_cache_release_all lt-slapd destroy: freeing system resources. slapd stopped. -------------------------------------------------------- ---test.out--------------- ldap_initialize( ldap://localhost:9012 ) ldap_bind: Invalid credentials (49) ------------------------------ -Dieter

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs