- openldap-bugs - openldap.org

(ITS#6306) Problems compiling OpenLDAP in 64 bit due to old libtool version included
by dam＠opencsw.org 24 Sep '09

24 Sep '09

Full_Name: Dagobert Michelsen Version: 2.4.18 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.103.225.254) There is a problem compiling the current OpenLDAP (2.4.18) in 64 bit on Solaris. The problem occurs when building with modules and enabling 64 bit in CFLAGS rather than setting CC to the compiler including flags. The source of the problem is the old libtool version 1.5.x included in OpenLDAP. The libtool maintainers recommended upgrading libtool to at least 2.2 where the problem was fixed. The corresponding libtool thread is available at <http://lists.gnu.org/archive/html/bug-libtool/2009-09/msg00017.html> This is the excerpt of my tests: This works fine: ./configure CC='/opt/studio/SOS11/SUNWspro/bin/cc -xarch=v9' CPPFLAGS='-I/opt/csw/include' LDFLAGS='-L/opt/csw/lib/64 -R/opt/csw/ lib/64' && gmake And it also works with modules: ./configure CC='/opt/studio/SOS11/SUNWspro/bin/cc -xarch=v9' CPPFLAGS='-I/opt/csw/include' LDFLAGS='-L/opt/csw/lib/64 -R/opt/csw/ lib/64' --enable-modules && gmake Without modules this works also: ./configure CC='/opt/studio/SOS11/SUNWspro/bin/cc' CFLAGS='-xarch=v9' CPPFLAGS='-I/opt/csw/include' LDFLAGS='-L/opt/csw/lib/64 -R/opt/csw/ lib/64' && gmake This does not work: ./configure CC='/opt/studio/SOS11/SUNWspro/bin/cc' CFLAGS='-xarch=v9' CPPFLAGS='-I/opt/csw/include' LDFLAGS='-L/opt/csw/lib/64 -R/opt/csw/ lib/64' --enable-modules && gmake For now this tiny patch fixed my problem, but it needs to be worked on for general usage: diff -Naur openldap-2.4.17.orig/build/ltmain.sh openldap-2.4.17.patched/build/ltmain.sh --- openldap-2.4.17.orig/build/ltmain.sh 2009-01-22 01:00:41.000000000 +0100 +++ openldap-2.4.17.patched/build/ltmain.sh 2009-09-11 14:26:06.136891084 +0200 @@ -4745,7 +4745,10 @@ case "$compile_command " in *" -static "*) ;; *) pic_flag_for_symtable=" $pic_flag";; - esac + esac;; + *-*-solaris*) + LTCFLAGS="$compiler_flags" + ;; esac # Now compile the dynamic symbol file.

1 0

Re: (ITS#6305) slapo-chain(5): description for chain-rebind-as-user missing
by ghenry＠OpenLDAP.org 24 Sep '09

24 Sep '09

----- michael(a)stroeder.com wrote: > Full_Name: Michael Str=EF=BF=BDder > Version: HEAD > OS:=20 > URL:=20 > Submission from: (NULL) (84.163.127.85) >=20 >=20 > In slapo-chain(5) there is no descriptive text for configuration > directive > 'chain-rebind-as-user' yet like for the other directives. Thanks, Will take a look. --=20 Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6305) slapo-chain(5): description for chain-rebind-as-user missing
by michael＠stroeder.com 24 Sep '09

24 Sep '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.127.85) In slapo-chain(5) there is no descriptive text for configuration directive 'chain-rebind-as-user' yet like for the other directives.

1 0

Re: (ITS#6303) Buffer overflow with new glibc
by h.b.furuseth＠usit.uio.no 24 Sep '09

24 Sep '09

jzeleny(a)redhat.com writes: > I guess new version of glibc has some kind of mechanism which is > checking boundaries of structures and isn't allowing write out of > those boundaries. Could you test if this works instead? http://folk.uio.no/hbf/ol-struct-hack-1.patch If that doesn't work, similar code elsewhere may be in danger. Not that it's important in this case since the back-ldif code isn't run often. It just avoids one malloc, one check for whether that succeeded, and one free. Your patch forgot the last two. Actually the boundary check you mention is exactly the problem the BVL_NAME macro avoids, though I'm not sure why I didn't just use the standard "struct hack". Maybe the problem is with padding bytes after fname. Anyway, I suppose this means the old "struct hack" is now definitely getting dangerous to use. Whatever is going on, I'd like to find out. Which versions of gcc and glibc, and which architecture is this? (32-bit i683, 64-bit amd, etc). And if it doesn't take much time, could you try if these variants fix the problem too? http://folk.uio.no/hbf/ol-struct-hack-2.patch http://folk.uio.no/hbf/ol-struct-hack-3.patch I don't plan to use them, we can use your variant if my first patch doesn't work. I'm just curious what's going on. -- Hallvard

1 0

(ITS#6304) Slapd freezes during SSL handshake when TLSVerifyClient=allow
by jzeleny＠redhat.com 24 Sep '09

24 Sep '09

Full_Name: Jan Zeleny Version: 2.4.18 OS: Fedora 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.40.79.66) Following bug report is a good introduction to the issue: https://bugzilla.redhat.com/show_bug.cgi?id=509230 I managed to reproduce it simply by turning on TLS and setting TLSVerifyClient allow. In that configuration local connections to ldaps still work, but connections from remote machines don't work in about 80-90% cases. I tried to trace the bug, so far I found that when using this option, slapd sends it's certificate to TCP socket and gets the EAGAIN in the middle of writing. After that it goes to epoll_wait and there it waits indefinitely. I suspect the EAGAIN happens because TCP socket is full or something like that. Notice that when you turn on debugging information about packet handling, this issue disappears - maybe socket has time to get empty? I tried and confirmed the bug in several versions of openldap (incl. 2.4.18) and several Linux distributions to eliminate the possibility this issue is caused by some other component or it was solved already.

1 0

(ITS#6303) Buffer overflow with new glibc
by jzeleny＠redhat.com 24 Sep '09

24 Sep '09

Full_Name: Jan Zeleny Version: 2.4.18 OS: Fedora 12 URL: http://jzeleny.fedorapeople.org/patches/openldap/openldap-2.4.18-ldif-buf-o… Submission from: (NULL) (62.40.79.66) I tried to make configuration directory (instead of config file) work in Fedora 12. I noticed that new builds of slapd fail during start with config dir. The start results in SIGABRT, backtrace and buffer overflow error. I traced the bug to ldif.c. I guess new version of glibc has some kind of mechanism which is checking boundaries of structures and isn't allowing write out of those boundaries. I made attached patch to avoid the issue. After testing it seems to be working well.

1 0

Re: (ITS#6301) PATCH - used red-black tree for response messages
by bduncan＠apple.com 23 Sep '09

23 Sep '09

On Sep 22, 2009, at 5:07 PM, Howard Chu wrote: > bduncan(a)apple.com wrote: >> Full_Name: Bryan Duncan >> Version: 2.4.16 >> OS: Mac OS X 10.6 >> URL: ftp://ftp.openldap.org/incoming/bryan-duncan-rbtree-090922.patch >> Submission from: (NULL) (17.224.21.109) >> >> >> Uploaded patch that replaces the linked-list of response messages >> with a >> red-black tree. This improves performance since random access to >> the response >> messages is needed. >> > Hmm, there is no such file at the above URL. Hmmm... there's some issue ftp'ing it up. New URL: http://public.me.com/bryan.duncan/bryan-duncan-rbtree.090922.patch > > Also, while I don't doubt that a tree structure beats a linked list > for performance, could you please describe the analysis that led you > to writing this patch? What problem were you tracking, and what > situation caused it? When running performance benchmarks we noticed one process was consuming huge amount (75%) of the CPU. Further analysis revealed two problems: 1) the vast majority of those cycles were spent in ldap_msgdelete(), walking the response message linked-list. 2) There was a lot of contention for the thread mutex that's held while the message list is walked. Thus we needed to reduce the time spent walking the list in order to achieve the desired performance. After switching to the red-black tree we saw CPU utilization for the process was down in the noise. > > Why did you use a red-black tree, rather than just using the AVL > code that's already in the source? I had a red-black tree implementation I knew had been tuned for performance and has been in shipping software. I'm not saying the OpenLDAP AVL code couldn't handle it. I could only implement one or the other, so I chose the one I was familiar with. > > In the future it would be a good idea to raise these topics on the > openldap-devel mailing list before diving in, since this is core > functionality and performance-related. Performance patches don't get > committed without test results showing a clear before/after gain. Yes, that's a good idea. My apologies for not raising the issue sooner. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ Bryan Duncan Apple

1 0

Re: (ITS#6299) Support for RFC 4529 in slapo-allowed
by masarati＠aero.polimi.it 23 Sep '09

23 Sep '09

> masarati(a)aero.polimi.it wrote: >>> If the client wants to request via slapo-allowed which attributes are >>> readable/writeable before adding another object class then object >>> classes >>> not >>> yet part of the entry could be used if the client adds the object class >>> name >>> prefixed with @. This is an extension to the semantics but should not >>> cause any >>> problem with existing clients. >> >> with the current implementation of slapo-allowed, the client does not do >> anything specific but requesting those special operational attributes. > > Yes. That's what I've implemented. Well, what slapo-allowed and MS AD > implement is limited anyway. E.g. no way to determine writeable attrs when > adding new entries. > >> It is not clear to me how the semantics you propose should be activated. >> If you mean that having some "@" + <objectClass> in the requested attrs >> should populate the allowedAttributes and allowedAttributesEffective >> attributes, I think it would be a significant distortion of the meaning >> of >> the requested attributes. > > Yes, my suggestion was that slapo-allowed looks at the attr list in the > search > request for occurences of "@" + <objectClass>. And then use each > <objectClass> > (if not yet in the set of current object classes of the entry) to evaluate > the > accompanying attrs and put them into allowedAttributes and/or > allowedAttributesEffective. > > Yes, that's a change in the current semantics. Not only a change in semantics, but also a poor choice, IMHO. How can the server determine whether a request is malformed or the client really wanted to trigger such an esoteric feature? > I now partially worked around the problem with new object classes in > web2ldap > by determining which attrs would be really new when adding a set of object > classes enabling all the input fields for these new attrs. But off course > that's not nice. > >> I'd rather favor defining a specific control request, that sort of >> "mimics" adding some attributes, including objectClass values, to an >> existing entry, so that allowedAttributes and allowedAttributesEffective >> are populated accordingly. > > There are some implementations of the Get Effective Rights control but > they > seem to slightly differ. That control's definition really sounds like an overkill, although I understand the intention of allowing clients to specify everything a DSA could use to determine access privileges. I'd favor a much lighter control. Perhaps, all the features allowed by that spec, and even more and better (possibly with a flexible mechanism) could be made optional. In any case, it should be clear that the result will only be a hint, or a guess, and the only reliable way to determine read access would be to actually read data, and, to determine write access, to attempt the operation using the noOp control. p.

1 0

Re: (ITS#6299) Support for RFC 4529 in slapo-allowed
by michael＠stroeder.com 23 Sep '09

23 Sep '09

masarati(a)aero.polimi.it wrote: >> If the client wants to request via slapo-allowed which attributes are >> readable/writeable before adding another object class then object classes >> not >> yet part of the entry could be used if the client adds the object class >> name >> prefixed with @. This is an extension to the semantics but should not >> cause any >> problem with existing clients. > > with the current implementation of slapo-allowed, the client does not do > anything specific but requesting those special operational attributes. Yes. That's what I've implemented. Well, what slapo-allowed and MS AD implement is limited anyway. E.g. no way to determine writeable attrs when adding new entries. > It is not clear to me how the semantics you propose should be activated. > If you mean that having some "@" + <objectClass> in the requested attrs > should populate the allowedAttributes and allowedAttributesEffective > attributes, I think it would be a significant distortion of the meaning of > the requested attributes. Yes, my suggestion was that slapo-allowed looks at the attr list in the search request for occurences of "@" + <objectClass>. And then use each <objectClass> (if not yet in the set of current object classes of the entry) to evaluate the accompanying attrs and put them into allowedAttributes and/or allowedAttributesEffective. Yes, that's a change in the current semantics. I now partially worked around the problem with new object classes in web2ldap by determining which attrs would be really new when adding a set of object classes enabling all the input fields for these new attrs. But off course that's not nice. > I'd rather favor defining a specific control request, that sort of > "mimics" adding some attributes, including objectClass values, to an > existing entry, so that allowedAttributes and allowedAttributesEffective > are populated accordingly. There are some implementations of the Get Effective Rights control but they seem to slightly differ. Ciao, Michael.

1 0

Re: (ITS#6302) second-guessing of libsasl ABI is incorrect for Linux distributions
by vorlon＠debian.org 22 Sep '09

22 Sep '09

--BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Patch attached. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=do-not-second-guess-sonames Rip out code that second-guesses the libsasl soname / Debian shlibs. If cyrus sasl upstream is breaking the ABI, this needs to be fixed upstream there, not kludged around upstream here! Debian bug #546885 Upstream ITS #6302 filed. Index: trunk/libraries/libldap/cyrus.c =================================================================== --- trunk.orig/libraries/libldap/cyrus.c +++ trunk/libraries/libldap/cyrus.c @@ -78,28 +78,6 @@ /* XXX not threadsafe */ static int sasl_initialized = 0; -#ifdef HAVE_SASL_VERSION - /* stringify the version number, sasl.h doesn't do it for us */ -#define VSTR0(maj, min, pat) #maj "." #min "." #pat -#define VSTR(maj, min, pat) VSTR0(maj, min, pat) -#define SASL_VERSION_STRING VSTR(SASL_VERSION_MAJOR, SASL_VERSION_MINOR, \ - SASL_VERSION_STEP) - { int rc; - sasl_version( NULL, &rc ); - if ( ((rc >> 16) != ((SASL_VERSION_MAJOR << 8)|SASL_VERSION_MINOR)) || - (rc & 0xffff) < SASL_VERSION_STEP) { - char version[sizeof("xxx.xxx.xxxxx")]; - sprintf( version, "%u.%d.%d", (unsigned)rc >> 24, (rc >> 16) & 0xff, - rc & 0xffff ); - - Debug( LDAP_DEBUG_ANY, - "ldap_int_sasl_init: SASL library version mismatch:" - " expected " SASL_VERSION_STRING "," - " got %s\n", version, 0, 0 ); - return -1; - } - } -#endif if ( sasl_initialized ) { return 0; } Index: trunk/servers/slapd/sasl.c =================================================================== --- trunk.orig/servers/slapd/sasl.c +++ trunk/servers/slapd/sasl.c @@ -1135,26 +1135,6 @@ #endif #ifdef HAVE_CYRUS_SASL -#ifdef HAVE_SASL_VERSION - /* stringify the version number, sasl.h doesn't do it for us */ -#define VSTR0(maj, min, pat) #maj "." #min "." #pat -#define VSTR(maj, min, pat) VSTR0(maj, min, pat) -#define SASL_VERSION_STRING VSTR(SASL_VERSION_MAJOR, SASL_VERSION_MINOR, \ - SASL_VERSION_STEP) - - sasl_version( NULL, &rc ); - if ( ((rc >> 16) != ((SASL_VERSION_MAJOR << 8)|SASL_VERSION_MINOR)) || - (rc & 0xffff) < SASL_VERSION_STEP) - { - char version[sizeof("xxx.xxx.xxxxx")]; - sprintf( version, "%u.%d.%d", (unsigned)rc >> 24, (rc >> 16) & 0xff, - rc & 0xffff ); - Debug( LDAP_DEBUG_ANY, "slap_sasl_init: SASL library version mismatch:" - " expected %s, got %s\n", - SASL_VERSION_STRING, version, 0 ); - return -1; - } -#endif sasl_set_mutex( ldap_pvt_sasl_mutex_new, --BXVAT5kNtrzKuDFl--

1 0

(ITS#6302) second-guessing of libsasl ABI is incorrect for Linux distributions
by vorlon＠debian.org 22 Sep '09

22 Sep '09

Full_Name: Steve Langasek Version: 2.4.17 OS: Debian URL: http://bugs.debian.org/546885 Submission from: (NULL) (66.93.39.86) Debian bug #546885 reports a problem with the Debian package of slapd aborting because it's running against an older version of libsasl than the one it was built against. Distribution packaging systems have provisions for declaring versioned dependencies when necessary, slapd should not have a blanket rule that assumes preceding versions of libsasl are incompatible: - if two versions of libsasl are incompatible but this has not been declared by way of an soname change, this is a bug in the library that should be forwarded to the libsasl upstream, not papered over in slapd - the version check assumes that running against an *older* libsasl than the one built against is a problem, but running against a *newer* libsasl is not, when I don't see any reason that should be the case. patch to remove this version check follows; it has been applied to the Debian openldap package.

1 0

Re: (ITS#6301) PATCH - used red-black tree for response messages
by hyc＠symas.com 22 Sep '09

22 Sep '09

bduncan(a)apple.com wrote: > Full_Name: Bryan Duncan > Version: 2.4.16 > OS: Mac OS X 10.6 > URL: ftp://ftp.openldap.org/incoming/bryan-duncan-rbtree-090922.patch > Submission from: (NULL) (17.224.21.109) > > > Uploaded patch that replaces the linked-list of response messages with a > red-black tree. This improves performance since random access to the response > messages is needed. > Hmm, there is no such file at the above URL. Also, while I don't doubt that a tree structure beats a linked list for performance, could you please describe the analysis that led you to writing this patch? What problem were you tracking, and what situation caused it? Why did you use a red-black tree, rather than just using the AVL code that's already in the source? In the future it would be a good idea to raise these topics on the openldap-devel mailing list before diving in, since this is core functionality and performance-related. Performance patches don't get committed without test results showing a clear before/after gain. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6299) Support for RFC 4529 in slapo-allowed
by masarati＠aero.polimi.it 22 Sep '09

22 Sep '09

> If the client wants to request via slapo-allowed which attributes are > readable/writeable before adding another object class then object classes > not > yet part of the entry could be used if the client adds the object class > name > prefixed with @. This is an extension to the semantics but should not > cause any > problem with existing clients. with the current implementation of slapo-allowed, the client does not do anything specific but requesting those special operational attributes. It is not clear to me how the semantics you propose should be activated. If you mean that having some "@" + <objectClass> in the requested attrs should populate the allowedAttributes and allowedAttributesEffective attributes, I think it would be a significant distortion of the meaning of the requested attributes. I'd rather favor defining a specific control request, that sort of "mimics" adding some attributes, including objectClass values, to an existing entry, so that allowedAttributes and allowedAttributesEffective are populated accordingly. p.

1 0

Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 22 Sep '09

22 Sep '09

On Sep 22, 2009, at 1:02 PM, Quanah Gibson-Mount wrote: > --On Tuesday, September 22, 2009 7:23 PM +0000 bduncan(a)apple.com > wrote: > >> Subject should have been: "PATCH - Added kqueue support to slapd" to >> make clear this ITS tracks a patch that has been submitted. > > What OS(es) has this kqueue support been tested with? For example, > the last time I looked at kqueue on OSX 10.5, it was very marginal, > and missing most of the important pieces, which meant it wouldn't > work for OpenLDAP or Postfix, etc. It was tested on OS X 10.6. Should work on all BSDs; nothing OSX- specific about the kqueue usage in the patch. As far as kqueue support in OS X 10.5, from what I see, most everything is there. Certainly all of the kqueue features in this patch are supported in OS X 10.5. -- Bryan Duncan

1 0

Re: (ITS#6300) Add kqueue support to slapd
by quanah＠zimbra.com 22 Sep '09

22 Sep '09

--On Tuesday, September 22, 2009 7:23 PM +0000 bduncan(a)apple.com wrote: > Subject should have been: "PATCH - Added kqueue support to slapd" to > make clear this ITS tracks a patch that has been submitted. What OS(es) has this kqueue support been tested with? For example, the last time I looked at kqueue on OSX 10.5, it was very marginal, and missing most of the important pieces, which meant it wouldn't work for OpenLDAP or Postfix, etc. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 22 Sep '09

22 Sep '09

Subject should have been: "PATCH - Added kqueue support to slapd" to make clear this ITS tracks a patch that has been submitted. -- Bryan

1 0

(ITS#6301) PATCH - used red-black tree for response messages
by bduncan＠apple.com 22 Sep '09

22 Sep '09

Full_Name: Bryan Duncan Version: 2.4.16 OS: Mac OS X 10.6 URL: ftp://ftp.openldap.org/incoming/bryan-duncan-rbtree-090922.patch Submission from: (NULL) (17.224.21.109) Uploaded patch that replaces the linked-list of response messages with a red-black tree. This improves performance since random access to the response messages is needed.

1 0

(ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 22 Sep '09

22 Sep '09

Full_Name: Bryan Duncan Version: 2.4.16 OS: Mac OS X 10.6 URL: ftp://ftp.openldap.org/incoming/bryan-duncan-kqueue-090922.patch Submission from: (NULL) (17.224.21.109) Added support for using kqueue in slapd (for systems that support kqueue(2).

1 0

(ITS#6299) Support for RFC 4529 in slapo-allowed
by michael＠stroeder.com 22 Sep '09

22 Sep '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.118.158) If the client wants to request via slapo-allowed which attributes are readable/writeable before adding another object class then object classes not yet part of the entry could be used if the client adds the object class name prefixed with @. This is an extension to the semantics but should not cause any problem with existing clients.

1 0

Re: (ITS#6296) Strong bind doesn't work in slapd-ldap when used by slapd-relay or slapo-translucent
by mrubas＠kerio.com 18 Sep '09

18 Sep '09

This is a multi-part message in MIME format. --------------070504020207040208060908 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit So far, it seems to be working. Good job, thanks. It was not easy to get fresh binary because I had to manage compilation with MSVC but that's another issue (ssl3_send_alert() in ITS#1955 & ITS#1954). Thanks again, M. masarati(a)aero.polimi.it wrote: >> I have to use slapd-ldap in "strong bind" mode which means that user >> binds using its own credentials and no identity assertion is performed. >> If slapd-ldap is the only module that is processing request then >> everything works fine. If slapd-ldap is processing an request forwarded >> from slapd-relay (with slapo-rwm) or request to database with >> slapo-translucent then the authentication problem occurs. >> > The solution was a little less intrusive than the one you proposed, but > your analysis was just fine and definitely effective in pointing me to the > core of the issue. It should now be fixed in HEAD, please test. > > servers/slapd/back-ldap/bind.c > new revision: 1.255; previous revision: 1.254 > > Thanks, p. > --------------070504020207040208060908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> So far, it seems to be working. Good job, thanks. It was not easy to get fresh binary because I had to manage compilation with MSVC but that's another issue (ssl3_send_alert() in ITS#1955 & ITS#1954). Thanks again, M. <a class="moz-txt-link-abbreviated" href="mailto:masarati@aero.polimi.it">masarati(a)aero.polimi.it</a> wrote: <blockquote cite="mid:38264.93.149.38.238.1253215000.squirrel@www.aero.polimi.it" type="cite"> <blockquote type="cite"> <pre wrap="">I have to use slapd-ldap in "strong bind" mode which means that user binds using its own credentials and no identity assertion is performed. If slapd-ldap is the only module that is processing request then everything works fine. If slapd-ldap is processing an request forwarded from slapd-relay (with slapo-rwm) or request to database with slapo-translucent then the authentication problem occurs. </pre> </blockquote> <pre wrap="">The solution was a little less intrusive than the one you proposed, but your analysis was just fine and definitely effective in pointing me to the core of the issue. It should now be fixed in HEAD, please test. servers/slapd/back-ldap/bind.c new revision: 1.255; previous revision: 1.254 Thanks, p. </pre> </blockquote> </body> </html> --------------070504020207040208060908--

1 0

Re: (ITS#6298) ldapsearch hangs after ldapadd
by tculjaga＠gmail.com 18 Sep '09

18 Sep '09

--00151743f754b6ee3f0473da2c09 Content-Type: text/plain; charset=ISO-8859-1 Aster recompiling OpenLDAP with changes to servers/slapd/back-bdb/idl.h > > #define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17 */ #define BDB_IDL_DB_SIZE (1<<(BDB_IDL_LOGN+1)) /* moved from 64k to 128K */ #define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+2)) /* moved from 128k to 256k */ I'm unable to reproduce the issue.... it looks like problem solved... time ldapsearch -h localhost -x -b ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr -w passwd objectClass=originatorPrefixID # extended LDIF # # LDAPv3 # base <ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr> with scope subtree # filter: objectClass=originatorPrefixID # requesting: ALL # <----------------snip--------------------> # 000010, 078120.100.10000.100, 385, bestMatchPrefixList, sipDirektor, ot.hr dn: originatorPrefixID=000010,carrierPrefixID=078120.100.10000.100,bestMatchPr efix=385,ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr originatorPrefix: 000010 priority: 100 originator: T-COM/HT originatorPrefixID: 000010 objectClass: top objectClass: originatorPrefixID # search result search: 2 result: 0 Success # numResponses: 84256 # numEntries: 84255 real 0m22.500s user 0m1.635s sys 0m1.671s [tculjaga@l01lnp1 lib]$ [tculjaga@l01lnp1 lib]$ What can we expect as the DB grows? Does it mean i will have to increase the values again? What is the limit and drawback? Tihomir. On Fri, Sep 18, 2009 at 10:10 AM, Tihomir Culjaga <tculjaga(a)gmail.com>wrote: > I'm gonna try this: > > > In the file 'servers/slapd/back-bdb/idl.h': > > #define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17 */ > > #define BDB_IDL_DB_SIZE (1<<(BDB_IDL_LOGN+1)) /* modified from 64k > to 128K */ > #define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+2)) /* modified from 128k > to 256k */ > > > > i have a question for the line in the file 'include/ldap_pvt_thread.h': > > define LDAP_PVT_THREAD_STACK_SIZE ( 1 * 1024 * 1024 * sizeof(void *) ) > > > ehat is sizeof(void *) when i run 64bit OS? > > > > > > On Fri, Sep 18, 2009 at 8:49 AM, Howard Chu <hyc(a)symas.com> wrote: > >> tculjaga(a)gmail.com wrote: >> >>> Full_Name: Tihomir Culjaga >>> Version: 2.4.18 >>> OS: CentOS 5.3 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (93.136.5.55) >>> >> >> commands to perform whole-tree ldapsearch >>> >> >> Note to developers: this description is a red herring. The actual search >> that demonstrates the problem was posted later, here: >> >> http://www.openldap.org/lists/openldap-technical/200909/msg00129.html >> >> ldapsearch -h localhost -x -b >>> ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr >>> -w >>> passwd >>> >>> >>> >>> DB information >>> >>> 3437278 entries >>> >>> du -c -h /var/lib/ldap/*.bdb >>> 204K /var/lib/ldap/bestMatchPrefix.bdb >>> 982M /var/lib/ldap/dn2id.bdb >>> 2.4G /var/lib/ldap/id2entry.bdb >>> 1.9M /var/lib/ldap/objectClass.bdb >>> 1.3M /var/lib/ldap/originatorPrefixID.bdb >>> 48M /var/lib/ldap/uniqueID.bdb >>> 3.4G total >>> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > > --00151743f754b6ee3f0473da2c09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aster recompiling OpenLDAP with changes to servers/slapd/back-bdb/idl.h<blo= ckquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204,= 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"></blockquote> #def= ine BDB_IDL_LOGN=A0=A0=A0 16=A0=A0=A0=A0=A0 /* DB_SIZE is 2^16, UM_SIZE is = 2^17 */ #define BDB_IDL_DB_SIZE=A0=A0=A0=A0=A0=A0=A0=A0 (1<<(BDB_IDL_LOGN= +1)) /* moved from 64k to 128K */ #define BDB_IDL_UM_SIZE=A0=A0=A0=A0=A0=A0=A0=A0 (1<<(BDB_IDL_LOGN+2))= /* moved from 128k to 256k */ I'm unable to reproduce the i= ssue.... it looks like problem solved... time ldapsearch=A0 -h l= ocalhost -x -b ou=3DbestMatchPrefixList,ou=3DsipDirektor,dc=3Dot,dc=3Dhr=A0= -D cn=3Dadmin,dc=3Dot,dc=3Dhr -w passwd objectClass=3DoriginatorPrefixID<b= r> # extended LDIF # # LDAPv3 # base <ou=3DbestMatchPrefixList,ou= =3DsipDirektor,dc=3Dot,dc=3Dhr> with scope subtree # filter: objectCl= ass=3DoriginatorPrefixID # requesting: ALL # <-------------= ---snip--------------------> # 000010, 078120.100.10000.100, 385, bestMatchPrefixList, sipDirektor, = <a href=3D"http://ot.hr">ot.hr</a> dn: originatorPrefixID=3D000010,carri= erPrefixID=3D078120.100.10000.100,bestMatchPr =A0efix=3D385,ou=3DbestMat= chPrefixList,ou=3DsipDirektor,dc=3Dot,dc=3Dhr originatorPrefix: 000010 priority: 100 originator: T-COM/HT origin= atorPrefixID: 000010 objectClass: top objectClass: originatorPrefixID= # search result search: 2 result: 0 Success # numRespo= nses: 84256 # numEntries: 84255 real=A0=A0=A0 0m22.500s user=A0=A0=A0 0m1.635= s sys=A0=A0=A0=A0 0m1.671s [tculjaga@l01lnp1 lib]$ [tculjaga@l01l= np1 lib]$ What can we expect as the DB grows? Does it mean i wi= ll have to increase the values again? What is the limit and drawback? Tihomir. <div= class=3D"gmail_quote">On Fri, Sep 18, 2009 at 10:10 AM, Tihomir Culjaga <s= pan dir=3D"ltr"><<a href=3D"mailto:tculjaga@gmail.com">tculjaga(a)gmail.co= m</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm gonna try= this: In the file 'servers/slapd/back-bdb/idl.h': <b= r> #define BDB_IDL_LOGN=A0=A0=A0 16=A0=A0=A0=A0=A0 /* DB_SIZE is 2^16, UM_SIZE= is 2^17 */ #define BDB_IDL_DB_SIZE=A0=A0=A0=A0=A0=A0=A0=A0 (1<&l= t;(BDB_IDL_LOGN+1)) /* modified from 64k to 128K */ #define BDB_IDL_UM_SIZE=A0=A0=A0=A0=A0=A0=A0=A0 (1<<(BDB_IDL_LOGN+2))= /* modified from 128k to 256k */ i have a question for the = line in the file 'include/ldap_pvt_thread.h': define LDAP_PV= T_THREAD_STACK_SIZE ( 1 * 1024 * 1024 * sizeof(void *) ) ehat is sizeof(void *) when i run 64bit OS?<div><div></div><div cla= ss=3D"h5"> <div class=3D"gmail_quote">On Fri, Sep 18, 20= 09 at 8:49 AM, Howard Chu <<a href=3D"mailto:hyc@symas= .com" target=3D"_blank">hyc(a)symas.com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href=3D"mailto= :tculjaga@gmail.com" target=3D"_blank">tculjaga(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Full_Name: Tihomir Culjaga Version: 2.4.18 OS: CentOS 5.3 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (93.136.5.55) </blockquote> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> commands to perform whole-tree ldapsearch </blockquote> Note to developers: this description is a red herring. The actual search th= at demonstrates the problem was posted later, here: <a href=3D"http://www.openldap.org/lists/openldap-technical/200909/msg00129= .html" target=3D"_blank">http://www.openldap.org/lists/openldap-technical/2= 00909/msg00129.html</a> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> =A0 =A0ldapsearch =A0-h localhost -x -b ou=3DbestMatchPrefixList,ou=3DsipDirektor,dc=3Dot,dc=3Dhr -D cn=3Dadmin,dc= =3Dot,dc=3Dhr -w passwd DB information 3437278 entries du -c -h /var/lib/ldap/*.bdb =A0 204K /var/lib/ldap/bestMatchPrefix.bdb =A0 982M /var/lib/ldap/dn2id.bdb =A0 2.4G /var/lib/ldap/id2entry.bdb =A0 1.9M /var/lib/ldap/objectClass.bdb =A0 1.3M /var/lib/ldap/originatorPrefixID.bdb =A0 48M =A0/var/lib/ldap/uniqueID.bdb =A0 3.4G total </blockquote> -- =A0-- Howard Chu =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> </div></div></blockquote></div> --00151743f754b6ee3f0473da2c09--

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 18 Sep '09

18 Sep '09

masarati(a)aero.polimi.it wrote: >> http://purgatory.spnet.net/~karavelov/faillog >> > > There is no corruption. What happens is that back-bdb, when returning the > entry from the cache, correctly locates it based on the indexed attrs used > in the filter, but at some point decides that the entry is outside the > scope of your search: > > Aug 5 16:44:22 work slapd[17541]: bdb_search: 87 scope not okay > > This should not happen, since your search is performed with exactly the > same parameters used for the original one, and the scope is 1 (onelevel). > > I wonder what happens there. Could you walk through the failing request > with a debugger, and print some values? I'd like to see, from within > bdb_search(), line 780 of back-bdb/search.c of re23, the value of > > op->o_request->oq_search > > base > > *ei->ei_parent > > p. > Hello, I have switched to slapd 2.4.18 (last release) and the problem still pesist. I have made the requested debug session. The relevant log file could be found here: http://purgatory.spnet.net/~karavelov/log The gdb session is here: http://purgatory.spnet.net/~karavelov/debug The configuration file is here: http://purgatory.spnet.net/~karavelov/slapd.conf.clean I have tried without pcacheValidate and pcachePosition options without any difference. Thanks in advance Luben

1 0

Re: (ITS#6298) ldapsearch hangs after ldapadd
by tculjaga＠gmail.com 18 Sep '09

18 Sep '09

--000325558fd60e8a6a0473d5abd4 Content-Type: text/plain; charset=ISO-8859-1 I'm gonna try this: In the file 'servers/slapd/back-bdb/idl.h': #define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17 */ #define BDB_IDL_DB_SIZE (1<<(BDB_IDL_LOGN+1)) /* modified from 64k to 128K */ #define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+2)) /* modified from 128k to 256k */ i have a question for the line in the file 'include/ldap_pvt_thread.h': define LDAP_PVT_THREAD_STACK_SIZE ( 1 * 1024 * 1024 * sizeof(void *) ) ehat is sizeof(void *) when i run 64bit OS? On Fri, Sep 18, 2009 at 8:49 AM, Howard Chu <hyc(a)symas.com> wrote: > tculjaga(a)gmail.com wrote: > >> Full_Name: Tihomir Culjaga >> Version: 2.4.18 >> OS: CentOS 5.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (93.136.5.55) >> > > commands to perform whole-tree ldapsearch >> > > Note to developers: this description is a red herring. The actual search > that demonstrates the problem was posted later, here: > > http://www.openldap.org/lists/openldap-technical/200909/msg00129.html > > ldapsearch -h localhost -x -b >> ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr >> -w >> passwd >> >> >> >> DB information >> >> 3437278 entries >> >> du -c -h /var/lib/ldap/*.bdb >> 204K /var/lib/ldap/bestMatchPrefix.bdb >> 982M /var/lib/ldap/dn2id.bdb >> 2.4G /var/lib/ldap/id2entry.bdb >> 1.9M /var/lib/ldap/objectClass.bdb >> 1.3M /var/lib/ldap/originatorPrefixID.bdb >> 48M /var/lib/ldap/uniqueID.bdb >> 3.4G total >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --000325558fd60e8a6a0473d5abd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm gonna try this: In the file 'servers/slapd/back-bdb/= idl.h': #define BDB_IDL_LOGN=A0=A0=A0 16=A0=A0=A0=A0=A0 /* DB_SI= ZE is 2^16, UM_SIZE is 2^17 */ #define BDB_IDL_DB_SIZE=A0=A0=A0=A0= =A0=A0=A0=A0 (1<<(BDB_IDL_LOGN+1)) /* modified from 64k to 128K */<br= > #define BDB_IDL_UM_SIZE=A0=A0=A0=A0=A0=A0=A0=A0 (1<<(BDB_IDL_LOGN+2))= /* modified from 128k to 256k */ i have a question for the = line in the file 'include/ldap_pvt_thread.h': define LDAP_PV= T_THREAD_STACK_SIZE ( 1 * 1024 * 1024 * sizeof(void *) ) ehat is sizeof(void *) when i run 64bit OS? <div= class=3D"gmail_quote">On Fri, Sep 18, 2009 at 8:49 AM, Howard Chu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>>= wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href=3D"mailto= :tculjaga@gmail.com" target=3D"_blank">tculjaga(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Full_Name: Tihomir Culjaga Version: 2.4.18 OS: CentOS 5.3 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (93.136.5.55) </blockquote> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> commands to perform whole-tree ldapsearch </blockquote> Note to developers: this description is a red herring. The actual search th= at demonstrates the problem was posted later, here: <a href=3D"http://www.openldap.org/lists/openldap-technical/200909/msg00129= .html" target=3D"_blank">http://www.openldap.org/lists/openldap-technical/2= 00909/msg00129.html</a> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> =A0 =A0ldapsearch =A0-h localhost -x -b ou=3DbestMatchPrefixList,ou=3DsipDirektor,dc=3Dot,dc=3Dhr -D cn=3Dadmin,dc= =3Dot,dc=3Dhr -w passwd DB information 3437278 entries du -c -h /var/lib/ldap/*.bdb =A0 204K /var/lib/ldap/bestMatchPrefix.bdb =A0 982M /var/lib/ldap/dn2id.bdb =A0 2.4G /var/lib/ldap/id2entry.bdb =A0 1.9M /var/lib/ldap/objectClass.bdb =A0 1.3M /var/lib/ldap/originatorPrefixID.bdb =A0 48M =A0/var/lib/ldap/uniqueID.bdb =A0 3.4G total </blockquote> -- =A0-- Howard Chu =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> --000325558fd60e8a6a0473d5abd4--

1 0

Re: (ITS#6298) ldapsearch hangs after ldapadd
by hyc＠symas.com 17 Sep '09

17 Sep '09

tculjaga(a)gmail.com wrote: > Full_Name: Tihomir Culjaga > Version: 2.4.18 > OS: CentOS 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.136.5.55) > commands to perform whole-tree ldapsearch Note to developers: this description is a red herring. The actual search that demonstrates the problem was posted later, here: http://www.openldap.org/lists/openldap-technical/200909/msg00129.html > ldapsearch -h localhost -x -b > ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr -w > passwd > > > > DB information > > 3437278 entries > > du -c -h /var/lib/ldap/*.bdb > 204K /var/lib/ldap/bestMatchPrefix.bdb > 982M /var/lib/ldap/dn2id.bdb > 2.4G /var/lib/ldap/id2entry.bdb > 1.9M /var/lib/ldap/objectClass.bdb > 1.3M /var/lib/ldap/originatorPrefixID.bdb > 48M /var/lib/ldap/uniqueID.bdb > 3.4G total -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6298) ldapsearch hangs after ldapadd
by tculjaga＠gmail.com 17 Sep '09

17 Sep '09

--0015175cf9f62a63290473d460e8 Content-Type: text/plain; charset=ISO-8859-1 please find the relevant logs/config/ldifs on ftp://sulaco.optinet.hr bug/bugreport Tihomir. --0015175cf9f62a63290473d460e8 Content-Type: text/html; charset=ISO-8859-1 please find the relevant logs/config/ldifs on <a href="ftp://sulaco.optinet.hr">ftp://sulaco.optinet.hr </a> bug/bugreport Tihomir. --0015175cf9f62a63290473d460e8--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs