- openldap-bugs - openldap.org

Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify
by hyc＠symas.com 11 May '07

11 May '07

guenther+ldapdev(a)sendmail.com wrote: > Full_Name: Philip Guenther > Version: 2.3.27 > OS: Linux and Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.58.1.252) > > > [I vaguely recall seeing a report of this issue in the archives of one of the > mailing lists, but I can no longer find the original.] > > If you trace the packets sent when you use, for example, ldapsearch against a > server on a different host, using either the -Z option to do TLS or using an > ldaps URI, you'll discover that the TCP connection is actually reset instead of > being closed cleanly: the client sends TCP RSTs in response to the server's > final packets. > > This is because libldap uses the following sequence when unbind a TLS or SSL > connection: > 1) send the unbind request (over the TLS or SSL layer) > 2) call SSL_shutdown(), sending the TLS close_notify alert > 3) call close() > > After receiving the close_notify alert from step (2), the server sends back its > own close_notify alert and then calls close(). However, because the client > didn't wait for the server's response before calling close() on its end, the > client's TCP stack considers the TCP connection to already be gone and responds > with the RST packets. This occurs with Linux and Solaris clients and probably > most other unices: the response to packets after a close() doesn't vary in my > experience. That sounds like you're seeing a bug in the kernel's TCP stack then. A TCP close sends a FIN to the other end and is required to wait for the FIN to be ACK'd before the connection can be torn down. (Subject to 2MSL timeout.) That is most certainly not our problem. -- -- 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#4956) slapd cores with a SEGFAULT after a failed proxy authorization
by hyc＠symas.com 11 May '07

11 May '07

pturgyan(a)umich.edu wrote: > Full_Name: Paul Turgyan > Version: 2.3.35 > OS: linux - 2.6 kernal > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.213.231.201) > slapd cores with a SEGFAULT after a failed proxy authorization, > with a core file like: This was already reported in ITS#4954 and is fixed in HEAD. Simply NULLing out the pointer will introduce a memory leak. This ITS will be closed as a dup of #4954. -- -- 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#4956) slapd cores with a SEGFAULT after a failed proxy authorization
by pturgyan＠umich.edu 11 May '07

11 May '07

Full_Name: Paul Turgyan Version: 2.3.35 OS: linux - 2.6 kernal URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.213.231.201) slapd cores with a SEGFAULT after a failed proxy authorization, with a core file like: (gdb) bt #0 0xb7c74be5 in *__GI___libc_free (mem=0xab5fc714) at malloc.c:3402 #1 0x0807aa96 in ch_free (ptr=0xab5fc714) at ch_malloc.c:139 #2 0x080a5886 in slap_sasl_authorize (sconn=0xacb03000, context=0xada20428, requested_user=0xacb03910 "pturgyan(a)UMICH.EDU", rlen=18, auth_identity=0xacb03a11 "pturgyan(a)UMICH.EDU", alen=18, def_realm=0xacb049e0 "UMICH.EDU", urlen=9, props=0x0) at sasl.c:673 #3 0xb7ea2ba3 in do_authorization (s_conn=0xacb03000) at server.c:1163 #4 0xb7ea2d18 in sasl_server_step (conn=0xacb03000, clientin=0xacb01dae "`?\006\t*\206H\206?\022\001\002\002\002\001\004", clientinlen=0, serverout=0xad61d114, serveroutlen=0x1) at server.c:1420 #5 0x080a6654 in slap_sasl_bind (op=0x830fad0, rs=0xad61d240) at sasl.c:1395 #6 0x0807cdaa in fe_op_bind (op=0x830fad0, rs=0xad61d240) at bind.c:276 #7 0x0807c5b3 in do_bind (op=0x830fad0, rs=0xad61d240) at bind.c:200 #8 0x0806176f in connection_operation (ctx=0x0, arg_v=0x830fad0) at connection.c:1133 #9 0x08133e28 in ldap_int_thread_pool_wrapper (xpool=0x81ff4e0) at tpool.c:478 #10 0xb7e83c6b in start_thread (arg=0xad61dbb0) at pthread_create.c:261 #11 0xb7cc9d9e in clone () from /lib/libc.so.6 We are using cyrus-sasl-2.1.21 heimdahl-0.6.2 During a proxy auth, c_sasl_dn is set at sasl.c:682. If the proxy auth fails for some reason, then c_sasl_dn is never cleared. Sometime later, when that connection block is reused for another sasl bind, slap_sasl_authorize attempts to free the memory pointed to by c_sasl_dn.bv_val at sasl.c:673 and free SEGFAULTs. This can be duplicated by looping a ldapsearch that does a sasl bind with an invalid proxy authorization. You have to loop long enough to force a reuse of a connection struct. The following patch NULL's out c_sasl_dn at sasl.c:702 when the proxy auth is disallowed. *** sasl.c- Thu Jan 25 07:42:38 2007 --- sasl.c Fri May 11 13:47:19 2007 *************** *** 699,704 **** --- 699,705 ---- "proxy authorization disallowed (%d)\n", (long) (conn ? conn->c_connid : -1), rc, 0 ); + BER_BVZERO( &conn->c_sasl_dn ); sasl_seterror( sconn, 0, "not authorized" ); ch_free( authzDN.bv_val ); return SASL_NOAUTHZ;

1 0

(ITS#4955) v3 referrals problem in libldap/request.c
by steven.rellinger＠hp.com 11 May '07

11 May '07

Full_Name: Steve Version: 2.3.35 OS: Windows 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.227.217.75) There is a potential hang in the libldap/request.c code for chasing v3 referrals. I've narrowed down the scope of this issue to libldap/request.c in the function ldap_chase_v3referrals, specifically the loop after find_connection where it tries to see if the DN was already requested on that connection. (This is all around line 889) >From an outsider's perspective it seems like a really trivial bug was introduced into this loop in how it deals with the 'lp' variable. if ( lp == origreq ) { lp = lp->lr_child; } else { lp = lr->lr_refnext; } ... The variable lr does not change in this loop at all, it seems like a mistake to use it here as a condition on the loops flow. To me, it would seem like they meant to use something more like this which is a traditional linked list tree enumeration. if ( lp == origreq ) { lp = lp->lr_child; } else { lp = lp->lr_refnext; } I've tested this particular situation and it seems to eliviate the issue I was experiencing where it was chasing referrals from AD and never finishing this part of the function. I hope this helps others and or can be applied to the latest source code.

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 11 May '07

11 May '07

Howard Chu writes: > Quite a lot of changes, will take some time to evaluate the overall > impact. I hope it helped to make one patch per issue, and that the comments were clear about what each patch was fixing. > The semaphore stuff probably needs to be axed/unifdef'd. It is If it is unusable, do you mean "axed/#if 0'ed"? > unusable, it would only result in deadlocks, and I think I already > removed the slapd code that would have invoked it. slapd/daemon.c does ldap_lazy_sem_init(). No other calls outside tpool.c. >> tpool.c breaks if there are multiple pools. The simplest >> solution seems to be to remove support for multiple pools. >> The problem is thread_keys[]. It is shared between pools, but: > > slapd only uses a single pool, and that's really the only use case we > care about. In fact it makes no sense to support multiple pools, > because we have no mechanism to assert scheduling priorities of one > pool over another. I'm afraid I did not think of scheduling priorities at all, only bugs. But it certainly makes things simpler if we remove multiple pools. Simple documentation of how tpool should be used may remove some of my concerns - or how it _is_ used, since it's only used in slapd. (Several probably only are problems if it is used as a library feature. tpool depends on being used the way slapd is using it. I've wondered what it's doing in libldap_r/ instead of in slapd/.) I wrote: >> - ltp_max_count (max #threads) is pool-specific, but is used to >> protect from array bounds violation on thread_keys[LDAP_MAXTHR]. >> (New simple code from me, previously there was no limit.) sorry, s/array bounds violation/eternal loop looking for free slot/. >> Other thread_keys[] strangeness: >> >> - setkey does not free the old data with ltk_free. Possibly that's >> intentional, but if so that requires weird code elsewhere. > > Yes, that's intentional. ltk_free is only intended for cleanup if a key > is still set by the time a thread exits. All of the keys we set are live > for the entire life of a thread, they don't get re-assigned. So if I call setkey and the key already exists and has an ltk_free function, it's my responsibility to know the old data was there, and free it or take back ownership? (A clarifying comment would be useful.) >> - maybe related to how getkey can return the ltk_free function - which >> seems crazy since a caller who uses it must then explicitly reset the >> key afterwards (or better, before), to be sure purgekey doesn't >> see the data and free it again. > > Nothing actually depends on returning the ltk_free function, that was > just included for completeness' sake. Then I suggest the getkey(,,,kfree) output parameter is removed, to avoid inviting to future duplicate frees. If anyone later needs it, a cleaner mechanism can be included - e.g. a setkey(data=kfree=0) variant which does call ltk_free before removing the key, or maybe a setkey which returns any old data and free function. >> - tpool.c uses LDAP_FREE(), can call ldap_pvt_thread_pool_context(), >> which uses thread_keys[]. If one thread does that when another thread >> has paused the pool, that can break since thread_keys[] is reserved >> for ldap_pvt_thread_pool_purgekey() during pauses. I'm wrong, thread_keys[] is _read-only_ during pauses. pool_context() is safe since it does not write thread_keys, just like pool_purgekey(). > Since there is only one thread pool in use, it is impossible for another > thread to be active. No. Though it's true that my concern above was wrong. It is "ltp_active_count--" which triggers the start of a pause. So "active" here means "included in ltp_active_count". A pool_wrapper() thread is only "active" when handling a context, not when adding itself to or removing itself from thread_keys[]. That's what my new pause waits were for. Also I don't think the main thread is included in the "active" threads - so it's only impossible if the main thread doesn't interfere. (Again, I suppose a comment may be the "fix".) But this reminds me: How much should an ltk_free() function be allowed to do? - pool_context_reset() calls ltk_free(). Should pool_wrapper() go active (wait for !pause, increment ltp_active_count, unlock ltp_mutex) before calling pool_context_reset()? - Should ltk_free() be allowed to change the contents of ltu_key[], so pool_purgekey() and pool_context_reset() should be prepared for that? >> - ltp_pending_count includes threads sleeping in pool_pause() - should >> it? In effect, pool_pause() temporarily reduces ltp_max_pending. > > I don't see why any special consideration is needed here. Nothing else > in the thread pool is going to move while a pause is in effect. That single thread could do ldap_pvt_thread_pool_submit() - which could fail due to the reduced effectinve max_pending. Again, if slapd won't, even with weird overlays and whatnot in effect, a comment will fix that. >> - In ldap_pvt_thread_pool_submit(): >> >> This comment: >> /* there is another open thread, so this >> * context will be handled eventually. >> * continue on and signal that the context >> * is waiting. >> */ >> is wrong if the previous if (pool->ltp_open_count == 0) was >> taken but the no thread was found inside that. > > The comment may be incomplete... "and signal that..." should be "we have signalled that...". Otherwise it's correct if we remove the remove the semaphore and unlock like you say below. With the current code, I think the comment should be /* another open thread took or eventually will * take care of this context. continue on, we * have signalled that the context is waiting. */ >> Also if ctx is invalid (another thread handled it) and a new >> pending request has gotten the now-unused ctx, then the >> 'if (pool->ltp_open_count == 0)' code will free that new >> pending request instead of the old one. > > Most likely this is due to unlocking and relocking the mutex around the > semaphore code. Axe that, remove the gratuitous unlock/relock, and then > that problem goes away. Yes, that should fix it. >> - Note, I haven't looked at the new semaphore stuff yet. >> >> Will get back to this later, but could use review so far. In particular >> I'd like to know if we'll keep or kill multi-pool support. > > Thus far we've only had to worry about a single pool. If anyone can come > up with a reason to need multiple pools, I guess we need to hear it. > Given the lack of scheduling control, I don't see how it would be of any > benefit. At the same time, I don't see a compelling reason to perturb > the code at the moment. Well, there are still bugs left. And can't say I like to have a feature (multiple pools) which only a not-bug because it isn't used. -- Regards, Hallvard

1 0

(ITS#4954) must clear c_sasl_dn after error
by donn＠u.washington.edu 10 May '07

10 May '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) After SASL bind failure, c_sasl_dn is not cleared, and eventually causes a crash when it is encountered in a subsequent bind attempt, in ch_free, slap_sasl_authorize ca. line 676. (Depending on platform malloc - NetBSD complains here but doesn't crash, Linux/glibc may or may not complain but does corrupt heap and eventually crashes.) Duplicate: Attempt SASL PLAIN bind as "" with password "" (for example) to get SASL "User not found" error. Then make one or more SASL EXTERNAL binds, until server crashes - shouldn't take but one or two. I make a supportSASLMechanisms search before the PLAIN bind, because that's what our user did when he crashed our service, but this is probably irrelevant. I do not specify a bind name in the EXTERNAL bind. Fix: in slap_sasl_bind, ca. line 1713, BER_BVZERO(&op->o_conn->c_sasl_dn) after bind fails (sc neither SASL_OK nor SASL_CONTINUE) Problem initially encountered in 2.3.24, also observed in 2.3.21 and 2.4.4. Fix tested on 2.3.21 and 2.3.24.

1 0

(ITS#4953) test043-delta-syncrepl failed (exit 1): producer and consumer databases differ
by michael＠stroeder.com 10 May '07

10 May '07

Full_Name: Michael Ströder Version: HEAD OS: openSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.125.59) michael@nb2:/usr/src/openldap-HEAD/ldap/tests> ./run -b bdb test043 Cleaning up test run directory leftover from previous run. Running ./scripts/test043-delta-syncrepl... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entries in the producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that producer slapd is running... Using ldapmodify to modify producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the consumer slapd... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... test failed - producer and consumer databases differ

1 0

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

10 May '07

h.b.furuseth(a)usit.uio.no wrote: > OK, I've fixed some of it in HEAD. See comments in the commits for > tpool.c 1.63 and outwards. Quite a lot of changes, will take some time to evaluate the overall impact. > > RE23 has the same problems. Nearly identical code sans the new > semaphore stuff and a few variable names, so fixes should be easy > to import when they've been tested a bit. The semaphore stuff probably needs to be axed/unifdef'd. It is unusable, it would only result in deadlocks, and I think I already removed the slapd code that would have invoked it. > Remaining problems: > > tpool.c breaks if there are multiple pools. The simplest > solution seems to be to remove support for multiple pools. > The problem is thread_keys[]. It is shared between pools, but: slapd only uses a single pool, and that's really the only use case we care about. In fact it makes no sense to support multiple pools, because we have no mechanism to assert scheduling priorities of one pool over another. > Other thread_keys[] strangeness: > > - setkey does not free the old data with ltk_free. Possibly that's > intentional, but if so that requires weird code elsewhere. Yes, that's intentional. ltk_free is only intended for cleanup if a key is still set by the time a thread exits. All of the keys we set are live for the entire life of a thread, they don't get re-assigned. > - maybe related to how getkey can return the ltk_free function - which > seems crazy since a caller who uses it must then explicitly reset the > key afterwards (or better, before), to be sure purgekey doesn't > see the data and free it again. Nothing actually depends on returning the ltk_free function, that was just included for completeness' sake. > Other notes: > > - I've inserted new, possibly too aggressive, waits for ltp_pause in > pool_wrapper. See the tpool.c 1.65 comment. Yet another alternative > than splitting the ltp_pause state might be to remove the requirement > that purgekey() can only be used by a paused thread. (Could loop > until the key is _really_ gone instead, or something.) Will look at this later. > > - tpool.c uses LDAP_FREE(), can call ldap_pvt_thread_pool_context(), > which uses thread_keys[]. If one thread does that when another thread > has paused the pool, that can break since thread_keys[] is reserved > for ldap_pvt_thread_pool_purgekey() during pauses. Since there is only one thread pool in use, it is impossible for another thread to be active. > - ltp_pending_count includes threads sleeping in pool_pause() - should > it? In effect, pool_pause() temporarily reduces ltp_max_pending. I don't see why any special consideration is needed here. Nothing else in the thread pool is going to move while a pause is in effect. > - In ldap_pvt_thread_pool_submit(): > > This comment: > /* there is another open thread, so this > * context will be handled eventually. > * continue on and signal that the context > * is waiting. > */ > is wrong if the previous if (pool->ltp_open_count == 0) was > taken but the no thread was found inside that. The comment may be incomplete... > Also if ctx is invalid (another thread handled it) and a new > pending request has gotten the now-unused ctx, then the > 'if (pool->ltp_open_count == 0)' code will free that new > pending request instead of the old one. Most likely this is due to unlocking and relocking the mutex around the semaphore code. Axe that, remove the gratuitous unlock/relock, and then that problem goes away. > - Note, I haven't looked at the new semaphore stuff yet. > > Will get back to this later, but could use review so far. In particular > I'd like to know if we'll keep or kill multi-pool support. Thus far we've only had to worry about a single pool. If anyone can come up with a reason to need multiple pools, I guess we need to hear it. Given the lack of scheduling control, I don't see how it would be of any benefit. At the same time, I don't see a compelling reason to perturb the code at the moment. -- -- 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 10 May '07

10 May '07

OK, I've fixed some of it in HEAD. See comments in the commits for tpool.c 1.63 and outwards. RE23 has the same problems. Nearly identical code sans the new semaphore stuff and a few variable names, so fixes should be easy to import when they've been tested a bit. Remaining problems: tpool.c breaks if there are multiple pools. The simplest solution seems to be to remove support for multiple pools. The problem is thread_keys[]. It is shared between pools, but: - ldap_pvt_thread_pool_purgekey() needs _all_ pools to be paused, but ldap_pvt_thread_pool_pause() only pauses one pool. If we keep multi-pool support, maybe it only should destroy keys from the current pool? - ltp_max_count (max #threads) is pool-specific, but is used to protect from array bounds violation on thread_keys[LDAP_MAXTHR]. (New simple code from me, previously there was no limit.) - This '#if 0'ed comment is also wrong with multiple pools: /* start up one thread, just so there is one. no need to * lock the mutex right now, since no threads are running. */ Time to remove the whole #if 0? Other thread_keys[] strangeness: - setkey does not free the old data with ltk_free. Possibly that's intentional, but if so that requires weird code elsewhere. - maybe related to how getkey can return the ltk_free function - which seems crazy since a caller who uses it must then explicitly reset the key afterwards (or better, before), to be sure purgekey doesn't see the data and free it again. Other notes: - I've inserted new, possibly too aggressive, waits for ltp_pause in pool_wrapper. See the tpool.c 1.65 comment. Yet another alternative than splitting the ltp_pause state might be to remove the requirement that purgekey() can only be used by a paused thread. (Could loop until the key is _really_ gone instead, or something.) - tpool.c uses LDAP_FREE(), can call ldap_pvt_thread_pool_context(), which uses thread_keys[]. If one thread does that when another thread has paused the pool, that can break since thread_keys[] is reserved for ldap_pvt_thread_pool_purgekey() during pauses. Not sure if that can happen, haven't checked. If LDAP_MALLOC/LDAP_CALLOC also can do call pool_context(), we do have problem in pool_submit(). One fix is to use malloc/calloc/free instead. Another, in the case of LDAP_FREE(ctx) in pool_submit, is to put the ctx on the free list instead. - ltp_pending_count includes threads sleeping in pool_pause() - should it? In effect, pool_pause() temporarily reduces ltp_max_pending. - In ldap_pvt_thread_pool_submit(): This comment: /* there is another open thread, so this * context will be handled eventually. * continue on and signal that the context * is waiting. */ is wrong if the previous if (pool->ltp_open_count == 0) was taken but the no thread was found inside that. Also if ctx is invalid (another thread handled it) and a new pending request has gotten the now-unused ctx, then the 'if (pool->ltp_open_count == 0)' code will free that new pending request instead of the old one. One fix is to add an is_pending flag=1 in submit() and int *ltc_pendingp; in ldap_int_thread_ctx_t. In submit, if need_thread, set ltc_pendingp = &is_pending. In if(pool->ltp_open_count == 0) check is_pending instead of searching for ctx. Elsewhere set *ltc_pendingp = 0 and/or ltc_pendingp = NULL when appropriate. - Note, I haven't looked at the new semaphore stuff yet. Will get back to this later, but could use review so far. In particular I'd like to know if we'll keep or kill multi-pool support. -- Regards, Hallvard

1 0

(ITS#4952) null CSN due to CSN length mismatch in updateCookie
by donn＠u.washington.edu 09 May '07

09 May '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) syncrepl_updateCookie finds CSN values in syncCookie and si->si_cookieState. Numerically, the syncCookie CSN is lesser, but it compares greater because it's longer: syncCookie->ctxcsn: 20070508130333Z#000000#00#000000 si->si_cookieState->cs_vals[0]: 20070507215402.502403Z#000000#000#000000 Eventually slap_queue_csn() gets a null CSN, and slapd aborts. I am pretty sure the former explains the latter. The only thing that doesn't fit is that gdb reports "j" == 20936000, where I expect 0, but I think everything else adds up - numcsns is 1, cs_num is 1, the two sids are the same (0). Evidently this format difference is entryCSN vs. contextCSN. The unusual order may be due to entries modified in the master with explicit entryCSN values. I guess that's not supported, but it seems to have exposed a bug here - I assume you want a comparison between dates, not format lengths. To reproduce (I'm guessing): modify master directory with explicit entryCSN values that are later than its contextCSN.

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

Actually, tpool.c is quite buggy. I'm fixing some of them, and will summarize the rest later. -- Regards, Hallvard

1 0

Re: (ITS#4948) #if/#elif argument in .../include/ac/time.h
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

I wrote: > That said, it's indeed a reasonable cleanup. I'll do that and some > others shortly. Fixed in the cvs HEAD version. There are a few cases left though - in particular, do anyone know if #if DOS/MACOS/HAVE_WINSOCK can be replaced with #ifdef? I'm not touching them without word from someone who knows OpenLDAP on these platforms. Besides, I still don't know if the "issues" you refer to are just compiler warnings, or errors - or if the one macro you reported was a special case. So while allowing -Wundef to catch macro typos is worthwhile, I likely won't do anything more unless I hear a reason to. And I'd like to know what Plan 9 C says about this program: > BTW, will 9 C accept this (when you do not define FOO/BAR)? What > error/warning messages, if any? > > #if defined(FOO) && FOO /* Guard #if FOO with defined(FOO) */ > int main() { return 2; } > #elif BAR > int main() { return 1; } > #else > int main() { return 0; } > #endif -- Regards, Hallvard

1 0

Re: (ITS#4937) chain overlay bugs with Statslog & ldbm/ldif databases
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

hyc(a)symas.com writes: > This seems to be a known limitation, see the FIXME in slapd/compare.c, > near SLAP_COMPARE_IN_FRONTEND. At least, that explains the problem > for back-ldif, which does not provide its own compare entry point. Looks like a bug to me, and that the correct fix is be to delete that code and let the current back-ldif return an error. Maybe it could be split out to a separate function which backends can set be_compare to if they have a be_attribute(), or something like that? > As for back-ldbm, there is a missing referral_rewrite call in > back-ldbm/referral.c. I don't consider it worthwhile to fix back-ldbm, > but you're welcome to fix it if you wish. I might, though actually I'm more concerned with failed tests than fixing ldbm at the moment:-) Will look later. However: > Just have a look at back-bdb/referral.c for the correct code. There is no correct code as yet, note the bogus logging I mentioned. -- Regards, Hallvard

1 0

(ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu 09 May '07

09 May '07

Full_Name: Aaron Richton Version: HEAD OS: irrelevant URL: https://www.nbcs.rutgers.edu/~richton/richton-20070508-radius.patch Submission from: (NULL) (68.196.250.105) Please find at this address a patch against the RADIUS contrib module. This patch addresses two issues: * libradius makes use of MT-Unsafe calls, so a protecting mutex is added. * config_filename could be passed to rad_config without initialization (when accepting the default). I, Aaron Richton, hereby place these modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by ahasenack＠terra.com.br 08 May '07

08 May '07

On Tue, May 08, 2007 at 08:42:24PM +0200, Pierangelo Masarati wrote: > ahasenack(a)terra.com.br wrote: > > > The monitor backend attributes and object classes, when loaded, should also be > > exported in the subschema entries at the server. > > > > I know of one ldap client that breaks because of this: luma. It says it can't > > display the cn=monitor entries because it doesn't know the object classes or > > attributes. I guess it uses this info to determine how to show each entry. > > The schema is not exposed since it's considered experimental. To expose > it, you need to #define LDAP_DEVEL. It doesn't see a good idea for me to define LDAP_DEVEL just to get this schema published: probably many other things in openldap would change.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by ando＠sys-net.it 08 May '07

08 May '07

ahasenack(a)terra.com.br wrote: > The monitor backend attributes and object classes, when loaded, should also be > exported in the subschema entries at the server. > > I know of one ldap client that breaks because of this: luma. It says it can't > display the cn=monitor entries because it doesn't know the object classes or > attributes. I guess it uses this info to determine how to show each entry. The schema is not exposed since it's considered experimental. To expose it, you need to #define LDAP_DEVEL. 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#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by erici＠motown.cc.utexas.edu 07 May '07

07 May '07

On Fri, 4 May 2007, hyc(a)symas.com wrote: >> Either the conversion should put all of the loglevel masks in the same >> olcLogLevel value or cn=config should AND all of the olcLogLevel values. > > You mean OR of course, not AND. Yes, sorry. OR, +, mask, that's what I mean. It must have been Friday. -- Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342

1 0

Re: (ITS#4950) error LDAP Server
by quanah＠zimbra.com 07 May '07

07 May '07

--On Monday, May 07, 2007 11:03 AM +0000 thuanpvm(a)blitzgrp.com wrote: > Full_Name: Phan Van Minh Thuan > Version: 2.3.35 > OS: Linux Enterprise 4.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (58.186.92.53) > > > Dear Sirs, > > When I submit ldapadd -x -D "cn=Manager, dc=blitzcie,dc=dyndns,dc=org" -W > -f /usr/local/etc/openldap/schema/initial.ldif, the error display: > Enter LDAP password: > ldap_bin: Can't contact LDAP server (-1) > > Looking forward to hearing from you soon The ITS system is for submitting bugs about the software. You appear to be having a configuration/usage problem. Please subscribe to openldap-software(a)openldap.org and describe the problems you are having there. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4950) error LDAP Server
by thuanpvm＠blitzgrp.com 07 May '07

07 May '07

Full_Name: Phan Van Minh Thuan Version: 2.3.35 OS: Linux Enterprise 4.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (58.186.92.53) Dear Sirs, When I submit ldapadd -x -D "cn=Manager, dc=blitzcie,dc=dyndns,dc=org" -W -f /usr/local/etc/openldap/schema/initial.ldif, the error display: Enter LDAP password: ldap_bin: Can't contact LDAP server (-1) Looking forward to hearing from you soon Many Thanks. Thuan

1 0

Re: (ITS#4933) syncrepl unlimited timeout vs. .ldaprc
by hyc＠symas.com 05 May '07

05 May '07

donn(a)u.washington.edu wrote: > 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) > > > Appears to me that unless timelimit value passed to ldap_search_ext() is > positive, the ld_timelimit from .ldaprc overrides, so there's no way for > syncrepl ldap_sync_search() to literally specify "unlimited". > > To duplicate: configure syncrepl timelimit=unlimited; edit /.ldaprc -> > "TIMELIMIT 23"; start replica slapd with a sufficiently large replication > backlog; observe timeout at 23 seconds. > > To kludge: use extravagantly large value instead: if (si->si_tlimit > 0) > timeout.tv_sec = si->tlimit; else timeout.tv_sec = 31536000; > > and pass &timeout unconditionally. Hmmm. I guess this is a consequence of changing the timeout representation in the LDAP handle. I suppose we can just make the syncrepl consumer do an explicit ldap_set_option() on its session handles to override any .ldaprc setting. Will have to play with this a bit to see how we can maintain backward compatibility. -- -- 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#4948) #if/#elif argument in .../include/ac/time.h
by h.b.furuseth＠usit.uio.no 05 May '07

05 May '07

lucio(a)proxima.alt.za writes: > Whether the existing format is legitimate or not is a matter for the C > standards, but I believe that the alternative would be both clearer > and more portable. It's legitimate. In #if/#elif statements, an undefined macro (without arguments) has the value 0 in a correct compiler. That said, it's indeed a reasonable cleanup. I'll do that and some others shortly. Allows us to compile with 'gcc -Wundef' without too much noise too. I'll tests I'm not sure about alone (in particular Windows stuff), in case it's supposed to be OK to compile with '-D<macro name>=0' so a change from #if to #ifdef would change OpenLDAP's behavior. Maybe someone else can have a look at that. > The Plan 9 C pre-processor has a definite issue with it and it seems a > reasonable change to implement. There may be other places where a > similar change would be beneficial, I'll identify them as I > encountered and will provide a comprehensive list on demand. Please be specific: Give the exact error/warning message, and make clear whether it _is_ a warning or an error. BTW, will 9 C accept this (when you do not define FOO/BAR)? What error/warning messages, if any? #if defined(FOO) && FOO /* Guard #if FOO with defined(FOO) */ int main() { return 2; } #elif BAR int main() { return 1; } #else int main() { return 0; } #endif -- Regards, Hallvard

1 0

Re: (ITS#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by hyc＠symas.com 05 May '07

05 May '07

erici(a)motown.cc.utexas.edu wrote: > Full_Name: Eric Irrgang > Version: 2.3.35 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.83.93.52) > > > When a slapd.conf file is converted to cn=config with -f and -F the loglevel > parameter gets converted into multiple olcLogLevel=keyword attribute/value > pairs. However, only the last one in the configuration seems to apply. > Manually updating > dn: cn=config > changetype: modify > replace: olcLogLevel > olcLogLevel: keyword1 keyword2 ... > - > > gets the intended logging behavior. > > Either the conversion should put all of the loglevel masks in the same > olcLogLevel value or cn=config should AND all of the olcLogLevel values. You mean OR of course, not AND. Yes, the code only does ORs correctly when multiple levels are set at once. Oops. -- -- 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#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by erici＠motown.cc.utexas.edu 04 May '07

04 May '07

Full_Name: Eric Irrgang Version: 2.3.35 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.93.52) When a slapd.conf file is converted to cn=config with -f and -F the loglevel parameter gets converted into multiple olcLogLevel=keyword attribute/value pairs. However, only the last one in the configuration seems to apply. Manually updating dn: cn=config changetype: modify replace: olcLogLevel olcLogLevel: keyword1 keyword2 ... - gets the intended logging behavior. Either the conversion should put all of the loglevel masks in the same olcLogLevel value or cn=config should AND all of the olcLogLevel values.

1 0

(ITS#4948) #if/#elif argument in .../include/ac/time.h
by lucio＠proxima.alt.za 04 May '07

04 May '07

Full_Name: Lucio De Re Version: 2.3.35 and earlier OS: Plan 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.255.250) The arguments on lines 20 and 23 (#if and #elif, respectively) in .../include/ac/time.h ought to be surrounded with "defined()". Whether the existing format is legitimate or not is a matter for the C standards, but I believe that the alternative would be both clearer and more portable. The Plan 9 C pre-processor has a definite issue with it and it seems a reasonable change to implement. There may be other places where a similar change would be beneficial, I'll identify them as I encountered and will provide a comprehensive list on demand. Naturally, there are many other issues applicable specific to porting OpenLDAP to Plan 9, but these seem trivial enough to warrant addressing in a broader context.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by quanah＠zimbra.com 04 May '07

04 May '07

--On Friday, May 04, 2007 2:39 PM +0000 ahasenack(a)terra.com.br wrote: > Full_Name: Andreas Hasenack > Version: 2.3.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.140.247.99) > > > (enhancement, or minor) > > The monitor backend attributes and object classes, when loaded, should > also be exported in the subschema entries at the server. > > I know of one ldap client that breaks because of this: luma. It says it > can't display the cn=monitor entries because it doesn't know the object > classes or attributes. I guess it uses this info to determine how to show > each entry. Not disagreeing, but making the assumption that cn=subschema is readable is also a broken behavior on the luma side. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4947) monitor schema should appear under subschema entry
by ahasenack＠terra.com.br 04 May '07

04 May '07

Full_Name: Andreas Hasenack Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.99) (enhancement, or minor) The monitor backend attributes and object classes, when loaded, should also be exported in the subschema entries at the server. I know of one ldap client that breaks because of this: luma. It says it can't display the cn=monitor entries because it doesn't know the object classes or attributes. I guess it uses this info to determine how to show each entry.

1 0

Re: (ITS#4830) test030-relay fails with back-meta
by ghenry＠suretecsystems.com 04 May '07

04 May '07

<quote who="hyc(a)symas.com"> > ahasenack(a)terra.com.br wrote: >> On Fri, Feb 02, 2007 at 04:03:43PM +0000, ahasenack(a)terra.com.br wrote: >>> ==> rewrite_context_apply [depth=1] string='(objectClass=*)' >>> ==> rewrite_context_apply [depth=1] res={0,'NULL'} >>> [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" >>> /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: >>> symbol lookup error: >>> +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: >>> ldap_back_proxy_authz_ctrl >> >> Howard debugged this on IRC and it turns out that our (mine and >> _ranger_'s) libunixodbc has lt_dl* symbols in it. Relinking slapd >> without the unixodbc lib fixes it. > > Yes, so there are two potential issues - the unixodbc shared library seems > to > be statically linked with an older version of libltdl. I didn't run into > this > problem on my build because I don't have that odbc library. Anyway, due to > the link order of the libraries, the lt_dlopen in this library gets used > before the linker resolves to the system's libltdl.so, and it seems that > this > version of lt_dlopen doesn't automatically export the symbols of modules > that > it loads. > > I'm guessing the reason this is a problem in 2.3.33 and not in 2.3.32 is > because there is a new dependency in 2.3.33 between back-meta and > back-ldap. > > The other part of this is that the slapd binary should not be getting > linked > against -lodbc when back_sql is built as a module. > > Although, if back-sql is built statically, and other backends are dynamic, > this problem may still crop up. It seems that fixing -lodbc would be > required > then. I've hit this same problem tonight (no sql though): ./scripts/test030-relay: line 78: kill: (7779) - No such process >>>>> ./scripts/test030-relay failed (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/home/suretec/src/openldap-2.3.35/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/suretec/src/openldap-2.3.35/tests' make: *** [test] Error 2 slapd.1.log: /home/suretec/src/openldap-2.3.35/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: ldap_back_proxy_authz_ctrl Config options were: env CC=/usr/local/bin/gcc CPPFLAGS="-I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/include/sasl" \ LDFLAGS="-L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/local/lib/sasl2" \ LIBS="-ldl" \ LD_LIBRARY_PATH="/usr/local/ssl/lib /usr/local/BerkeleyDB.4.2/lib /usr/local/lib/sasl2" ./configure \ --prefix=/usr/local --enable-slapd --enable-syslog \ --enable-dynamic --enable-rewrite --disable-sql --disable-ipv6 --disable-shell \ --with-threads --enable-modules --enable-backends=mod \ --enable-overlays=mod --with-tls --enable-wrappers On Debian Sarge 3.1 with custom compiled: openssl-0.9.8e cyrus-sasl-2.1.22 db-4.2.52 heimdal-0.8.1 I can't get past it. Any debug advice? Thanks. -- 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

(ITS#4945) slapd drops connections during search results
by mhardin＠symas.com 03 May '07

03 May '07

Full_Name: Matthew Hardin Version: 2.3.35 OS: Windows 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.215.67.85) If Winsock returns EWOULDBLOCK while sending search results to a client, slapd will stop sending results and close the connection. The problem is in openldap/servers/slapd/result.c at line 173, where it incorrectly checks errno. It should be checking sock_errno(). I note that HEAD already does this.

1 0

Re: (ITS#4944) 2.3.35 and openssl-0.9.8e
by hyc＠symas.com 03 May '07

03 May '07

Looks like your OpenSSL library depends on -ldl. That's an OpenSSL build problem, not OpenLDAP. Can probably get around it by adding -ldl to LIBS on the configure invocation. This ITS will be closed. ghenry(a)suretecsystems.com wrote: > <quote who="Howard Chu"> >> It works for me. Check your config.log to see why it didn't link. > > Here's the main probs: > > configure:19501: /usr/local/bin/gcc -E -I/usr/local/ssl/include > -I/usr/local/BerkeleyDB.4.2/include conftest.c > configure:19507: $? = 0 > configure:19527: result: yes > configure:19562: checking for openssl/ssl.h > configure:19569: result: yes > configure:19584: checking for SSL_library_init in -lssl > configure:19614: /usr/local/bin/gcc -o conftest -g -O2 > -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include > -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl > -lcrypto -lresolv >&5 > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2ae): In function > `dlfcn_bind_func': > : undefined reference to `dlsym' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x333): In function > `dlfcn_bind_func': > : undefined reference to `dlerror' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x3ae): In function > `dlfcn_bind_var': > : undefined reference to `dlsym' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x431): In function > `dlfcn_bind_var': > : undefined reference to `dlerror' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x497): In function > `dlfcn_unload': > : undefined reference to `dlclose' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x557): In function > `dlfcn_load': > : undefined reference to `dlopen' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5b5): In function > `dlfcn_load': > : undefined reference to `dlclose' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5ec): In function > `dlfcn_load': > : undefined reference to `dlerror' > collect2: ld returned 1 exit status > configure:19620: $? = 1 > configure: failed program was: > | /* confdefs.h. * > > | char SSL_library_init (); > | int > | main () > | { > | SSL_library_init (); > | ; > | return 0; > | } > configure:19646: result: no > configure:19657: checking for ssl3_accept in -lssl > configure:19687: /usr/local/bin/gcc -o conftest -g -O2 > -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include > -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl > -lcrypto -lRSAglue -lrsaref -lresolv >&5 > /usr/bin/ld: cannot find -lRSAglue > collect2: ld returned 1 exit status > configure:19693: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > > > Like I said, this didn't happen in 0.9.7, will check my built options with > 0.9.8 > > Gavin. > > > -- -- 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#4944) 2.3.35 and openssl-0.9.8e
by ghenry＠suretecsystems.com 03 May '07

03 May '07

<quote who="Howard Chu"> > It works for me. Check your config.log to see why it didn't link. Here's the main probs: configure:19501: /usr/local/bin/gcc -E -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include conftest.c configure:19507: $? = 0 configure:19527: result: yes configure:19562: checking for openssl/ssl.h configure:19569: result: yes configure:19584: checking for SSL_library_init in -lssl configure:19614: /usr/local/bin/gcc -o conftest -g -O2 -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl -lcrypto -lresolv >&5 /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2ae): In function `dlfcn_bind_func': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x333): In function `dlfcn_bind_func': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x3ae): In function `dlfcn_bind_var': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x431): In function `dlfcn_bind_var': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x497): In function `dlfcn_unload': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x557): In function `dlfcn_load': : undefined reference to `dlopen' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5b5): In function `dlfcn_load': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5ec): In function `dlfcn_load': : undefined reference to `dlerror' collect2: ld returned 1 exit status configure:19620: $? = 1 configure: failed program was: | /* confdefs.h. * | char SSL_library_init (); | int | main () | { | SSL_library_init (); | ; | return 0; | } configure:19646: result: no configure:19657: checking for ssl3_accept in -lssl configure:19687: /usr/local/bin/gcc -o conftest -g -O2 -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl -lcrypto -lRSAglue -lrsaref -lresolv >&5 /usr/bin/ld: cannot find -lRSAglue collect2: ld returned 1 exit status configure:19693: $? = 1 configure: failed program was: | /* confdefs.h. */ Like I said, this didn't happen in 0.9.7, will check my built options with 0.9.8 Gavin.

1 0

Re: (ITS#4944) 2.3.35 and openssl-0.9.8e
by hyc＠symas.com 03 May '07

03 May '07

It works for me. Check your config.log to see why it didn't link. ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.35 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Dear All, > > Just a heads up to say I couldn't get 2.3.35 to compile with openssl 0.9.8e, > only latest 0.9.7m: > > env CC=gcc CPPFLAGS="-I/usr/local/ssl/include" \ > LDFLAGS="-L/usr/local/ssl/lib" \ > LD_LIBRARY_PATH="/usr/local/ssl/lib" ./configure \ > --prefix=/usr/local --enable-slapd --enable-syslog --with-cyrus-sasl=yes \ > --enable-dynamic --enable-rewrite --disable-ipv6 --disable-shell \ > --disable-sql --with-threads --enable-modules --enable-backends=mod \ > --enable-overlays=mod --with-tls --enable-wrappers > > checking openssl/ssl.h usability... yes > checking openssl/ssl.h presence... yes > checking for openssl/ssl.h... yes > checking for SSL_library_init in -lssl... no > checking for ssl3_accept in -lssl... no > checking OpenSSL library version (CRL checking capability)... yes > configure: error: Could not locate TLS/SSL package > > > You probably already know ;-) > > Gavin. > > > . > -- -- 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#4944) 2.3.35 and openssl-0.9.8e
by ghenry＠suretecsystems.com 03 May '07

03 May '07

Full_Name: Gavin Henry Version: 2.3.35 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, Just a heads up to say I couldn't get 2.3.35 to compile with openssl 0.9.8e, only latest 0.9.7m: env CC=gcc CPPFLAGS="-I/usr/local/ssl/include" \ LDFLAGS="-L/usr/local/ssl/lib" \ LD_LIBRARY_PATH="/usr/local/ssl/lib" ./configure \ --prefix=/usr/local --enable-slapd --enable-syslog --with-cyrus-sasl=yes \ --enable-dynamic --enable-rewrite --disable-ipv6 --disable-shell \ --disable-sql --with-threads --enable-modules --enable-backends=mod \ --enable-overlays=mod --with-tls --enable-wrappers checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_library_init in -lssl... no checking for ssl3_accept in -lssl... no checking OpenSSL library version (CRL checking capability)... yes configure: error: Could not locate TLS/SSL package You probably already know ;-) Gavin.

1 0

RE: (ITS#4934) Port change
by Babu.Suresh＠pacificlife.com 02 May '07

02 May '07

Thank you..this was resolved after I implemented ACL in slapd.conf. _babu -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Wednesday, May 02, 2007 9:20 AM To: Suresh, Babu; openldap-its(a)openldap.org Subject: Re: (ITS#4934) Port change --On April 21, 2007 12:03:23 AM +0000 babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.8.254) > > > My openldap was running on default port 389 and imported all schema & > data. Now I would like to change the port to different..would be > 4000/5000. OpenLDAP process started successfully with non default port > but I am getting "error 32 no such object" when try to browse the data > using soferra. > > is it possible to change the port anytime? Yes. It sounds like perhaps softerra has a bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration ------------------------------------------------------------------------------ The information in this e-mail and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. If you believe that you have received this e-mail in error, please contact the sender immediately and delete the e-mail and all of its attachments. ==============================================================================

1 0

Re: (ITS#4934) Port change
by quanah＠zimbra.com 02 May '07

02 May '07

--On April 21, 2007 12:03:23 AM +0000 babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.8.254) > > > My openldap was running on default port 389 and imported all schema & > data. Now I would like to change the port to different..would be > 4000/5000. OpenLDAP process started successfully with non default port > but I am getting "error 32 no such object" when try to browse the data > using soferra. > > is it possible to change the port anytime? Yes. It sounds like perhaps softerra has a bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4930) slaptest should be quiet on success
by quanah＠zimbra.com 02 May '07

02 May '07

--On April 18, 2007 9:42:20 AM +0000 jsafranek(a)redhat.com wrote: > Full_Name: Jan Safranek > Version: 2.3.35 > OS: Linux (Fedora 6) > URL: > Submission from: (NULL) (62.40.79.66) > > > The 'slaptest' tool is a bit verbose, it sends 'config file testing > succeeded' to stderr. IMHO it should do not output anything, especially > to stderr, if everything is all right. > > Here is a small patch, causing the slaptest to display the aforementioned > message only if -v switch is used: > > Index: servers/slapd/slaptest.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/slaptest.c,v > retrieving revision 1.9 > diff -r1.9 slaptest.c > 107c107,108 > < fprintf( stderr, "config file testing succeeded\n"); > --- >> if (verbose) >> fprintf( stderr, "config file testing succeeded\n"); The point of slaptest is to tell users whether or not things are okay. Having slaptest exit with nothing displayed somewhat defeats that purpose... --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 02 May '07

02 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard As far as I can tell from tpool.c, ldap_pvt_thread_pool_destroy() will act prematurely if another thread pauses: ldap_pvt_thread_pool_destroy (...) { ... if ( pool->ltp_open_count ) { ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); ldap_pvt_thread_cond_wait(&pool->ltp_cond, &pool->ltp_mutex); } ... since ldap_pvt_thread_pool_resume() broadcasts on the same mutex. Also ldap_pvt_thread_pool_resume() will reset ltp_state to RUNNING instead of FINISHING/STOPPING. If that can happen, the fix would be: (a) use while() instead of if(), (b) keep an ltp_unpaused_state along with ltp_pause which is _pause does not change and _resume copies to ltp_state, or just remove LDAP_INT_THREAD_POOL_PAUSING in favor of an ltp_pausing flag. (And possibly some code which currently checks ltp_state ought to check ltp_unpaused_state instead, I'm not sure.) (c) if _destroy() can be called while LDAP_INT_THREAD_POOL_PAUSING, I think the other if()s around ltp_cond need to be while() too.

1 0

Re: (ITS#4942) configurable filter blocking
by hyc＠symas.com 01 May '07

01 May '07

quanah(a)zimbra.com wrote: > ----- "h b furuseth" <h.b.furuseth(a)usit.uio.no> wrote: >> quanah(a)OpenLDAP.org writes: >>> For example, I may want to block subfinal indices on the >>> "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree. >> I should have added: Unless you've got a better answer than me for >> why this is better than the "unchecked" limit, it might be more >> useful to block "suAffiliation" from getting a "subfinal" index. >> Then use the "unchecked" limit to block too general searches. > > Hi Hallvard, > > My reasoning comes from this: At my previous job we had a tree rooted at "dc=stanford,dc=edu". Controlling the indexing to allow/block certain types of searches has been very important, and the directory well tuned to that purpose. The following subtrees are what exist: cn=people, cn=accounts, and cn=organizations. cn=organizations is the newest subtree, and additional indexing had to be added on attributes that used to be indexed differently in the person tree. There is no desire to split the trees apart into their own databases, but indexing is per database (not per subtree). > > For example, displayName used to be indexed "eq" only. Now with organizations, we need to change the index to "eq,sub". So it would be nice to block substring filters of displayName in the cn=people tree, etc. > > --Quanah Should be simple enough to write an overlay that can be configured with a URI and filter types to block. Just return Unwilling to Perform for any matching patterns. Certainly not something that needs to be added to the core code. -- -- 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#4942) configurable filter blocking
by quanah＠zimbra.com 01 May '07

01 May '07

----- "h b furuseth" <h.b.furuseth(a)usit.uio.no> wrote: > quanah(a)OpenLDAP.org writes: > > For example, I may want to block subfinal indices on the > > "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree. > > I should have added: Unless you've got a better answer than me for > why this is better than the "unchecked" limit, it might be more > useful to block "suAffiliation" from getting a "subfinal" index. > Then use the "unchecked" limit to block too general searches. Hi Hallvard, My reasoning comes from this: At my previous job we had a tree rooted at "dc=stanford,dc=edu". Controlling the indexing to allow/block certain types of searches has been very important, and the directory well tuned to that purpose. The following subtrees are what exist: cn=people, cn=accounts, and cn=organizations. cn=organizations is the newest subtree, and additional indexing had to be added on attributes that used to be indexed differently in the person tree. There is no desire to split the trees apart into their own databases, but indexing is per database (not per subtree). For example, displayName used to be indexed "eq" only. Now with organizations, we need to change the index to "eq,sub". So it would be nice to block substring filters of displayName in the cn=people tree, etc. --Quanah

1 0

Re: (ITS#4942) configurable filter blocking
by h.b.furuseth＠usit.uio.no 30 Apr '07

30 Apr '07

quanah(a)OpenLDAP.org writes: > For example, I may want to block subfinal indices on the > "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree. I should have added: Unless you've got a better answer than me for why this is better than the "unchecked" limit, it might be more useful to block "suAffiliation" from getting a "subfinal" index. Then use the "unchecked" limit to block too general searches. -- Regards, Hallvard

1 0

Re: (ITS#4942) configurable filter blocking
by h.b.furuseth＠usit.uio.no 30 Apr '07

30 Apr '07

quanah(a)OpenLDAP.org writes: > In reading through the documentation for Fedora DS, I saw an > interesting feature where you can, at the slapd level, disable the > ability for clients to execute filters when the attribute(s) being > filtered on are not indexed. What's the motivation for this? I've thought about suggesting similar features (or maybe even suggested it, I don't remember) - but so far the "unchecked" limit has proved a better way for my purposes. How does it work with complex filters? E.g. (&(cn=foo)(mail=*)) where cn is indexed and finds the relevant entries, mail=* eliminates the 0.1% mailless users. Should this succeed if mail has no presence index? If no, what's the advantage of forbidding it? If yes, how do you stop (&(objectClass=person)(mail=*))? > This seems an interesting feature to me, but I think it could be > more worthwhile to make it a bit more configurable, (...) > For example, I may want to block subfinal indices on the > "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree. I can see an access control reason for doing that, though users might get trivially around it by appending a '*' to the filter. And I do use sizelimit and the "unchecked" limit as a crude form of access control, as well as to ensure a good response time. But it remains crude, since it's not what an index is for - it's basically just an optimization. -- Regards, Hallvard

1 0

Re: (ITS#4941) incorrect description of TLS_REQCERT setting
by guenther＠sendmail.com 30 Apr '07

30 Apr '07

On Mon, 30 Apr 2007, Howard Chu wrote: > guenther+ldapdev(a)sendmail.com wrote: ... >> - 'allow' checks the identity of the server vs its cert (per RFC 4513, >> section 3.1.3) and will terminate the connection if they don't match >> - 'try' is the same as 'demand' and 'hard' > > Not quite. With both "allow" and "try" it's OK if the server provides no > certificate. That's true of 'demand' and 'hard' as well. The only difference between 'try' and 'demand' in the code is that the latter passes SSL_CTX_set_verify() the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, but that flag has NO EFFECT on SSL clients. This is documented on the SSL_CTX_set_verify() manpage and confirmed by grepping the openssl source for it. If you don't believe me, I suggest you try configuring your server to accept the ADH suites (don't forget to set TLSDHParamFile to /dev/null) and give ldapsearch a whirl with LDAPTLS_REQCERT=hard LDAPTLS_CIPHER_SUITE=ADH-AES256-SHA in your environment. That's what I did. Philip Guenther

1 0

(ITS#4942) configurable filter blocking
by quanah＠OpenLDAP.org 30 Apr '07

30 Apr '07

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) In reading through the documentation for Fedora DS, I saw an interesting feature where you can, at the slapd level, disable the ability for clients to execute filters when the attribute(s) being filtered on are not indexed. This seems an interesting feature to me, but I think it could be more worthwhile to make it a bit more configurable, where you could block certain filter types from being used, regardless of whether or not they were indexed, and expanded to only pertain to particular subtrees. For example, I may want to block subfinal indices on the "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree. Just food for thought. --Quanah

1 0

Re: (ITS#4941) incorrect description of TLS_REQCERT setting
by hyc＠symas.com 30 Apr '07

30 Apr '07

guenther+ldapdev(a)sendmail.com wrote: > Full_Name: Philip Guenther > Version: 2.3.27 > OS: linux and solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.58.1.252) > > > The description of the TLS_REQCERT setting in the ldap.conf(5) manpage does not > match the actual operation of the code. In particular: > - clients don't 'request' server certs in TLS. They get one if the cipher > suite > uses them, otherwise they don't > - 'allow' checks the identity of the server vs its cert (per RFC 4513, > section 3.1.3) and will terminate the connection if they don't match > - 'try' is the same as 'demand' and 'hard' Not quite. With both "allow" and "try" it's OK if the server provides no certificate. The difference is, with "try", if a cert is provided, it must be valid. > > > Here's a possible patch to ldap.conf.5 to fix the above. A reference to the RFC > should perhaps be added to the text. I was also tempted to add a sentence to > the lead-in to clarify that the setting has no effect if the negotiated cipher > suite doesn't use certs, as a clarification of the "if any" in the existing > lead-in, but that's minor. Simply having an even slightly correct description > of 'allow' is the important thing. > > --- ldap.conf.5 26 Jan 2006 05:57:49 -0000 > +++ ldap.conf.5 30 Apr 2007 08:39:53 -0000 > @@ -249,22 +249,20 @@ > .RS > .TP > .B never > -The client will not request or check any server certificate. > +The client will not check the server certificate at all. > .TP > .B allow > -The server certificate is requested. If no certificate is provided, > -the session proceeds normally. If a bad certificate is provided, it will > -be ignored and the session proceeds normally. > -.TP > -.B try > -The server certificate is requested. If no certificate is provided, > -the session proceeds normally. If a bad certificate is provided, > +The client will only verify that name used to connect to the server > +matches one of the server certificate's subjectAltName or CN values. > +If no match is found, the session is immediately terminated. > +.TP > +.B try | demand | hard > +These keywords are equivalent. > +The client will verify the server certificate is valid and matches the > +name used to connect (as for 'allow'). > +If a bad or mismatched certificate is provided, > the session is immediately terminated. > -.TP > -.B demand | hard > -These keywords are equivalent. The server certificate is requested. If no > -certificate is provided, or a bad certificate is provided, the session > -is immediately terminated. This is the default setting. > +This is the default setting. > .RE > .TP > .B TLS_CRLCHECK <level> > > > -- -- 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#4941) incorrect description of TLS_REQCERT setting
by guenther+ldapdev＠sendmail.com 30 Apr '07

30 Apr '07

Full_Name: Philip Guenther Version: 2.3.27 OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.58.1.252) The description of the TLS_REQCERT setting in the ldap.conf(5) manpage does not match the actual operation of the code. In particular: - clients don't 'request' server certs in TLS. They get one if the cipher suite uses them, otherwise they don't - 'allow' checks the identity of the server vs its cert (per RFC 4513, section 3.1.3) and will terminate the connection if they don't match - 'try' is the same as 'demand' and 'hard' Here's a possible patch to ldap.conf.5 to fix the above. A reference to the RFC should perhaps be added to the text. I was also tempted to add a sentence to the lead-in to clarify that the setting has no effect if the negotiated cipher suite doesn't use certs, as a clarification of the "if any" in the existing lead-in, but that's minor. Simply having an even slightly correct description of 'allow' is the important thing. --- ldap.conf.5 26 Jan 2006 05:57:49 -0000 +++ ldap.conf.5 30 Apr 2007 08:39:53 -0000 @@ -249,22 +249,20 @@ .RS .TP .B never -The client will not request or check any server certificate. +The client will not check the server certificate at all. .TP .B allow -The server certificate is requested. If no certificate is provided, -the session proceeds normally. If a bad certificate is provided, it will -be ignored and the session proceeds normally. -.TP -.B try -The server certificate is requested. If no certificate is provided, -the session proceeds normally. If a bad certificate is provided, +The client will only verify that name used to connect to the server +matches one of the server certificate's subjectAltName or CN values. +If no match is found, the session is immediately terminated. +.TP +.B try | demand | hard +These keywords are equivalent. +The client will verify the server certificate is valid and matches the +name used to connect (as for 'allow'). +If a bad or mismatched certificate is provided, the session is immediately terminated. -.TP -.B demand | hard -These keywords are equivalent. The server certificate is requested. If no -certificate is provided, or a bad certificate is provided, the session -is immediately terminated. This is the default setting. +This is the default setting. .RE .TP .B TLS_CRLCHECK <level>

1 0

(ITS#4940) libldap doesn't wait for server's TLS close_notify
by guenther+ldapdev＠sendmail.com 30 Apr '07

30 Apr '07

Full_Name: Philip Guenther Version: 2.3.27 OS: Linux and Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.58.1.252) [I vaguely recall seeing a report of this issue in the archives of one of the mailing lists, but I can no longer find the original.] If you trace the packets sent when you use, for example, ldapsearch against a server on a different host, using either the -Z option to do TLS or using an ldaps URI, you'll discover that the TCP connection is actually reset instead of being closed cleanly: the client sends TCP RSTs in response to the server's final packets. This is because libldap uses the following sequence when unbind a TLS or SSL connection: 1) send the unbind request (over the TLS or SSL layer) 2) call SSL_shutdown(), sending the TLS close_notify alert 3) call close() After receiving the close_notify alert from step (2), the server sends back its own close_notify alert and then calls close(). However, because the client didn't wait for the server's response before calling close() on its end, the client's TCP stack considers the TCP connection to already be gone and responds with the RST packets. This occurs with Linux and Solaris clients and probably most other unices: the response to packets after a close() doesn't vary in my experience. There are a number of ways this can be handled: 1) change the client to wait until it sees the server's close_notify alert by replacing "SSL_shutdown( p->ssl );" in tls.c with the two lines: if (SSL_shutdown( p->ssl ) == 0) SSL_shutdown( p->ssl ); (I have confirmed that this works. As documented, the first call will return 1 if the server's close_notify has already been received, if not, the second call will block until it is received.) 2) change the client to not bother to send a close_notify alert when it's just going to close() the connection; change the server to not send a close_notify if it didn't get one. This probably violates the TLS spec, but the fact that TLS/1.1 permits resumption of sessions without close_notify having been sent indicates that the violation is not a major issue, particularly given that LDAP's unbind request prevents truncation attacks. Close_notifies are, of course, required if the client just wants to terminate the TLS layer and resume unprotected LDAP operations. 3) ignore the issue: it only causes one or two extra packets to be sent. While it also eliminates the TIME_WAIT state, LDAP's application-level close (the unbind request) means it doesn't need reliable full-duplex closure, so the only concern would be random connection issues from reincarnations of the TCP tuple, which is unlikely for an LDAP connection. Personally, I like the simplicity and cleanliness of solution (1).

1 0

(ITS#4939) Typographical error in client tool_common_usage()
by ceri＠submonkey.net 28 Apr '07

28 Apr '07

Full_Name: Ceri Davies Version: HEAD OS: FreeBSD URL: http://shrike.submonkey.net/~ceri/clients-tools-common.c.patch Submission from: (NULL) (81.106.128.65) The help output from the client tools contains a misspelling of "Identifier". See the patch at http://shrike.submonkey.net/~ceri/clients-tools-common.c.patch which applies against today's -HEAD. I seriously doubt that you need this, but: I, Ceri Davies, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#4938) hdb_db_close SEGVs
by quanah＠zimbra.com 26 Apr '07

26 Apr '07

----- quanah(a)zimbra.com wrote: > ----- richton(a)nbcs.rutgers.edu wrote: > > I don't have #5 (sleepycat#14657) nor the unofficial > > > http://www.stanford.edu/services/directory/openldap/configuration/patches/d… > > > > patch. As for the official one, I'm not sure about its relevance to > > the > > actual SEGV due to the "recovery...fail" comment. In other words, > > though > > it may be impacting the ability of alock/db_recover to do its thing, > > > that's just a side effect of the unclean shutdown which is the real > > bug > > here to my view. > > > > > Patch #5 specifically deals with a race condition where a checkpoint > is occuring while a cache buffer retrieval is also occuring causing a > database corruption that will later not be recoverable from. At > least, that's how I read sleepcat's description: > > 5. Fix a bug where cache buffer retrieval could race with a checkpoint > call, potentially causing database environment recovery to fail. > [#14657] > > Given that OpenLDAP checkpoints on shutdown, shutting down the server > could be what is triggering the issue for you. I'd suggest applying > the patch and seeing if this resolves your problem. Just to note, I shut down one of my 2.3.35 servers that's served out over 1 million connections since I brought it up, and everything was clean on both shutdown and startup. --Quanah

1 0

Re: (ITS#4938) hdb_db_close SEGVs
by quanah＠zimbra.com 26 Apr '07

26 Apr '07

----- richton(a)nbcs.rutgers.edu wrote: > I don't have #5 (sleepycat#14657) nor the unofficial > http://www.stanford.edu/services/directory/openldap/configuration/patches/d… > > patch. As for the official one, I'm not sure about its relevance to > the > actual SEGV due to the "recovery...fail" comment. In other words, > though > it may be impacting the ability of alock/db_recover to do its thing, > that's just a side effect of the unclean shutdown which is the real > bug > here to my view. Patch #5 specifically deals with a race condition where a checkpoint is occuring while a cache buffer retrieval is also occuring causing a database corruption that will later not be recoverable from. At least, that's how I read sleepcat's description: 5. Fix a bug where cache buffer retrieval could race with a checkpoint call, potentially causing database environment recovery to fail. [#14657] Given that OpenLDAP checkpoints on shutdown, shutting down the server could be what is triggering the issue for you. I'd suggest applying the patch and seeing if this resolves your problem. > The region size patch is interesting, but I will tell you that the > database in question has > > set_cachesize 0 200000000 0 > > and it (to a glance) looks like that only impacts the gig column, > which I > have as zero anyway. Yeah, the patch may not apply for you (I have a 3.5GB cache, so it does for me). Wouldn't harm anything, of course, if you decided later you needed a larger BDB cache. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4938) hdb_db_close SEGVs
by richton＠nbcs.rutgers.edu 26 Apr '07

26 Apr '07

I don't have #5 (sleepycat#14657) nor the unofficial http://www.stanford.edu/services/directory/openldap/configuration/patches/d… patch. As for the official one, I'm not sure about its relevance to the actual SEGV due to the "recovery...fail" comment. In other words, though it may be impacting the ability of alock/db_recover to do its thing, that's just a side effect of the unclean shutdown which is the real bug here to my view. The region size patch is interesting, but I will tell you that the database in question has set_cachesize 0 200000000 0 and it (to a glance) looks like that only impacts the gig column, which I have as zero anyway. I can tell you that stop/starts weren't an issue with 2.3.32 and the same Sleepycat binaries...not that I stop/start often as a rule of thumb. (I am lately; we're implementing ando's {RADIUS} module.) But two identical traces on two different boxes caught my eye. On Thu, 26 Apr 2007, Quanah Gibson-Mount wrote: > > ----- richton(a)nbcs.rutgers.edu wrote: >> Full_Name: Aaron RIchton >> Version: 2.3.35 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.6.30.206) >> >> >> BDB 4.2.52. I've had a couple (different) machines SEGV on slapd >> shutdown. Both >> had identical stack traces: > > Wierd, I've been running hdb on my servers for nearly a year without such an issue. Did this just start with 2.3.35? > > Also, what patches do you have applied to BDB 4.2.52. I'm up to 6 now. > > <http://www.stanford.edu/services/directory/openldap/configuration/bdb-build…> > > 5 are direct from sleepycat: > > <http://www.oracle.com/technology/products/berkeley-db/db/update/4.2.52/patc…> > > with the last one there possibly impacting you if you don't have it? > > --Quanah > > -- > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

1 0

Re: (ITS#4938) hdb_db_close SEGVs
by quanah＠zimbra.com 26 Apr '07

26 Apr '07

----- richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron RIchton > Version: 2.3.35 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.30.206) > > > BDB 4.2.52. I've had a couple (different) machines SEGV on slapd > shutdown. Both > had identical stack traces: Wierd, I've been running hdb on my servers for nearly a year without such an issue. Did this just start with 2.3.35? Also, what patches do you have applied to BDB 4.2.52. I'm up to 6 now. <http://www.stanford.edu/services/directory/openldap/configuration/bdb-build…> 5 are direct from sleepycat: <http://www.oracle.com/technology/products/berkeley-db/db/update/4.2.52/patc…> with the last one there possibly impacting you if you don't have it? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs