- openldap-bugs - openldap.org

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 30 Apr '07

30 Apr '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

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

26 Apr '07

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: current thread: t@1 =>[1] __dbreg_revoke_id(dbp = 0xa498818, have_lock = 0, force_id = -1), line 427 in "dbreg.c" [2] __dbreg_close_files(dbenv = 0x405320), line 206 in "dbreg_util.c" [3] __log_dbenv_refresh(dbenv = 0x405320), line 744 in "log.c" [4] __dbenv_refresh(dbenv = 0x405320, orig_flags = 0, rep_check = 0), line 648 in "env_open.c" [5] __dbenv_close(dbenv = 0x405320, rep_check = 0), line 579 in "env_open.c" [6] __dbenv_close_pp(dbenv = 0x405320, flags = 0), line 534 in "env_open.c" [7] hdb_db_close(be = 0x367340), line 517 in "init.c" [8] backend_shutdown(be = 0x367340), line 351 in "backend.c" [9] slap_shutdown(be = (nil)), line 279 in "init.c" [10] main(argc = 4, argv = 0xffbffd6c), line 870 in "main.c" No idea if this is Sleepycat or slapd, but it dirties the database in a way that automatic nor command-line db_recover appreciate: Ignoring log file: log.0000000007: magic number 0, not 40988 Invalid log file: log.0000000007: Invalid argument PANIC: Invalid argument PANIC: DB_RUNRECOVERY: Fatal error, run database recovery hdb_db_open: Database cannot be recovered, err -30978. Restore from backup! DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem txn_checkpoint interface requires an environment configured for the transaction subsystem bdb_db_close: txn_checkpoint failed: Invalid argument (22) backend_startup_one: bi_db_open failed! (-30978)

1 0

Re: (ITS#4937) chain overlay bugs with Statslog & ldbm/ldif databases
by hyc＠symas.com 25 Apr '07

25 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23 > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > overlay chain breaks with databases ldbm and ldif: > > ./run -b {ldbm or ldif} test032-chain outputs: > ... > Starting second slapd on TCP/IP port 9012... > ... > Comparing "cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com" > on port 9012... > ldapcompare failed (10)! > > ldapcompare output in testrun/test.out: > Compare Result: Referral (10) > Matched DN: ou=People,dc=example,dc=com > Referral: ldap://localhost:9011/ou=People,dc=example,dc=com > UNDEFINED > > testrun/slapd.1.log says the Compare was sent to the chained server, but > with baseDN=<Matched DN above>: > ... > do_compare: dn (ou=People,dc=example,dc=com) attr (cn) value (mark elliot) > conn=5 op=2 CMP dn="ou=People,dc=example,dc=com" attr="cn" > ... > conn=5 op=2 RESULT tag=111 err=16 text= > ... > > Slapcat says the Matched DN entry is correct (same as in a BDB run): > dn: ou=People,dc=example,dc=com > objectClass: referral > objectClass: extensibleObject > ou: People > ref: ldap://localhost:9011/ou=People,dc=example,dc=com > structuralObjectClass: referral > > > Also the Statslog output is wrong for all three databases: > > With LDBM and LDIF, the CMP operation is not logged, only its result: > grep '^conn=4' testrun/slapd.2.log # the ldapcompare operation above > conn=4 fd=14 ACCEPT from IP=127.0.0.1:45280 (IP=127.0.0.1:9012) > conn=4 op=0 BIND dn="" method=128 > conn=4 op=0 RESULT tag=97 err=0 text= > conn=4 op=1 RESULT tag=111 err=10 text= > conn=4 op=2 UNBIND > conn=4 fd=14 closed > > With BDB, the CMP operation is not logged, but both the returned > result and the suppressed referral result is logged: > conn=4 fd=12 ACCEPT from IP=127.0.0.1:42190 (IP=127.0.0.1:9012) > conn=4 op=0 BIND dn="" method=128 > conn=4 op=0 RESULT tag=97 err=0 text= > conn=4 op=1 RESULT tag=111 err=6 text= > conn=4 op=1 RESULT tag=111 err=10 text= > conn=4 op=2 UNBIND > conn=4 fd=12 closed > > > I haven't tried other databases, but since two different databases > had the same bug and same wrong Statlog, I'm guessing others do too. 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. 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. Just have a look at back-bdb/referral.c for the correct 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

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

25 Apr '07

Full_Name: Hallvard B Furuseth Version: RE23 OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard overlay chain breaks with databases ldbm and ldif: ./run -b {ldbm or ldif} test032-chain outputs: ... Starting second slapd on TCP/IP port 9012... ... Comparing "cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com" on port 9012... ldapcompare failed (10)! ldapcompare output in testrun/test.out: Compare Result: Referral (10) Matched DN: ou=People,dc=example,dc=com Referral: ldap://localhost:9011/ou=People,dc=example,dc=com UNDEFINED testrun/slapd.1.log says the Compare was sent to the chained server, but with baseDN=<Matched DN above>: ... do_compare: dn (ou=People,dc=example,dc=com) attr (cn) value (mark elliot) conn=5 op=2 CMP dn="ou=People,dc=example,dc=com" attr="cn" ... conn=5 op=2 RESULT tag=111 err=16 text= ... Slapcat says the Matched DN entry is correct (same as in a BDB run): dn: ou=People,dc=example,dc=com objectClass: referral objectClass: extensibleObject ou: People ref: ldap://localhost:9011/ou=People,dc=example,dc=com structuralObjectClass: referral Also the Statslog output is wrong for all three databases: With LDBM and LDIF, the CMP operation is not logged, only its result: grep '^conn=4' testrun/slapd.2.log # the ldapcompare operation above conn=4 fd=14 ACCEPT from IP=127.0.0.1:45280 (IP=127.0.0.1:9012) conn=4 op=0 BIND dn="" method=128 conn=4 op=0 RESULT tag=97 err=0 text= conn=4 op=1 RESULT tag=111 err=10 text= conn=4 op=2 UNBIND conn=4 fd=14 closed With BDB, the CMP operation is not logged, but both the returned result and the suppressed referral result is logged: conn=4 fd=12 ACCEPT from IP=127.0.0.1:42190 (IP=127.0.0.1:9012) conn=4 op=0 BIND dn="" method=128 conn=4 op=0 RESULT tag=97 err=0 text= conn=4 op=1 RESULT tag=111 err=6 text= conn=4 op=1 RESULT tag=111 err=10 text= conn=4 op=2 UNBIND conn=4 fd=12 closed I haven't tried other databases, but since two different databases had the same bug and same wrong Statlog, I'm guessing others do too.

1 0

Re: (ITS#4936) default modulepath
by ahasenack＠terra.com.br 23 Apr '07

23 Apr '07

On Mon, Apr 23, 2007 at 09:17:26PM +0000, abartlet(a)samba.org wrote: > It would be very useful if OpenLDAP would provide a default value for > modulepath. > > This would ensure that on systems with multiple openldap installs (such as test > rigs) that we do not need to specify the *correct* modulepath, when starting the > config with different slapd binaries. > > Similarly, it would avoid the need to guess which modulepath is correct for a > given system, such as when we find slapd in the path (as Samba4's test mode > does), but needs to automatically enable modules. Another scenario is with some tool providing a config file for slapd. It wouldn't have to guess the host arch whether it's i386 or x86_64 and set the correct module_path (/usr/lib/openldap vs /usr/lib64/openldap).

1 0

(ITS#4936) default modulepath
by abartlet＠samba.org 23 Apr '07

23 Apr '07

Full_Name: Andrew Bartlett Version: devel OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.70.73.150) It would be very useful if OpenLDAP would provide a default value for modulepath. This would ensure that on systems with multiple openldap installs (such as test rigs) that we do not need to specify the *correct* modulepath, when starting the config with different slapd binaries. Similarly, it would avoid the need to guess which modulepath is correct for a given system, such as when we find slapd in the path (as Samba4's test mode does), but needs to automatically enable modules. (Discussed with Howard Chu)

1 0

Re: (ITS#4935) SASL_MAX_BUFF_SIZE is too small
by lukeh＠novell.com 23 Apr '07

23 Apr '07

--=__PartDCFBBB68.0__= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Confirmed fix works. — Luke --=__PartDCFBBB68.0__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"> <META content=3D"MSHTML 6.00.5346.5" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma"> <DIV>Confirmed fix works.</DIV> <DIV> </DIV> <DIV>=E2=80=94 Luke<BR></DIV></BODY></HTML> --=__PartDCFBBB68.0__=--

1 0

(ITS#4935) SASL_MAX_BUFF_SIZE is too small
by lukeh＠novell.com 23 Apr '07

23 Apr '07

Full_Name: Luke Howard Version: 2.3.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (125.16.129.17) SASL_MAX_BUFF_SIZE is too small for SASL mechanisms, such as GSS-SPNEGO, that use a buffer size unconstrained by the 64K limit defined for some mechanisms in RFC 2222. A more reasonable default would 0xFFFFFF (2^24), used as the maximum buffer size by many of the mechanisms shipped with Cyrus itself.

1 0

(ITS#4934) Port change
by babu.suresh＠pacificlife.com 20 Apr '07

20 Apr '07

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? thank you

1 0

(ITS#4933) syncrepl unlimited timeout vs. .ldaprc
by donn＠u.washington.edu 20 Apr '07

20 Apr '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) 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.

1 0

Re: (ITS#4922)
by ando＠sys-net.it 19 Apr '07

19 Apr '07

Juri Tanganelli wrote: > After further debugging i found the following behaviour: > > The entry has the uid attribute correctly initialized: uid S287384. Then it should have a corresponding normalized value "s287384" (note the lowercase "s") in the a_nvals array of bervals of the Attribute strycture where it's stored. If it doesn't (e.g. because the attribute was created incorrectly by your custom backend) then the behavior you see makes perfectly sense, and is not indicative of a software bug in OpenLDAP software. p. > If the uid starts with a capital letter then using these two filters: > > (uid=S287384) or (uid=s287384) doesn't return any result. > > If the uid attribute starts with a lower case letter ( i.e. uid=s287384 > ) then both filters work and return the entry. > The definition of the uid attribute is embodied in openldap source code > and from what i have seen it should be treated as a case insensitive > attribute. How to explain this behaviour?? 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#4932) Core dump caused in ldap_extended_operation()
by h.b.furuseth＠usit.uio.no 19 Apr '07

19 Apr '07

rguerrero(a)datamirror.com writes: > ldap_extended_operation(ld = (nil), reqoid = "1.3.6.1.4.1.1466.20037", reqdata = (nil), sctrls = (nil), cctrls = ??, msgidp = 0x2ff18cd4), line 62 in "extended.c" > ldap_start_tls(ld = ??, serverctrls = ??, clientctrls = ??, msgidp = ??), line 1859 in "tls.c" > do_start_tls(session = 0xf027b7f0), line 1343 in "ldap-nss.c" Looks like an ldap-nss.c problem to me, not an OpenLDAP problem. An uninitialized (or destroyed but not zeroed) LDAP*, perhaps? Look at the value of *session, in particular session->ls_conn, in the do_start_tls() frame. -- Regards, Hallvard

1 0

(ITS#4922)
by juritanganelli＠gmail.com 19 Apr '07

19 Apr '07

------=_Part_125517_21113365.1176969864256 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline After further debugging i found the following behaviour: The entry has the uid attribute correctly initialized: uid S287384. If the uid starts with a capital letter then using these two filters: (uid=S287384) or (uid=s287384) doesn't return any result. If the uid attribute starts with a lower case letter ( i.e. uid=s287384 ) then both filters work and return the entry. The definition of the uid attribute is embodied in openldap source code and from what i have seen it should be treated as a case insensitive attribute. How to explain this behaviour?? Best Regards, Juri. ------=_Part_125517_21113365.1176969864256 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div>After further debugging i found the following behaviour:</div> <div> </div> <div>The entry has the uid attribute correctly initialized: uid S287384.</div> <div> </div> <div>If the uid starts with a capital letter then using these two filters:</div> <div> </div> <div>(uid=S287384) or (uid=s287384) doesn't return any result.</div> <div> </div> <div>If the uid attribute starts with a lower case letter ( i.e. uid=s287384 ) then both filters work and return the entry.</div> <div>The definition of the uid attribute is embodied in openldap source code and from what i have seen it should be treated as a case insensitive attribute. How to explain this behaviour??</div> <div> </div> <div>Best Regards,</div> <div>Juri.</div> ------=_Part_125517_21113365.1176969864256--

1 0

(ITS#4932) Core dump caused in ldap_extended_operation()
by rguerrero＠datamirror.com 18 Apr '07

18 Apr '07

Full_Name: Ron Guerrero Version: 2.3.27 OS: AIX 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.201.167.139) We've got an application that indirectly calls OpenLDAP APIs. One function in particular is causing our process to core dump. The stack trace generated by dbx is as follows: 0xd0128470 (pthread_kill+0x88) 80410014 lwz r2,0x14(r1) pthread_kill(??, ??) at 0xd0128470 _p_raise(??) at 0xd0127f08 raise.raise(??) at 0xd0315740 abort.abort() at 0xd0344cb0 __assert_c99(??, ??, ??, ??) at 0xd03aede0 ldap_extended_operation(ld = (nil), reqoid = "1.3.6.1.4.1.1466.20037", reqdata = (nil), sctrls = (nil), cctrls = ??, msgidp = 0x2ff18cd4), line 62 in "extended.c" ldap_start_tls(ld = ??, serverctrls = ??, clientctrls = ??, msgidp = ??), line 1859 in "tls.c" do_start_tls(session = 0xf027b7f0), line 1343 in "ldap-nss.c" unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" _nss_ldap_search_s(args = 0x2ff196c8, filterprot = "(&(objectClass=posixAccount)(uidNumber=%d))", sel = LM_PASSWD, user_attrs = (nil), sizelimit = 1, res = 0x2ff19658), line 3047 in "ldap-nss.c" _nss_ldap_getbyname(args = 0x2ff196c8, result = 0x20131698, buffer = "", buflen = 1024, errnop = 0x2ff22ff8, filterprot = "(&(objectClass=posixAccount)(uidNumber=%d))", sel = LM_PASSWD, parser = 0xf027b97c), line 3394 in "ldap-nss.c" ldap-pwd.pw_byuid(this = ??, uid = ??), line 55 in "irs-pwd.c" _nss_ldap_getpwuid(uid = 138056), line 181 in "aix_authmeth.c" _getpwuid_shadow_r(??, ??, ??, ??, ??) at 0xd03d0900 _posix_getpwuid_shadow_r(??, ??, ??, ??, ??, ??) at 0xd03d02cc sniq.getpwuid_r(??, ??, ??, ??, ??) at 0xd249170c snigun(??, ??, ??) at 0xd2491648 nigconcbs(??, ??, ??) at 0xd28cc858 osncon(0x0, 0x0, 0x1803, 0x201090ec, 0x20105bec, 0x20105be4, 0x20105b70, 0x20105c20) at 0xd28cce6c kpuadef(??, ??, ??, ??, ??, ??, ??, ??) at 0xd1d0d1b4 upiini(0x0, 0x0, 0x0, 0x0, 0x200eda80, 0x200edca0, 0x200edef4, 0x2010fe40) at 0xd20f24d4 upiah0(??, ??, ??, ??, ??, ??, ??) at 0xd20efce4 kpuatch(??, ??, ??, ??, ??, ??, ??) at 0xd1d378fc OCIServerAttach(??, ??, ??, ??, ??) at 0xd20fbfb0 As you can see application makes a call to an Oracle API. Has anyone seen this issue before? Notice in ldap_start_tls() the first parameter, the ldap handle, is non-null. However, in ldap_extended_operation(), the ldap handle is null. Looking at the code, ldap_start_tls() is calling ldap_extended_operation() with the same ldap handle that was passed to it. The latest source files for extended.c and tls.c have not changed since the 2.3.27 release.

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 18 Apr '07

18 Apr '07

This seems really to be an PPC specific kernel (or glibc) issue. I think I was able to create an isolated testcase to reproduce that problem outside of the OpenLDAP libraries. I'll now bug our kernel guys with it. But removing the assert(0) from request.c was still the right thing as Hallvard already mentioned in his first reply. -- Ralf

1 0

Re: (ITS#4931) To integrate Open LDAP with Jetspeed2
by quanah＠stanford.edu 18 Apr '07

18 Apr '07

--On Wednesday, April 18, 2007 1:57 PM +0000 vaibhav(a)omnimessaging.com wrote: > Full_Name: > Version: openldap-2.2.13-2 > OS: redhat linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (210.211.142.177) > > > How to use OPENLDAP with jetspeed2 ? > > please guide me. > Also please let me know how to check if ldap is working with jetspeed. > > I installed LDAP with BDB also can see all entires in LDAP -Browser. > Bis issue is how to use LDAP with Jetspeed2 for auth. Hello, The OpenLDAP ITS system is for reporting bugs, not for asking usage questions. If you have questions specific to the OpenLDAP software, please use the "openldap-software(a)openldap.org" mailing list. On a side note, you may need to contact RedHat for support if you run into issues with the openldap release you are using, as it is significantly out of date. Regards, Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4931) To integrate Open LDAP with Jetspeed2
by vaibhav＠omnimessaging.com 18 Apr '07

18 Apr '07

Full_Name: Version: openldap-2.2.13-2 OS: redhat linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.211.142.177) How to use OPENLDAP with jetspeed2 ? please guide me. Also please let me know how to check if ldap is working with jetspeed. I installed LDAP with BDB also can see all entires in LDAP -Browser. Bis issue is how to use LDAP with Jetspeed2 for auth. regards VAibhav KAle

1 0

(ITS#4930) slaptest should be quiet on success
by jsafranek＠redhat.com 18 Apr '07

18 Apr '07

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");

1 0

(ITS#4929) Contriware Tool to create backsql metadata and tables
by takyin＠hotmail.com 17 Apr '07

17 Apr '07

Full_Name: Paul Version: 2..3.34 OS: FC6 URL: ftp://ftp.openldap.org/incoming/paul-070417.tar.gz Submission from: (NULL) (219.79.33.240) Dear Sir/Madam, I am interested to contribute my work on a tool that help backsql to work with MYSQL 5.0. It will create all tables, functions and metadata in sql command that can fit into MYSQL ver 5.0 ============================================= Some brief information about the tool ============================================= It is a php program with web interface, user can select which schema they want and create the resultant sql command. It should work with openldap 2.3.34 . Yours Paul

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by quanah＠stanford.edu 16 Apr '07

16 Apr '07

--On Monday, April 16, 2007 6:31 PM +0000 ryan(a)stat.Berkeley.EDU wrote: > On Fri, Apr 13, 2007 at 11:29:39PM +0200, Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >> > 3) if you can reproduce this issue with an unstripped set of OpenLDAP >> > libraries that would make the backtrace more useful. >> >> ...which I think you build with >> env ac_cv_prog_STRIP=":" ./configure ... > > I tried ac_cv_proj_STRIP as well as STRIP, but the Makefiles were still > prepared with "STRIP = -s" which then leads to "install -s". I found this: > > http://www.openldap.org/lists/openldap-bugs/200604/msg00123.html > > I edited build/top.mk and removed the '-s' from STRIP and the configure > stage prepared Makefiles with "STRIP = ". You can always just run: make install STRIP="" or rather than hacking the makefiles. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by ryan＠stat.Berkeley.EDU 16 Apr '07

16 Apr '07

On Fri, Apr 13, 2007 at 11:29:39PM +0200, Hallvard B Furuseth wrote: > hyc(a)symas.com writes: > > 3) if you can reproduce this issue with an unstripped set of OpenLDAP > > libraries that would make the backtrace more useful. > > ...which I think you build with > env ac_cv_prog_STRIP=":" ./configure ... I tried ac_cv_proj_STRIP as well as STRIP, but the Makefiles were still prepared with "STRIP = -s" which then leads to "install -s". I found this: http://www.openldap.org/lists/openldap-bugs/200604/msg00123.html I edited build/top.mk and removed the '-s' from STRIP and the configure stage prepared Makefiles with "STRIP = ". But the original issue has been resolved due to a local build issue. Thanks! Ryan

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by ryan＠stat.Berkeley.EDU 16 Apr '07

16 Apr '07

On Fri, Apr 13, 2007 at 02:10:19PM -0700, Howard Chu wrote: > >cups 1.2.10 invokes pam_authenticate which on my system goes through ldap. > >When > >cups tries to authenticate it is dumping core. The backtrace seems to show > >that > >it is crashing within the OpenLDAP code. I'm using the PADL libraries, not > >the > >native Solaris libraries. > > A few things: > 1) This is most likely going to be an nss_ldap issue. > 2) please provide the output for "info shared" in gdb. > 3) if you can reproduce this issue with an unstripped set of OpenLDAP > libraries that would make the backtrace more useful. Thanks for your feedback. Your second tip, running "info shared", showed that cups was linking against 2 different LDAP libraries, the one I intended and the one in /opt/SFW/. Once I fixed the build everything worked just fine. This issue can be closed. Ryan

1 0

Problème with SASL/DIGEST-MD5 authentication
by Abdelmjid HALLOUM 16 Apr '07

16 Apr '07

hi, i am a beginer with OpenLDAP, i installed it in my mchine ubuntu 6 but when i the problem is : root # ldapadd ............................) SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database anyhelp?

2 1

Re: (ITS#4928) LDAP Error 0x34=LDAP_UNAVAILABLE
by hyc＠symas.com 16 Apr '07

16 Apr '07

imtiazpk82(a)gmail.com wrote: > Full_Name: Imtiaz Khadim > Version: 3 > OS: Window server 2000 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.38.48.230) > > > Hi, > > I am using Sun Iplanet Directory Server 5.2 That's your first problem. Nothing in this report has anything to do with OpenLDAP Software. I suggest you contact Sun for assistance, or upgrade from the Sun server to a current OpenLDAP release. This ITS will be closed. > and LDAP Version 3.0 to fetch > records. The Problem currently i am facing is as follow > > I have made three conection to Iplanet Directory with same authentication level. > Each connection apply diferent filter and fetch records. > First rule fetch 15000 records. > and 2nd and third fetch 700 record each and this schedule is to be run on every > day. > First time it fetch records correctly but when on next day it ran again 2nd and > third filter run correctly but when first filter is applied the API > ldap_search_s() return error code 0x34. Why this happen? the other two are > working fine and these three connections are part of one application. Can any > one help me out please. > > reagrds > Imtiaz Khadim > > > . > -- -- 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#4928) LDAP Error 0x34=LDAP_UNAVAILABLE
by imtiazpk82＠gmail.com 16 Apr '07

16 Apr '07

Full_Name: Imtiaz Khadim Version: 3 OS: Window server 2000 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.38.48.230) Hi, I am using Sun Iplanet Directory Server 5.2 and LDAP Version 3.0 to fetch records. The Problem currently i am facing is as follow I have made three conection to Iplanet Directory with same authentication level. Each connection apply diferent filter and fetch records. First rule fetch 15000 records. and 2nd and third fetch 700 record each and this schedule is to be run on every day. First time it fetch records correctly but when on next day it ran again 2nd and third filter run correctly but when first filter is applied the API ldap_search_s() return error code 0x34. Why this happen? the other two are working fine and these three connections are part of one application. Can any one help me out please. reagrds Imtiaz Khadim

1 0

Re: (ITS#4922) test_filter problem on uid filter
by ando＠sys-net.it 16 Apr '07

16 Apr '07

Please post replies to the ITS system. Juri Tanganelli wrote: > The entry e497004 is a candidate for sure My point is: it's clear that if you filter for (uid=e497004) the corresponding entry must be selected as candidate. But does it actually get selected, and does test_filter() get applied to it? I understand it's obvious, but the typical bug with things that have always worked is that one believes they don't work while the point is that they don't get used as one expects. You should check this. > : a filter on a different > attribute > of the same entry returns the correct result. I can provide you with any > information you need for an analysis of the problem (stack trace, variable > dumps, etc...). > What kind of information do you want me to produce? Well, you should check that when searching for (uid=e497004) test_filter() gets invoked and the entry passed to it contains the attribute "uid" with the value "e497004". To do this, you should run slapd within a debugger, set a breakpoint at test_filter() and, as soon as the function is entered, check the contents of e->e_attrs down the list until you find the "uid" attribute. If the attribute is there with the requested value, and it is searchable (ACL), test_filter() must succeed (return LDAP_COMPARE_TRUE). So you need to check: - the presence of "uid" - the presence of the desired value - the access privileges of the identity that runs the request It might be that test_filter() returns LDAP_COMPARE_TRUE but the result is handled incorrectly by your custom backend, or by the frontend based on the way the result is passed back to it. By stepping through the whole operation you should be able to detect what goes wrong. If you find out that the error is in test_filter(), we'll be happy of fixing it, of course. 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#4927) pam_authenticate through ldap causes cups to crash
by hyc＠symas.com 13 Apr '07

13 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >> 3) if you can reproduce this issue with an unstripped set of OpenLDAP >> libraries that would make the backtrace more useful. > > ...which I think you build with > env ac_cv_prog_STRIP=":" ./configure ... > No need to rerun configure. Just "make install STRIP=" -- -- 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#4927) pam_authenticate through ldap causes cups to crash
by h.b.furuseth＠usit.uio.no 13 Apr '07

13 Apr '07

hyc(a)symas.com writes: > 3) if you can reproduce this issue with an unstripped set of OpenLDAP > libraries that would make the backtrace more useful. ...which I think you build with env ac_cv_prog_STRIP=":" ./configure ... -- Regards, Hallvard

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by hyc＠symas.com 13 Apr '07

13 Apr '07

ryan(a)stat.berkeley.edu wrote: > Full_Name: Ryan Lovett > Version: 2.3.32 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.32.135.6) > > > cups 1.2.10 invokes pam_authenticate which on my system goes through ldap. When > cups tries to authenticate it is dumping core. The backtrace seems to show that > it is crashing within the OpenLDAP code. I'm using the PADL libraries, not the > native Solaris libraries. A few things: 1) This is most likely going to be an nss_ldap issue. 2) please provide the output for "info shared" in gdb. 3) if you can reproduce this issue with an unstripped set of OpenLDAP libraries that would make the backtrace more useful. -- -- 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#4927) pam_authenticate through ldap causes cups to crash
by ryan＠stat.berkeley.edu 13 Apr '07

13 Apr '07

Full_Name: Ryan Lovett Version: 2.3.32 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.32.135.6) cups 1.2.10 invokes pam_authenticate which on my system goes through ldap. When cups tries to authenticate it is dumping core. The backtrace seems to show that it is crashing within the OpenLDAP code. I'm using the PADL libraries, not the native Solaris libraries. #0 0xfe50ddf0 in ldap_abandoned () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 (gdb) bt #0 0xfe50ddf0 in ldap_abandoned () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 #1 0xfe50b354 in chkResponseList () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 #2 0xfe50b230 in ldap_result () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 #3 0xfe5d40f0 in do_bind (ld=0x1272d8, timelimit=30, dn=0xfe5f4a65 "uid=ldapadmin,cn=users,dc=our,dc=ldap,dc=domain", pw=0xfe5f4b7c "PaSsWoRD", with_sasl=1) at ldap-nss.c:1792 #4 0xfe5d49b8 in do_with_reconnect ( base=0xfe5f4acc "cn=users,dc=our,dc=ldap,dc=domain", scope=1, filter=0xffbefa60 "(&(objectClass=shadowAccount)(uid=op))", attrs=0xfe5f57dc, sizelimit=1, private=0xffbf02e0, search_func=0xfe5d4ef0 <do_search_s>) at ldap-nss.c:1620 #5 0xfe5d7a00 in _nss_ldap_search_s (args=0xffbf0368, filterprot=0xfe5fa2a0 "(&(objectClass=shadowAccount)(uid=%s))", sel=LM_SHADOW, user_attrs=0x0, sizelimit=1, res=0xffbf02e0) at ldap-nss.c:3047 #6 0xfe5d7b84 in _nss_ldap_getbyname (args=0xffbf0368, result=0x128430, buffer=0x12c0e0 "nobody4", buflen=1024, errnop=0xffbf0484, filterprot=0xfe5fa2a0 "(&(objectClass=shadowAccount)(uid=%s))", sel=LM_SHADOW, parser=0xfe5db86c <_nss_ldap_parse_sp>) at ldap-nss.c:3394 #7 0xfe5dbb88 in _nss_ldap_getspnam_r (be=0x3, args=0xffbf0460) at ldap-spwd.c:136 #8 0xfeddbbfc in nss_search () from /lib/libc.so.1 #9 0xfedcad80 in getspnam_r () from /lib/libc.so.1 #10 0xfeba9630 in nss_getpwnam () from /usr/lib/passwdutil.so.1 #11 0xfeba9778 in nss_getattr () from /usr/lib/passwdutil.so.1 #12 0xfeba2e90 in __get_authtoken_attr () from /usr/lib/passwdutil.so.1 #13 0xfebd0cf0 in pam_sm_authenticate () from /usr/lib/security/pam_authtok_get.so.1 #14 0xff2d2c88 in run_stack () from /lib/libpam.so.1 #15 0xff2d2f2c in pam_authenticate () from /lib/libpam.so.1 #16 0x00018b70 in cupsdAuthorize (con=0x140fe8) at auth.c:513 #17 0x0001eb98 in cupsdReadClient (con=0x140fe8) at client.c:1033 #18 0x0002dd04 in main (argc=476808, argv=0x461fc665) at main.c:934

1 0

Re: (ITS#4926) german special characters ( Umlaute ) in Password
by h.b.furuseth＠usit.uio.no 13 Apr '07

13 Apr '07

2.1.22 is very old. See if it helps to upgrade. OpenLDAP has had bugs with 8-bit characters, though admittedly I don't see how those would affect passwords. Have you checked that the bug is not in your C program's input routine? Print out the password before passing it to OpenLDAP. -- Regards, Hallvard

1 0

(ITS#4926) german special characters ( Umlaute ) in Password
by m.birkenkamp＠e-fact-gmbh.de 13 Apr '07

13 Apr '07

Full_Name: Marcel Birkenkamp Version: 2.1.22 OS: HP-UX 11.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.63.14.237) hi, i have a problem submitting passwords containing german special characters (Umlaute ä,ü,ö & ß) by using the OpenLDAP Function ldap_simple_bind_s to our Active Directory Server. After investigating the issue it seems as if the password is cut off at the position of the special char, since it is possible to log in a user with his password (without special characters) if i use the correct password and add one of these characters to the end. Example: password for user: test submitted: testö this would succeed the problem is if a user i.e. enters the password: bäume the submitted password is: b Is there a fix/workaround for this? btw: i'm using this in a c program. Thanks in advance.

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 13 Apr '07

13 Apr '07

On Friday 13 April 2007 01:11, Pierangelo Masarati wrote: > You should print the contents of "res", which contains the offending > response message type. (gdb) frame 3 #3 0x0ffb459c in ldap_new_connection (ld=0x10016128, srvlist=0x10020278, use_ldsb=0, connect=1, bind=0xff9b4624) at request.c:465 465 assert( 0 ); (gdb) print *res $5 = {lm_msgid = 530, lm_msgtype = 96, lm_ber = 0x10020238, lm_chain = 0x0, lm_chain_tail = 0x10021458, lm_next = 0x0, lm_time = 0} (gdb) print *res->lm_ber $6 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 96, ber_len = 13, ber_usertag = 0, ber_buf = 0x10021368 "\002\002\002\022`\a\002\001\003\004", ber_ptr = 0x1002136c "`\a\002\001\003\004", ber_end = 0x10021375 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

rhafer(a)suse.de wrote: > #3 0x0ffb459c in ldap_new_connection (ld=0x10016128, srvlist=0x10020278, use_ldsb=0, connect=1, bind=0xff9b4624) at request.c:465 > tv = {tv_sec = 0, tv_usec = 100000} > res = (LDAPMessage *) 0x10021458 > msgid = 530 > rc = 0 > passwd = {bv_len = 0, bv_val = 0x0} > err = 1 > savedefconn = (LDAPConn *) 0x10016098 > lc = (LDAPConn *) 0x10016310 > srv = (LDAPURLDesc *) 0x10020278 > __PRETTY_FUNCTION__ = "ldap_new_connection" You should print the contents of "res", which contains the offending response message type. 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#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

Hallvard suggested that a backtrace might help. This is what I was able to get: (gdb) bt full #0 0x0fb4fce0 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x0fb51620 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x0fb478dc in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0x0ffb459c in ldap_new_connection (ld=0x10016128, srvlist=0x10020278, use_ldsb=0, connect=1, bind=0xff9b4624) at request.c:465 tv = {tv_sec = 0, tv_usec = 100000} res = (LDAPMessage *) 0x10021458 msgid = 530 rc = 0 passwd = {bv_len = 0, bv_val = 0x0} err = 1 savedefconn = (LDAPConn *) 0x10016098 lc = (LDAPConn *) 0x10016310 srv = (LDAPURLDesc *) 0x10020278 __PRETTY_FUNCTION__ = "ldap_new_connection" #4 0x0ffb3c44 in ldap_send_server_request (ld=0x10016128, ber=0x10020338, msgid=529, parentreq=0x100163e0, srvlist=0x10020278, lc=0x0, bind=0xff9b4624) at request.c:206 lr = (LDAPRequest *) 0xffb6cb8 incparent = 1 rc = -6601376 #5 0x0ffb5d34 in ldap_chase_v3referrals (ld=0x10016128, lr=0x100163e0, refs=0x0, sref=1, errstrp=0x100163fc, hadrefp=0xff9b46f4) at request.c:1013 unfollowed = 0x0 unfollowedcnt = 0 origreq = (LDAPRequest *) 0x100163e0 srv = (LDAPURLDesc *) 0x10020278 ber = (BerElement *) 0x10020338 refarray = (char **) 0x10016218 lc = (LDAPConn *) 0x0 rc = 0 count = 0 i = 0 j = 267910176 id = 529 rinfo = {ri_msgid = 528, ri_request = 99, ri_url = 0x100201f0 "ldap://localhost:9016/cn=Somewhere,ou=Meta,dc=example,dc=com??sub"} #6 0x0ff970e0 in try_read1msg (ld=0x10016128, msgid=528, all=1, lcp=0xff9b47e0, result=0xff9b48bc) at result.c:560 tmpber = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 0, ber_len = 73, ber_usertag = 0, ber_buf = 0x100201a0 "\002\002\002\020sC\004Aldap://localhost:9016/cn=Somewhere,ou=Meta,dc=example,dc=com??sub", ber_ptr = 0x100201e9 "", ber_end = 0x100201e9 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} refs = (char **) 0x10016218 ber = (BerElement *) 0x10020170 newmsg = (LDAPMessage *) 0x100162f0 l = (LDAPMessage *) 0x0 prev = (LDAPMessage *) 0x0 id = 528 tag = 115 len = 67 foundit = 0 lr = (LDAPRequest *) 0x100163e0 tmplr = (LDAPRequest *) 0x0 lc = (LDAPConn *) 0x10016098 tmpber = {ber_opts = {lbo_valid = 4095, lbo_options = 26992, lbo_debug = -6601008}, ber_tag = 4288366336, ber_len = 268140648, ber_usertag = 0, ber_buf = 0xffffffff <Address 0xffffffff out of bounds>, ber_ptr = 0x100170b8 "", ber_end = 0x3 <Address 0x3 out of bounds>, ber_sos = 0x10016128, ber_rwptr = 0x10016238 "", ber_memctx = 0xff9b4730} rc = -2 refer_cnt = 0 hadref = 0 simple_request = 0 lderr = 268396596 tmp = (LDAPMessage *) 0x0 chain_head = (LDAPMessage *) 0x0 moremsgs = 0 isv2 = 0 v3ref = V3REF_TOAPP __PRETTY_FUNCTION__ = "try_read1msg" #7 0x0ff96994 in wait4msg (ld=0x10016128, msgid=528, all=1, timeout=0x0, result=0xff9b48bc) at result.c:344 lc_ready = 0 rc = -2 tv = {tv_sec = 0, tv_usec = 0} tv0 = {tv_sec = 0, tv_usec = 0} tvp = (struct timeval *) 0x0 start_time = 0 tmp_time = -6600704 lc = (LDAPConn *) 0x10016098 __PRETTY_FUNCTION__ = "wait4msg" #8 0x0ff9612c in ldap_result (ld=0x10016128, msgid=528, all=1, timeout=0x0, result=0xff9b48bc) at result.c:124 lm = (LDAPMessage *) 0x0 rc = 268567256 __PRETTY_FUNCTION__ = "ldap_result" #9 0x0ff9a860 in ldap_search_s (ld=0x10016128, base=0x10016048 "o=Example,c=US", scope=2, filter=0x10016060 "cn=Barbara Jensen", attrs=0xff9b48ac, attrsonly=0, res=0xff9b48bc) at search.c:379 msgid = 528 #10 0x100020a0 in do_search (uri=0x0, host=0x10016008 "localhost", port=9013, manager=0x10016018 "cn=Manager,o=Example,c=US", passwd=0x10016038 "secret", sbase=0x10016048 "o=Example,c=US", filter=0x10016060 "cn=Barbara Jensen", maxloop=500, maxretries=20, delay=0) at slapd-search.c:201 ld = (LDAP *) 0x10016128 i = 263 do_retry = 20 attrs = {0x10003dfc "%d).\n", 0x10003e00 "\n", 0x0} pid = 13557 rc = 0 #11 0x10001eac in do_search (uri=0x0, host=0x0, port=19, manager=0xff9b4bd4 "�\233N��\233O\b�\233O\v�\233O\025�\233O\030�\233O\035�\233O �\233O:�\233O=�\233OD�\233OG�\233OJ�\233OM�\233OP�\233OS�\233OU�\233OX�\233Og�\233Oj", passwd=0x22 <Address 0x22 out of bounds>, sbase=0xff9b4bd4 "�\233N��\233O\b�\233O\v�\233O\025�\233O\030�\233O\035�\233O �\233O:�\233O=�\233OD�\233OG�\233OJ�\233OM�\233OP�\233OS�\233OU�\233OX�\233Og�\233Oj", filter=0xff9b4950 "�\233K\200\017�\217`�", maxloop=-134155200, maxretries=-134154560, delay=-134154568) at slapd-search.c:156 ld = (LDAP *) 0x10016038 i = 268525640 do_retry = 268525664 attrs = {0x10016018 "cn=Manager,o=Example,c=US", 0x10016008 "localhost", 0x0} pid = 0 rc = 20 #12 0x0fb38f60 in generic_start_main () from /lib/libc.so.6 No symbol table info available. #13 0x0fb3918c in __libc_start_main () from /lib/libc.so.6 No symbol table info available. #14 0x00000000 in ?? () No symbol table info available. -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

Ralf Haferkamp wrote: > It's not back-ldap that's trying to chase referrals here. It's slapd-search > (from the tester binaries), but if I see it corretcly that has referral > chasing turned of as well. At least it is not started with the -C option, > which should enable referral chasing. That's indeed puzzling. OK, I completely screwed the thing. slapd-search doesn't do anything about referrals, so it sticks with the default of libldap (on); also, it seems to have no -C flag. I'll fix this in a moment. This leaves the open point of ldap_result() returning what appears to be LDAP_REQ_BIND instead of a LDAP_RES_* in response to ... LDAP_REQ_BIND itself. Still digging... 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#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

On Thursday 12 April 2007 17:39, Pierangelo Masarati wrote: > Ralf Haferkamp wrote: > > On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > >> Another comment: would it be possible to check if the problem was > >> already present in earlier versions? > > > > I checked back to 2.3.27 and the problem as present there as well. I was > > however not yet able to reproduce the issue on another architecture, I've > > been running test039 for a few hours on an Intel x86_64 box without any > > problem. > > So this problem might as well be locate in some other part of the system > > (kernel, glibc, ...). What do you think? > > What puzzles me is that referral chasing should be disabled in that > test. In fact, slapd.3.conf contains "chase-referrals no" for both > instances of back-ldap. It's not back-ldap that's trying to chase referrals here. It's slapd-search (from the tester binaries), but if I see it corretcly that has referral chasing turned of as well. At least it is not started with the -C option, which should enable referral chasing. That's indeed puzzling. -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

Ralf Haferkamp wrote: > On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > >> Another comment: would it be possible to check if the problem was >> already present in earlier versions? > I checked back to 2.3.27 and the problem as present there as well. I was > however not yet able to reproduce the issue on another architecture, I've > been running test039 for a few hours on an Intel x86_64 box without any > problem. > So this problem might as well be locate in some other part of the system > (kernel, glibc, ...). What do you think? > What puzzles me is that referral chasing should be disabled in that test. In fact, slapd.3.conf contains "chase-referrals no" for both instances of back-ldap. 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#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > Another comment: would it be possible to check if the problem was > already present in earlier versions? I checked back to 2.3.27 and the problem as present there as well. I was however not yet able to reproduce the issue on another architecture, I've been running test039 for a few hours on an Intel x86_64 box without any problem. So this problem might as well be locate in some other part of the system (kernel, glibc, ...). What do you think? -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > ando(a)sys-net.it wrote: > > rhafer(a)suse.de wrote: > >> I was able to reproduce this problem again. It does not happen during > >> every run of test039-glue-ldap-concurrency (probably during 1 out of > >> 10). This time I had enabled debug logging in the slapd-search tester. > >> Find the log of it below. What's really strange that it fails when > >> chasing a referral to ldap://localhost:9016 (there is nothing listening > >> on port 9016 during test039) > >> > >> ldap_new_connection 0x100141e0: unexpected response 96 from BIND request > >> id=376 lt-slapd-search: request.c:470: ldap_new_connection: Assertion > >> `0' failed. > > > > 96 is LDAP_REQ_BIND, which __should_not__ be returned by ldap_result() > > in any case. The bug is buried deeper in libldap, so the assert(0) was > > apparently worth :) > > Another comment: would it be possible to check if the problem was > already present in earlier versions? Yes, I had that on my list already. I am also trying to reproduce it on a different architecture, currently I only used different PowerPC machines. -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

ando(a)sys-net.it wrote: > rhafer(a)suse.de wrote: >> I was able to reproduce this problem again. It does not happen during every >> run of test039-glue-ldap-concurrency (probably during 1 out of 10). This >> time I had enabled debug logging in the slapd-search tester. Find the log >> of it below. What's really strange that it fails when chasing a referral to >> ldap://localhost:9016 (there is nothing listening on port 9016 during >> test039) > >> ldap_new_connection 0x100141e0: unexpected response 96 from BIND request id=376 >> lt-slapd-search: request.c:470: ldap_new_connection: Assertion `0' failed. > > 96 is LDAP_REQ_BIND, which __should_not__ be returned by ldap_result() > in any case. The bug is buried deeper in libldap, so the assert(0) was > apparently worth :) Another comment: would it be possible to check if the problem was already present in earlier versions? 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#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

rhafer(a)suse.de wrote: > I was able to reproduce this problem again. It does not happen during every > run of test039-glue-ldap-concurrency (probably during 1 out of 10). This > time I had enabled debug logging in the slapd-search tester. Find the log > of it below. What's really strange that it fails when chasing a referral to > ldap://localhost:9016 (there is nothing listening on port 9016 during > test039) > ldap_new_connection 0x100141e0: unexpected response 96 from BIND request id=376 > lt-slapd-search: request.c:470: ldap_new_connection: Assertion `0' failed. 96 is LDAP_REQ_BIND, which __should_not__ be returned by ldap_result() in any case. The bug is buried deeper in libldap, so the assert(0) was apparently worth :) Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

I was able to reproduce this problem again. It does not happen during every run of test039-glue-ldap-concurrency (probably during 1 out of 10). This time I had enabled debug logging in the slapd-search tester. Find the log of it below. What's really strange that it fails when chasing a referral to ldap://localhost:9016 (there is nothing listening on port 9016 during test039) [..] ldap_chase_v3referral: msgid 374, url "ldap://localhost:9016/cn=Somewhere,ou=Meta,dc=example,dc=com??sub" ldap_send_server_request ldap_new_connection 0 1 1 ldap_int_open_connection ldap_connect_to_host: TCP localhost:9016 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying 127.0.0.1:9016 ldap_connect_timeout: fd: 4 tm: -1 async: 0 anonymous rebind via ldap_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ldap_result ld 0x100141e0 msgid 376 ldap_chkResponseList ld 0x100141e0 msgid 376 all 1 ldap_chkResponseList returns ld 0x100141e0 NULL wait4msg ld 0x100141e0 msgid 376 (timeout 100000 usec) wait4msg continue ld 0x100141e0 msgid 376 all 1 ** ld 0x100141e0 Connections: * host: localhost port: 9016 refcnt: 2 status: Connected last used: Thu Apr 12 08:10:47 2007 rebind in progress queue is empty * host: localhost port: 9013 (default) refcnt: 2 status: Connected last used: Thu Apr 12 08:10:47 2007 ** ld 0x100141e0 Outstanding Requests: * msgid 376, origid 376, status InProgress outstanding referrals 0, parent count 0 * msgid 374, origid 374, status InProgress outstanding referrals 1, parent count 0 ** ld 0x100141e0 Response Queue: * msgid 374, type 100 ldap_chkResponseList ld 0x100141e0 msgid 376 all 1 ldap_chkResponseList returns ld 0x100141e0 NULL ldap_int_select read1msg: ld 0x100141e0 msgid 376 all 1 read1msg: ld 0x100141e0 msgid 376 message type unknown new result: res_errno: 3, res_error: <>, res_matched: <> read1msg: ld 0x100141e0 0 new referrals read1msg: mark request completed, ld 0x100141e0 msgid 376 request done: ld 0x100141e0 msgid 376 res_errno: 3, res_error: <>, res_matched: <> ldap_free_request (origid 376, msgid 376) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_new_connection 0x100141e0: unexpected response 96 from BIND request id=376 lt-slapd-search: request.c:470: ldap_new_connection: Assertion `0' failed. [..] -- Ralf

1 0

Re: (ITS#4925) Modify operation with NOOP control on a BDB backend causes slapd to crash
by jclarke＠linagora.com 12 Apr '07

12 Apr '07

Pierangelo Masarati wrote: > jclarke(a)linagora.com wrote: > >> When trying a modify operation (such as changing or adding a value of an >> attribute) with the NOOP control (set to critical) on an entry stored in a BDB >> backend, slapd crashes, with the following error: > > Thanks, applied to HEAD/re23. Please test and report. p. Just tested HEAD and RE23, NOOP works great on all operations. Thanks! -- Jonathan Clarke Linagora - OSSA 27, rue de Berri 75008 Paris Tél. 01 58 18 68 28 Fax. 01 58 18 68 29

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by ando＠sys-net.it 11 Apr '07

11 Apr '07

ando(a)sys-net.it wrote: > Right. Time permitting, I'll check why back-sql behaves differently > and, in case, how to fix it. HEAD should be working as expected, now. I've also updated mysql and psql sql-test000 (the latter is untested, though). Please test and report. 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#4922) test_filter problem on uid filter
by ando＠sys-net.it 11 Apr '07

11 Apr '07

juritanganelli(a)gmail.com wrote: > I have developed a custom backend that uses the test_filter function to > determine > if an entry is matching a given input filter. Filter on any of the entry > attribute but Uid works fine. When i specify i filter on the uid attribute i get > very strange results for example: > > - when i use the complete value of the attribute such as uid=e497004 no result > is returned, but there is an entry with that value. > - when i use some regular expressions the result is correclty such as uid=e* the > corresponding entry is correctly returned. Unless you can show evidence that the problem is within test_filter(), which is known to work as expected, custom code issues cannot be considered OpenLDAP issues. You don't provide enough information to prove the above, so this ITS will be suspended waiting for further information. For example, did you check that the entry with uid=e497004 was actually candidate and thus subjected to test_filter()? 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#4925) Modify operation with NOOP control on a BDB backend causes slapd to crash
by ando＠sys-net.it 11 Apr '07

11 Apr '07

jclarke(a)linagora.com wrote: > When trying a modify operation (such as changing or adding a value of an > attribute) with the NOOP control (set to critical) on an entry stored in a BDB > backend, slapd crashes, with the following error: Thanks, applied to HEAD/re23. Please test and report. 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#4925) Modify operation with NOOP control on a BDB backend causes slapd to crash
by jclarke＠linagora.com 11 Apr '07

11 Apr '07

Full_Name: Jonathan Clarke Version: 2.3.35 OS: Linux (ubuntu) URL: Submission from: (NULL) (213.41.243.192) When trying a modify operation (such as changing or adding a value of an attribute) with the NOOP control (set to critical) on an entry stored in a BDB backend, slapd crashes, with the following error: *** glibc detected *** ./servers/slapd/slapd: munmap_chunk(): invalid pointer: 0x0821e235 *** ======= Backtrace: ========= [...] ======= Memory map: ======== [...] Abandon (core dumped) This only happens for operations that should succeed (ie, should return the NOOP error code LDAP_X_NO_OPERATION). Operations which fail for other reasons (refused by ACLs, schema error, etc) do not make slapd crash. I have tested this on versions 2.3.32, 2.3.34, 2.3.35 and HEAD (as of today). The crash only happens with the BDB backend (I tested slapd with a ldap backend which only made the remote slapd with a BDB backend crash, not the one with the ldap backend). After some investigation, I found that this crash results from a call to attrs_free() in servers/slapd/back-bdb/modify.c, after the "return_results" label. This seems to be a double free() problem. The following patch solved the problem for me on versions 2.3.32, 2.3.34, 2.3.35 and HEAD (as of today). With this patch, NOOP behaves as expected. The patch simply adds 2 lines copied from the error handling "if" higher up in the same function (bdb_modify). ---------------------BEGIN PATCH--------------------- --- modify.c.~1.124.2.16.~ 2007-01-02 22:44:00.000000000 +0100 +++ modify.c 2007-04-11 14:44:56.000000000 +0200 @@ -538,6 +538,8 @@ } else { rs->sr_err = LDAP_X_NO_OPERATION; ltid = NULL; + /* Only free attrs if they were dup'd. */ + if ( dummy.e_attrs == e->e_attrs ) dummy.e_attrs = NULL; goto return_results; } } else { ----------------------END PATCH---------------------- (sorry not to put this patch on an FTP site, but ftp.openldap.org complains with 452 Error writing file: No space left on device.) I, Jonathan Clarke, hereby place the preceding 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#4910) mirrormode prevents syncrepl engine from working
by ali.pouya＠free.fr 11 Apr '07

11 Apr '07

Works fine. Thanks a lot. Issue to be closed. Best regards Ali Pouya

1 0

RE: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by imriz＠co.zahav.net.il 10 Apr '07

10 Apr '07

I have new tar.gz file ready, this time with unstripped binaries: http://mariska.inter.net.il/~imriz/slapd-crash-10042007.tar.gz root@cemetery:~$ ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.3-releng.so.2 => /usr/local/lib/libldap_r-2.3-releng.so.2 (0xa8161000) liblber-2.3-releng.so.2 => /usr/local/lib/liblber-2.3-releng.so.2 (0xa81a1000) libssl.so.4 => /usr/lib/libssl.so.4 (0xa81b7000) libcrypto.so.4 => /lib/libcrypto.so.4 (0xa81e5000) libfetch.so.4 => /usr/lib/libfetch.so.4 (0xa82d8000) libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0xa82e5000) libcrypt.so.3 => /lib/libcrypt.so.3 (0xa82e7000) libltdl.so.4 => /usr/local/lib/libltdl.so.4 (0xa82ff000) libpthread.so.2 => /usr/lib/libthr.so.2 (0xa8307000) libc.so.6 => /lib/libc.so.6 (0xa8319000) root@cemetery:~$ file /usr/local/libexec/slapd /usr/local/libexec/slapd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped Please let me know if there is anything else you need, --imriz > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Tuesday, April 03, 2007 12:42 AM > To: Imri Zvik ( Smile ) > Cc: openldap-its(a)openldap.org > Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > > imriz(a)co.zahav.net.il wrote: > > Sure. New core dumps and binary file is at > > http://mariska.inter.net.il/~imriz/slapd-core.tar.gz > > The slapd in this snapshot was stripped so no debug symbols are > present. > Please be sure to use an unstripped binary. > > Also, since you're also loading libldap_r, liblber, back-ldap, back- > bdb, > back-meta, and back-ldbm dynamically, you'll need to include those > modules in the tarball. (Also with debug and unstripped.) > > Although at this point I'm wondering why you're using back-ldbm, which > has been deprecated for quite a long time. > > > Please notice that the previous dump was from FreeBSD ports (OpenLDAP > > version 2.3.33). > > > > This one was fetched from the CVS (OPENLDAP_REL_ENG_2_3), with the > > following configure options: > > > > ./configure --with-threads=posix --with-tls=openssl --enable-dynamic > > --without-cyrus-sasl --enable-modules --localstatedir=/var/ > > db --enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable- > ldap=mod > > --enable-meta=mod --enable-rewrite --enable-null=mod --enabl > > e-monitor=mod --enable-proxycache --disable-syncprov --enable-bdb=mod > > --enable-hdb=mod --enable-dbm-api=berkeley --disable-slurpd -- > > prefix=/usr/local --enable-debug > > > > > > -----Original Message----- > > From: Howard Chu [mailto:openldap-its@OpenLDAP.org] > > Sent: Tuesday, February 13, 2007 1:14 AM > > To: Imri Zvik > > Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > > > > It looks like this core is from a binary without debug symbols > present, > > can you > > recompile with debugging enabled and get a new stack trace and core > > file? > > > > > > . > > > > > -- > -- 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#4924) assertion failure during test039-glue-ldap-concurrency
by h.b.furuseth＠usit.uio.no 10 Apr '07

10 Apr '07

That assert() looks bad anyway. Looks like a server can crash the client by sending an incorrectly tagged result. -- Regards, Hallvard

1 0

(ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 10 Apr '07

10 Apr '07

Full_Name: Ralf Haferkamp Version: 2.3.35 OS: Linux (Kernel 2.6 on ppc) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.148.128) 2.3.35 failed for me during test039-glue-ldap-concurrency with: lt-slapd-search: request.c:465: ldap_new_connection: Assertion `0' failed. stopping: child terminated with signal 6 Unfortunately, I can't provide any more info currently as the logs were already removed from our build farm :( I'll try to reproduce the problem again. But it seems to not to occur during every run.

1 0

Re: (ITS#4922) test_filter problem on uid filter
by h.b.furuseth＠usit.uio.no 10 Apr '07

10 Apr '07

juritanganelli(a)gmail.com writes: > I don't believe that i can use an index. The result is returned from > my backend that doesn't use any dbd based database but generates data > on the fly ( merging results from an oracle db with some custom > business logic.). I read somewhere else that this was a known issue on > a previous version of openldap but in this situation i can't generate > any useful index Duh.. sorry, I read "custom backend" as "customized"... What you described is the usual symptom when you use a backend which does support indexing (bdb/hdb/ldbm) and you edit slapd.conf to include a new index. -- Regards, Hallvard

1 0

Re: (ITS#4922) test_filter problem on uid filter
by h.b.furuseth＠usit.uio.no 10 Apr '07

10 Apr '07

juritanganelli(a)gmail.com writes: > - when i use the complete value of the attribute such as uid=e497004 > no result is returned, but there is an entry with that value. stop slapd, run sbin/slapindex, restart slapd, and tell us if that helped. Needed if you add the index to slapd.conf when you alreayd have a database, since just editing slapd.conf does not index existing data. > - when i use some regular expressions the result is correclty such as > uid=e* the corresponding entry is correctly returned. Substring, not a regular expression. By default, a substring search with just a single letter does not use indexes, it just trawls through each entry in scope. -- Regards, Hallvard

1 0

Re: (ITS#4923) back-config and olcModuleLoad kills slapd
by ghenry＠suretecsystems.com 10 Apr '07

10 Apr '07

<quote who="hyc(a)symas.com"> > ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.35 >> OS: Fedora Core 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> Dear All, >> >> I know you can add modules like: >> >> dn: cn=module{0},cn=config >> objectClass: olcModuleList >> cn: module{0} >> olcModuleLoad: /usr/local/lib/smbk5pwd.la >> >> dn: cn=module{1},cn=config >> objectClass: olcModuleList >> cn: module{1} >> olcModulePath: /usr/local/lib:/usr/local/lib/slapd >> olcModuleLoad: accesslog.la >> olcModuleLoad: pcache.la >> >> But when migrating from slapd.conf, they get listed as: >> >> dn: cn=module{0},cn=config >> olcModuleLoad: {0}back_hdb.la >> olcModuleLoad: {1}accesslog.la >> olcModuleLoad: {2}syncprov.la >> olcModuleLoad: {3}back_monitor.la >> >> I am trying to add the smbk5pwd module like so: >> >> dn: cn=module{0},cn=config >> changetype: modify >> replace: olcModuleLoad >> olcModuleLoad: {0}back_hdb.la >> olcModuleLoad: {1}accesslog.la >> olcModuleLoad: {2}syncprov.la >> olcModuleLoad: {3}back_monitor.la >> olcModuleLoad: {4}smbk5pwd.la >> >> Command: >> >> ldapmodify -d 1 -x -D "cn=config" -W -f /home/ghenry/Desktop/smb.ldif >> -ZZ >> >> ldapmodify excepts the above LDIF. >> >> But slapd dies: >> >> Program received signal SIGABRT, Aborted. >> [Switching to Thread -1558062192 (LWP 24587)] >> 0x00bfd402 in __kernel_vsyscall () >> (gdb) bt >> #0 0x00bfd402 in __kernel_vsyscall () >> #1 0x0026ad40 in raise () from /lib/libc.so.6 >> #2 0x0026c591 in abort () from /lib/libc.so.6 >> #3 0x0026438b in __assert_fail () from /lib/libc.so.6 >> #4 0x080a26ce in slap_bv2ad () >> #5 0x080a33c0 in slap_str2ad () >> #6 0x08060f81 in init_config_attrs () >> #7 0x0805f7e7 in config_register_schema () >> #8 0x004db1e3 in hdb_back_init_cf (bi=0x4f8960) at config.c:695 >> #9 0x004d755d in hdb_back_initialize (bi=0x4f8960) at init.c:683 >> #10 0x08075e6b in backend_add () >> #11 0x004d7328 in init_module (argc=0, argv=0x0) at init.c:693 >> #12 0x080aec33 in module_load () >> #13 0x0805abd6 in str2loglevel () >> #14 0x080611e2 in config_set_vals () >> #15 0x0806310d in config_parse_add () >> #16 0x0805d899 in str2loglevel () >> #17 0x0807f89b in fe_op_modify () >> #18 0x080800d8 in do_modify () >> #19 0x08068bd9 in connection2anonymous () >> #20 0x0099260d in ldap_int_thread_pool_wrapper (xpool=0xa3c1ffd8) at >> tpool.c:478 >> #21 0x006e63db in start_thread () from /lib/libpthread.so.0 >> #22 0x0030f26e in clone () from /lib/libc.so.6 >> >> Is this a LDIF format issue on my part? > > Yes. > > You should just be doing a modify like > > > dn: cn=module{0},cn=config > > changetype: modify > > add: olcModuleLoad > > olcModuleLoad: smbk5pwd.la > > since you're not actually changing any of the other values. True. I remember reading somewhere the ordering etc. nm. as slapd does that bit. > > In the meantime, back-config should not be accepting a "replace" request > for olcModuleLoad attributes, since you're not allowed to delete > modules, and replace is just delete/add. Yeah, anything that causes a crash shouldn't be allowed ;-) Thanks. > > -- > -- 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#4921) back-config and included ACLs
by ghenry＠suretecsystems.com 10 Apr '07

10 Apr '07

<quote who="hyc(a)symas.com"> > hyc(a)symas.com wrote: >> ghenry(a)suretecsystems.com wrote: >>> Full_Name: Gavin Henry >>> Version: 2.3.35 >>> OS: Fedora Core 6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (212.159.59.85) >>> >>> >>> Dear All, >>> >>> Minor issue. When including an acl file, this acl file appears in >>> cn=schema: >>> >>> dn: cn=include{8},cn=config >>> objectClass: olcIncludeFile >>> cn: include{8} >>> olcInclude: /usr/local/etc/openldap/suretec.acl >>> >>> Shows as: >>> >>> dn: cn={8}suretec,cn=schema,cn=config >>> objectClass: olcSchemaConfig >>> cn: {8}suretec >>> >>> I don't think this should show in the schema tree. >> >> Indeed. It's only supposed to show up there if it actually contained any >> schema directives. Oops. > > back-config in HEAD/RE24 already does the right thing here. The > corresponding code just didn't get backported to RE23. I guess we can > fix it in the next RE23, but it doesn't seem critical. Nah, just thought it worth a mention. 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#4921) back-config and included ACLs
by hyc＠symas.com 10 Apr '07

10 Apr '07

hyc(a)symas.com wrote: > ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.35 >> OS: Fedora Core 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> Dear All, >> >> Minor issue. When including an acl file, this acl file appears in cn=schema: >> >> dn: cn=include{8},cn=config >> objectClass: olcIncludeFile >> cn: include{8} >> olcInclude: /usr/local/etc/openldap/suretec.acl >> >> Shows as: >> >> dn: cn={8}suretec,cn=schema,cn=config >> objectClass: olcSchemaConfig >> cn: {8}suretec >> >> I don't think this should show in the schema tree. > > Indeed. It's only supposed to show up there if it actually contained any > schema directives. Oops. back-config in HEAD/RE24 already does the right thing here. The corresponding code just didn't get backported to RE23. I guess we can fix it in the next RE23, but it doesn't seem critical. -- -- 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#4923) back-config and olcModuleLoad kills slapd
by hyc＠symas.com 10 Apr '07

10 Apr '07

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.35 > OS: Fedora Core 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Dear All, > > I know you can add modules like: > > dn: cn=module{0},cn=config > objectClass: olcModuleList > cn: module{0} > olcModuleLoad: /usr/local/lib/smbk5pwd.la > > dn: cn=module{1},cn=config > objectClass: olcModuleList > cn: module{1} > olcModulePath: /usr/local/lib:/usr/local/lib/slapd > olcModuleLoad: accesslog.la > olcModuleLoad: pcache.la > > But when migrating from slapd.conf, they get listed as: > > dn: cn=module{0},cn=config > olcModuleLoad: {0}back_hdb.la > olcModuleLoad: {1}accesslog.la > olcModuleLoad: {2}syncprov.la > olcModuleLoad: {3}back_monitor.la > > I am trying to add the smbk5pwd module like so: > > dn: cn=module{0},cn=config > changetype: modify > replace: olcModuleLoad > olcModuleLoad: {0}back_hdb.la > olcModuleLoad: {1}accesslog.la > olcModuleLoad: {2}syncprov.la > olcModuleLoad: {3}back_monitor.la > olcModuleLoad: {4}smbk5pwd.la > > Command: > > ldapmodify -d 1 -x -D "cn=config" -W -f /home/ghenry/Desktop/smb.ldif -ZZ > > ldapmodify excepts the above LDIF. > > But slapd dies: > > Program received signal SIGABRT, Aborted. > [Switching to Thread -1558062192 (LWP 24587)] > 0x00bfd402 in __kernel_vsyscall () > (gdb) bt > #0 0x00bfd402 in __kernel_vsyscall () > #1 0x0026ad40 in raise () from /lib/libc.so.6 > #2 0x0026c591 in abort () from /lib/libc.so.6 > #3 0x0026438b in __assert_fail () from /lib/libc.so.6 > #4 0x080a26ce in slap_bv2ad () > #5 0x080a33c0 in slap_str2ad () > #6 0x08060f81 in init_config_attrs () > #7 0x0805f7e7 in config_register_schema () > #8 0x004db1e3 in hdb_back_init_cf (bi=0x4f8960) at config.c:695 > #9 0x004d755d in hdb_back_initialize (bi=0x4f8960) at init.c:683 > #10 0x08075e6b in backend_add () > #11 0x004d7328 in init_module (argc=0, argv=0x0) at init.c:693 > #12 0x080aec33 in module_load () > #13 0x0805abd6 in str2loglevel () > #14 0x080611e2 in config_set_vals () > #15 0x0806310d in config_parse_add () > #16 0x0805d899 in str2loglevel () > #17 0x0807f89b in fe_op_modify () > #18 0x080800d8 in do_modify () > #19 0x08068bd9 in connection2anonymous () > #20 0x0099260d in ldap_int_thread_pool_wrapper (xpool=0xa3c1ffd8) at > tpool.c:478 > #21 0x006e63db in start_thread () from /lib/libpthread.so.0 > #22 0x0030f26e in clone () from /lib/libc.so.6 > > Is this a LDIF format issue on my part? Yes. You should just be doing a modify like > dn: cn=module{0},cn=config > changetype: modify > add: olcModuleLoad > olcModuleLoad: smbk5pwd.la since you're not actually changing any of the other values. In the meantime, back-config should not be accepting a "replace" request for olcModuleLoad attributes, since you're not allowed to delete modules, and replace is just delete/add. -- -- 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#4921) back-config and included ACLs
by hyc＠symas.com 10 Apr '07

10 Apr '07

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.35 > OS: Fedora Core 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Dear All, > > Minor issue. When including an acl file, this acl file appears in cn=schema: > > dn: cn=include{8},cn=config > objectClass: olcIncludeFile > cn: include{8} > olcInclude: /usr/local/etc/openldap/suretec.acl > > Shows as: > > dn: cn={8}suretec,cn=schema,cn=config > objectClass: olcSchemaConfig > cn: {8}suretec > > I don't think this should show in the schema tree. Indeed. It's only supposed to show up there if it actually contained any schema directives. Oops. > > Thanks, > > 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#4923) back-config and olcModuleLoad kills slapd
by ghenry＠suretecsystems.com 10 Apr '07

10 Apr '07

Full_Name: Gavin Henry Version: 2.3.35 OS: Fedora Core 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, I know you can add modules like: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: /usr/local/lib/smbk5pwd.la dn: cn=module{1},cn=config objectClass: olcModuleList cn: module{1} olcModulePath: /usr/local/lib:/usr/local/lib/slapd olcModuleLoad: accesslog.la olcModuleLoad: pcache.la But when migrating from slapd.conf, they get listed as: dn: cn=module{0},cn=config olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}accesslog.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}back_monitor.la I am trying to add the smbk5pwd module like so: dn: cn=module{0},cn=config changetype: modify replace: olcModuleLoad olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}accesslog.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}back_monitor.la olcModuleLoad: {4}smbk5pwd.la Command: ldapmodify -d 1 -x -D "cn=config" -W -f /home/ghenry/Desktop/smb.ldif -ZZ ldapmodify excepts the above LDIF. But slapd dies: Program received signal SIGABRT, Aborted. [Switching to Thread -1558062192 (LWP 24587)] 0x00bfd402 in __kernel_vsyscall () (gdb) bt #0 0x00bfd402 in __kernel_vsyscall () #1 0x0026ad40 in raise () from /lib/libc.so.6 #2 0x0026c591 in abort () from /lib/libc.so.6 #3 0x0026438b in __assert_fail () from /lib/libc.so.6 #4 0x080a26ce in slap_bv2ad () #5 0x080a33c0 in slap_str2ad () #6 0x08060f81 in init_config_attrs () #7 0x0805f7e7 in config_register_schema () #8 0x004db1e3 in hdb_back_init_cf (bi=0x4f8960) at config.c:695 #9 0x004d755d in hdb_back_initialize (bi=0x4f8960) at init.c:683 #10 0x08075e6b in backend_add () #11 0x004d7328 in init_module (argc=0, argv=0x0) at init.c:693 #12 0x080aec33 in module_load () #13 0x0805abd6 in str2loglevel () #14 0x080611e2 in config_set_vals () #15 0x0806310d in config_parse_add () #16 0x0805d899 in str2loglevel () #17 0x0807f89b in fe_op_modify () #18 0x080800d8 in do_modify () #19 0x08068bd9 in connection2anonymous () #20 0x0099260d in ldap_int_thread_pool_wrapper (xpool=0xa3c1ffd8) at tpool.c:478 #21 0x006e63db in start_thread () from /lib/libpthread.so.0 #22 0x0030f26e in clone () from /lib/libc.so.6 Is this a LDIF format issue on my part? Thanks, Gavin.

1 0

(ITS#4922) test_filter problem on uid filter
by juritanganelli＠gmail.com 10 Apr '07

10 Apr '07

Full_Name: juri tanganelli Version: 2.3.27 OS: Red Hat EL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.7.19.10) I have developed a custom backend that uses the test_filter function to determine if an entry is matching a given input filter. Filter on any of the entry attribute but Uid works fine. When i specify i filter on the uid attribute i get very strange results for example: - when i use the complete value of the attribute such as uid=e497004 no result is returned, but there is an entry with that value. - when i use some regular expressions the result is correclty such as uid=e* the corresponding entry is correctly returned. Regards, Juri

1 0

(ITS#4921) back-config and included ACLs
by ghenry＠suretecsystems.com 10 Apr '07

10 Apr '07

Full_Name: Gavin Henry Version: 2.3.35 OS: Fedora Core 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, Minor issue. When including an acl file, this acl file appears in cn=schema: dn: cn=include{8},cn=config objectClass: olcIncludeFile cn: include{8} olcInclude: /usr/local/etc/openldap/suretec.acl Shows as: dn: cn={8}suretec,cn=schema,cn=config objectClass: olcSchemaConfig cn: {8}suretec I don't think this should show in the schema tree. Thanks, Gavin.

1 0

Re: (ITS#4920) bad connection sequencing
by hyc＠symas.com 09 Apr '07

09 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: http://folk.uio.no/hbf/OpenLDAP/bug032.tgz > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > Statslog() from even successful tests can show strange sequencing. > > grep '^conn=' testrun/slapd.*.log from a test032-chain run shows > - Operations logged on connections before ACCEPT > (slapd.1.log conn=2,3 + slapd.2.log conn=7,9) > - Operations on a connection with no ACCEPT (slapd.1.log conn=10), > but a 'conn=-1 fd=21 ACCEPT' _after_ that fd's 'close', > and valgrind shows memory errors between the close and the ACCEPT. > The enclosed URL gives the testrun directory and test output. Haven't looked at that yet. > Similar things show up in other tests. A test019 run with a > conn=-1 ACCEPT did not get valgrind memory compaints though. > grep 'conn=-1' testrun/slapd.*.log also found a number of > send_ldap_result: conn=-1 op=0 p=<0 or 3> > even in logs without any conn=-1, but maybe that's a "fake > connection"? Don't know why results are sent though. send_ldap_result is always logged, since it occurs before callback processing. So even if it's an internal op with a null callback, it will get logged. -- -- 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#4920) bad connection sequencing
by h.b.furuseth＠usit.uio.no 09 Apr '07

09 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: http://folk.uio.no/hbf/OpenLDAP/bug032.tgz Submission from: (NULL) (129.240.202.105) Submitted by: hallvard Statslog() from even successful tests can show strange sequencing. grep '^conn=' testrun/slapd.*.log from a test032-chain run shows - Operations logged on connections before ACCEPT (slapd.1.log conn=2,3 + slapd.2.log conn=7,9) - Operations on a connection with no ACCEPT (slapd.1.log conn=10), but a 'conn=-1 fd=21 ACCEPT' _after_ that fd's 'close', and valgrind shows memory errors between the close and the ACCEPT. The enclosed URL gives the testrun directory and test output. Similar things show up in other tests. A test019 run with a conn=-1 ACCEPT did not get valgrind memory compaints though. grep 'conn=-1' testrun/slapd.*.log also found a number of send_ldap_result: conn=-1 op=0 p=<0 or 3> even in logs without any conn=-1, but maybe that's a "fake connection"? Don't know why results are sent though.

1 0

Re: (ITS#4919) Why CPU usage can not reach 100% while doing modify operation?
by hyc＠symas.com 09 Apr '07

09 Apr '07

The ITS is for tracking bug reports and enhancement requests. I don't see a bug report here. Try asking your question on the OpenLDAP-software mailing list. This ITS will be closed. seuler(a)163.com wrote: > Full_Name: Seuler Shi > Version: openldap-2.3.30 > OS: SUSE 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.138.202.50) > > > When I do the search operation, the CPU usage of OpenLDAP Server can reach 100% > when the number of search operations per second arise? But for the modify > operation, > the CPU usage can only reach 87% at most? > > What is the bottleneck that makes OpenLDAP can not make CPU recource fully while > > doing modify operation? -- -- 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#4919) Why CPU usage can not reach 100% while doing modify operation?
by seuler＠163.com 09 Apr '07

09 Apr '07

Full_Name: Seuler Shi Version: openldap-2.3.30 OS: SUSE 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.138.202.50) When I do the search operation, the CPU usage of OpenLDAP Server can reach 100% when the number of search operations per second arise? But for the modify operation, the CPU usage can only reach 87% at most? What is the bottleneck that makes OpenLDAP can not make CPU recource fully while doing modify operation?

1 0

Re: (ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by brian＠zimbra.com 06 Apr '07

06 Apr '07

thanks, that worked, this case can be closed. Brian Peterson On Apr 6, 2007, at 1:58 PM, Howard Chu wrote: > brian(a)zimbra.com wrote: >> Full_Name: Brian Peterson >> Version: 2.3.34 >> OS: Linux >> URL: pro >> Submission from: (NULL) (66.92.25.194) >> When setup sync replication the contextCSN is available via >> ldapsearch on the >> provider but not the consumer as an operation attribute. If we do >> a slapcat on >> the consumer the resulting ldif contains the contextCSN. > > This is because your context entry has no DN, it's a glue entry. > When you do a search on it you get the contents of the server > rootDSE instead of your glue entry. The search works on the > provider because the syncprov overlay intercepts searches to insert > the current contextCSN value in the result. You can add a syncprov > overlay to the consumer to get the same effect. > >> Top entry from slapcat ldif on the consumer. >> dn: >> objectClass: glue >> structuralObjectClass: glue >> contextCSN: 20070405182202Z#000000#00#000000 >> entryCSN: 20070405182202Z#000000#00#000000 >> modifiersName: uid=zimbra,cn=admins,cn=zimbra >> modifyTimestamp: 20070405182202Z > > > -- > -- 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#4918) int = pointer assignment in syncrepl
by hyc＠symas.com 06 Apr '07

06 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23 > OS: > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > In RE23:syncrepl.c:do_syncrepl() lin 1155, the statement > fail = si->si_retrynum; > assigns an int* to an int. > > > . > Thanks, fixed. -- -- 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#4918) int = pointer assignment in syncrepl
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

Full_Name: Hallvard B Furuseth Version: RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard In RE23:syncrepl.c:do_syncrepl() lin 1155, the statement fail = si->si_retrynum; assigns an int* to an int.

1 0

Re: (ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by hyc＠symas.com 06 Apr '07

06 Apr '07

brian(a)zimbra.com wrote: > Full_Name: Brian Peterson > Version: 2.3.34 > OS: Linux > URL: pro > Submission from: (NULL) (66.92.25.194) > > > When setup sync replication the contextCSN is available via ldapsearch on the > provider but not the consumer as an operation attribute. If we do a slapcat on > the consumer the resulting ldif contains the contextCSN. This is because your context entry has no DN, it's a glue entry. When you do a search on it you get the contents of the server rootDSE instead of your glue entry. The search works on the provider because the syncprov overlay intercepts searches to insert the current contextCSN value in the result. You can add a syncprov overlay to the consumer to get the same effect. > Top entry from slapcat ldif on the consumer. > dn: > objectClass: glue > structuralObjectClass: glue > contextCSN: 20070405182202Z#000000#00#000000 > entryCSN: 20070405182202Z#000000#00#000000 > modifiersName: uid=zimbra,cn=admins,cn=zimbra > modifyTimestamp: 20070405182202Z > > > -- -- 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#4917) at_insert() moves sat_ad_mutex
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

hyc(a)symas.com wrote: >h.b.furuseth(a)usit.uio.no wrote: >> If so, the simplest clean fix may be to destroy and reinitialize >> the mutexes (instead of swapping them back), I think strictly >> speaking behaviour is undefined if one copies mutexes around at >> all. Or since one will immediately be destroyed, maybe they should >> be destroyed when SLAP_AT_DELETED is set, if it is not needed then. > > Destroying immediately is not feasible since the attribute may still > be in use. OK. > Show me the POSIX spec that indicates this behavior is undefined. I wasn't thinking of POSIX in particular (OpenLDAP supports several mutex types afer all), though the pthread_mutex_init() spec says Only mutex itself may be used for performing synchronization. The result of referring to copies of mutex in calls to pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_unlock(), and pthread_mutex_destroy() is undefined. Attempting to initialize an already initialized mutex results in undefined behavior. The current swap definitely makes it undefined. Whether swapping and copying back does so as well is probably just pedantry when they are unlocked, though in theory I imagine some thread magic could happen even to "passive" mutexes. Except I take it only one thread is running... -- Regards, Hallvard

1 0

Re: (ITS#4917) at_insert() moves sat_ad_mutex
by hyc＠symas.com 06 Apr '07

06 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > slapd/at.c:at_insert() swaps the contents of the initialized > mutexes 'old_sat->sat_ad_mutex' and 'sat->sat_ad_mutex' in the > /* replacing a deleted definition? */ code. > > I hope they are at least unlocked at the time... > Does ldap_pvt_thread_pool_pause() in config_back_add() & co block > the other threads? Yes of course, otherwise none of the config activities would be safe. > If so, the simplest clean fix may be to destroy and reinitialize > the mutexes (instead of swapping them back), I think strictly > speaking behaviour is undefined if one copies mutexes around at > all. Or since one will immediately be destroyed, maybe they should > be destroyed when SLAP_AT_DELETED is set, if it is not needed then. Destroying immediately is not feasible since the attribute may still be in use. Show me the POSIX spec that indicates this behavior is undefined. -- -- 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#4917) at_insert() moves sat_ad_mutex
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard slapd/at.c:at_insert() swaps the contents of the initialized mutexes 'old_sat->sat_ad_mutex' and 'sat->sat_ad_mutex' in the /* replacing a deleted definition? */ code. I hope they are at least unlocked at the time... Does ldap_pvt_thread_pool_pause() in config_back_add() & co block the other threads? If so, the simplest clean fix may be to destroy and reinitialize the mutexes (instead of swapping them back), I think strictly speaking behaviour is undefined if one copies mutexes around at all. Or since one will immediately be destroyed, maybe they should be destroyed when SLAP_AT_DELETED is set, if it is not needed then.

1 0

(ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by brian＠zimbra.com 06 Apr '07

06 Apr '07

Full_Name: Brian Peterson Version: 2.3.34 OS: Linux URL: pro Submission from: (NULL) (66.92.25.194) When setup sync replication the contextCSN is available via ldapsearch on the provider but not the consumer as an operation attribute. If we do a slapcat on the consumer the resulting ldif contains the contextCSN. relavent slapd.conf entries from provider(please let me know if you want the entire file). database bdb suffix "" rootdn "uid=zimbra,cn=admins,cn=zimbra" # recommended for replication index entryUUID eq index entryCSN eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 500 slapd.conf entries from consumer. database bdb suffix "" rootdn "uid=zimbra,cn=admins,cn=zimbra" syncrepl rid=022 provider=ldap://ldapmaster:389 retry="60 +" type=refreshAndPersist schemachecking=off updatedn="uid=zimbrareplication,cn=admins,cn=zimbra" searchbase="" bindmethod=simple binddn="uid=zimbra,cn=admins,cn=zimbra" creditionals=secret updateref ldap://ldapmaster:389 Ldap search output from the consumer ldapsearch -LLL -x -D uid=zimbra,cn=admins,cn=zimbra -w secret -H ldap://ldapreplica:389 -s base -b "" + dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 entryDN: subschemaSubentry: cn=Subschema Top entry from slapcat ldif on the consumer. dn: objectClass: glue structuralObjectClass: glue contextCSN: 20070405182202Z#000000#00#000000 entryCSN: 20070405182202Z#000000#00#000000 modifiersName: uid=zimbra,cn=admins,cn=zimbra modifyTimestamp: 20070405182202Z

1 0

Re: (ITS#4915) Syncrepl task exits are not logged
by hyc＠symas.com 05 Apr '07

05 Apr '07

unix.gurus(a)gmail.com wrote: > Full_Name: Sean Burford > Version: 2.3.32 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.57.245.11) > > > It is hard to tell when the syncrepl task has exited. The attached patch adds > logging of syncrepl hard and soft failures. > > Using this patch, it is easier to spot unfortunate conditions where recoverable > failures are treated as hard failures, for example the third line below shows > that a (temporarily) unavailable kerberos credential cache causes a hard > failure: > GSSAPI Error: Miscellaneous failure (No credentials cache found) > do_syncrep1: rid 123 ldap_sasl_interactive_bind_s failed (-2) > do_syncrepl: rid 123 hard failure Looks like a good idea, thanks. I think I'd just change the messages to "giving up" or "quitting", and "retrying". That final else clause in your patch should never occur, there is no 3rd outcome. > > Hmm, no attachment because the FTP server returns: > 200 PORT command successful. > 150 Opening ASCII mode data connection for > 'openldap-2.3.32-syncrepl-log-failure.patch'. > ## > 452 Error writing file: No space left on device. > 1104 bytes sent in 0.00011 seconds (1e+04 Kbytes/s) > > The patch was: > *** openldap-2.3.32.orig/servers/slapd/syncrepl.c Wed Apr 4 17:21:31 > 2007 > --- openldap-2.3.32/servers/slapd/syncrepl.c Wed Apr 4 17:55:58 2007 > *************** > *** 1147,1159 **** > --- 1147,1169 ---- > } > > if ( !si->si_retrynum || si->si_retrynum[i] == RETRYNUM_TAIL ) > { > + Debug( LDAP_DEBUG_ANY, > + "do_syncrepl: rid %03d hard failure\n", > + si->si_rid, 0, 0 ); > ldap_pvt_runqueue_remove( &slapd_rq, rtask ); > } else if ( RETRYNUM_VALID( si->si_retrynum[i] ) ) { > if ( si->si_retrynum[i] > 0 ) > si->si_retrynum[i]--; > + Debug( LDAP_DEBUG_ANY, > + "do_syncrepl: rid %03d soft failure, > rescheduling (retries left: %d)\n", > + si->si_rid, si->si_retrynum[i], 0 ); > rtask->interval.tv_sec = si->si_retryinterval[i]; > ldap_pvt_runqueue_resched( &slapd_rq, rtask, 0 ); > slap_wake_listener(); > + } else { > + Debug( LDAP_DEBUG_ANY, > + "do_syncrepl: rid %03d soft failure, > rescheduling\n", > + si->si_rid, 0, 0 ); > } > } > > > -- -- 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#4915) Syncrepl task exits are not logged
by unix.gurus＠gmail.com 05 Apr '07

05 Apr '07

Full_Name: Sean Burford Version: 2.3.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.57.245.11) It is hard to tell when the syncrepl task has exited. The attached patch adds logging of syncrepl hard and soft failures. Using this patch, it is easier to spot unfortunate conditions where recoverable failures are treated as hard failures, for example the third line below shows that a (temporarily) unavailable kerberos credential cache causes a hard failure: GSSAPI Error: Miscellaneous failure (No credentials cache found) do_syncrep1: rid 123 ldap_sasl_interactive_bind_s failed (-2) do_syncrepl: rid 123 hard failure Hmm, no attachment because the FTP server returns: 200 PORT command successful. 150 Opening ASCII mode data connection for 'openldap-2.3.32-syncrepl-log-failure.patch'. ## 452 Error writing file: No space left on device. 1104 bytes sent in 0.00011 seconds (1e+04 Kbytes/s) The patch was: *** openldap-2.3.32.orig/servers/slapd/syncrepl.c Wed Apr 4 17:21:31 2007 --- openldap-2.3.32/servers/slapd/syncrepl.c Wed Apr 4 17:55:58 2007 *************** *** 1147,1159 **** --- 1147,1169 ---- } if ( !si->si_retrynum || si->si_retrynum[i] == RETRYNUM_TAIL ) { + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d hard failure\n", + si->si_rid, 0, 0 ); ldap_pvt_runqueue_remove( &slapd_rq, rtask ); } else if ( RETRYNUM_VALID( si->si_retrynum[i] ) ) { if ( si->si_retrynum[i] > 0 ) si->si_retrynum[i]--; + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d soft failure, rescheduling (retries left: %d)\n", + si->si_rid, si->si_retrynum[i], 0 ); rtask->interval.tv_sec = si->si_retryinterval[i]; ldap_pvt_runqueue_resched( &slapd_rq, rtask, 0 ); slap_wake_listener(); + } else { + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d soft failure, rescheduling\n", + si->si_rid, 0, 0 ); } }

1 0

Re: (ITS#4907) Syncrepl consumer failing to perform deletes
by unix.gurus＠gmail.com 05 Apr '07

05 Apr '07

------=_Part_45311_2874873.1175811229646 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 4/3/07, Howard Chu <hyc(a)symas.com> wrote: > The log says that ITS#4638 was already fixed in 2.3.32. Why are you > still using that particular patch, given that an alternate solution is > already present in the release? I can't replicate ITS#4638 under 2.3.32, so you can mark ITS#4907 resolved (I removed the bad patch). I also see that in RE23 we had one more patch to fix some interaction > between slapo-rwm and back-meta for filter processing. I suggest you > test against the current RE23 code. I expect to push 2.3.35 out pretty > soon. Thank you. Sean ------=_Part_45311_2874873.1175811229646 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <span class="gmail_quote">On 4/3/07, <b class="gmail_sendername">Howard Chu</b> <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:</span><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The log says that ITS#4638 was already fixed in 2.3.32. Why are you<br>still using that particular patch, given that an alternate solution is<br>already present in the release?</blockquote><div><br>I can't replicate ITS#4638 under 2.3.32, so you can mark ITS#4907 resolved (I removed the bad patch).<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I also see that in RE23 we had one more patch to fix some interaction <br>between slapo-rwm and back-meta for filter processing. I suggest you<br>test against the current RE23 code. I expect to push 2.3.35 out pretty soon.</blockquote><div><br>Thank you. <br></div><br></div>Sean ------=_Part_45311_2874873.1175811229646--

1 0

Re: (ITS#4913) configure & BerkleyDB
by ando＠sys-net.it 05 Apr '07

05 Apr '07

fredo(a)sundancer.us wrote: > Full_Name: Fred Obermann > Version: 2.3.34 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.20.15.25) > > > I just downloaded, built and installed openldap-2.3.34 using BerkeleyDB-4.5.20. > > > There seems to be a disconnect between where openldap-2.3.34 'configure' expects > db.h is and where Oracle's build procedure puts db.h. > > For 4.5.20, db.h is located in "/usr/local/BerkeleyDB.4.5/include". Setting: > CPPFLAGS="I/usr/local/BerkeleyDB.4.5/include", prior to invoking 'configure' Perhaps adding a "-" before "I" could help. Please check and report. > does not seem to enable 'configure' to find 'db.h'. Providing soft link from > /usr/local/BerkeleyDB.4.5/include/db.h to /usr/include seems to fix this > problem > > Furthermore there seems to be a disconnect between the Oracle naming convention > for the BerkeleyDB libraries and what openldap's 'configure' utility seems to > expect. > > I set: > LIBS=-L/usr/local/BerkeleyDB.4.5/lib prior to invoking 'configure' > > But 'configure' is looking for libdb45.a or libdb-45.a or libdb4.5.a. > > However, what the Oracle build procedure produces are: libdb-4.5.a > libdb-4.5.la libdb-4.5.so libdb-4.so libdb.a libdb.so > > Creating a soft link from libdb-4.5.a to libdb45.a seems to fix this problem. > > Nonetheless, it would be better if the 'configure' script were expanded to > gracefully handle this latest release of BerkeleyDB from Oracle. > > > > > > 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#4913) configure & BerkleyDB
by hyc＠symas.com 05 Apr '07

05 Apr '07

fredo(a)sundancer.us wrote: > Full_Name: Fred Obermann > Version: 2.3.34 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.20.15.25) > > > I just downloaded, built and installed openldap-2.3.34 using BerkeleyDB-4.5.20. > > > There seems to be a disconnect between where openldap-2.3.34 'configure' expects > db.h is and where Oracle's build procedure puts db.h. > > For 4.5.20, db.h is located in "/usr/local/BerkeleyDB.4.5/include". Setting: > CPPFLAGS="I/usr/local/BerkeleyDB.4.5/include", prior to invoking 'configure' > does not seem to enable 'configure' to find 'db.h'. Providing soft link from > /usr/local/BerkeleyDB.4.5/include/db.h to /usr/include seems to fix this > problem If that's exactly what you used, you're missing the "-" in CPPFLAGS="-I..." > Furthermore there seems to be a disconnect between the Oracle naming convention > for the BerkeleyDB libraries and what openldap's 'configure' utility seems to > expect. The configure script works perfectly fine with all 4.x releases of BerkeleyDB, including 4.6 which has not yet been publicly released. This ITS will be closed. -- -- 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#4914) It's possible to add multiple config-Databases
by rhafer＠suse.de 05 Apr '07

05 Apr '07

Full_Name: Ralf Haferkamp Version: HEAD OS: Linux (Kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.166.70) Subject say it. You can add multiple olcDatabase=config Entries to the cn=config Backend. (With slapadd or through ldapadd) A fix is on the way to CVS. It will also make sure that olcDatabase=config always gets the Index 0.

1 0

(ITS#4913) configure & BerkleyDB
by fredo＠sundancer.us 04 Apr '07

04 Apr '07

Full_Name: Fred Obermann Version: 2.3.34 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.20.15.25) I just downloaded, built and installed openldap-2.3.34 using BerkeleyDB-4.5.20. There seems to be a disconnect between where openldap-2.3.34 'configure' expects db.h is and where Oracle's build procedure puts db.h. For 4.5.20, db.h is located in "/usr/local/BerkeleyDB.4.5/include". Setting: CPPFLAGS="I/usr/local/BerkeleyDB.4.5/include", prior to invoking 'configure' does not seem to enable 'configure' to find 'db.h'. Providing soft link from /usr/local/BerkeleyDB.4.5/include/db.h to /usr/include seems to fix this problem Furthermore there seems to be a disconnect between the Oracle naming convention for the BerkeleyDB libraries and what openldap's 'configure' utility seems to expect. I set: LIBS=-L/usr/local/BerkeleyDB.4.5/lib prior to invoking 'configure' But 'configure' is looking for libdb45.a or libdb-45.a or libdb4.5.a. However, what the Oracle build procedure produces are: libdb-4.5.a libdb-4.5.la libdb-4.5.so libdb-4.so libdb.a libdb.so Creating a soft link from libdb-4.5.a to libdb45.a seems to fix this problem. Nonetheless, it would be better if the 'configure' script were expanded to gracefully handle this latest release of BerkeleyDB from Oracle.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs