- openldap-bugs - openldap.org

Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by hyc＠symas.com 14 Oct '10

14 Oct '10

Arthur de Jong wrote: > On Wed, 2010-10-13 at 14:17 -0700, Howard Chu wrote: >> It seems you can workaround this by changing tls_g.c's invocation of >> gnutls_bye() to use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR. However, that >> strikes me as fundamentally wrong, since libldap is clearly closing both >> directions when it gets here. I think the bug is in gnutls_bye(), it shouldn't >> be waiting indefinitely when it tries to read the peer's Close alert. I'm not >> sure it should even be trying to read that at all; some peers may never send it. > > I can't comment on the GnuTLS API because I haven't used it before. Can > you file a bugreport with GnuTLS? Do you need any more input from my > end? What is the GnuTLS version number? Seems like you should be submitting this to their tracker anyway, as the original reporter. https://savannah.gnu.org/support/?group=gnutls >> Note that because you're breaking the connection without warning, TCP doesn't >> know that the connection is gone, so there will be no error detected when >> gnutls attempts to send its own Close alert. In this case, it will probably >> block for 2*MSL before getting any further. > > In my tests I haven't waited that long (I think). Do you know if there > are any problems with using setsockopt(SO_RCVTIMEO) and > setsockopt(SO_SNDTIMEO) on the socket? > I have no idea whether GnuTLS handles asynch I/O properly or not. If you're only setting these options immediately before closing, I don't see why it should cause any problems. But GnuTLS has enough flaws in general that I wouldn't claim it ever does anything right or as expected. -- -- 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#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 14 Oct '10

14 Oct '10

Version 2... Part 3 of 3 of this patch with the request changes to options.c is now available for review. The full details are located here: http://cr.opensolaris.org/~djl/openldap-patch3/ The revised patch has been updated to include all changes as on 10-14-10AM including the commit of: Modified Files: cyrus.c 1.159 -> 1.160 The only file modified between the first and second version of this patch was options.c The web link above includes both the original patch (as version 1) and the revised patch (version 2) with full diff -Us, tarballs and such for both versions. Retesting has been completed on both Solaris x86 and Solaris SPARC. Both platforms have been re-tested under 32-bit and 64-bit compiles. All regression testing passed successfully. IPR Notice This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Oracle Corporation. Oracle Corporation has not assigned rights and/or interest in this work to any party. I, Douglas Leavitt am authorized by Oracle Corporation, my employer, to release this work under the following terms. Thank you for your consideration, Doug.

1 0

Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org 14 Oct '10

14 Oct '10

--=-6hDPPEPvd2QOD+/Er+Q8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-10-13 at 14:17 -0700, Howard Chu wrote: > It seems you can workaround this by changing tls_g.c's invocation of=20 > gnutls_bye() to use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR. However, = that=20 > strikes me as fundamentally wrong, since libldap is clearly closing both= =20 > directions when it gets here. I think the bug is in gnutls_bye(), it shou= ldn't=20 > be waiting indefinitely when it tries to read the peer's Close alert. I'm= not=20 > sure it should even be trying to read that at all; some peers may never s= end it. I can't comment on the GnuTLS API because I haven't used it before. Can you file a bugreport with GnuTLS? Do you need any more input from my end? > Note that because you're breaking the connection without warning, TCP doe= sn't=20 > know that the connection is gone, so there will be no error detected when= =20 > gnutls attempts to send its own Close alert. In this case, it will probab= ly=20 > block for 2*MSL before getting any further. In my tests I haven't waited that long (I think). Do you know if there are any problems with using setsockopt(SO_RCVTIMEO) and setsockopt(SO_SNDTIMEO) on the socket? --=20 -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org -- --=-6hDPPEPvd2QOD+/Er+Q8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJMt01mAAoJECqLdGgQ4K/B5ogP/ihMljH3hvC7aKd6W4Mt526F J/W6Gpx8w7UUI2uymq23epRa1s/2aLWnPDpdP9uGbswrdBrOsRrUARWHPRy/I61L 8JhCiFcEXqyMJxrm7sW4uaVTHBS1AZPklCdfQ0+s4JdVKccLjOkUGJFh4sQL5TtA 3syopgjuQ2inqc9+wA3ZuGL3HgiOuLjXQauHQ0YbWdr+QYZjDZcero5RU6HU+jIv uh+SyQaTiTkzDc8MqGc/ImPZ5R55YORiKUF90Wr+3lGPGCloj8snqfUbMpjNTBkG jUPKBrl+bKgmKPtnpJzLzeCAZsH/rMdyhL0Apr1AZb5Ay8uHqxE3bHE/bTL7/mxA J/RvZlIR/BGed1dWWlQ+j2YE8zsCfvUNxH1GbbmWqk6pO+4BbZP/7XHs6rMW7XkL bT+LwW6J70ZrUFR7XEjkn/a++S7dm9zRoIVDvVgw7HduQSVU+nVQRIwh/CxyGhoG J8OefK5OEYuAqZjFJk8U1OpslstpGDvMjr7nbnY2TRkAg1QshydvhFaq+cp56Uey RT97jWFYTYuIUTrWh8SOog/NxE0WaBJuUqx/Lz/mBX7BkJj+zSDT9SD6IntV73eJ GBBr5wgyEzYyu7pg9uo3Ux16XFp+wwtjMHd8H9/EEEsBjOkuPyGVCz/9CynUgegr A/rMhnTnXTAt7zM/ydh2 =uUuU -----END PGP SIGNATURE----- --=-6hDPPEPvd2QOD+/Er+Q8--

1 0

Re: (ITS#6675) ConnectException UnknownHostException using subdomain URL when searching
by quanah＠zimbra.com 14 Oct '10

14 Oct '10

--On Thursday, October 14, 2010 10:54 AM +0000 adolfo(a)ingenia.es wrote: > Full_Name: Adolfo Cort?s > Version: openldap-2.3.43-12.el5 > OS: CentOS release 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.15.226.90) I see nothing in this report that has to do with OpenLDAP. I.e., you do not show any problems with ldapsearch or any other utility provided by the OpenLDAP Foundation. All of your information is about Java/JNDI, none of which uses the OpenLDAP Code base. I advise you to contact Oracle if you have questions/issues with JNDI. I would note that there are far superior Java API's for connecting to LDAP than JNDI, and that Active Directory, while LDAP "like", is not truly LDAP, and has many unique quirks. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6675) ConnectException UnknownHostException using subdomain URL when searching
by adolfo＠ingenia.es 14 Oct '10

14 Oct '10

Full_Name: Adolfo Cortés Version: openldap-2.3.43-12.el5 OS: CentOS release 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.15.226.90) I try to connect to an Active directory from a java application using JNDI /OpenLDAP openldap-2.3.43-12.el5 in CentOS release 5.2 When i did a search i get a CommunicationException Error : javax.naming.CommunicationException: xxxxxxxx.es:636 [Root exception is java.net.UnknownHostException: xxxxxxxx.es]] xxxxxxxx.es:636 is reachable and another operations over LDAP as create user goes fine. I see that the problem is related to the DNS configuration: the Active Directory server DNS is aaaaa.bbbbb.xxxxxxxx.es but the base search is only xxxxxxxx.es when I do the search i get the exception because it takes xxxxxxxx.es instead of ssss.xxxxxxxx.es to perform the operation. I tried to solve it adding xxxxxxxx.es to hosts and writing the same IP of aaaaa.bbbbb.xxxxxxxx.es , so the bypass works and the connection goes but now i have a new problem, when i execute the search it connects but retrieves a Referral Limit Exception, iŽm thinking because there are jumps or confussion between aaaaa.bbbbb.xxxxxxxx.es and xxxxxxxx.es because of the hosts bypass i did. So my workaround doesnŽt works and i need to know or solve the connection problem for use subdomain DNS and domain in search base. Connection Parameters: everytihg goes right, is interesting the url, using not secure ldap protocol I also get the same error. [url: ldaps://aaaaa.bbbbb.xxxxxxxx.es] java.naming.security.authentication:simple Usuario mypassword(a)bbbbb.xxxxxxxx.es] Password[getLDAPropertiesSSL]:mypassword] keystore[getLDAPropertiesSSL]:/opt/java/jre/lib/security/jssecacerts trustStore[getLDAPropertiesSSL]:/opt/java/jre/lib/security/jssecacerts Especificacion uso SSL[getLDAPPropertiesSSL]java.naming.security.protocol ssl Search details: see that base DC is xxxxxxxx.es [base: OU=YYY,DC=xxxxxxxx,DC=es] [searchFilter: (&(objectClass=group)(cn={0}))] [filterArgs: new String[] {Usuarios}] [searchControls: SUBTREE_SCOPE, Atributes null, returningobjflag true] This Hosts file doesnŽt produce the Communication ERROR aaaaa.bbbbb.xxxxxxxx.es ccc.ccc.ccc.ccc xxxxxxxx.es ccc.ccc.ccc.ccc With this hosts file i get the Communication ERROR aaaaa.bbbbb.xxxxxxxx.es ccc.ccc.ccc.ccc If i try this search directly in the AD server console, it works giving me the results. Thanks in advance, Adolfo

1 0

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by hyc＠symas.com 13 Oct '10

13 Oct '10

doug.leavitt(a)oracle.com wrote: > Part 3 of 3 of this patch > Part #1 delivered as: ITS#6669 remove obsolete SunOS4 LWP support > Part #2 delivered as: ITS#6672 mutex cleanup > > Is now available for review. The full details are located here: > > http://cr.opensolaris.org/~djl/openldap-patch3/ > > This patch is part 3 of 3 of the original ITS #6625 effort. > (aka openldap draft-zeilenga-ldap-c-api-concurrency) (aka CONCURRENCY) > This patch contains the library modifications to implement CONCURRENCY > as discussed previously in ITS #6625, on the openldap-devel mail list. > > This patch uses the new LDAP_MUTEX_[UN]LOCK macros, delivered by patch2. > Regression testing (post conversion) was performed using both 32-bit and > 64-bit x86 > compiles on an OpenSolaris system. In options.c, I'd rather just see "rc = foo; break;" instead of UNLOCK_RETURN() everywhere. (With the final unlock, return rc at the end of the function.) Aside from that things look ok to me. Anyone else have comments? > Additionally regular ongoing Solaris system testing is being performed > using the libraries built with this patch on both Solaris SPARC and > Solaris x86 systems. > > As previously shown in Round 3 codereview, there seems to be no performance > degradation with this patch, and a slight performance improvement with > the LDAP > server when using back-ldap and back-meta features of the server. > > IPR Notice > > This patch file is derived from OpenLDAP Software. All of the > modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Oracle Corporation. Oracle Corporation has not assigned rights and/or > interest > in this work to any party. I, Douglas Leavitt am authorized by Oracle > Corporation, > my employer, to release this work under the following terms. > > Thank you for your consideration, > Doug. > > > > -- -- 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#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 13 Oct '10

13 Oct '10

Part 3 of 3 of this patch Part #1 delivered as: ITS#6669 remove obsolete SunOS4 LWP support Part #2 delivered as: ITS#6672 mutex cleanup Is now available for review. The full details are located here: http://cr.opensolaris.org/~djl/openldap-patch3/ This patch is part 3 of 3 of the original ITS #6625 effort. (aka openldap draft-zeilenga-ldap-c-api-concurrency) (aka CONCURRENCY) This patch contains the library modifications to implement CONCURRENCY as discussed previously in ITS #6625, on the openldap-devel mail list. This patch uses the new LDAP_MUTEX_[UN]LOCK macros, delivered by patch2. Regression testing (post conversion) was performed using both 32-bit and 64-bit x86 compiles on an OpenSolaris system. Additionally regular ongoing Solaris system testing is being performed using the libraries built with this patch on both Solaris SPARC and Solaris x86 systems. As previously shown in Round 3 codereview, there seems to be no performance degradation with this patch, and a slight performance improvement with the LDAP server when using back-ldap and back-meta features of the server. IPR Notice This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Oracle Corporation. Oracle Corporation has not assigned rights and/or interest in this work to any party. I, Douglas Leavitt am authorized by Oracle Corporation, my employer, to release this work under the following terms. Thank you for your consideration, Doug.

1 0

Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by hyc＠symas.com 13 Oct '10

13 Oct '10

Arthur de Jong wrote: > On Wed, 2010-10-13 at 01:05 -0700, Howard Chu wrote: >> arthur(a)arthurdejong.org wrote: >>> If the connection is opened without TLS ldap_unbind() only writes some data on >>> the connection and then closes it but with TLS it expects some response back. >>> Since read() is used this blocks. >> >> Looks like this is a GnuTLS issue. Have you duplicated this with OpenSSL? > > I can confirm that this only happens if libldap is linked with GnuTLS > and not when it is linked against OpenSSL. It seems you can workaround this by changing tls_g.c's invocation of gnutls_bye() to use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR. However, that strikes me as fundamentally wrong, since libldap is clearly closing both directions when it gets here. I think the bug is in gnutls_bye(), it shouldn't be waiting indefinitely when it tries to read the peer's Close alert. I'm not sure it should even be trying to read that at all; some peers may never send it. Note that because you're breaking the connection without warning, TCP doesn't know that the connection is gone, so there will be no error detected when gnutls attempts to send its own Close alert. In this case, it will probably block for 2*MSL before getting any further. -- -- 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#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org 13 Oct '10

13 Oct '10

--=-r1RmaIBBY6pCvl2u7gnR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-10-13 at 01:05 -0700, Howard Chu wrote: > arthur(a)arthurdejong.org wrote: > > If the connection is opened without TLS ldap_unbind() only writes some = data on > > the connection and then closes it but with TLS it expects some response= back. > > Since read() is used this blocks. >=20 > Looks like this is a GnuTLS issue. Have you duplicated this with OpenSSL? I can confirm that this only happens if libldap is linked with GnuTLS and not when it is linked against OpenSSL. --=20 -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org -- --=-r1RmaIBBY6pCvl2u7gnR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJMthnmAAoJECqLdGgQ4K/BXucP/RnIZ5OWQtivRE94QBQyvb2C hSoQb0U+ToQZucUDxxsIoFO81eEKTfOk5M1RVawzVVDUviq7YVxiE28BEbZQMvix FPiyEYFsUhrsq+ieRMupYS1tsSXE+6fZUjRVJ7JXYMJyMy/sG17zzMJhD/GXfB3Z A2yewks+jl+1i88w55ufwvPAwDgo3TIS1VudvA1K9gJ1wOoDY3jUHCAuUGjDLQ6V kHZ8IYmyRgspD7/pjjCfIewGkoy+ARzguPl28bNcai9xlvnNCmDfg1ECeGoZ5hwD tGTRGTAChhsYX+Aflv0UHRgIk1mPThdFCLgwpda36faiYFsjjWdDKw8u0owqgeLX OUnjkZ+3Q7eetROaqi+VtAqKQ78pRmsMbydsF0O88fERxDOYTGFMqdPItzPtFay5 uFFWBt/SaJruxU/FDNM87lAoL6uOBuQSGJJLoTRa8Sh8cjwakrN/NbIYcEwYBaSJ mNCoeFudWTJLvEa/4Iflu3RXR74599J4/QVyHJUm5GScyLEtfqB+7Vs9FH5Fqni8 qr+OdVVxw1x93WEEFMRv6RRBcsTFhjDFiP3vZ47jez4QLY9lU7iIzAD86I1jT37e CV+oZa2o/vgZR5O8NLsK23c5JM8nGDMBmaNo4c+iTDCxcI+zAUulG2XLVh9u4u7w F/KVk/Tt1bHunrjDWHyF =pUs6 -----END PGP SIGNATURE----- --=-r1RmaIBBY6pCvl2u7gnR--

1 0

Re: (ITS#6674) OpenLDAP 2.4.16 has very high CPU load on Solaris 10, x86
by quanah＠zimbra.com 13 Oct '10

13 Oct '10

--On Wednesday, October 13, 2010 10:11 AM +0000 donal.duane(a)ericsson.com wrote: > Full_Name: Donal Duane > Version: 2.4.16 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.45.199.134) The current stable release is 2.4.23. Please use the current release. You also should note the size of your database, BDB version (and whether or not it is up to date on patches), and the relevant configuration bits for the database configuration. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6674) OpenLDAP 2.4.16 has very high CPU load on Solaris 10, x86
by donal.duane＠ericsson.com 13 Oct '10

13 Oct '10

Full_Name: Donal Duane Version: 2.4.16 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.45.199.134) Hi, I would like to know if this is a known issue, and if so, if a fix has been issued. We have only recently started using OpenLDAP 2.4.16 on Solaris 10, x86 HW. (Because of this, we have no previous benchmark for CPU usage for OpenDLAP for comparison - we also have sparc systems, but have not stress tested OpenLDAP on sparc yet). We have noticed that the slapd process is using a huge amount of CPU. There are massive CPU time spikes obvious over a period of time which we monitored, reaching 520 CPU seconds and even 700 CPU seconds at one stage. there are also some completely flat periods. The activities seem to be purely LDAP searches. Processor info: # psrinfo -pv The physical processor has 4 virtual processors (0 4 8 12) x86 (chipid 0x0 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz The physical processor has 4 virtual processors (1 5 9 13) x86 (chipid 0x1 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz The physical processor has 4 virtual processors (2 6 10 14) x86 (chipid 0x2 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz The physical processor has 4 virtual processors (3 7 11 15) x86 (chipid 0x3 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz # isainfo -b 64 => (64 bit) # uname -a SunOS atrcxb1226 5.10 Generic_142901-13 i86pc i386 i86pc Any help appreciated. Regards, Dónal

1 0

Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by hyc＠symas.com 13 Oct '10

13 Oct '10

arthur(a)arthurdejong.org wrote: > Full_Name: Arthur de Jong > Version: 2.4.23 > OS: Debian/unstable > URL: > Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) > > > When a network connection to the LDAP server fails (is severed with iptables in > my set-up) the error is detected properly with ldap_result() > (LDAP_OPT_TIMELIMIT, LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT options are > set), however closing the connection with ldap_unbind() hangs indefinitely on a > read() operation (determined by strace) when using a ldaps:// connection. > > If the connection is opened without TLS ldap_unbind() only writes some data on > the connection and then closes it but with TLS it expects some response back. > Since read() is used this blocks. Looks like this is a GnuTLS issue. Have you duplicated this with OpenSSL? > > This is a backtrace of the thread that was hanging: > > #0 0xb7fe2424 in __kernel_vsyscall () > #1 0xb7f5809b in read () at ../sysdeps/unix/syscall-template.S:82 > #2 0xb7e021bb in sb_stream_read (sbiod=0x8064630, buf=0x8083038, len=5) > at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:493 > #3 0xb7e0132a in sb_debug_read (sbiod=0x807e250, buf=0x8083038, len=5) > at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:827 > #4 0xb7fa0d27 in tlsg_recv (ptr=0x806fb50, buf=0x8083038, len=4294966784) at > tls_g.c:904 > #5 0xb7c65aa2 in ?? () from /usr/lib/libgnutls.so.26 > #6 0xb7c65f77 in ?? () from /usr/lib/libgnutls.so.26 > #7 0xb7c611e7 in _gnutls_recv_int () from /usr/lib/libgnutls.so.26 > #8 0xb7c626b8 in gnutls_bye () from /usr/lib/libgnutls.so.26 > #9 0xb7fa0dc4 in tlsg_sb_close (sbiod=0x807e268) at tls_g.c:970 > #10 0xb7e01831 in ber_int_sb_close (sb=0x80645a8) > at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:383 > #11 0xb7f8d1a0 in ldap_free_connection (ld=0x8066418, lc=0x8065b60, force=1, > unbind=1) at request.c:768 > #12 0xb7f83060 in ldap_ld_free (ld=0x8066418, close=1, sctrls=0x0, cctrls=0x0) > at unbind.c:93 > #13 0xb7f83326 in ldap_unbind_ext (ld=0x8066418, sctrls=0x0, cctrls=0x0) at > unbind.c:52 > #14 0xb7f8343f in ldap_unbind (ld=0x8066418) at unbind.c:69 > #15 0x0804cfc0 in ?? () > #16 0x0804e750 in ?? () > #17 0x08057a9f in ?? () > #18 0x0804bb8d in ?? () > #19 0xb7f50955 in start_thread (arg=0xb7b92b70) at pthread_create.c:300 > #20 0xb7ed0e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 > > > More background information is available at [0]. > > As a workaround [1] I've used LDAP_OPT_DESC to get the file descriptor for the > connection and used setsockopt(SO_RCVTIMEO) and setsockopt(SO_SNDTIMEO) on it. > This fixes the problem for me at least but I'm not 100% this has no unwanted > side-effects. > > [0] http://bugs.debian.org/596983 > [1] http://arthurdejong.org/viewvc/nss-pam-ldapd?view=rev&revision=1264 > -- -- 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

Local structure mech in servers/slapd/bind.c assigned to op->orb_mech.
by Grafton Kennedy 13 Oct '10

13 Oct '10

The local structure mech in servers/slapd/bind.c is declared in do_bind as struct berval mech = BER_BVNULL; at about line 44. Further in do_bind, around line 201, mech is assigned to op->orb_mech. As a newbie to slapd, I'm concerned about this assignment. Later, slapd cores in an_find and I see that op->orb_mech.bv_len shares the same address as op->o_request.oq_search.rs_attrs: Program received signal SIGSEGV, Segmentation fault. an_find (a=0x6, s=0x814322c) at ad.c:874 874 for ( ; a->an_name.bv_val; a++ ) { (gdb) up #1 0x0807f865 in slap_attr_flags (an=0x6) at result.c:1659 1659 flags |= an_find( an, slap_bv_all_operational_attrs ) (gdb) up #2 0x08080a54 in slap_send_search_entry (op=0x81e74e0, rs=0xbfffa368) at result.c:821 821 rs->sr_attr_flags = slap_attr_flags( rs->sr_attrs ); (gdb) print &op->o_request.oq_bind.rb_mech $97 = (struct berval *) 0x81e751c (gdb) print &op->o_request.oq_bind.rb_mech.bv_len $98 = (ber_len_t *) 0x81e751c (gdb) print &op->o_request.oq_search.rs_attrs $99 = (AttributeName **) 0x81e751c I am using back-shell and slapd cores when my bind shell script outputs blank lines between data lines. If I remove the blank lines slapd doesn't core. But then it dumps the whole input and complains "expected RESULT" which I know isn't right. Thanks, Grafton

2 1

Re: (ITS#6672) OpenLDAP LDAP_R_COMPILE cleanup (LDAP_MUTEX_LOCK/LDAP_MUTEX_UNLOCK)
by hyc＠symas.com 12 Oct '10

12 Oct '10

doug.leavitt(a)oracle.com wrote: > Full_Name: Douglas Leavitt > Version: HEAD > OS: OpenSolaris > URL: http://cr.opensolaris.org/~djl/openldap-patch2/ > Submission from: (NULL) (192.18.43.225) > > > This patch is part 2 of 3 of the original ITS #6625 effort. > (aka openldap draft-zeilenga-ldap-c-api-concurrency) > > As discussed on openldap-devel(a)openldap.org, #6625 is to be split into 3 > distinct patches. > > This patch cleans up much of the LDAP_R_COMPILE ifdefs in libldap. > The patch converts almost all > > #ifdef LDAP_R_COMPILE > ldap_pvt_thread_mutex_[un]lock(...) > #endif > > sequences to simpler > LDAP_MUTEX_[UN]LOCK macros. > > No behavioral changes are introduced by this patch. It is strictly a > code cleanup patch. Thanks, committed. > > Regression testing (post conversion) performed using both > 32-bit and 64-bit x86 compiles on an OpenSolaris system. > > IPR Notice > > This patch file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed > by Oracle Corporation. Oracle Corporation has not assigned rights and/or > interest in this work to any party. I, Douglas Leavitt am authorized by Oracle > Corporation, my employer, to release this work under the following terms. > > -- -- 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

(ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org 12 Oct '10

12 Oct '10

Full_Name: Arthur de Jong Version: 2.4.23 OS: Debian/unstable URL: Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) When a network connection to the LDAP server fails (is severed with iptables in my set-up) the error is detected properly with ldap_result() (LDAP_OPT_TIMELIMIT, LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT options are set), however closing the connection with ldap_unbind() hangs indefinitely on a read() operation (determined by strace) when using a ldaps:// connection. If the connection is opened without TLS ldap_unbind() only writes some data on the connection and then closes it but with TLS it expects some response back. Since read() is used this blocks. This is a backtrace of the thread that was hanging: #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb7f5809b in read () at ../sysdeps/unix/syscall-template.S:82 #2 0xb7e021bb in sb_stream_read (sbiod=0x8064630, buf=0x8083038, len=5) at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:493 #3 0xb7e0132a in sb_debug_read (sbiod=0x807e250, buf=0x8083038, len=5) at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:827 #4 0xb7fa0d27 in tlsg_recv (ptr=0x806fb50, buf=0x8083038, len=4294966784) at tls_g.c:904 #5 0xb7c65aa2 in ?? () from /usr/lib/libgnutls.so.26 #6 0xb7c65f77 in ?? () from /usr/lib/libgnutls.so.26 #7 0xb7c611e7 in _gnutls_recv_int () from /usr/lib/libgnutls.so.26 #8 0xb7c626b8 in gnutls_bye () from /usr/lib/libgnutls.so.26 #9 0xb7fa0dc4 in tlsg_sb_close (sbiod=0x807e268) at tls_g.c:970 #10 0xb7e01831 in ber_int_sb_close (sb=0x80645a8) at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:383 #11 0xb7f8d1a0 in ldap_free_connection (ld=0x8066418, lc=0x8065b60, force=1, unbind=1) at request.c:768 #12 0xb7f83060 in ldap_ld_free (ld=0x8066418, close=1, sctrls=0x0, cctrls=0x0) at unbind.c:93 #13 0xb7f83326 in ldap_unbind_ext (ld=0x8066418, sctrls=0x0, cctrls=0x0) at unbind.c:52 #14 0xb7f8343f in ldap_unbind (ld=0x8066418) at unbind.c:69 #15 0x0804cfc0 in ?? () #16 0x0804e750 in ?? () #17 0x08057a9f in ?? () #18 0x0804bb8d in ?? () #19 0xb7f50955 in start_thread (arg=0xb7b92b70) at pthread_create.c:300 #20 0xb7ed0e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 More background information is available at [0]. As a workaround [1] I've used LDAP_OPT_DESC to get the file descriptor for the connection and used setsockopt(SO_RCVTIMEO) and setsockopt(SO_SNDTIMEO) on it. This fixes the problem for me at least but I'm not 100% this has no unwanted side-effects. [0] http://bugs.debian.org/596983 [1] http://arthurdejong.org/viewvc/nss-pam-ldapd?view=rev&revision=1264

1 0

(ITS#6672) OpenLDAP LDAP_R_COMPILE cleanup (LDAP_MUTEX_LOCK/LDAP_MUTEX_UNLOCK)
by doug.leavitt＠oracle.com 12 Oct '10

12 Oct '10

Full_Name: Douglas Leavitt Version: HEAD OS: OpenSolaris URL: http://cr.opensolaris.org/~djl/openldap-patch2/ Submission from: (NULL) (192.18.43.225) This patch is part 2 of 3 of the original ITS #6625 effort. (aka openldap draft-zeilenga-ldap-c-api-concurrency) As discussed on openldap-devel(a)openldap.org, #6625 is to be split into 3 distinct patches. This patch cleans up much of the LDAP_R_COMPILE ifdefs in libldap. The patch converts almost all #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_[un]lock(...) #endif sequences to simpler LDAP_MUTEX_[UN]LOCK macros. No behavioral changes are introduced by this patch. It is strictly a code cleanup patch. Regression testing (post conversion) performed using both 32-bit and 64-bit x86 compiles on an OpenSolaris system. IPR Notice This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Oracle Corporation. Oracle Corporation has not assigned rights and/or interest in this work to any party. I, Douglas Leavitt am authorized by Oracle Corporation, my employer, to release this work under the following terms.

1 0

(ITS#6671) multi-master replication fails to delete objects from consumer
by bcolston＠xtec.com 12 Oct '10

12 Oct '10

Full_Name: Barry Colston Version: 2.4.23 OS: Fedora 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.255.208.200) When a "Refresh Present" phase is performed at a multi-master consumer, objects that were deleted at the provider while the consumer was down are not deleted from the multi-master consumer (if the provider is brought down and back up after the consumer is down). This problem can be duplicated as follows: 1. Start provider 2. Start consumer, which is configured as a multi-master server 3. Add 10 records to the provider and wait until the records are replicated to the multi-master consumer 4. Stop the consumer 5. Delete 3 of the records that were added to the provider 6. Stop the provider 7. Start the provider 8. Start the consumer 9. After giving the consumer time to perform the refresh present phase, the 3 records that were deleted at the provider while the consumer was down are still present on the consumer and were not deleted during the refresh present phase Note: the consumer database must have a contextCSN attribute value present for itself (e.g., there should be 2 contextCSN attribute values present in the consumer database, one for the provider (in my configuration, this is serverID 000), and one value for the consumer (in my configuration, this is serverID 001). An example of the contextCSN values follows: dn: dc=authentx objectClass: top entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f contextCSN: 20101012154030.379053Z#000000#000#000000 contextCSN: 20101012141508.956053Z#000000#001#000000 OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches). Consumer log file from -d sync logging option: @(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $ Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd slapd starting do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT do_syncrep2: rid=001 cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000 slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000 slap_graduate_commit_csn: removing 0x1841b18 20101012180219.072053Z#000000#000#000000 daemon: shutdown requested and initiated. slapd shutdown: waiting for 1 operations/tasks to finish slapd stopped. Provider slapd.conf file: # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/authentx.schema pidfile /usr/local/var/slapd.sync1.pid argsfile /usr/local/var/slapd.sync1.args allow bind_v2 threads 32 #loglevel 416 password-hash {SSHA} serverID 000 database bdb suffix "dc=authentx" rootdn "cn=xroot,dc=authentx" rootpw SECRET directory /authentx/db/ldap/authentx-sync1 overlay syncprov syncprov-checkpoint 100 15 syncprov-sessionlog 150000 # checkpoint <kbytes> <min> checkpoint 128 20 #index for the objectclass index objectClass eq,pres index cid,eid,pid eq,pres index gcoid eq,pres index sysid,certid eq,pres index imageid,bioid eq,pres index addrid,emplid eq,pres index acid,apid,aeid eq,pres index acpid,agpid eq,pres index deviceid eq,pres index qid eq,pres index scid eq,pres index docid eq,pres index procid eq,pres index prochandlerid eq,pres index ounit eq,pres index credentials eq,pres index entities eq,pres index permissions eq,pres index region eq,pres index aliasedObjectName eq,pres index proctype eq,pres index procname eq,pres index status eq,pres index upi,ediident eq,pres index xsync eq,pres index role,xrole eq,pres index eroid eq,pres index esfunction eq,pres index nippsector eq,pres index ercog,ercoop eq,pres index eropron eq,pres index xsyncid eq,pres index stockid eq,pres index stocktypecode eq,pres index lotserialin eq,pres index lotserialout eq,pres index entryCSN,entryUUID eq index incl eq,pres cachesize 10000 dncachesize 20000 idlcachesize 1000 sizelimit 500000 timelimit 36000 include /usr/local/etc/openldap/acl.authentx database monitor Consumer slapd.conf file: # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/authentx.schema pidfile /usr/local/var/slapd.sync2.pid argsfile /usr/local/var/slapd.sync2.args allow bind_v2 threads 32 #loglevel 416 password-hash {SSHA} serverID 001 database bdb suffix "dc=authentx" rootdn "cn=xroot,dc=authentx" rootpw SECRET directory /authentx/db/ldap/authentx-sync2 overlay syncprov syncprov-checkpoint 100 15 syncprov-sessionlog 5000 # SLAVE server replication section syncrepl rid=001 provider=ldap://localhost:3891 type=refreshAndPersist retry="30 60 60 +" searchbase="dc=authentx" scope=sub schemachecking=off bindmethod=simple binddn="cn=xroot,dc=authentx" credentials="SECRET" mirrormode on # checkpoint <kbytes> <min> checkpoint 128 20 #index for the objectclass index objectClass eq,pres index cid,eid,pid eq,pres index gcoid eq,pres index sysid,certid eq,pres index imageid,bioid eq,pres index addrid,emplid eq,pres index acid,apid,aeid eq,pres index acpid,agpid eq,pres index deviceid eq,pres index qid eq,pres index scid eq,pres index docid eq,pres index procid eq,pres index prochandlerid eq,pres index ounit eq,pres index credentials eq,pres index entities eq,pres index permissions eq,pres index region eq,pres index aliasedObjectName eq,pres index proctype eq,pres index procname eq,pres index status eq,pres index upi,ediident eq,pres index xsync eq,pres index role,xrole eq,pres index eroid eq,pres index esfunction eq,pres index nippsector eq,pres index ercog,ercoop eq,pres index eropron eq,pres index xsyncid eq,pres index stockid eq,pres index stocktypecode eq,pres index lotserialin eq,pres index lotserialout eq,pres index entryCSN,entryUUID eq index incl eq,pres cachesize 10000 dncachesize 20000 idlcachesize 1000 sizelimit 100000 timelimit 36000 # the authentx database access control directives include /usr/local/etc/openldap/acl.authentx database monitor

1 0

(ITS#6670) memberof overlay problem
by henjes＠informatik.uni-wuerzburg.de 12 Oct '10

12 Oct '10

Full_Name: Robert Henjes Version: 2.4.23-4 OS: Debian Squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.187.12.89) Hi, while using memberof overlay I recognized the following problem in conjunction with groupOfNames. If you try to add an empty group of names you have to set at least one member attribute, since it is mandatory. One could have the idea to point to the group dn itself. If having the memberof overlay active this leads to a loop while executing an ldapadd. I assume this happens while the memberof overlay is triggered. Tried to analyze the slapd debug output, but it stops, after the addition is completed. Example LDIF file: dn: cn=stupid,ou=groups,dc=domain objectClass: top objectClass: groupOfNames cn: stupid member: cn=stupid,ou=groups,dc=domain The slapd server seems proceed working, except the add process and the subtree where the LDIF is gets added. You can not stop the slapd server in a normal way, you just have to do a "kill -9". After that the LDIF file seems to be added, but I assume, that the memberof overlay representation is inconsistent. The memberof overlay should be aware of such situations, even if building loops in dn references is in general not a good idea. Best regards, Robert

1 0

Re: (ITS#5693) [enhancement] extension of slapo-translucent filtering approach
by wdh＠vasco.com 12 Oct '10

12 Oct '10

Hi Pierangelo, I want to override the objectclass of a remote server to extend it with the attribute posixAccount This works but when I search on the attribute objectclass=* the only result giving me back i the ones with the local defined objectclass. Is it this issue? If so, can we do something about it? is here an easy fix? Thanks Wouter

1 0

Re: (ITS#6669) SunOS4 LWP removal patch
by hyc＠symas.com 12 Oct '10

12 Oct '10

doug.leavitt(a)oracle.com wrote: > Full_Name: Douglas Leavitt > Version: HEAD > OS: OpenSolaris > URL: http://cr.opensolaris.org/~djl/openldap-patch1/ > Submission from: (NULL) (192.18.43.225) > > > This is part 1 of 3 proposed patches pertaining to ITS #6625 > (aka draft-zeilenga-ldap-c-api-concurrency support) > As discussed on openldap-devel(a)openldap.org, #6625 is to be split into 3 > distinct patches. > > This patch (#1) removes the SunOS 4 LWP threading API support from OpenLDAP. Thanks, committed. > > SunOS4 LWP support has not been supported by Sun (now Oracle) in over a decade. > Sun's records indicate the last patch was made to the SunOS 4.1.4 patch gate > code base in 1999. The last major reelase was SunOS 4.1.3U in 1993, 4.1.1 in > 1990, and SunOS 3.5 in 1988. There are known to be a small number of Solaris 2.6 > and 2.7 systems still running, but Solaris 2.5.1 or earlier are statistically > very rare. Side note, Sun stops providing any support for Solaris 2.7 on August > 15, 2008. > > Realistically speaking this code has likely not been in use in almost 10 years, > so it's removal should have no negative effect. > > > > IPR Notice > > This patch file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed > by Oracle Corporation. Oracle Corporation has not assigned rights and/or > interest in this work to any party. I, Douglas Leavitt am authorized by Oracle > Corporation, my employer, to release this work under the following terms. > > > > -- -- 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

(ITS#6669) SunOS4 LWP removal patch
by doug.leavitt＠oracle.com 11 Oct '10

11 Oct '10

Full_Name: Douglas Leavitt Version: HEAD OS: OpenSolaris URL: http://cr.opensolaris.org/~djl/openldap-patch1/ Submission from: (NULL) (192.18.43.225) This is part 1 of 3 proposed patches pertaining to ITS #6625 (aka draft-zeilenga-ldap-c-api-concurrency support) As discussed on openldap-devel(a)openldap.org, #6625 is to be split into 3 distinct patches. This patch (#1) removes the SunOS 4 LWP threading API support from OpenLDAP. SunOS4 LWP support has not been supported by Sun (now Oracle) in over a decade. Sun's records indicate the last patch was made to the SunOS 4.1.4 patch gate code base in 1999. The last major reelase was SunOS 4.1.3U in 1993, 4.1.1 in 1990, and SunOS 3.5 in 1988. There are known to be a small number of Solaris 2.6 and 2.7 systems still running, but Solaris 2.5.1 or earlier are statistically very rare. Side note, Sun stops providing any support for Solaris 2.7 on August 15, 2008. Realistically speaking this code has likely not been in use in almost 10 years, so it's removal should have no negative effect. IPR Notice This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Oracle Corporation. Oracle Corporation has not assigned rights and/or interest in this work to any party. I, Douglas Leavitt am authorized by Oracle Corporation, my employer, to release this work under the following terms.

1 0

Re: (ITS#6668) MemberOf Overlay
by wf＠bitplan.com 11 Oct '10

11 Oct '10

Howard, thank you for your comments. I'll happily make more details available since I have the feeling that there is some value in doing so and quite a few people might benefit from a clarification of: http://www.openldap.org/doc/admin24/overlays.html#Member%20Of%20Configurati… which have been commented in http://www.openldap.org/lists/openldap-technical/201001/msg00125.html with "I think that the example in the docs is clear enough if you think it over :)" the example seems indeed to be clear. The configuration and installation of the memberOf functionality is IMHO not. My first bug assumption here is that a non installed memberOf overlay should lead to some kind of visible reaction in the logs or in an ldapsearch query at least when using some verbose or debug option. At least I did not find any mention of a way to make this happen. So a system with a memberOf Overlay installed might show results with a correct query where one that has none installed will simply show no results. So someone trying to tryout memberOf will not know whether the query is incorrect or the overlay is simply not installed. Even knowing that memberOf is an overlay is something people need to find out. My feeling is that memberOf is a default installation part in other ldap implementations. I think I have seen a request to make it part of the default installation for openldap. I would support this request given that this would make sure that distributions are forced to contain it and that overlays are not considered to be optional. If you look for the overlays in rpmseek you'll see that it seems to be not-so-common to put them in to distros as it might look from your response. Wolfgang Am 11.10.2010 11:43, schrieb Howard Chu: > wf(a)bitplan.com wrote: >> on >> http://serverfault.com/questions/73213/how-do-i-configure-reverse-group-mem… >> >> >> one can see how the issue hit us. We have a Suse 11.2 machine where >> the standard openldap configuration is slapd.conf based. >> On another ubuntu 10.04 machine it's cn=config based. >> >> The memberOf function simply didn't work and there were not proper error >> messages and googling the issue was a pain in the **** >> >> When we finally found out that we need an overlay no rpm was available. >> So we went and tried everything on the ubuntu machine. > > Whatever mechanism your distro uses to package the overlays is not > under our control. Whining about it here doesn't help anyone. If your > distro didn't adequately document where to find the overlays, file a > doc bug report with them. > >> But then there was this change of how everything is configured. >> Basically we could start googling all over again. Many hours and >> problems later we got the memberOf function working. What we know now is >> that OpenLdap has joined the list of projects that have abandondend >> simple configuration with a more complicated one. We've seen this with >> grub2, gnome and other projects. In all cases in our opinion this is not >> helping the majority of people using these projects. Many years of >> Documentation on the internet is invalidated and worse there are now two >> ways to do things that are incompatible and if you try to go back (as we >> did on ubuntu trying to get a slapd.conf based version running) it does >> not get any easier. > > Whining about the config mechanism is pointless. The slapd.conf > mechanism still works exactly the same as before. The cn=config > mechanism is the way forward because our large customers demanded a > way to modify the config without requiring a server restart. If you > can live with restarting every time you make a config change, you can > keep using OpenLDAP 2.4 the same as you always have. > >> Please use the contact form on BITPlan's webpage if you'd like to get >> our configuration script for memberOf - we won't publish it at this time >> since it contains user data. > > I personally don't have time to go chasing hither and yon for relevant > bug report data. If you can't provide a sanitized copy of the relevant > details, then you're just wasting everyone's time. > -- BITPlan - smart solutions Wolfgang Fahl Pater-Delp-Str. 1, D-47877 Willich Schiefbahn Tel. +49 2154 811-480, Fax +49 2154 811-481 Web: http://www.bitplan.de BITPlan GmbH, Willich - HRB 6820 Krefeld, Steuer-Nr.: 10258040548, Geschäftsführer: Wolfgang Fahl

1 0

Re: (ITS#6668) MemberOf Overlay
by hyc＠symas.com 11 Oct '10

11 Oct '10

wf(a)bitplan.com wrote: > on > http://serverfault.com/questions/73213/how-do-i-configure-reverse-group-mem… > > one can see how the issue hit us. We have a Suse 11.2 machine where > the standard openldap configuration is slapd.conf based. > On another ubuntu 10.04 machine it's cn=config based. > > The memberOf function simply didn't work and there were not proper error > messages and googling the issue was a pain in the **** > > When we finally found out that we need an overlay no rpm was available. > So we went and tried everything on the ubuntu machine. Whatever mechanism your distro uses to package the overlays is not under our control. Whining about it here doesn't help anyone. If your distro didn't adequately document where to find the overlays, file a doc bug report with them. > But then there was this change of how everything is configured. > Basically we could start googling all over again. Many hours and > problems later we got the memberOf function working. What we know now is > that OpenLdap has joined the list of projects that have abandondend > simple configuration with a more complicated one. We've seen this with > grub2, gnome and other projects. In all cases in our opinion this is not > helping the majority of people using these projects. Many years of > Documentation on the internet is invalidated and worse there are now two > ways to do things that are incompatible and if you try to go back (as we > did on ubuntu trying to get a slapd.conf based version running) it does > not get any easier. Whining about the config mechanism is pointless. The slapd.conf mechanism still works exactly the same as before. The cn=config mechanism is the way forward because our large customers demanded a way to modify the config without requiring a server restart. If you can live with restarting every time you make a config change, you can keep using OpenLDAP 2.4 the same as you always have. > Please use the contact form on BITPlan's webpage if you'd like to get > our configuration script for memberOf - we won't publish it at this time > since it contains user data. I personally don't have time to go chasing hither and yon for relevant bug report data. If you can't provide a sanitized copy of the relevant details, then you're just wasting everyone's time. -- -- 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#6665) back_ldap and back_meta chasing referrals authentication
by javier.sanz＠pandasecurity.com 11 Oct '10

11 Oct '10

Backported patch to 2.4.17 and tested there, it works as expected. Nice job, thanks.

1 0

Re: (ITS#6668) MemberOf Overlay
by wf＠bitplan.com 10 Oct '10

10 Oct '10

on http://serverfault.com/questions/73213/how-do-i-configure-reverse-group-mem… one can see how the issue hit us. We have a Suse 11.2 machine where the standard openldap configuration is slapd.conf based. On another ubuntu 10.04 machine it's cn=config based. The memberOf function simply didn't work and there were not proper error messages and googling the issue was a pain in the **** When we finally found out that we need an overlay no rpm was available. So we went and tried everything on the ubuntu machine. But then there was this change of how everything is configured. Basically we could start googling all over again. Many hours and problems later we got the memberOf function working. What we know now is that OpenLdap has joined the list of projects that have abandondend simple configuration with a more complicated one. We've seen this with grub2, gnome and other projects. In all cases in our opinion this is not helping the majority of people using these projects. Many years of Documentation on the internet is invalidated and worse there are now two ways to do things that are incompatible and if you try to go back (as we did on ubuntu trying to get a slapd.conf based version running) it does not get any easier. Please use the contact form on BITPlan's webpage if you'd like to get our configuration script for memberOf - we won't publish it at this time since it contains user data. -- BITPlan - smart solutions Wolfgang Fahl Web: http://www.bitplan.de

1 0

(ITS#6668) MemberOf Overlay
by wf＠bitplan.com 10 Oct '10

10 Oct '10

Full_Name: Wolfgang Fahl Version: 2.4 OS: many URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.193.149.46) We have been struggling a full day with the memberOf issue and have now given up. In our humble opinon the complexity is well out of range for such a seemingly trival functionality.

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> The configuration and test operations below should show exactly what's > going on, but first, allow me to describe the > process in a nutshell: > > 1. The client binds to the slave and issues a modification request > > 2. The slave creates the referral and tries to chase it automatically on > the client's behalf to the upstream master > using slapo-chain > > 3. The automatic referral chasing fails because the DN is not passed > through and the slave erroneously rebinds to the > master as anonymous (an empty DN) instead of the identity it's configured > to assert, as set by the olcDbIDAssertBind > attribute. > > 4. Because the automatic referral chasing fails, the slave kicks back the > referral to the client, stating that the > client "is not logged in" to the master and that "modifications require > authentication". > > 5. When the client provides credentials for the referral (manual referral > chasing), the rest of the operation works as > expected (updates made on master, which then cascades to the slaves). What the case description and the logs suggest is that the referral is chased anonymously because the protocol/host/port portion of the URI in the referral does not match the one configured in the chain-uri directive. In this case, slapo-chain defaults to anonymous. What slapo-chain does is take the referral string, pass it to URL parsing routines, isolate protocol, host and port, pass it back to URL unparsing, and compare the resulting string with the one configured in chain-uri (which had to go through the same "normalization" when configured). Perhaps if you try with a more detailed log level you'll be able to see the two strings and figure out if and how they differ. Hope this helps. p. > > The following LDIFs and sample operations exemplify the problem; please > let me know if this example suffices, or if you > need a more complete reference or further clarification: > > ################################################# > # CONFIGURATION # > ################################################# > > ### back-config base entry on slave (abbreviated) > dn: cn=config > objectClass: olcGlobal > cn: config > olcConfigDir: /etc/ldap/slapd.d > olcReadOnly: FALSE > olcReverseLookup: FALSE > olcTLSCACertificateFile: /etc/ldap/ssl/certs/cacert.pem > olcTLSCertificateFile: /etc/ldap/ssl/certs/openldap.cert.pem > olcTLSCertificateKeyFile: /etc/ldap/ssl/keys/openldap.key.pem > olcAuthzPolicy: none > olcLogLevel: stats sync > olcPasswordHash: {SSHA}SUPERSECRET > olcServerID: 1 ldap://master1.example.com > olcServerID: 2 ldap://slave1.example.com > > ### back-config modules entry > dn: cn=module{0},cn=config > objectClass: olcModuleList > cn: module{0} > olcModulePath: /usr/lib/ldap > olcModuleLoad: {0}back_hdb.la > olcModuleLoad: {1}autogroup.la > olcModuleLoad: {2}syncprov.la > olcModuleLoad: {3}back_ldap.la > > ### back-config chain overlay entry > dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectClass: olcOverlayConfig > objectClass: olcChainConfig > olcOverlay: {0}chain > > ### back-config chain database > dn: > olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectClass: olcLDAPConfig > objectClass: olcChainDatabase > olcDatabase: {0}ldap > olcDbURI: ldap://master1.example.com > olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=com" > credentials=SECRET mode=self > > > ################################################# > # SIMPLE OPERATIONAL EXAMPLE # > ################################################# > > ### NOTE: This example uses ldapvi, but results are identical to > ldapmodify, etc. > ### NOTE: The client binds initially to the slave as the admin here, but > results are identical to scenarios in which the > client binds as a regular user > > ### Attempting to modify 'displayColor' attribute belonging to entry > 'uid=ryans,ou=Users,dc=example,dc=com' > root@slave1:~# ldapvi -h localhost --bind=simple -D > cn=admin,dc=example,dc=com -w `cat /etc/ldap.secret` --discover > 159 entries read > > add: 0, rename: 0, modify: 1, delete: 0 > Action? [yYqQvVebB*rsf+?] y > Received referral to > ldap://master1.example.com/uid=ryans,ou=Users,dc=example,dc=com. > You are not logged in to ldap://master1.example.com:389 yet. > Type '!' or 'y' to do so. > Rebind? [y!nB*qQ?] y > > --- Login > Type M-h for help on key bindings. > > Filter or DN: cn=admin,dc=example,dc=com > Password: *********** > Bound as cn=admin,dc=example,dc=com. > Done. > > ################################################# > # LOGS FOR OPERATIONAL EXAMPLE # > ################################################# > > ### Logs on slave showing referral was correctly generated (err=10) > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 ACCEPT from > IP=127.0.0.1:34118 (IP=0.0.0.0:389) > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 EXT > oid=1.3.6.1.4.1.1466.20037 > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 STARTTLS > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 RESULT oid= err=0 text= > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 TLS established > tls_ssf=128 ssf=128 > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND > dn="cn=admin,dc=example,dc=com" method=128 > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND > dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 RESULT tag=97 err=0 > text= > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH base="" scope=0 > deref=0 filter="(objectClass=*)" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH attr=+ * > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 ENTRY dn="" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SEARCH RESULT tag=101 > err=0 nentries=1 text= > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SRCH > base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="cn=admin,dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="ou=users,dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="ou=groups,dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="uid=ryans,ou=users,dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="cn=ryans,ou=groups,dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SEARCH RESULT tag=101 > err=0 nentries=159 text= > Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD > dn="uid=ryans,ou=Users,dc=example,dc=com" > Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD attr=displayColor > Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 RESULT tag=103 err=10 > text= > > > ### Logs on master showing that when the slave tried to chase the > referral, it erroneously bound as anonymous > ### NOTE: slave1.example.com = 10.0.1.196 > Oct 5 10:27:07 master1 slapd[8794]: conn=402475 fd=273 ACCEPT from > IP=10.0.1.196:43376 (IP=0.0.0.0:389) > Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 BIND dn="" > method=128 > Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 RESULT tag=97 err=0 > text= > Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=1 MOD > dn="uid=ryans,ou=Users,dc=example,dc=com" > Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 MOD > attr=displayColor > Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 RESULT tag=103 err=8 > text=modifications require authentication > Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=2 UNBIND > Oct 5 10:27:08 master1 slapd[8794]: conn=402475 fd=273 closed > Oct 5 10:27:08 master1 slapd[8794]: conn=402476 fd=273 ACCEPT from > IP=10.0.1.196:43377 (IP=0.0.0.0:389) > > > If there are any details not shown that you'd like, or any clarification > you require, or if there's anything at all you > need to help facilitate the investigation, please let me know and I'll do > my best to accommodate. Thanks! > > -Ryan > > >

1 0

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> Note that the SSSVLV overlay can handle paged results locally too, thus > negating any need for back-ldap/back-meta to forward it to a remote > server. > Obviously for greatest generality, there needs to be a way to configure > which > set of controls to pass through, and which to process locally. (Much like > back-ldap's option to process the WhoAmI exop...) Right. With proxies the problem is twofold: a) clients request pr because they think they're talking to AD b) the proxy may need to use pr even if the client does not request it, because it knows it's talking to AD In (a), the issue could be handled the way sssvlv does, relieving the proxy from having to deal with server-side pr; this would be extremely beneficial, for example, for back-meta In (b), the proxy could be configured to use pr the way I mentioned above; in principle, the proxy could be so clever to avoid using pr, and simply accept to handle unrequested pr responses, but only if instructed to do so. Filtering what controls are passed thru should be easy, since both proxy backends always call ldap_back_controls_add()/meta_back_controls_add() to muck with request controls (usually to add proxied authorization and so); this function could easily strip or add pr if instructed to do so. p.

1 0

Re: (ITS#6665) back_ldap and back_meta chasing referrals authentication
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> Full_Name: Javier Sanz > Version: 2.4.17 > OS: Debian Linux 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.38.203.12) > > > back_ldap and back_meta should be able to do a non-anonymous bind to the > referrals returned by the external LDAP servers. > > This is a regression since 2.3, because the old directives "pseudorootdn" > and > "pseudorootpw" allowed specifying the binddn and password that would be > used to > chase the referrals, but their 2.4 replacements "idassert-bind" and > "idassert-authzFrom" do not allow that, so these binds are always done > anonymously. Back-ldap seems to work as expected if you set chase-referrals yes rebind-as-user yes idassert-bind bindmethod=simple binddn=<dn> credentials=<cred> mode=self and binddn <dn> with credentials <cred> exists on both the remote server and the one pointed to by the referral. With back-meta, it should work with the same parameters; however, I've checked and the specific code used to bind during searches does not set the rebind procedure correctly. I've fixed this in HEAD, please test. Thanks, p.

1 0

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by hyc＠symas.com 08 Oct '10

08 Oct '10

masarati(a)aero.polimi.it wrote: >> Full_Name: Javier Sanz >> Version: 2.4.17 >> OS: Debian Linux 5.0 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.38.203.12) >> >> >> back_meta and back_ldap should forward server controls that clients use in >> their >> queries to the corresponding external LDAP servers. > > Both back-ldap and back-meta forward controls to the remote servers. > >> For example, the inhability to send controls to external servers currently >> causes that RFC2696 paged results control cannot be used, so it is >> impossible to >> retrieve more results for a query than the page size configured in the >> external >> server, which often is not a big number. > > As far as I can tell, back-ldap supports paged results correctly (just > tested with HEAD and 2.4.23 code). Back-meta does not, and likely will > never do. Please note that while all back-ldap needs to do is blindly > forward control request/response, back-meta would need to separately > handle requests server-side (i.e. when the client requests the control) > and client-side (i.e. when non LDAP-compliant remote servers return the > control while the client did not request it). In between, it would need > to return the page size requested by the client and store the (possibly > paged) response of each remote server. Not worth the effort. The > solution consists in increasing the page size returned by default by > non-LDAP compliant remote servers. > > Perhaps the problem could be split in two: > > 1) allow to configure per-target mandatory use of paged results, with a > specified page size; this means that search requests hitting a specific > target would always add the paged results control to the request, and > handle control responses accordingly. > > 2) handle server-side control response in an overlay that takes care of > storing search results and returning them as appropriate. This would > (maybe inefficiently) handle paged results regardless of the backend that > is actually handling a request. > > Even if only (1) is implemented, clients would no longer need to use pr > when talking to slapd, since back-meta would handle non-LDAP compliant > remote servers that return pr response when the control is not requested. > > I think this ITS should be closed (back-ldap and back-meta do forward > controls); maybe another ITS with a back-meta feature request to handle > non-LDAP compliant remote servers could be filed. Note that the SSSVLV overlay can handle paged results locally too, thus negating any need for back-ldap/back-meta to forward it to a remote server. Obviously for greatest generality, there needs to be a way to configure which set of controls to pass through, and which to process locally. (Much like back-ldap's option to process the WhoAmI exop...) -- -- 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#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> Full_Name: Javier Sanz > Version: 2.4.17 > OS: Debian Linux 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.38.203.12) > > > back_meta and back_ldap should forward server controls that clients use in > their > queries to the corresponding external LDAP servers. Both back-ldap and back-meta forward controls to the remote servers. > For example, the inhability to send controls to external servers currently > causes that RFC2696 paged results control cannot be used, so it is > impossible to > retrieve more results for a query than the page size configured in the > external > server, which often is not a big number. As far as I can tell, back-ldap supports paged results correctly (just tested with HEAD and 2.4.23 code). Back-meta does not, and likely will never do. Please note that while all back-ldap needs to do is blindly forward control request/response, back-meta would need to separately handle requests server-side (i.e. when the client requests the control) and client-side (i.e. when non LDAP-compliant remote servers return the control while the client did not request it). In between, it would need to return the page size requested by the client and store the (possibly paged) response of each remote server. Not worth the effort. The solution consists in increasing the page size returned by default by non-LDAP compliant remote servers. Perhaps the problem could be split in two: 1) allow to configure per-target mandatory use of paged results, with a specified page size; this means that search requests hitting a specific target would always add the paged results control to the request, and handle control responses accordingly. 2) handle server-side control response in an overlay that takes care of storing search results and returning them as appropriate. This would (maybe inefficiently) handle paged results regardless of the backend that is actually handling a request. Even if only (1) is implemented, clients would no longer need to use pr when talking to slapd, since back-meta would handle non-LDAP compliant remote servers that return pr response when the control is not requested. I think this ITS should be closed (back-ldap and back-meta do forward controls); maybe another ITS with a back-meta feature request to handle non-LDAP compliant remote servers could be filed. p.

1 0

Re: (ITS#6667) memberof infinite recursion on node rename
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

Can you provide a minimal example that triggers the problem? You should boil it down to: - the slapd.conf or the contents of the cn=config database - the LDIF needed to populate the database - the operation that causes the problem (I presume it's a modify or a write operation, so you should be able to provide it in form of LDIF and main parameters, e.g. the identity that is performing the operation). Thanks, p.

1 0

Re: (ITS#6632) Core dump in test030 when using back-ldap
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

Valgrind shows more issues possibly related to this ITS when SLAP_NO_SL_MALLOC is defined. When running test047, whoami results in conn=1013 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.3 conn=1013 op=1 WHOAMI ==11941== Thread 5: ==11941== Conditional jump or move depends on uninitialised value(s) ==11941== at 0x820B122: rwm_op_rollback (rwm.c:62) ==11941== by 0x820B518: rwm_op_cleanup (rwm.c:165) ==11941== by 0x809EC0F: slap_cleanup_play (result.c:436) ==11941== by 0x809F34B: send_ldap_response (result.c:621) ==11941== by 0x80A0035: slap_send_ldap_extended (result.c:802) ==11941== by 0x80C90BD: fe_extended (extended.c:237) ==11941== by 0x810E8FD: overlay_op_walk (backover.c:669) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==11941== ==11941== Conditional jump or move depends on uninitialised value(s) ==11941== at 0x820B13A: rwm_op_rollback (rwm.c:65) ==11941== by 0x820B518: rwm_op_cleanup (rwm.c:165) ==11941== by 0x809EC0F: slap_cleanup_play (result.c:436) ==11941== by 0x809F34B: send_ldap_response (result.c:621) ==11941== by 0x80A0035: slap_send_ldap_extended (result.c:802) ==11941== by 0x80C90BD: fe_extended (extended.c:237) ==11941== by 0x810E8FD: overlay_op_walk (backover.c:669) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) conn=1013 op=1 RESULT oid= err=0 text= Possibly, although not directly, related leaks: ==11941== ==11941== 244 bytes in 4 blocks are definitely lost in loss record 10 of 11 ==11941== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==11941== by 0x826BB67: ber_memalloc_x (memory.c:226) ==11941== by 0x80F5229: slap_sl_malloc (sl_malloc.c:285) ==11941== by 0x826BB82: ber_memalloc_x (memory.c:229) ==11941== by 0x824C16E: ldap_dn2bv_x (getdn.c:3015) ==11941== by 0x80A53E2: dnPrettyNormal (dn.c:745) ==11941== by 0x820D4DC: rwm_exop_passwd (rwm.c:1048) ==11941== by 0x820D7C5: rwm_extended (rwm.c:1116) ==11941== by 0x810E87D: overlay_op_walk (backover.c:659) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) Will look at this ASAP. p.

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by hyc＠symas.com 07 Oct '10

07 Oct '10

Hallvard B Furuseth wrote: > Maybe an overlay version of back-sock, with an overlay option > which says whether or not to wait for responses from the socket? Sure. Someone could easily start with e.g. chain.c or pbind.c and write an overlay wrapper for back-sock. Patches welcome. -- -- 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#6666) Feature Request: Triggers implementation
by h.b.furuseth＠usit.uio.no 07 Oct '10

07 Oct '10

Maybe an overlay version of back-sock, with an overlay option which says whether or not to wait for responses from the socket?

1 0

(ITS#6667) memberof infinite recursion on node rename
by miguelangel＠nbee.es 07 Oct '10

07 Oct '10

Full_Name: Miguel Angel Ajo Pelayo Version: 2.4.23 stable OS: Linux (Centos5) URL: Submission from: (NULL) (95.16.169.142) I detected that my (compiled from source) openldap crashes on node rename. I run gdb and detected an infinite (too big) recursion that seems to be related with the "memberof" overlay. This is the GDB / debug output: >>> dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> <<< dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> bdb_modrdn: new ndn=cn=aaa aaavzadadfa,dc=nbee,dc=es => bdb_dn2id("cn=aaa aaavzadadfa,dc=nbee,dc=es") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) => bdb_dn2id_delete 0x11: "cn=aaa aaavzadadf,dc=nbee,dc=es" <= bdb_dn2id_delete 0x11: 0 => bdb_dn2id_add 0x11: "cn=aaa aaavzadadfa,dc=nbee,dc=es" <= bdb_dn2id_add 0x11: 0 bdb_modify_internal: 0x00000011: cn=aaa aaavzadadfa,dc=nbee,dc=es oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "inetOrgPerson" oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "posixAccount" oc_check_allowed type "givenName" oc_check_allowed type "sn" oc_check_allowed type "gidNumber" oc_check_allowed type "uid" oc_check_allowed type "uidNumber" oc_check_allowed type "userPassword" oc_check_allowed type "loginShell" oc_check_allowed type "homeDirectory" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "cn" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es <= entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es bdb_modrdn: rdn modified id=00000011 dn="cn=aaa aaavzadadf,dc=nbee,dc=es" send_ldap_result: conn=1007 op=2 p=3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb79e7b90 (LWP 11613)] 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 713 db = *op->o_bd; #0 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 #1 0x080eb21c in over_aux_chk_controls (op=0xb79e680c, rs=0xb79e67d0) at backover.c:814 #2 0x0807bc38 in backend_check_restrictions (op=0xb79e680c, rs=0xb79e67d0, opdata=0x0) at backend.c:1036 #3 0x0806e1fa in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:334 #4 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #5 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #6 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #7 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 [.......] A LOT of recursion... #37385 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37386 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37387 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 #37388 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #37389 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37390 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37391 0x08163ee4 in memberof_isGroupOrMember (op=0x8370ce0, mci=0xb6fe4450) at memberof.c:288 ---Type <return> to continue, or q <return> to quit--- #37392 0x0816723b in memberof_res_modrdn (op=0x8370ce0, rs=0xb79e7134) at memberof.c:1451 #37393 0x0807e621 in slap_response_play (op=0x8370ce0, rs=0xb79e7134) at result.c:402 #37394 0x0807e7cc in send_ldap_response (op=0x8370ce0, rs=0xb79e7134) at result.c:476 #37395 0x0807f5a2 in slap_send_ldap_result (op=0x8370ce0, rs=0xb79e7134) at result.c:750 #37396 0x080fbca9 in bdb_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:789 #37397 0x0808bbb0 in fe_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:314 #37398 0x080eae42 in overlay_op_walk (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn, oi=0x8304f40, on=0x0) at backover.c:669 #37399 0x080eaff7 in over_op_func (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn) at backover.c:721 #37400 0x080eb10c in over_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at backover.c:766 #37401 0x0808b513 in do_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:186 #37402 0x0806aed0 in connection_operation (ctx=0xb79e7220, arg_v=0x8370ce0) at connection.c:1109 #37403 0x0806b410 in connection_read_thread (ctx=0xb79e7220, argv=0xe) at connection.c:1245 #37404 0x081b5055 in ldap_int_thread_pool_wrapper (xpool=0x82d9e00) at tpool.c:685 #37405 0x00adf832 in start_thread () from /lib/libpthread.so.0 #37406 0x00220e0e in clone () from /lib/libc.so.6 Any idea of why could this be happening?

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by nick＠eurobjects.com 07 Oct '10

07 Oct '10

Sorry, I' m not a developer. I'm trying to find a solution from an administrator's point of view. How about doing something like: on log attr <attrname> notify <[ip]:[port]> which would send a "message" with the attr name, the old and the new value of the attribute to [ip]:[port]. Then, someone can set up a net listening process like netcat (nc) to read data and do whatever. Nick On 7/10/2010 5:32 πμ, Howard Chu wrote: > > Spawning processes is not thread safe. The solution you propose will > never be implemented. Alternative suggestions are welcome. >

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by hyc＠symas.com 06 Oct '10

06 Oct '10

nick(a)eurobjects.com wrote: > Full_Name: Nick Milas > Version: 2.3.43 > OS: CentOS 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.65.0.240) > > > Triggers in openldap is a much-desired feature. As mentioned in various places, > openldap community suggests using the accesslog overlay to log changes and then > use another process to listen to changes (e.g. back-perl) or back-sock (I saw > the example in the source tree), feasibly back-shell or even write one's own > overlay. The problem is that all those methods require low-level programming > (not to mention various incompatibilities with system components), which makes > them unusable by administrators, that is by those who mainly install and run > openldap and directories. As a result, I would suggest to slightly enhance > future versions by offering minimal trigger support over the accesslog overlay. > > > So I would suggest to support in slapd.conf a statement like: > "on log attr<attribute name> call<bash script>" (with obvious meaning). > > I consider this would allow the openldap average administrator to use particular > attributes as triggers to start scripts which in turn offer the advantage of > full access to script programming, which does not require low-level > programming. > > Spawning processes is not thread safe. The solution you propose will never be implemented. Alternative suggestions are welcome. -- -- 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

memberof infinite recursion on node rename
by Miguel Angel 06 Oct '10

06 Oct '10

Hi there, I think I found a bug. I detected that my (compiled from source) openldap crashes on node rename. I run gdb and detected an infinite (too big) recursion that seems to be related with the "memberof" overlay. I'm not familiar with openldap sources, so I decided to post it here, and then try to help fixing it with your advice: This is the GDB / debug output: >>> dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> <<< dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> bdb_modrdn: new ndn=cn=aaa aaavzadadfa,dc=nbee,dc=es => bdb_dn2id("cn=aaa aaavzadadfa,dc=nbee,dc=es") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) => bdb_dn2id_delete 0x11: "cn=aaa aaavzadadf,dc=nbee,dc=es" <= bdb_dn2id_delete 0x11: 0 => bdb_dn2id_add 0x11: "cn=aaa aaavzadadfa,dc=nbee,dc=es" <= bdb_dn2id_add 0x11: 0 bdb_modify_internal: 0x00000011: cn=aaa aaavzadadfa,dc=nbee,dc=es oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "inetOrgPerson" oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "posixAccount" oc_check_allowed type "givenName" oc_check_allowed type "sn" oc_check_allowed type "gidNumber" oc_check_allowed type "uid" oc_check_allowed type "uidNumber" oc_check_allowed type "userPassword" oc_check_allowed type "loginShell" oc_check_allowed type "homeDirectory" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "cn" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es <= entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es bdb_modrdn: rdn modified id=00000011 dn="cn=aaa aaavzadadf,dc=nbee,dc=es" send_ldap_result: conn=1007 op=2 p=3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb79e7b90 (LWP 11613)] 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 713 db = *op->o_bd; #0 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 #1 0x080eb21c in over_aux_chk_controls (op=0xb79e680c, rs=0xb79e67d0) at backover.c:814 #2 0x0807bc38 in backend_check_restrictions (op=0xb79e680c, rs=0xb79e67d0, opdata=0x0) at backend.c:1036 #3 0x0806e1fa in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:334 #4 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #5 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #6 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #7 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 [.......] A LOT of recursion... #37385 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37386 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37387 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 #37388 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #37389 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37390 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37391 0x08163ee4 in memberof_isGroupOrMember (op=0x8370ce0, mci=0xb6fe4450) at memberof.c:288 ---Type <return> to continue, or q <return> to quit--- #37392 0x0816723b in memberof_res_modrdn (op=0x8370ce0, rs=0xb79e7134) at memberof.c:1451 #37393 0x0807e621 in slap_response_play (op=0x8370ce0, rs=0xb79e7134) at result.c:402 #37394 0x0807e7cc in send_ldap_response (op=0x8370ce0, rs=0xb79e7134) at result.c:476 #37395 0x0807f5a2 in slap_send_ldap_result (op=0x8370ce0, rs=0xb79e7134) at result.c:750 #37396 0x080fbca9 in bdb_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:789 #37397 0x0808bbb0 in fe_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:314 #37398 0x080eae42 in overlay_op_walk (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn, oi=0x8304f40, on=0x0) at backover.c:669 #37399 0x080eaff7 in over_op_func (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn) at backover.c:721 #37400 0x080eb10c in over_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at backover.c:766 #37401 0x0808b513 in do_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:186 #37402 0x0806aed0 in connection_operation (ctx=0xb79e7220, arg_v=0x8370ce0) at connection.c:1109 #37403 0x0806b410 in connection_read_thread (ctx=0xb79e7220, argv=0xe) at connection.c:1245 #37404 0x081b5055 in ldap_int_thread_pool_wrapper (xpool=0x82d9e00) at tpool.c:685 #37405 0x00adf832 in start_thread () from /lib/libpthread.so.0 #37406 0x00220e0e in clone () from /lib/libc.so.6 Any idea of why could this be happening? Thanks in advance, Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo

2 1

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 06 Oct '10

06 Oct '10

masarati(a)aero.polimi.it wrote: >> Hey Pierangelo, >> >> I just noticed http://www.openldap.org/its/index.cgi?findid=6574 - this >> looks like it fixes the issue I mentioned in >> http://www.openldap.org/its/index.cgi?findid=6540? Is that assertion >> correct? > > I couldn't specifically look at your issue (apart from the simple fix to > allow cn=config to work). ITS#6574 should have nothing to do with your > issue, as it affects back-meta in a part that has no code commonality with > back-ldap, and slapo-chain is built on top of back-ldap. I apologize - it had occurred to me that since http://www.openldap.org/doc/admin24/backends.html#Metadirectory states that back-meta and back-ldap share a subset of code, and since the issue described in ITS#6574 appears to be *exactly* the same problem I'm seeing in ITS#6540, that they might have been one and the same. > I'm sorry I went back through this thread and got somehow lost; what's the > exact topic now? I infer (from followup #14) that there seems to be an > issue about chaining because slapo-chain seems not to rebind as expected. ITS#6540 had two parts: 1. The test script failed to identify a specific set of conditions in which slapo-chain would cause slapcat to fail and also prevent slapd from being restarted after slapo-chain was enabled. 2. The problem that the test script failed to detect with slapo-chain is directly related to the current problem: slapo-chain does not properly rebind as the appropriate user as set in the olcDbIDAssertBind attribute. Instead, it rebinds as 'anonymous' (an empty DN), which is of very little practical use, since unauthenticated anonymous users should not be allowed to modify anything. As a result, slapd kicks the referral back to the client instead of chasing it automatically, which completely defeats the purpose of using slapo-chain. > Could you isolate the problem in a minimal setup (slapd.conf or the > corresponding back-config's LDIF, a database and a simple operation that > can be performed with ldapmodify/ldappasswd or so) to clearly reproduce > the issue? > > Thanks, p. > The configuration and test operations below should show exactly what's going on, but first, allow me to describe the process in a nutshell: 1. The client binds to the slave and issues a modification request 2. The slave creates the referral and tries to chase it automatically on the client's behalf to the upstream master using slapo-chain 3. The automatic referral chasing fails because the DN is not passed through and the slave erroneously rebinds to the master as anonymous (an empty DN) instead of the identity it's configured to assert, as set by the olcDbIDAssertBind attribute. 4. Because the automatic referral chasing fails, the slave kicks back the referral to the client, stating that the client "is not logged in" to the master and that "modifications require authentication". 5. When the client provides credentials for the referral (manual referral chasing), the rest of the operation works as expected (updates made on master, which then cascades to the slaves). The following LDIFs and sample operations exemplify the problem; please let me know if this example suffices, or if you need a more complete reference or further clarification: ################################################# # CONFIGURATION # ################################################# ### back-config base entry on slave (abbreviated) dn: cn=config objectClass: olcGlobal cn: config olcConfigDir: /etc/ldap/slapd.d olcReadOnly: FALSE olcReverseLookup: FALSE olcTLSCACertificateFile: /etc/ldap/ssl/certs/cacert.pem olcTLSCertificateFile: /etc/ldap/ssl/certs/openldap.cert.pem olcTLSCertificateKeyFile: /etc/ldap/ssl/keys/openldap.key.pem olcAuthzPolicy: none olcLogLevel: stats sync olcPasswordHash: {SSHA}SUPERSECRET olcServerID: 1 ldap://master1.example.com olcServerID: 2 ldap://slave1.example.com ### back-config modules entry dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}autogroup.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}back_ldap.la ### back-config chain overlay entry dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain ### back-config chain database dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldap://master1.example.com olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=SECRET mode=self ################################################# # SIMPLE OPERATIONAL EXAMPLE # ################################################# ### NOTE: This example uses ldapvi, but results are identical to ldapmodify, etc. ### NOTE: The client binds initially to the slave as the admin here, but results are identical to scenarios in which the client binds as a regular user ### Attempting to modify 'displayColor' attribute belonging to entry 'uid=ryans,ou=Users,dc=example,dc=com' root@slave1:~# ldapvi -h localhost --bind=simple -D cn=admin,dc=example,dc=com -w `cat /etc/ldap.secret` --discover 159 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Received referral to ldap://master1.example.com/uid=ryans,ou=Users,dc=example,dc=com. You are not logged in to ldap://master1.example.com:389 yet. Type '!' or 'y' to do so. Rebind? [y!nB*qQ?] y --- Login Type M-h for help on key bindings. Filter or DN: cn=admin,dc=example,dc=com Password: *********** Bound as cn=admin,dc=example,dc=com. Done. ################################################# # LOGS FOR OPERATIONAL EXAMPLE # ################################################# ### Logs on slave showing referral was correctly generated (err=10) Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 ACCEPT from IP=127.0.0.1:34118 (IP=0.0.0.0:389) Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 STARTTLS Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 RESULT oid= err=0 text= Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 TLS established tls_ssf=128 ssf=128 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 RESULT tag=97 err=0 text= Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH attr=+ * Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 ENTRY dn="" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="cn=admin,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="ou=users,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="ou=groups,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="uid=ryans,ou=users,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="cn=ryans,ou=groups,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SEARCH RESULT tag=101 err=0 nentries=159 text= Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD attr=displayColor Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 RESULT tag=103 err=10 text= ### Logs on master showing that when the slave tried to chase the referral, it erroneously bound as anonymous ### NOTE: slave1.example.com = 10.0.1.196 Oct 5 10:27:07 master1 slapd[8794]: conn=402475 fd=273 ACCEPT from IP=10.0.1.196:43376 (IP=0.0.0.0:389) Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 BIND dn="" method=128 Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 RESULT tag=97 err=0 text= Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 MOD attr=displayColor Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 RESULT tag=103 err=8 text=modifications require authentication Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=2 UNBIND Oct 5 10:27:08 master1 slapd[8794]: conn=402475 fd=273 closed Oct 5 10:27:08 master1 slapd[8794]: conn=402476 fd=273 ACCEPT from IP=10.0.1.196:43377 (IP=0.0.0.0:389) If there are any details not shown that you'd like, or any clarification you require, or if there's anything at all you need to help facilitate the investigation, please let me know and I'll do my best to accommodate. Thanks! -Ryan

1 0

(ITS#6666) Feature Request: Triggers implementation
by nick＠eurobjects.com 06 Oct '10

06 Oct '10

Full_Name: Nick Milas Version: 2.3.43 OS: CentOS 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.65.0.240) Triggers in openldap is a much-desired feature. As mentioned in various places, openldap community suggests using the accesslog overlay to log changes and then use another process to listen to changes (e.g. back-perl) or back-sock (I saw the example in the source tree), feasibly back-shell or even write one's own overlay. The problem is that all those methods require low-level programming (not to mention various incompatibilities with system components), which makes them unusable by administrators, that is by those who mainly install and run openldap and directories. As a result, I would suggest to slightly enhance future versions by offering minimal trigger support over the accesslog overlay. So I would suggest to support in slapd.conf a statement like: "on log attr <attribute name> call <bash script>" (with obvious meaning). I consider this would allow the openldap average administrator to use particular attributes as triggers to start scripts which in turn offer the advantage of full access to script programming, which does not require low-level programming.

1 0

Re: FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 06 Oct '10

06 Oct '10

--=-J3E4Om04oCzTAxqDTGlw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit > In the meanwhile, you can try to use an instance of back-ldap as the > translucent local storage, and place slapo-rwm on the database of the > remote server that acts as local. I haven't tested it, so there might be > minor issues, but I don't expect anything like this one. Thanks for the input. This is also not an option because the remote server is in fact an Active Directory. Which in this case I can't alter. I will try to create 2 slapd process - One which will do the translucent proxy stuff, running on a non standard port - one which will have a back-ldap to this non standard port and doing there the rewrites. Thanks for helping me with this issue. --=-J3E4Om04oCzTAxqDTGlw Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> <PRE> > In the meanwhile, you can try to use an instance of back-ldap as the > translucent local storage, and place slapo-rwm on the database of the > remote server that acts as local.  I haven't tested it, so there might be > minor issues, but I don't expect anything like this one. Thanks for the input. This is also not an option because the remote server is in fact an Active Directory. Which in this case I can't alter. I will try to create 2 slapd process - One which will do the translucent proxy stuff, running on a non standard port - one which will have a back-ldap to this non standard port and doing there the rewrites. Thanks for helping me with this issue. </PRE> </BODY> </HTML> --=-J3E4Om04oCzTAxqDTGlw--

1 0

Re: FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by masarati＠aero.polimi.it 06 Oct '10

06 Oct '10

> I installed the latest version currently available 2.4.23 > The same bug still exists in this version. > > So I can for sure say this is not related to ITS#6070 > > Since this is a major loss of functionality I would kindly ask someone to > h= > ave a deeper look at this. I confirm it is related to ITS#6070; only, that ITS could be fixed (read: worked around) differently. I don't think this qualifies as a "major loss of functionality" for the vast majority of the users of OpenLDAP. Solving this issue the right way (and few others) would require to advance OpenLDAP at least to 2.5 or 3.0, because a significant portion of the ABI would need to change, so do not expect to see it solved any soon. In the meanwhile, you can try to use an instance of back-ldap as the translucent local storage, and place slapo-rwm on the database of the remote server that acts as local. I haven't tested it, so there might be minor issues, but I don't expect anything like this one. p.

1 0

FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 05 Oct '10

05 Oct '10

I installed the latest version currently available 2.4.23 The same bug still exists in this version. So I can for sure say this is not related to ITS#6070 Since this is a major loss of functionality I would kindly ask someone to h= ave a deeper look at this. Thanks Wouter=

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 05 Oct '10

05 Oct '10

--=-pjbfbkt+SDCV4FzF9Ohv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I'm hitting this bug also in Debian Lenny. Is this bug already fixed? It prevents me from implementing our OpenLDAP server. Thanks Wouter --=-pjbfbkt+SDCV4FzF9Ohv Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> I'm hitting this bug also in Debian Lenny. Is this bug already fixed? It prevents me from implementing our OpenLDAP server. Thanks Wouter </BODY> </HTML> --=-pjbfbkt+SDCV4FzF9Ohv--

1 0

(ITS#6665) back_ldap and back_meta chasing referrals authentication
by jsceballos＠gmail.com 05 Oct '10

05 Oct '10

Full_Name: Javier Sanz Version: 2.4.17 OS: Debian Linux 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) back_ldap and back_meta should be able to do a non-anonymous bind to the referrals returned by the external LDAP servers. This is a regression since 2.3, because the old directives "pseudorootdn" and "pseudorootpw" allowed specifying the binddn and password that would be used to chase the referrals, but their 2.4 replacements "idassert-bind" and "idassert-authzFrom" do not allow that, so these binds are always done anonymously.

1 0

(ITS#6664) Server control forwarding in back_meta and back_ldap
by jsceballos＠gmail.com 05 Oct '10

05 Oct '10

Full_Name: Javier Sanz Version: 2.4.17 OS: Debian Linux 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) back_meta and back_ldap should forward server controls that clients use in their queries to the corresponding external LDAP servers. For example, the inhability to send controls to external servers currently causes that RFC2696 paged results control cannot be used, so it is impossible to retrieve more results for a query than the page size configured in the external server, which often is not a big number.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by clem.oudot＠gmail.com 05 Oct '10

05 Oct '10

--=-sj86jeXTHEFBrrKIl07g Content-Type: text/plain; charset=utf-8 Content-ID: <1286271588.1952.3.camel@Nokia-N900-51-1> Content-Transfer-Encoding: 8bit ----- Message d'origine ----- > > > Please try this (nearly blind) patch > > > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…> > > > > and report through the ITS. Thanks, p. > > I note that I have messed things up a bit in cleanup; however, this > should not affect the testing of the functionality, except if you delete > the overlay from the configuration using back-config. If the patch works > fine, I'll fix that part. > Hi, sorry for this late reply. I tried the patch on 2.4.23 source code, the second hunk was not working, so I deleted it to apply the patch. I am not using cn=config anyway. After recompiling with your patch and --enable-overlays, all works fine: a search with sss extention returns success (and fails if the control is critical). So I think you can commit the code! Thanks, Clément. --=-sj86jeXTHEFBrrKIl07g Content-Type: text/html; charset=utf-8 Content-ID: <1286271588.1952.5.camel@Nokia-N900-51-1> Content-Transfer-Encoding: 8bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="generator" content="Osso Notes"> <title></title></head> <body> ----- Message d'origine ----- > > > Please try this (nearly blind) patch > > > > <<a href="ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…">ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…</a>; > > > > and report through the ITS.  Thanks, p. > > I note that I have messed things up a bit in cleanup; however, this > should not affect the testing of the functionality, except if you delete > the overlay from the configuration using back-config.  If the patch works > fine, I'll fix that part. > Hi, sorry for this late reply. I tried the patch on 2.4.23 source code, the second hunk was not working, so I deleted it to apply the patch. I am not using cn=config anyway. After recompiling with your patch and --enable-overlays, all works fine: a search with sss extention returns success (and fails if the control is critical). So I think you can commit the code! Thanks, Clément. </body> </html> --=-sj86jeXTHEFBrrKIl07g--

1 0

(ITS#6663) refint not altering last attribute on delete
by knewell＠math.arizona.edu 04 Oct '10

04 Oct '10

Full_Name: Karl Newell Version: 2.4.21 OS: Ubuntu 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.196.224.235) refint does not alter the value of an attribute to refint_nothing when the last "member" of a group is deleted. refint is working when the dn of a member is modified. slapd.conf: loglevel 16383 ... moduleload refint ... overlay refint refint_attributes member uniqueMember seeAlso refint_nothing cn=Manager,dc=math,dc=arizona,dc=edu ... ldap.log (what I believe to be the relevant entries): ... Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb <cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu> Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb: uniqueMember: uid=atb,ou=Users,dc=math,dc=arizona,dc=edu (#1) Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: err=0 matched="" text="" Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb <NOTHING> Oct 4 14:12:03 vm-ldap slapd[8744]: hdb_modify: cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_dn2entry("cn=ldap admins,ou=groups,dc=math,dc=arizona,dc=edu") Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: 0x00000008: cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu Oct 4 14:12:03 vm-ldap slapd[8744]: <= acl_access_allowed: granted to database root Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: delete uniqueMember Oct 4 14:12:03 vm-ldap slapd[8744]: dnMatch 0#012#011"uid=atb,ou=users,dc=math,dc=arizona,dc=edu"#012#011"uid=atb,ou=users,dc=math,dc=arizona,dc=edu" Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: replace modifiersName Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: delete uniqueMember Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: 16 modify/delete: uniqueMember: no such attribute Oct 4 14:12:03 vm-ldap slapd[8744]: hdb_modify: modify failed (16) Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: err=16 matched="" text="modify/delete: uniqueMember: no such attribute" Oct 4 14:12:03 vm-ldap slapd[8744]: refint_repair: dependent modify failed: 16 ...

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 30 Sep '10

30 Sep '10

--On Thursday, September 30, 2010 11:14 AM +0000 masarati(a)aero.polimi.it wrote: > There's no mention of overlays; I was wondering whether or not it could be > related to some adverse interaction, e.g. with sssvlv, which has some > paged-results specific code. Can you also post on overlays either global > or specific to "olcDatabase={2}hdb"? There are no overlays being used. ;) As I said, a very vanilla config. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs