- openldap-bugs - openldap.org

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 14 Sep '13

14 Sep '13

On 2013-09-13 23:09, sog(a)msg.com.mx wrote: > If the call fails because O_DIRECT, in a "tmpfs" in my Fedora 19 > '/tmp', > the file is left created anyway! so the retry fails because > O_EXCL|O_CREAT. Also on RHEL 6.4 (2.6.32-358.18.1.el6.x86_64) with /dev/shm/nosuch. I'll report it to RedHat and see what they say. > I propose the following: > (...) > + * Fortunately seems that other errors are reported before EINVAL > + * So, we need to remove it before retry open. > */ > if (newfd == INVALID_HANDLE_VALUE && ErrCode() == EINVAL) > + (void)unlink(lpath) , No unlink(). EINVAL does not say whether the file existed before the call. Not on another OS, nor on another Linux version or filesystem where Linux may work differently. Somewhat better: #ifdef <buggy Linux>, replace O_EXCL with O_TRUNC in the 2nd call. Or add paranoia like taking an exclusive lock, but ignore "locking not supported" errors. > #endif > newfd = open(lpath, O_WRONLY|O_CREAT|O_EXCL, 0666); > #endif -- Hallvard

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by sog＠msg.com.mx 13 Sep '13

13 Sep '13

On 09/05/2013 06:33 PM, Howard Chu wrote: > sog(a)msg.com.mx wrote: >> Full_Name: Salvador Ortiz >> Version: 24 >> OS: Linux >> URL: >> ftp://ftp.msg.com.mx/pub/varios/0001-In-mdb_env_copy-retry-open-if-O_DIRECT-fails.patch >> Submission from: (NULL) (187.162.45.111) >> >> >> If the OS defines O_DIRECT mdb_env_copy unconditionally uses it, but >> according >> to open(2): "Some file systems may not implement the flag and >> open() will >> fail with EINVAL if it is used." >> >> In this cases mdb_env_copy should retry without the flag. >> >> The attached patch implements that. >> >> > Thanks, applied. > Thank you Howard, but I found an unexpected problem with the patch as commited. If the call fails because O_DIRECT, in a "tmpfs" in my Fedora 19 '/tmp', the file is left created anyway! so the retry fails because O_EXCL|O_CREAT. I consider this undocumented behavior for "open", buggy or at least ugly. (A simple test program in ftp://ftp.msg.com.mx/pub/varios/o_direct.c) I propose the following: ======== --- a/liblmdb/mdb.c 2013-09-05 17:31:01.498090281 -0500 +++ b/liblmdb/mdb.c 2013-09-13 14:45:00.918717292 -0500 @@ -4250,9 +4250,16 @@ /* The OS supports O_DIRECT, try with it */ newfd = open(lpath, O_WRONLY|O_CREAT|O_EXCL|O_DIRECT, 0666); /* But open can fail if O_DIRECT isn't supported by the file system - * so retry without the flag + * so retry without the flag. + * + * Sept 13 2013. + * On a tmpfs, at least, an open with O_DIRECT fails, + * BUT the file is created anyway!! + * Fortunately seems that other errors are reported before EINVAL + * So, we need to remove it before retry open. */ if (newfd == INVALID_HANDLE_VALUE && ErrCode() == EINVAL) + (void)unlink(lpath) , #endif newfd = open(lpath, O_WRONLY|O_CREAT|O_EXCL, 0666); #endif ========= What do you think? Regards.

1 0

Re: (ITS#7693) ProxyCache Problems
by quanah＠zimbra.com 13 Sep '13

13 Sep '13

--On Friday, September 13, 2013 9:19 AM +0000 teichler(a)message-mobile.de wrote: > That's not so easy how you think because this is a running producive > Server and i don't have the time to build OpenLDAP 2.4 for CentOS 5.9, > thats why i try to use an ProxyCache. This is why, again, you could use the LTB packages I pointed you at. They don't replace the existing ldap libraries, etc, on the server. They install into their own location (/usr/local I believe). Then you don't have to build it yourself, and you can actually be on something current. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de 13 Sep '13

13 Sep '13

That's not so easy how you think because this is a running producive Server and i don't have the time to build OpenLDAP 2.4 for CentOS 5.9, thats why i try to use an ProxyCache. Best Regards Mike Teichler -- _____________________________________________________ Message Mobile GmbH Stresemannstr. 6, D-21335 Lüneburg teichler(a)message-mobile.de tel.: +49 (0)4131 24444-234, fax: +49 (0)4131 24444-2349 www.message-mobile.de GF: Dr. Martin Hecker, AG Lüneburg, HRB: 2414 _____________________________________________________

1 0

Re: (ITS#7693) ProxyCache Problems
by ck＠cksoft.de 13 Sep '13

13 Sep '13

Hi, On Fri, 13 Sep 2013, teichler(a)message-mobile.de wrote: > My Problem is, that this LDAP Server running on CentOS 5.9 Server, and > there are more Services then LDAP so I can't Updatet the Server and LDAP > 2.4. ... doesn't Supports CentOS 5.9. it should be perfectly possible to update to a current openldap server and leave the dependencies of your system to the old libraries. Just use one of the freely available source rpm and build from that. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de 13 Sep '13

13 Sep '13

And my Destination LDAP where the ProxyCache works in on LDAP 2.4.23. My Questions is: Is it generelly possible to do a ProxyCache query from a LDAP 2.4 server to a LDAP 2.3 server? -- _____________________________________________________ Message Mobile GmbH Stresemannstr. 6, D-21335 Lüneburg teichler(a)message-mobile.de tel.: +49 (0)4131 24444-234, fax: +49 (0)4131 24444-2349 www.message-mobile.de GF: Dr. Martin Hecker, AG Lüneburg, HRB: 2414 _____________________________________________________

1 0

Re: (ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de 12 Sep '13

12 Sep '13

My Problem is, that this LDAP Server running on CentOS 5.9 Server, and there are more Services then LDAP so I can't Updatet the Server and LDAP 2.4. ... doesn't Supports CentOS 5.9. -- _____________________________________________________ Message Mobile GmbH Stresemannstr. 6, D-21335 Lüneburg teichler(a)message-mobile.de tel.: +49 (0)4131 24444-234, fax: +49 (0)4131 24444-2349 www.message-mobile.de GF: Dr. Martin Hecker, AG Lüneburg, HRB: 2414 _____________________________________________________

1 0

(ITS#7695) Fix regression using ldapsearch with cldap
by stefw＠redhat.com 12 Sep '13

12 Sep '13

Full_Name: Stef walter Version: git master OS: Fedora 19 URL: ftp://ftp.openldap.org/incoming/stef-walter-cldap-regression-130912.patch Submission from: (NULL) (46.5.2.70) I get an assertion with today's git master when using ldapsearch with a cldap URL. openldap has been compiled with -DLDAP_CONNECTIONLESS $ ldapsearch -d -1 -LL -H 'cldap://10.34.37.22' -b '' -s base '(&(DnsDomain=ad.baseos.qe)(NtVer=\06\00\00\00))' NetLogon ldap_url_parse_ext(cldap://10.34.37.22) ldap_create ldap_url_parse_ext(cldap://10.34.37.22:389/??base) ldap_simple_bind ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: UDP 10.34.37.22:389 ldap_new_socket: 7 ldap_prepare_socket: 7 ldap_connect_to_host: Trying 10.34.37.22:389 ldap_open_defconn: successful ldap_parse_result ldapsearch: error.c:255: ldap_parse_result: Assertion `r != ((void *)0)' failed. Program received signal SIGABRT, Aborted. 0x000000322e835a19 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x000000322e835a19 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x000000322e837128 in __GI_abort () at abort.c:90 #2 0x000000322e82e986 in __assert_fail_base ( fmt=0x322e97dda8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x489ded "r != ((void *)0)", file=file@entry=0x489d2c "error.c", line=line@entry=255, function=function@entry=0x489e20 <__PRETTY_FUNCTION__.7860> "ldap_parse_result") at assert.c:92 #3 0x000000322e82ea32 in __GI___assert_fail ( assertion=0x489ded "r != ((void *)0)", file=0x489d2c "error.c", line=255, function=0x489e20 <__PRETTY_FUNCTION__.7860> "ldap_parse_result") at assert.c:101 #4 0x0000000000421a96 in ldap_parse_result (ld=0x6c7c90, r=0x0, errcodep=0x7fffffff914c, matcheddnp=0x7fffffff9140, errmsgp=0x7fffffff9138, referralsp=0x7fffffff9130, serverctrls=0x7fffffff9128, freeit=1) at error.c:255 #5 0x0000000000412093 in tool_bind (ld=0x6c7c90) at common.c:1623 #6 0x0000000000407f01 in main (argc=12, argv=0x7fffffffd3f8) at ldapsearch.c:903

1 0

Re: (ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by quanah＠zimbra.com 12 Sep '13

12 Sep '13

--On Thursday, September 12, 2013 4:04 PM +0000 stefw(a)redhat.com wrote: >> 2.4.35 is not the current version of OpenLDAP, 2.4.36 is. There were >> fixes to CLDAP made in 2.4.36. Please test against 2.4.36 and report >> back, thanks. > > This patch is against master. > > However master cldap support is broken in additional ways, and I'll be > filing further bugs/patches. Hi Stef, Thanks! In the future then, if it is an issue with the current 2.4 release series still, you can just put RE24 as the version. ;) Then I won't spend time trying to see if it's a known issue already fixed via the changes log. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by stefw＠redhat.com 12 Sep '13

12 Sep '13

On 12.09.2013 18:00, Quanah Gibson-Mount wrote: > --On Thursday, September 12, 2013 3:56 PM +0000 stefw(a)redhat.com wrote: > >> Full_Name: Stef Walter >> Version: 2.4.35 >> OS: Fedora 19 >> URL: ftp://ftp.openldap.org/incoming/stef-walter-130912.patch >> Submission from: (NULL) (46.5.2.70) >> >> >> Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is >> broken for IPv6 for current versions of openldap. Tested with version >> 2.4.35 > > > 2.4.35 is not the current version of OpenLDAP, 2.4.36 is. There were > fixes to CLDAP made in 2.4.36. Please test against 2.4.36 and report > back, thanks. This patch is against master. However master cldap support is broken in additional ways, and I'll be filing further bugs/patches. Cheers, Stef

1 0

Re: (ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by quanah＠zimbra.com 12 Sep '13

12 Sep '13

--On Thursday, September 12, 2013 3:56 PM +0000 stefw(a)redhat.com wrote: > Full_Name: Stef Walter > Version: 2.4.35 > OS: Fedora 19 > URL: ftp://ftp.openldap.org/incoming/stef-walter-130912.patch > Submission from: (NULL) (46.5.2.70) > > > Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is > broken for IPv6 for current versions of openldap. Tested with version > 2.4.35 2.4.35 is not the current version of OpenLDAP, 2.4.36 is. There were fixes to CLDAP made in 2.4.36. Please test against 2.4.36 and report back, thanks. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7693) ProxyCache Problems
by quanah＠zimbra.com 12 Sep '13

12 Sep '13

--On Thursday, September 12, 2013 2:38 PM +0000 teichler(a)message-mobile.de wrote: > Full_Name: Mike Teichler > Version: 2.4 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.152.191.58) > > > > Hello, > > I have an Issue with the ProxyCache on OpenLDAP > (2.4.23-32.el6_4.1)[CentOS 6] which should Cache the Queryanswers from an > OpenLDAP ( 2.3.43-12.el5_7.9)[CentOS 5] Server. Please upgrade to a supported release series (2.3 is not supported). Please upgrade to a current release (2.4.36 is the most recent release). 2.4.23 as built by RedHat is known to have numerous problems. If you cannot build OpenLDAP yourself, then I would suggest the packages from the LTB project, which have OpenLDAP builds of 2.4.36 for both RHEL5 and RHEL6: <http://ltb-project.org/wiki/download#openldap> --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by stefw＠redhat.com 12 Sep '13

12 Sep '13

Full_Name: Stef Walter Version: 2.4.35 OS: Fedora 19 URL: ftp://ftp.openldap.org/incoming/stef-walter-130912.patch Submission from: (NULL) (46.5.2.70) Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is broken for IPv6 for current versions of openldap. Tested with version 2.4.35 It's not clear if this ever worked properly. Connections immediately fail with: ldap_search_ext: Can't contact LDAP server (-1) The reason for this is that the LDAP_CONNECTIONLESS buffers include a prefix containing an address in a "struct sockaddr". However, struct sockaddr, is not a concrete type. In particular struct sockaddr_in6 is longer than struct sockaddr. Noted here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… So this leads to failures when using IPv6 as the code assumes that the address length is equal to sizeof (struct sockaddr). Seen here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… Example command: $ ldapsearch -d -1 -LL -H 'cldap://[2620:52:0:2223::1:1]' -b '' -s base '(&(DnsDomain=ad.baseos.qe)(NtVer=\06\00\00\00))' NetLogon Output will contain this: ldap_write: want=96 error=Invalid argument Which is the EINVAL resulting from bad value passed to sendto().

1 0

(ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de 12 Sep '13

12 Sep '13

Full_Name: Mike Teichler Version: 2.4 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.152.191.58) Hello, I have an Issue with the ProxyCache on OpenLDAP (2.4.23-32.el6_4.1)[CentOS 6] which should Cache the Queryanswers from an OpenLDAP ( 2.3.43-12.el5_7.9)[CentOS 5] Server. The Problem isn't the Proxy but the Cache. When I do a query, i get the right Answer. But if I look into the LDAP.log with locklevel=2048, I always get the Strings: QUERY NOT ANSWERABLE QUERY NOT CACHABLE and if I shutdown the Server where the Proxy get its Informations it doesn't answers to the same query. My Konfiguration: In: /etc/openldap/slapd.d/olcDatabase={1}ldap/olcOverlay={0}pcache.ldif dn: olcOverlay={0}pcache objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {0}pcache olcPcache: bdb 100000 30 1000 3600 olcPcacheAttrset: 0 objectClass gidNumber mail cn uid displayName uidNumber ou userPassword olcPcacheTemplate: "(objectClass=)" 0 3600 olcPcachePosition: tail olcPcacheMaxQueries: 10000 olcPcacheValidate: FALSE structuralObjectClass: olcPcacheConfig entryUUID: 3a14c15c-ab42-1032-824e-7d8dac3932bf creatorsName: cn=config createTimestamp: 20130906131604Z olcPcacheOffline: FALSE olcPcachePersist: TRUE entryCSN: 20130910133719.273176Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130910133719Z In: /etc/openldap/slapd.d/olcDatabase={1}ldap/olcOverlay={0}pcache/olcDatabase={0}bdb.ldif dn: olcDatabase={0}bdb objectClass: olcBdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}bdb olcDbDirectory: /var/lib/ldap olcDbCacheSize: 10000 olcDbConfig: {0} # olcDbConfig: {1} # Set the database in memory cache size. olcDbConfig: {2} # olcDbConfig: {3} set_cachesize 0 524288000 1 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: displayName pres,eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 3a14cbde-ab42-1032-824f-7d8dac3932bf creatorsName: cn=config createTimestamp: 20130906131604Z entryCSN: 20130906131604.110178Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130906131604Z If you need more Informations please ask. best regards, M. Teichler

1 0

(ITS#7692) segfault in overlay constraint - constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at constraint.c:713
by coudot＠linagora.com 12 Sep '13

12 Sep '13

Full_Name: Clement OUDOT Version: 2.4.35 OS: CentOS 6 64bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) I use the overlay constraint to check that a value of the attribute ssoRoles exists in the directory. The configuration looks like this: ---------------------------------------------- overlay constraint constraint_attribute ssoRoles uri ldap:///ou=applications,dc=cirra,dc=net?entrydn?sub?(&(objectClass=organizationalUnit)(ou:dn:=roles)) restrict="ldap:///ou=users,dc=cirra,dc=net??one?(objectClass=inetOrgPerson)" ---------------------------------------------- An ldapmodify with this LDIF crash the slapd process: ---------------------------------------------- dn: uid=toto,ou=users,dc=cirra,dc=net changetype: modify add: ssoRoles ssoRoles: ou=ROLE_PES,ou=roles,ou=simabo,ou=applications,dc=cirra,dc=net ---------------------------------------------- The crash occurs because the entry uid=toto,ou=users,dc=cirra,dc=net do not exist. The same LDIF on an existing entry works well. Below is the stacktrace generated with gdb: ---------------------------------------------- (gdb) run -d 0 Starting program: /usr/local/openldap/libexec/slapd -d 0 [Thread debugging using libthread_db enabled] [New Thread 0x7fffb3d42700 (LWP 16519)] [New Thread 0x7fffb3541700 (LWP 16521)] [New Thread 0x7fffb2d40700 (LWP 16522)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb2d40700 (LWP 16522)] constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at constraint.c:713 713 int diff = e->e_nname.bv_len - c->restrict_ndn.bv_len; Missing separate debuginfos, use: debuginfo-install berkeleydb-ltb-4.6.21.NC-4.el6.patch4.x86_64 cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-ldap-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64 db4-4.7.25-17.el6.x86_64 glibc-2.12-1.107.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6.x86_64 libcom_err-1.41.12-14.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-27.el6.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) bt full #0 constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at constraint.c:713 diff = <value optimized out> __PRETTY_FUNCTION__ = "constraint_check_restrict" #1 0x000000000054b39f in constraint_update (op=<value optimized out>, rs=0x7fffb2d3f950) at constraint.c:989 j = <value optimized out> ce = 0 on = 0x9e5e30 be = 0x7fffb2d3e4e0 c = 0x9e60f0 cp = <value optimized out> target_entry = 0x0 target_entry_copy = 0x0 modlist = 0x7fffa8000920 m = 0x7fffa8000920 b = 0x7fffa81015c0 i = <value optimized out> rsv = {bv_len = 24, bv_val = 0x60f2a4 "modify breaks constraint"} rc = <value optimized out> msg = 0x0 is_v = <value optimized out> #2 0x00000000004a6d7a in overlay_op_walk (op=0x7fffa8000960, rs=0x7fffb2d3f950, which=op_modify, oi=0x9e1020, on=0x9e5e30) at backover.c:661 func = 0x9e5e88 rc = 32768 #3 0x00000000004a7847 in over_op_func (op=0x7fffa8000960, rs=<value optimized out>, which=<value optimized out>) at backover.c:723 oi = <value optimized out> on = <value optimized out> be = 0x9ba220 db = {bd_info = 0x9e5e30, bd_self = 0x9ba220, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 12 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x9dca20, be_nsuffix = 0x9dca50, be_schemadn = { bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 26, bv_val = 0x9dcb70 "cn=manager,dc=cirra,dc=net"}, be_rootndn = {bv_len = 26, bv_val = 0x9dcbc0 "cn=manager,dc=cirra,dc=net"}, be_rootpw = {bv_len = 38, bv_val = 0x9dc8b0 "{SSHA}2S9rqrduHEq4AcNIfS+wxClQwbD5aoLn"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x9e01a0, be_acl = 0x9b9850, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, ---Type <return> to continue, or q <return> to quit--- be_pending_csn_list = 0xa6f7f0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x8838c0, be_private = 0x9ba3c0, be_next = { stqe_next = 0x9e6470}} cb = {sc_next = 0x0, sc_response = 0x4a6af0 <over_back_response>, sc_cleanup = 0, sc_private = 0x9e1020} sc = <value optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #4 0x000000000045728b in fe_op_modify (op=0x7fffa8000960, rs=0x7fffb2d3f950) at modify.c:303 update = <value optimized out> repl_user = <value optimized out> op_be = <value optimized out> bd = 0x88c200 textbuf = ">\000\000\000\000\000\000\000\240\030\020\250\377\177\000\000\000\000\000\000\000\000\000\000@\026\020\250\377\177\000\000\240\235G\000\000\000\000\000\267\244E", '\000' <repeats 13 times>, "\003\000\000\000\060\000\000\000[\000\000\000|", '\000' <repeats 11 times>, "\b", '\000' <repeats 31 times>, ">\000\000\000\000\000\000\000\360\025\020\250\377\177\000\000\000\000\000\000\000\000\000\000 \t\000\250\377\177\000\000\000\000\000\000\000\000\000\000@É #5 0x0000000000457bb6 in do_modify (op=0x7fffa8000960, rs=0x7fffb2d3f950) at modify.c:177 dn = {bv_len = 33, bv_val = 0x7fffa8101507 "uid=toto,ou=users,dc=cirra,dc=net"} textbuf = "\027\f\000\250\377\177", '\000' <repeats 42 times>, "PG\253\367\000\000\000\000P\333\377\367\377\177\000\000\000\000A", '\000' <repeats 13 times>, "\030f@\000\000\000\000\000Y\345`\237\064", '\000' <repeats 11 times>"\351, \363[\000\000\000\000\000`\t\000\250\377\177\000\000\340\024\302\236\064\000\000\000\377\377\377\377\377\177\000\000\030\372Ó²\377\177\000\000\210\021\302\236\064\000\000\000@\304X\237\064", '\000' <repeats 11 times>, ":\236\240\236\064\000\000\000\320\016\000\250\377\177\000\000\000\000\020\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\260\372Ó²\377\177\000\000\360.I", '\000' <repeats 13 times>, "\t\000\000\000\062\000\000\000`\t\000\250\377\177\000\000\320\016\000\250\377\177\000" tmp = <value optimized out> #6 0x000000000043f9a9 in connection_operation (ctx=0x7fffb2d3fab0, arg_v=0x7fffa8000960) at connection.c:1155 rc = 80 cancel = <value optimized out> op = 0x7fffa8000960 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x7ffff632bc10 ---Type <return> to continue, or q <return> to quit--- memctx = 0x7fffa8000ed0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #7 0x0000000000440195 in connection_read_thread (ctx=0x7fffb2d3fab0, argv=<value optimized out>) at connection.c:1291 rc = <value optimized out> cri = {op = 0x7fffa8000960, func = 0, arg = 0x0, ctx = 0x7fffb2d3fab0, nullop = <value optimized out>} s = <value optimized out> #8 0x0000000000593d00 in ldap_int_thread_pool_wrapper (xpool=0x960c00) at tpool.c:688 pool = 0x960c00 task = 0x7fffac0008c0 work_list = <value optimized out> ctx = {ltu_id = 140736193627904, ltu_key = {{ltk_key = 0x43e7c0, ltk_data = 0x7fffa8000dc0, ltk_free = 0x43e890 <conn_counter_destroy>}, {ltk_key = 0x492d40, ltk_data = 0x7fffa8000ed0, ltk_free = 0x492d60 <slap_sl_mem_destroy>}, {ltk_key = 0xa6f810, ltk_data = 0x7fffa8100f80, ltk_free = 0x4f7280 <bdb_reader_free>}, {ltk_key = 0x452ba0, ltk_data = 0x0, ltk_free = 0x452970 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>, { ltk_key = 0x0, ltk_data = 0x349f607eea, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = <value optimized out> keyslot = 555 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #9 0x000000349f607851 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #10 0x000000349f2e890d in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) ---------------------------------------------- Please tell me if something else is needed in this bug report. Regards, Clement OUDOT.

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by quanah＠zimbra.com 11 Sep '13

11 Sep '13

--On Thursday, September 12, 2013 3:31 AM +0000 chewcs(a)bii.a-star.edu.sg wrote: > This is a multi-part message in MIME format. > --------------010103040709080503030708 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > One more thing: the ldap master version is > > Openldap 2.3.40 on sunOS Syncrepl in 2.3.40 is known to be broken. I would advise you to upgrade it to 2.4.36. This ITS will be closed as invalid. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by chewcs＠bii.a-star.edu.sg 11 Sep '13

11 Sep '13

This is a multi-part message in MIME format. --------------010103040709080503030708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One more thing: the ldap master version is Openldap 2.3.40 on sunOS While the ldap slave is : OpenLDAP: slapd 2.4.36 (Aug 21 2013 09:39:54) On 09/12/13 10:23, CHEW Chee Siang wrote: > One more thing. The entry with "cn=depth" name won't sync only when > adding entries to ou=mailinglist. Somehow it is ok with ou=people. > > > > "Master" LDAP configuration: > /Include /go/to/core.schema// > //Include /go/to/cosine.schema// > //Include /go/to/inetorgperson.schema// > //Include /go/to/nis.schema// > //Include /go/to/samba.schema// > //Include /go/to/test.schema// > //pidfile /go/to/slapd.pid// > //argsfile /go/to/slapd.args/ > > TLSCipherSuite HIGH:MEDIUM:+SSLv2 > /TLSCACertificateFile /go/to/ldap.pem// > //TLSCertificateFile /go/to/ldap.pem// > //TLSCertificateKeyFile /go/to/ldap.key/ > > access to attrs=userPassword > by self write > by users read > by peername.ip=127.0.0.1 read > by peername.ip=10.X.0.0%255.255.0.0 read > by peername.ip=172.X.129.132 read > by peername.ip=172.X.1.109 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=X.X.68.0%255.255.255.0 read > by anonymous auth > > access to attrs=cryptPassword,md5Password,shadowLastChange > by self write > by users read > by peername.ip=127.0.0.1 read > by peername.ip=10.217.0.0%255.255.0.0 read > by peername.ip=172.X.129.132 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=X.X.68.0%255.255.255.0 read > by anonymous none > > access to dn.subtree="ou=zgroups,dc=test,dc=com > by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write > by self read > by users read > by peername.ip=127.0.0.1 read > by peername.ip=10.X.0.0%255.255.0.0 read > by peername.ip=X.X.X.0%255.255.255.0 read > by peername.ip=172.X.129.132 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by anonymous none > > access to * > by self read > by users read > by peername.ip=127.0.0.1 read > by peername.ip=10.X.0.0%255.255.0.0 read > by peername.ip=172.X.129.132 read > by peername.ip=172.X.1.109 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=X.X.68.0%255.255.255.0 read > by anonymous none > > # Database backend configuration. > > allow bind_v2 > database bdb > password-hash {CRYPT} > directory /go/to/ldap-master > suffix "dc=test,dc=com" > rootdn "cn=root,dc=test,dc=com" > rootpw secret > index objectClass,uid,uidNumber,entryCSN,entryUUID pres,eq > > # Configure syncrepl (provider) > > overlay syncprov > syncprov-checkpoint 1 1 # <ops> <minutes> > syncprov-sessionlog 100 # <max number of session logs> > > > > > "Slave" LDAP configuration: > include /usr/local/openldap/etc/openldap/schema/core.schema > include //usr/local/openldap/etc/openldap/schema/test.schema/ > include /usr/local/openldap/etc/openldap/schema/cosine.schema > include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema > include /usr/local/openldap/etc/openldap/schema/nis.schema > include /usr/local/openldap/etc/openldap/schema/samba.schema > > > # Define global ACLs to disable default read access. > allow bind_v2 > > pidfile /usr/local/openldap/var/run/slapd.pid > argsfile /usr/local/openldap/var/run/slapd.args > loglevel 256 > moduleload back_hdb.la > moduleload syncprov.la > moduleload back_monitor.la > moduleload back_ldap.la > > access to * > by self write > by users read > by peername.ip=127.0.0.1 read > by peername.ip=172.20.201.0%255.255.255.0 read > by anonymous read > > ####################################################################### > # BDB database definitions > ####################################################################### > > database bdb > suffix /"dc=test,dc=com"/ > rootdn "cn=Manager,/dc=test,dc=com"/ > rootpw secret > directory /usr/local/openldap/var/openldap-data > > # Indices to maintain > index cn,sn,uid pres,eq,approx,sub > index objectClass eq > > > index entryCSN,entryUUID eq > syncrepl rid=1 > provider=/ldap://ldap-master.com/ > type=refreshOnly > interval=00:00:00:30 > searchbase=/"dc=test,dc=com"/ > scope=sub > schemachecking=off > bindmethod=simple > binddn=/"cn=ldaplogin,ou=people,dc=test,dc=com"/ > credentials=/secret/ > > > On 09/12/13 05:57, Quanah Gibson-Mount wrote: >> --On Wednesday, September 11, 2013 8:03 AM +0000 >> chewcs(a)bii.a-star.edu.sg wrote: >> >>> Full_Name: Chew Chee Siang >>> Version: slapd 2.4.36 >>> OS: CentOS 6.4 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (123.136.68.2) >>> >>> >>> The setup is a master-slave configuration >>> Whenever a new user with name starting with "depth" is created at >>> master, >>> the record will not be sync to slave using syncrepl. >>> The other records are ok. >>> For e.g. cn=depth-maker,ou=people,dc=tt,dc=com >>> or cn=depth,ou=people,dc=tt,dc=com >> >> Provide your configuration minus passwords. >> >> --Quanah >> >> >> >> -- >> >> Quanah Gibson-Mount >> Lead Engineer >> Zimbra, Inc >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> > --------------010103040709080503030708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">One more thing: the ldap master version is <pre wrap="">Openldap 2.3.40 on sunOS </pre> <pre wrap="">While the ldap slave is : </pre> OpenLDAP: slapd 2.4.36 (Aug 21 2013 09:39:54) On 09/12/13 10:23, CHEW Chee Siang wrote: </div> <blockquote cite="mid:523125B9.2020004@bii.a-star.edu.sg" type="cite"> <meta http-equiv="Context-Type" content="text/html; charset=ISO-8859-1"> <div class="moz-cite-prefix">One more thing. The entry with "cn=depth" name won't sync only when adding entries to ou=mailinglist. Somehow it is ok with ou=people. "Master" LDAP configuration: Include        /go/to/core.schema Include     /go/to/cosine.schema Include     /go/to/inetorgperson.schema Include     /go/to/nis.schema Include     /go/to/samba.schema Include     /go/to/test.schema pidfile        /go/to/slapd.pid argsfile    /go/to/slapd.args TLSCipherSuite        HIGH:MEDIUM:+SSLv2 TLSCACertificateFile    /go/to/ldap.pem TLSCertificateFile      /go/to/ldap.pem TLSCertificateKeyFile   /go/to/ldap.key access to attrs=userPassword   by self write   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.1.109 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous auth access to attrs=cryptPassword,md5Password,shadowLastChange   by self write   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.217.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous none access to dn.subtree="ou=zgroups,dc=test,dc=com   by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write   by self read   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=X.X.X.0%255.255.255.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by anonymous none access to *   by self read   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.1.109 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous none # Database backend configuration. allow        bind_v2 database    bdb password-hash    {CRYPT} directory    /go/to/ldap-master suffix        "dc=test,dc=com" rootdn        "cn=root,dc=test,dc=com" rootpw        secret index        objectClass,uid,uidNumber,entryCSN,entryUUID pres,eq # Configure syncrepl (provider) overlay            syncprov syncprov-checkpoint    1 1        # <ops> <minutes> syncprov-sessionlog    100        # <max number of session logs> "Slave" LDAP configuration: include        /usr/local/openldap/etc/openldap/schema/core.schema include     /usr/local/openldap/etc/openldap/schema/test.schema include     /usr/local/openldap/etc/openldap/schema/cosine.schema include     /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include     /usr/local/openldap/etc/openldap/schema/nis.schema include     /usr/local/openldap/etc/openldap/schema/samba.schema # Define global ACLs to disable default read access. allow bind_v2 pidfile        /usr/local/openldap/var/run/slapd.pid argsfile    /usr/local/openldap/var/run/slapd.args loglevel 256 moduleload      back_hdb.la moduleload      syncprov.la moduleload      back_monitor.la moduleload      back_ldap.la access to *      by self write      by users read      by peername.ip=127.0.0.1 read      by peername.ip=172.20.201.0%255.255.255.0 read      by anonymous read ####################################################################### # BDB database definitions ####################################################################### database    bdb suffix        "dc=test,dc=com" rootdn        "cn=Manager,dc=test,dc=com" rootpw        secret directory    /usr/local/openldap/var/openldap-data # Indices to maintain index cn,sn,uid pres,eq,approx,sub index    objectClass    eq index entryCSN,entryUUID eq syncrepl                rid=1                         provider=<a moz-do-not-send="true" class="moz-txt-link-freetext">ldap://ldap-master.com</a>                         type=refreshOnly                         interval=00:00:00:30                         searchbase="dc=test,dc=com"                         scope=sub                         schemachecking=off                         bindmethod=simple                         binddn="cn=ldaplogin,ou=people,dc=test,dc=com"                         credentials=secret On 09/12/13 05:57, Quanah Gibson-Mount wrote: </div> <blockquote cite="mid:75FEF2DB661402B3EB284EDD@%5B192.168.1.22%5D" type="cite">--On Wednesday, September 11, 2013 8:03 AM +0000 <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:chewcs@bii.a-star.edu.sg">chewcs(a)bii.a-star.edu.sg</a> wrote: <blockquote type="cite">Full_Name: Chew Chee Siang Version: slapd 2.4.36 OS: CentOS 6.4 URL: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> Submission from: (NULL) (123.136.68.2) The setup is a master-slave configuration Whenever a new user with name starting with "depth" is created at master, the record will not be sync to slave using syncrepl. The other records are ok. For e.g. cn=depth-maker,ou=people,dc=tt,dc=com or cn=depth,ou=people,dc=tt,dc=com </blockquote> Provide your configuration minus passwords. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra ::  the leader in open source messaging and collaboration </blockquote> </blockquote> </body> </html> --------------010103040709080503030708--

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by chewcs＠bii.a-star.edu.sg 11 Sep '13

11 Sep '13

This is a multi-part message in MIME format. --------------040706000700030201020504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One more thing. The entry with "cn=depth" name won't sync only when adding entries to ou=mailinglist. Somehow it is ok with ou=people. "Master" LDAP configuration: /Include /go/to/core.schema// //Include /go/to/cosine.schema// //Include /go/to/inetorgperson.schema// //Include /go/to/nis.schema// //Include /go/to/samba.schema// //Include /go/to/test.schema// //pidfile /go/to/slapd.pid// //argsfile /go/to/slapd.args/ TLSCipherSuite HIGH:MEDIUM:+SSLv2 /TLSCACertificateFile /go/to/ldap.pem// //TLSCertificateFile /go/to/ldap.pem// //TLSCertificateKeyFile /go/to/ldap.key/ access to attrs=userPassword by self write by users read by peername.ip=127.0.0.1 read by peername.ip=10.X.0.0%255.255.0.0 read by peername.ip=172.X.129.132 read by peername.ip=172.X.1.109 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=X.X.68.0%255.255.255.0 read by anonymous auth access to attrs=cryptPassword,md5Password,shadowLastChange by self write by users read by peername.ip=127.0.0.1 read by peername.ip=10.217.0.0%255.255.0.0 read by peername.ip=172.X.129.132 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=X.X.68.0%255.255.255.0 read by anonymous none access to dn.subtree="ou=zgroups,dc=test,dc=com by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write by self read by users read by peername.ip=127.0.0.1 read by peername.ip=10.X.0.0%255.255.0.0 read by peername.ip=X.X.X.0%255.255.255.0 read by peername.ip=172.X.129.132 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by anonymous none access to * by self read by users read by peername.ip=127.0.0.1 read by peername.ip=10.X.0.0%255.255.0.0 read by peername.ip=172.X.129.132 read by peername.ip=172.X.1.109 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=X.X.68.0%255.255.255.0 read by anonymous none # Database backend configuration. allow bind_v2 database bdb password-hash {CRYPT} directory /go/to/ldap-master suffix "dc=test,dc=com" rootdn "cn=root,dc=test,dc=com" rootpw secret index objectClass,uid,uidNumber,entryCSN,entryUUID pres,eq # Configure syncrepl (provider) overlay syncprov syncprov-checkpoint 1 1 # <ops> <minutes> syncprov-sessionlog 100 # <max number of session logs> "Slave" LDAP configuration: include /usr/local/openldap/etc/openldap/schema/core.schema include //usr/local/openldap/etc/openldap/schema/test.schema/ include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/samba.schema # Define global ACLs to disable default read access. allow bind_v2 pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args loglevel 256 moduleload back_hdb.la moduleload syncprov.la moduleload back_monitor.la moduleload back_ldap.la access to * by self write by users read by peername.ip=127.0.0.1 read by peername.ip=172.20.201.0%255.255.255.0 read by anonymous read ####################################################################### # BDB database definitions ####################################################################### database bdb suffix /"dc=test,dc=com"/ rootdn "cn=Manager,/dc=test,dc=com"/ rootpw secret directory /usr/local/openldap/var/openldap-data # Indices to maintain index cn,sn,uid pres,eq,approx,sub index objectClass eq index entryCSN,entryUUID eq syncrepl rid=1 provider=/ldap://ldap-master.com/ type=refreshOnly interval=00:00:00:30 searchbase=/"dc=test,dc=com"/ scope=sub schemachecking=off bindmethod=simple binddn=/"cn=ldaplogin,ou=people,dc=test,dc=com"/ credentials=/secret/ On 09/12/13 05:57, Quanah Gibson-Mount wrote: > --On Wednesday, September 11, 2013 8:03 AM +0000 > chewcs(a)bii.a-star.edu.sg wrote: > >> Full_Name: Chew Chee Siang >> Version: slapd 2.4.36 >> OS: CentOS 6.4 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (123.136.68.2) >> >> >> The setup is a master-slave configuration >> Whenever a new user with name starting with "depth" is created at >> master, >> the record will not be sync to slave using syncrepl. >> The other records are ok. >> For e.g. cn=depth-maker,ou=people,dc=tt,dc=com >> or cn=depth,ou=people,dc=tt,dc=com > > Provide your configuration minus passwords. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Lead Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > --------------040706000700030201020504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">One more thing. The entry with "cn=depth" name won't sync only when adding entries to ou=mailinglist. Somehow it is ok with ou=people. "Master" LDAP configuration: Include        /go/to/core.schema Include     /go/to/cosine.schema Include     /go/to/inetorgperson.schema Include     /go/to/nis.schema Include     /go/to/samba.schema Include     /go/to/test.schema pidfile        /go/to/slapd.pid argsfile    /go/to/slapd.args TLSCipherSuite        HIGH:MEDIUM:+SSLv2 TLSCACertificateFile    /go/to/ldap.pem TLSCertificateFile      /go/to/ldap.pem TLSCertificateKeyFile   /go/to/ldap.key access to attrs=userPassword   by self write   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.1.109 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous auth access to attrs=cryptPassword,md5Password,shadowLastChange   by self write   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.217.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous none access to dn.subtree="ou=zgroups,dc=test,dc=com   by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write   by self read   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=X.X.X.0%255.255.255.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by anonymous none access to *   by self read   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.1.109 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous none # Database backend configuration. allow        bind_v2 database    bdb password-hash    {CRYPT} directory    /go/to/ldap-master suffix        "dc=test,dc=com" rootdn        "cn=root,dc=test,dc=com" rootpw        secret index        objectClass,uid,uidNumber,entryCSN,entryUUID pres,eq # Configure syncrepl (provider) overlay            syncprov syncprov-checkpoint    1 1        # <ops> <minutes> syncprov-sessionlog    100        # <max number of session logs> "Slave" LDAP configuration: include        /usr/local/openldap/etc/openldap/schema/core.schema include     /usr/local/openldap/etc/openldap/schema/test.schema include     /usr/local/openldap/etc/openldap/schema/cosine.schema include     /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include     /usr/local/openldap/etc/openldap/schema/nis.schema include     /usr/local/openldap/etc/openldap/schema/samba.schema # Define global ACLs to disable default read access. allow bind_v2 pidfile        /usr/local/openldap/var/run/slapd.pid argsfile    /usr/local/openldap/var/run/slapd.args loglevel 256 moduleload      back_hdb.la moduleload      syncprov.la moduleload      back_monitor.la moduleload      back_ldap.la access to *      by self write      by users read      by peername.ip=127.0.0.1 read      by peername.ip=172.20.201.0%255.255.255.0 read      by anonymous read ####################################################################### # BDB database definitions ####################################################################### database    bdb suffix        "dc=test,dc=com" rootdn        "cn=Manager,dc=test,dc=com" rootpw        secret directory    /usr/local/openldap/var/openldap-data # Indices to maintain index cn,sn,uid pres,eq,approx,sub index    objectClass    eq index entryCSN,entryUUID eq syncrepl                rid=1                         provider=<a class="moz-txt-link-freetext" href="ldap://ldap-master.com">ldap://ldap-master.com</a>                         type=refreshOnly                         interval=00:00:00:30                         searchbase="dc=test,dc=com"                         scope=sub                         schemachecking=off                         bindmethod=simple                         binddn="cn=ldaplogin,ou=people,dc=test,dc=com"                         credentials=secret On 09/12/13 05:57, Quanah Gibson-Mount wrote: </div> <blockquote cite="mid:75FEF2DB661402B3EB284EDD@%5B192.168.1.22%5D" type="cite">--On Wednesday, September 11, 2013 8:03 AM +0000 <a class="moz-txt-link-abbreviated" href="mailto:chewcs@bii.a-star.edu.sg">chewcs(a)bii.a-star.edu.sg</a> wrote: <blockquote type="cite">Full_Name: Chew Chee Siang Version: slapd 2.4.36 OS: CentOS 6.4 URL: <a class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> Submission from: (NULL) (123.136.68.2) The setup is a master-slave configuration Whenever a new user with name starting with "depth" is created at master, the record will not be sync to slave using syncrepl. The other records are ok. For e.g. cn=depth-maker,ou=people,dc=tt,dc=com or cn=depth,ou=people,dc=tt,dc=com </blockquote> Provide your configuration minus passwords. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra ::  the leader in open source messaging and collaboration </blockquote> </body> </html> --------------040706000700030201020504--

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by quanah＠zimbra.com 11 Sep '13

11 Sep '13

--On Wednesday, September 11, 2013 8:03 AM +0000 chewcs(a)bii.a-star.edu.sg wrote: > Full_Name: Chew Chee Siang > Version: slapd 2.4.36 > OS: CentOS 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.136.68.2) > > > The setup is a master-slave configuration > Whenever a new user with name starting with "depth" is created at master, > the record will not be sync to slave using syncrepl. > The other records are ok. > For e.g. cn=depth-maker,ou=people,dc=tt,dc=com > or cn=depth,ou=people,dc=tt,dc=com Provide your configuration minus passwords. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7691) syncrepl does not work with names start with depth
by chewcs＠bii.a-star.edu.sg 11 Sep '13

11 Sep '13

Full_Name: Chew Chee Siang Version: slapd 2.4.36 OS: CentOS 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.136.68.2) The setup is a master-slave configuration Whenever a new user with name starting with "depth" is created at master, the record will not be sync to slave using syncrepl. The other records are ok. For e.g. cn=depth-maker,ou=people,dc=tt,dc=com or cn=depth,ou=people,dc=tt,dc=com

1 0

Re: (ITS#7687) slapd with chaining dies on ManageDsaIT control
by pierangelo.masarati＠polimi.it 10 Sep '13

10 Sep '13

Thanks for the report; I have a quick fix, I'm testing it and will commit shortly. p. On 09/10/2013 09:14 PM, ck(a)cksoft.de wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > > --4178219828-1091139785-1378839346=:6609 > Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed > Content-Transfer-Encoding: 8BIT > Content-ID: <alpine.BSF.2.00.1309102056121.6609(a)pohjola.cksoft.de> > > Hi, > > On Tue, 10 Sep 2013, Michael Ströder wrote: > >> ck(a)cksoft.de wrote: >>> we have a java application using JNDI that uses the password modify extended >>> operation to change user passwords. >>> [..] >>> When running slapd with heavy logging we save the only difference to ldappasswd >>> which works fine against our masters is that JNDI sets the ManageDsaIT by >>> default. >> >> Of course slapd should never crash. > > yes of course not. This opens an attack vector for shooting down the slapd to at least anyone who has bind access which is concerning me. > > Apart from that the customers problem is solved. We just stopped sending the control. A bit like Dr. Dr. it hurts when I Do this. Then why don't you stop doing it. > >> But strictly speaking the semantics of using ManageDsaIT control along with >> password modify ext.op. is not specified - at least not in RFC 3062. > > yes. jndi sets the control by default. > >>From looking at the assert > > slapd: chain.c:199: chaining_control_remove: Assertion `op->o_ctrls != ((void *)0)' failed. > > the comment in chain.c seems to hint at an overly simple assumption. But in understand too little of slapd internals and code flow: > > 188 static int > 189 chaining_control_remove( > 190 Operation *op, > 191 LDAPControl ***oldctrlsp ) > 192 { > 193 LDAPControl **oldctrls = *oldctrlsp; > 194 > 195 /* we assume that the first control is the chaining control > 196 * added by the chain overlay, so it's the only one we explicitly > 197 * free */ > 198 if ( op->o_ctrls != oldctrls ) { > 199 assert( op->o_ctrls != NULL ); > 200 assert( op->o_ctrls[ 0 ] != NULL ); > 201 > 202 free( op->o_ctrls ); > 203 > 204 op->o_chaining = 0; > 205 op->o_ctrls = oldctrls; > 206 } > 207 > 208 *oldctrlsp = NULL; > 209 > 210 return 0; > 211 } > > > Could it be as simple as walking the linked list and just removing the chaining control. > > Of course another strategy might be to filter anything but the chaining control up front. > > Greetings > Christian > >> >> Ciao, Michael. >> >> > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: (ITS#7687) slapd with chaining dies on ManageDsaIT control
by ck＠cksoft.de 10 Sep '13

10 Sep '13

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --4178219828-1091139785-1378839346=:6609 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: <alpine.BSF.2.00.1309102056121.6609(a)pohjola.cksoft.de> Hi, On Tue, 10 Sep 2013, Michael Ströder wrote: > ck(a)cksoft.de wrote: >> we have a java application using JNDI that uses the password modify extended >> operation to change user passwords. >> [..] >> When running slapd with heavy logging we save the only difference to ldappasswd >> which works fine against our masters is that JNDI sets the ManageDsaIT by >> default. > > Of course slapd should never crash. yes of course not. This opens an attack vector for shooting down the slapd to at least anyone who has bind access which is concerning me. Apart from that the customers problem is solved. We just stopped sending the control. A bit like Dr. Dr. it hurts when I Do this. Then why don't you stop doing it. > But strictly speaking the semantics of using ManageDsaIT control along with > password modify ext.op. is not specified - at least not in RFC 3062. yes. jndi sets the control by default. >From looking at the assert slapd: chain.c:199: chaining_control_remove: Assertion `op->o_ctrls != ((void *)0)' failed. the comment in chain.c seems to hint at an overly simple assumption. But in understand too little of slapd internals and code flow: 188 static int 189 chaining_control_remove( 190 Operation *op, 191 LDAPControl ***oldctrlsp ) 192 { 193 LDAPControl **oldctrls = *oldctrlsp; 194 195 /* we assume that the first control is the chaining control 196 * added by the chain overlay, so it's the only one we explicitly 197 * free */ 198 if ( op->o_ctrls != oldctrls ) { 199 assert( op->o_ctrls != NULL ); 200 assert( op->o_ctrls[ 0 ] != NULL ); 201 202 free( op->o_ctrls ); 203 204 op->o_chaining = 0; 205 op->o_ctrls = oldctrls; 206 } 207 208 *oldctrlsp = NULL; 209 210 return 0; 211 } Could it be as simple as walking the linked list and just removing the chaining control. Of course another strategy might be to filter anything but the chaining control up front. Greetings Christian > > Ciao, Michael. > > -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer --4178219828-1091139785-1378839346=:6609--

1 0

(ITS#7690) OpenLDAP 2.4.36 crashing with MDB
by marco.pizzoli＠gmail.com 10 Sep '13

10 Sep '13

Full_Name: Marco Pizzoli Version: 2.4.36 OS: RHEL 5.4 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) NOTICE: This is not a complete bug report. I'm aware I'm not providing useful information on the exact problem and how to fix it. I'm filing this ITS just to keep track of a crash happened to me with the latest release of OpenLDAP with MDB. WHAT HAS HAPPENED A colleague of mine tried to create a clone of an entry by using a graphic client. Something bad happened during that and as a result he obtained an entry nested 509 times: uid=pippo,uid=pippo,uid=pippo,etc...etc...ou=root When trying to delete the root of those entries, with phpldapadmin, I managed to crash OL without nothing executed. It was an MDB database. I zeroed that db, made it repopulate (it is part of a multi-master topology) by using the HDB database engine and re-tried to delete that (root)entry. This time the operation, even not completing (it dropped only half the of the subtree), it suffered no crash. All other slapds in the multi-master topology crashed. I restated the command on the first and this time it completed well. In the end, I re-used the MDB database after having those entries syncronized by other slapd of the multi-master topology. As said in advance, I simply can't provide any conf or core or anything else.

1 0

Re: (ITS#7687) slapd with chaining dies on ManageDsaIT control
by michael＠stroeder.com 10 Sep '13

10 Sep '13

This is a cryptographically signed message in MIME format. --------------ms020200010309050905060801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ck(a)cksoft.de wrote: > we have a java application using JNDI that uses the password modify ext= ended > operation to change user passwords. > [..] > When running slapd with heavy logging we save the only difference to ld= appasswd > which works fine against our masters is that JNDI sets the ManageDsaIT = by > default. Of course slapd should never crash. But strictly speaking the semantics of using ManageDsaIT control along wi= th password modify ext.op. is not specified - at least not in RFC 3062. Ciao, Michael. --------------ms020200010309050905060801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTEwMTgyMzM1WjAj BgkqhkiG9w0BCQQxFgQUEspAhGoCvSxwItIQvDO9RKj4c1kwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEASG/b4BKftKYcHYL3Q2ELEB+o3JQzuFoN kJf0ZxDQGuyOoR55w0WpGITlb+WOblLtZm34rdrB8ZeHbX3AmC4VH4yiuV8wnjByychDpbG0 8w+5Kqgm0Zrl/NYFpSbyYJJu3wvv1Jcj/pgRQ0BTprM95rMbEnC2XnNfp0JQeSZ0BmvbL6Fc R8yPkRqfxrsvHoCaGAlHlRihqSalR0m3JPjMM9H0TcfxJEtz2/rdtjN8zi3RRV94qmwd4qCk JW8FRFQEzdcd8Kjkd3HxRPfTTWNIbnROi9/K7wEb/lGgL8hBkgsz6pRGviD6xpIXZnYZ9+Vw o5+e3J5DNhfWgDgPtKCuRAAAAAAAAA== --------------ms020200010309050905060801--

1 0

Re: (ITS#7689) Configuration directive 'logfile' has no use
by quanah＠zimbra.com 10 Sep '13

10 Sep '13

--On Tuesday, September 10, 2013 4:02 PM +0000 eurban(a)harris.com wrote: > Full_Name: Eric Urban > Version: 2.4.36 > OS: RHEL 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (158.147.58.198) > > > Hi, I have been working on packaging 2.4.36 for RHEL 6.4. No issues > there. One requirement is to have logging enabled by default. OpenLDAP > supports syslog, but its use is discouraged within my business area. I > noticed the 'logfile' configuration directive. I still use the > 'slapd.conf' configuration file format, if that matters. I added the > following line to my 'slapd.conf' "logfile" is not a replacement for syslog logging, and is an entirely separate function. Please read the slapd.conf(5) man page. Closing this ITS as invalid. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7689) Configuration directive 'logfile' has no use
by eurban＠harris.com 10 Sep '13

10 Sep '13

Full_Name: Eric Urban Version: 2.4.36 OS: RHEL 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (158.147.58.198) Hi, I have been working on packaging 2.4.36 for RHEL 6.4. No issues there. One requirement is to have logging enabled by default. OpenLDAP supports syslog, but its use is discouraged within my business area. I noticed the 'logfile' configuration directive. I still use the 'slapd.conf' configuration file format, if that matters. I added the following line to my 'slapd.conf' logfile /var/log/openldap/openldap.log loglevel none sync stats Then I did mkdir /var/log/openldap chown ldap:ldap /var/log/openldap I restart OpenLDAP and the log file is created but never written to. If I start openldap with 'slapd -d -1' the log file is written to. I checked in include/ldap_log.h and see that the macros for LogN check against 'ldap_debug' before calling lutil_debug. The pseudo-variable 'ldap_debug' is a preprocessor #define at the bottom of the same file. It is just an integer bitmask for logging. I took a look at servers/slapd/bconfig.c and see that 'config_generic' does an fopen() and then passes the result to lutil_debug_file. So far, so good. In config_loglevel the 'loglevel' directive from my slapd.conf is parsed and assigned to 'ldap_syslog' but never 'ldap_debug'. So slapd in server mode will create this file but never write to it. If you set 'logfile' in slapd.conf and start with the -d flag it will, but this is pretty pointless is as you already have the logging messages in your terminal in that case. Is this intentional? I'm not seeing the utility of the 'logfile' configuration directive. In normal operations it's only purpose will be to create an empty file and to confuse system administrators.

1 0

(ITS#7688) MDB_WRITEMAP + non-writemap process broken
by h.b.furuseth＠usit.uio.no 10 Sep '13

10 Sep '13

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.8 OS: Linux x86_64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard mdb_env_open(,,MDB_WRITEMAP,) does not grow the data file to the mapsize if another process has it open without MDB_WRITEMAP. The new MDB_env gets Bus Error in mdb_page_alloc() if it tries to grow mt_next_pgno. Broken by 2e7130cab0129e3b72a25d39c5d4e5a5c55cb353 "Allow mdb_env_set_mapsize() on an open environment". It made ftruncate() conditional on 'newsize'. To avoid mapsize wars between environments? Could do: if (flags & MDB_WRITEMAP) { prot |= PROT_WRITE; if (!newsize) { off_t pos = lseek(env->me_fd, 0, SEEK_END); if (pos == (off_t)-1) return ErrCode(); if ((size_t)pos < env->me_mapsize) newsize = 1; } if (newsize && ftruncate(env->me_fd, env->me_mapsize) < 0) return ErrCode(); } But that still has a race between processes mapping the environment at the same time, one process could shrink the map just after another grew it. And I'm unsure how env->me_mapsize would end up in this case. Another way: Move ftruncate() to mdb_page_alloc(), which has no race. Grow to <new mt_next_pgno + 25%>. To avoid seeks, maintain me_txns->mti_next_pgno in mdb_page_alloc{MDB_WRITEMAP} and txn_reset(writer).

1 0

(ITS#7687) slapd with chaining dies on ManageDsaIT control
by ck＠cksoft.de 10 Sep '13

10 Sep '13

Full_Name: Christian Kratzer Version: 2.4.36 OS: CentOS / RedHat Enterprise URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2003:41:c010:8001:9028:d44e:e3ea:c880) Hi, we have a java application using JNDI that uses the password modify extended operation to change user passwords. This runs fine against our masters but causes an assert when run against our slaves that use chaining to pass the modify request to the masters. slapd: chain.c:199: chaining_control_remove: Assertion `op->o_ctrls != ((void *)0)' failed. Backtrace is as follows: Core was generated by `/usr/local/sbin/slapd -h ldap://:389/ ldaps://:636/ -d 1 -F /usr/local/etc/open'. Program terminated with signal 6, Aborted. #0 0x00007fdf5125c8a5 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install openldap-release-2.4.36-1.el6.x86_64 (gdb) bt #0 0x00007fdf5125c8a5 in raise () from /lib64/libc.so.6 #1 0x00007fdf5125e085 in abort () from /lib64/libc.so.6 #2 0x00007fdf51255a1e in __assert_fail_base () from /lib64/libc.so.6 #3 0x00007fdf51255ae0 in __assert_fail () from /lib64/libc.so.6 #4 0x00007fdf4e7fd3ca in chaining_control_remove (op=0x7fdef81add00, oldctrlsp=0x7fdf07ffe078) at chain.c:199 #5 0x00007fdf4e7feedd in ldap_chain_op (op=0x7fdef81add00, rs=0x7fdf07ffe950, op_f=0x7fdf4e7fc680 <ldap_back_extended>, ref=0x7fdef81ae0c0, depth=0) at chain.c:655 #6 0x00007fdf4e7ffd37 in ldap_chain_response (op=0x7fdef81add00, rs=0x7fdf07ffe950) at chain.c:1092 #7 0x00000000004954d8 in ?? () #8 0x000000000043d2ee in ?? () #9 0x000000000043de49 in ?? () #10 0x000000000043e5ae in slap_send_ldap_extended () #11 0x000000000045defc in fe_extended () #12 0x00000000004957e7 in overlay_op_walk () #13 0x00000000004961c7 in ?? () #14 0x000000000045e315 in do_extended () #15 0x000000000042df79 in ?? () #16 0x000000000042e755 in ?? () #17 0x00007fdf52a6d498 in ldap_int_thread_pool_wrapper (xpool=0x13f1450) at tpool.c:688 #18 0x00007fdf515c4851 in start_thread () from /lib64/libpthread.so.0 #19 0x00007fdf5131290d in clone () from /lib64/libc.so.6 (gdb) When running slapd with heavy logging we save the only difference to ldappasswd which works fine against our masters is that JNDI sets the ManageDsaIT by default. We were subsequently able to work around the issue by changing the default JNDI behaviour so as not to set the ManageDSA IT control with: env.put(Context.REFERRAL, "throw"); As detailed in following related post and jndi documentation: http://www.openldap.org/lists/ietf-ldapext/200409/msg00035.html http://docs.oracle.com/javase/1.4.2/docs/guide/jndi/jndi-ldap-gl.html#refer… It would of course be helpfull if slapd would handle the situation slightly more gracefully. Even though the control is utterly useless in our case with chaining it is the default on jndi so handling this case would be helpfull to all java users out there. I am not quire sure where this goes wrong exactly. If anybody can write up a patch I would be more than gratefull to test as we have a reproducible test setup on hand in our lab that we can run any time. I can also retest with fuller debug symbols than above if required. Seems only our modules hat debuginfo at the time of the backtrace. Greetings Christian Kratzer CK Software GmbH

1 0

Re: (ITS#7398) Retrieve LDAP server cert
by hyc＠symas.com 10 Sep '13

10 Sep '13

Michael Ströder wrote: > On Fri, 21 Sep 2012 10:43:42 -0700 Howard Chu <hyc(a)symas.com> wrote >> michael(a)stroeder.com wrote: >>> Feature request: >>> When using LDAPS or StartTLS it would be sometimes handy to retrieve the >>> LDAP server certificate over the LDAP client API. >>> >>> Opinions? >> >> And then what? I think it'd be straightforward for us to return a copy of it >> in DER binary format. What do clients need to do with it? > > In my case (web2ldap): Simply display it to the user. Probably would have been easier to just return the signature. > If it's not too much work this would be a handy feature. Added in master, please test - I have not tested any of this. -- -- 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#7686) Feature request: TLS prot/cipher retrievable with ldap_get_option()
by hyc＠symas.com 09 Sep '13

09 Sep '13

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: > Submission from: (NULL) (79.227.140.201) > > > Similar to logging at server-side (see ITS#7683) it should be possible for a > LDAP client to retrieve the TLS protocol version and cipher suites actually > negotiated by call to ldap_get_option(3) to be able to make decisions according > to local security policy. > > Added in master, tho I logged it against ITS#7683. -- -- 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#7686) Feature request: TLS prot/cipher retrievable with ldap_get_option()
by michael＠stroeder.com 09 Sep '13

09 Sep '13

Full_Name: Version: OS: URL: Submission from: (NULL) (79.227.140.201) Similar to logging at server-side (see ITS#7683) it should be possible for a LDAP client to retrieve the TLS protocol version and cipher suites actually negotiated by call to ldap_get_option(3) to be able to make decisions according to local security policy.

1 0

Re: (ITS#7381) Dynamically added chaining configuration stops working after restart
by hyc＠symas.com 09 Sep '13

09 Sep '13

Ivan Nejgebauer wrote: > On 06.09.2013. 21:56, hyc(a)symas.com wrote: >> ian(a)uns.ac.rs wrote: >>> If a minimal chaining configuration is dynamically added to a consumer server in >>> a provider/consumer pair running delta-syncrepl, it will stop working when the >>> consumer is restarted. The configuration is modelled after the one used in >>> test022 in the OpenLDAP source distribution: >> >> Sorry this report was neglected for so long, and thanks for the excellent test >> case. This is now fixed in git master. > > Tested against git master (721e46fe6695077d63a3df6ea2e397920a72308d) with the original > use case and it works, thanks. However, slapd now segfaults if started with cn=config > obtained by converting an existing chaining configuration from slapd.conf. Steps to > reproduce, using the scripts from the archive attached to the original report: Ah thanks. Previous commit changed too much. Fixed now in master. > $ make clean-all replica-chaining > $ ./start-replica.sh # segfault > > The crash is in chain_ldadd, and occurs because the first back-ldap instance in the > converted configuration lacks an olcDbURI. I have attached a patch which inserts a > dummy URI in the common parameter structure when it's allocated. This URI > (ldap://0.0.0.0) should never match any actual referral, so the instance can only > serve to initialize common parameters (which happens with the first instance anyway, > if I understood the code correctly.) > -- -- 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#7381) Dynamically added chaining configuration stops working after restart
by ian＠uns.ac.rs 09 Sep '13

09 Sep '13

This is a multi-part message in MIME format. --------------070406020601050207030907 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 06.09.2013. 21:56, hyc(a)symas.com wrote: > ian(a)uns.ac.rs wrote: >> If a minimal chaining configuration is dynamically added to a consumer server in >> a provider/consumer pair running delta-syncrepl, it will stop working when the >> consumer is restarted. The configuration is modelled after the one used in >> test022 in the OpenLDAP source distribution: > > Sorry this report was neglected for so long, and thanks for the excellent test > case. This is now fixed in git master. Tested against git master (721e46fe6695077d63a3df6ea2e397920a72308d) with the original use case and it works, thanks. However, slapd now segfaults if started with cn=config obtained by converting an existing chaining configuration from slapd.conf. Steps to reproduce, using the scripts from the archive attached to the original report: $ make clean-all replica-chaining $ ./start-replica.sh # segfault The crash is in chain_ldadd, and occurs because the first back-ldap instance in the converted configuration lacks an olcDbURI. I have attached a patch which inserts a dummy URI in the common parameter structure when it's allocated. This URI (ldap://0.0.0.0) should never match any actual referral, so the instance can only serve to initialize common parameters (which happens with the first instance anyway, if I understood the code correctly.) -- Ivan Nejgebauer Glavni sistem inženjer CIT-UNS/ARMUNS Univerzitet u Novom Sadu Trg Dositeja Obradovića 5 21000 Novi Sad +381 21 485 2025 ian(a)uns.ac.rs www.uns.ac.rs --------------070406020601050207030907 Content-Type: text/x-patch; name="0001-Fix-crash-w-converted-chain-config.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Fix-crash-w-converted-chain-config.patch" >From 49dc118a97cc5b7e0723905faf08480facb78912 Mon Sep 17 00:00:00 2001 From: Ivan Nejgebauer <ian(a)uns.ac.rs> Date: Mon, 9 Sep 2013 11:33:02 +0200 Subject: [PATCH] Fix crash w/converted chain config As a result of the fix for ITS#7381 (4d02a43ec9a4be422d83094e8d39b7ef3bc290c5) slapd segfaults if started with dynamic configuration after converting a slapd.conf chaining setup to cn=config. This is because the common back-ldap parameters, emitted as the first olcDatabase entry, lack an olcDbURI attribute. This patch adds a dummy LDAP URI which should never match a real one (ldap://0.0.0.0) to the common parameter structure. --- servers/slapd/back-ldap/chain.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/servers/slapd/back-ldap/chain.c b/servers/slapd/back-ldap/chain.c index a7c53ed..ab71b21 100644 --- a/servers/slapd/back-ldap/chain.c +++ b/servers/slapd/back-ldap/chain.c @@ -2019,6 +2019,7 @@ ldap_chain_db_init_common( BackendInfo *bi = be->bd_info; ldapinfo_t *li; int rc; + char *dummy_uri = "ldap://0.0.0.0"; be->bd_info = lback; be->be_private = NULL; @@ -2029,6 +2030,8 @@ ldap_chain_db_init_common( li = (ldapinfo_t *)be->be_private; li->li_urllist_f = NULL; li->li_urllist_p = NULL; + li->li_uri = ch_strdup( dummy_uri ); + li->li_bvuri = ch_calloc( sizeof( struct berval ), 1 ); be->bd_info = bi; -- 1.8.1.2 --------------070406020601050207030907--

1 0

Re: (ITS#7685) Config directive TLSProtocolMin not converted to attribute olcTLSProtocolMin
by michael＠stroeder.com 07 Sep '13

07 Sep '13

Howard Chu wrote: > michael(a)stroeder.com wrote: >> TLSProtocolMin 3.2 >> >> I'd expect this to appear as attribute 'olcTLSProtocolMin' in cn=config but >> it's >> missing. >> > Fixed in master Seems to work. Thanks. Ciao, Michael.

1 0

Re: (ITS#7678) Operational Error propagated from back-meta
by hyc＠symas.com 07 Sep '13

07 Sep '13

Matt Hamilton wrote: > On 2 Sep 2013, at 04:15 PM, Howard Chu <hyc(a)symas.com> wrote: > >> matth(a)netsight.co.uk wrote: >>> Full_Name: Matt Hamilton >>> Version: 2.4.36 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (213.133.64.253) >>> >>> >>> I am using the meta backend to query multiple LDAP (AD) backends. This is to >>> consolidate several directories in different departments into one. We attempt >>> both simple binds with username/password and also anon binds to look up user >>> information. >> >> That doesn't make much sense, since AD disallows anonymous Binds. > > Sorry, I wasn't clear. I mean we do both anon and simple binds to OpenLDAP. Hence why the config has credentials in it to use against the backends if not supplied by the client. > >>> At the moment, trying to do an authenticated simple bind to slapd caused an >>> Operational Error to be propagated to the client regardless of the setting of >>> 'onerr'. Even when a result is successfully found. This is due to one server in >>> the backend succeeding and the other returning an operational error due to an >>> invalid bind (as would be expected as the credentials supplied from the client >>> will only work with one of the backends). >>> >>> Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that >>> the code is not checking for 'Operational Error' as a specific case above and so >>> uses the default case (line 1665). Hence sres is set to 'Operational Error' too >>> at line 1934. >> >> back-meta/search.c has nothing to do with Binds. Not sure what you're trying to demonstrate there. > > I'm not talking about binds there. I'm talking about errors being propagated. You said, exactly: >>> At the moment, trying to do an authenticated simple bind to slapd caused an Operational Error to be propagated to the client regardless of the setting of 'onerr'. <<< So again, are you talking about Bind or are you talking about Search? I'm unable to reproduce any of the behavior you're describing since the config snippets you provided reference servers that are private to your network. Nor do I have any local AD servers to test against. Nor have you given exact details of the client side commands being issued. With so little ungarbled information to go on, we cannot investigate. -- -- 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#7669) tool_bind in common.c should be doing conditional assert
by hyc＠symas.com 07 Sep '13

07 Sep '13

k.venkata.kiran(a)ericsson.com wrote: > Full_Name: Venkata Kiran K > Version: 2.4.35 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.71.175.12) > > > tool_bind has below assert which might be hit when nsctrls is not updated > > assert(nsctrls < (int) (sizeof(sctrls) / sizeof(sctrls[0]))); nsctrls is initialized to 0. If it is not updated, the assert condition will of course be true, so the problem you describe cannot arise. Please provide a test case to demonstrate the problem you're seeing, otherwise this ITS will be closed. -- -- 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#7683) Feature request: write TLS prot/cipher to syslog
by hyc＠symas.com 07 Sep '13

07 Sep '13

michael(a)stroeder.com wrote: > Full_Name: > Version: HEAD > OS: > URL: > Submission from: (NULL) (79.219.124.115) > > > For debugging which TLS protocol version and cipher suites were actually > negotiated with several LDAP clients this information would be written to the > syslog message. > > Current logging: > > conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 > > Suggestion: > > conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.1 > tls_cipher=DHE-RSA-AES256-SHA256 > > Added to master. MozNSS version is untested due to absence of PEM support in MozNSS. (See https://bugzilla.mozilla.org/show_bug.cgi?id=402712 - whatever PEM support that may exist is not of usable quality.) -- -- 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#7684) Admin Guide: Correct 'TLSEphemeralDHParamFile' to 'TLSDHParamFile'
by hyc＠symas.com 07 Sep '13

07 Sep '13

michael(a)stroeder.com wrote: > Full_Name: > Version: HEAD > OS: > URL: > Submission from: (NULL) (79.219.124.115) > > > The admin guide incorrectly mentions the configuration directive name > 'TLSEphemeralDHParamFile' instead of 'TLSDHParamFile' like described in > slapd.conf(5). Thanks, fixed in master. (Also partly fixed in ITS#7506) > > See: http://www.openldap.org/doc/admin24/tls.html > > See this trivial patch: > > diff --git a/doc/guide/admin/aspell.en.pws b/doc/guide/admin/aspell.en.pws > index 3683f98..9921963 100644 > --- a/doc/guide/admin/aspell.en.pws > +++ b/doc/guide/admin/aspell.en.pws > @@ -23,7 +23,7 @@ ddd > DAs > TLSCACertificateFile > BNF > -TLSEphemeralDHParamFile > +TLSDHParamFile > ppolicy > gavin > ASN > diff --git a/doc/guide/admin/tls.sdf b/doc/guide/admin/tls.sdf > index 00bf83c..9e3243e 100644 > --- a/doc/guide/admin/tls.sdf > +++ b/doc/guide/admin/tls.sdf > @@ -188,7 +188,7 @@ and it doesn't need very much data to work. > > This directive is ignored with GnuTLS and Mozilla NSS. > > -H4: TLSEphemeralDHParamFile <filename> > +H4: TLSDHParamFile <filename> > > This directive specifies the file that contains parameters for > Diffie-Hellman ephemeral key exchange. This is required in order > > > -- -- 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#7685) Config directive TLSProtocolMin not converted to attribute olcTLSProtocolMin
by hyc＠symas.com 07 Sep '13

07 Sep '13

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: > Submission from: (NULL) (79.219.124.115) > > > I have in my static slapd.conf: > > TLSProtocolMin 3.2 > > I'd expect this to appear as attribute 'olcTLSProtocolMin' in cn=config but it's > missing. > > Fixed in master -- -- 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#7500) libldap starttls crashes if invalid GnuTLS cipher suite string
by hyc＠symas.com 07 Sep '13

07 Sep '13

jouko.orava(a)iki.fi wrote: > Full_Name: Jouko Orava > Version: 2.4.28, 2.4.33 > OS: Debian/Ubuntu > URL: > Submission from: (NULL) (82.181.197.37) > > > If the cipher suite string is unacceptable to GnuTLS, libldap_r-2.4 crashes in > ldap_start_tls_s() due to a double free. See > https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1103353 > for my original bug submission, including a suggested patch, > https://launchpadlibrarian.net/129174364/openldap-ciphersuite.patch > and a simple example ldapsearch-like program that can be used to test the > issue. This is now fixed in git master. > > This bug is not critical, since using a valid GnuTLS cipher suite does work, for > example "NORMAL" or "SECURE256". However, trying to use anything more specific > is exceedingly difficult -- basically trial and error, due to applications > crashing in libldap with an invalid one. > > The two other TLS implementations in OpenLDAP are not affected by this bug. > > The double free occurs in > openldap/libraries/libldap/tls2.c:ldap_int_tls_init_ctx(), in the > ldap_pvt_tls_ctx_free(lo->ldo_tls_ctx); call in the error_exit: path. Because > the cipher suite string was unacceptable to GnuTLS, the context is either > released by GnuTLS or never properly initialized. The error_exit: path tries to > release that context, and causes the C library to abort the program as it > detects a double free. > > Simply commenting the ldap_pvt_tls_ctx_free(lo->ldo_tls_ctx); call in the > error_exit: path in openldap/libraries/libldap/tls2.c:ldap_int_tls_init_ctx() > masks the issue, but is obviously incorrect (as it affects the two other TLS > implementations too). > > My suggested patch is to use the configured cipher suite string when creating > the new TLS context, instead of "NORMAL" as is currently done, in > openldap/libraries/libldap/tls_g.c:tlsg_ctx_new(). If there is a problem with > the cipher suite priority string, the initial context is torn down, and caught > earlier in openldap/libraries/libldap/tls2.c, avoiding the crash. (However, the > cipher suite string will be parsed twice.) > > There seem to be numerous unhandled bug reports in various distributions and > applications, including > http://www.openldap.org/its/index.cgi/Incoming?id=6939#themesg > which are quite tricky to investigate, as the actual bug occurs deep in libldap. > Only user checks with a patched libldap will prove whether these are actually > caused by this bug or not. It is very easy to assume it is an application bug, > due to the symptoms and pretty limited circumstances. > > Recap: libldap + GnuTLS, application using ldap_start_tls, and any cipher suite > string not acceptable to GnuTLS will cause libldap to crash due to a double > free. > > -- -- 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#7434) idassert-bind fails after restarting slapd
by hyc＠symas.com 07 Sep '13

07 Sep '13

blance3459(a)hotmail.com wrote: > Full_Name: Barry Lance > Version: 2.4.28 > OS: Ubuntu 12.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (70.226.37.226) It appears the submitter found an alternate solution, but just for future reference this issue was the same as ITS#7381, now fixed in git master. > > Two servers: Master (192.168.1.1) and Replica (192.168.1.2) both running slap > 2.4.28 and ubuntu 12.04. Replica is a replication partner of Master using > syncrepl. Replication is working fine. When I attempt to add a chain overlay > to Replica to send all writes over to the master, it works exactly as expected > allowing both normal users and the rootdn to make appropriate changes. However, > once I either reboot the replica server or restart slapd, the chain overlay > fails to allow any changes on the master. Looking at syslog shows that before > the reboot/restart the requesting users' dn is proxied over as expected. After > the restarting slapd or rebooting Replica, all changes are proxied anonymously > (dn=""). > > I am using simple binds at this point in the project, but it doesn't seems to > matter if I proxy in the clear, ldaps, or TLS the result is the same. All three > methods can successfully negotiate a connection. I've even tried switching > between using the rootdn and a different user as the binddn in my overlay, but > the result is still the same no matter what I use for the binddn. When I look > at my config, I notice that "chain-idassert-bind" appears to be hashed or > encrypted in thew config. Is that normal? Just seems really odd that my config > would work immediately when added, but fail after the the daemon has been > restarted. Am I missing something really silly? Hopefully, someone can assist > me on this. I've been driving myself crazy trying to figure out why this > behavior is occurring. > > Disclaimer: I am using openldap as part of my capstone project for graduation. > I'm not asking for anyone to do my "homework" for me, I'm just stuck on this one > issue that I would love to resolve so I can move on to the Kerberos phase of my > project (and maybe even study for an exam coming up in my algorithms class next > week). > > Here is my overlay config using the rootDN and TLS (on Replica): > > dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config > changetype: add > objectClass: olcLDAPConfig > objectClass: olcChainDatabase > olcDatabase: {0}ldap > olcDbURI: "ldap://master.example.net/" > olcDbRebindAsUser: TRUE > olcDbIDAssertBind: bindmethod=simple > binddn="cn=admin,dc=example,dc=net" > credentials=(secret) > mode=self > starttls=critical > tls_cacert=/etc/ssl/certs/cacert.pem > tls_reqcert=demand > > And without TLS (also on Replica): > > dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config > changetype: add > objectClass: olcLDAPConfig > objectClass: olcChainDatabase > olcDatabase: {0}ldap > olcDbURI: "ldap://master.example.net/" > olcDbRebindAsUser: TRUE > olcDbIDAssertBind: bindmethod=simple > binddn="cn=admin,dc=example,dc=net" > credentials=(secret) > mode=self > > -- -- 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#7595) OpenLDAP lacks a ECDHE key generation callback
by hyc＠symas.com 07 Sep '13

07 Sep '13

crest(a)tzi.de wrote: > Full_Name: Jan Bramkamp > Version: 2.4.35 > OS: FreeBSD 9.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.230.127.217) > > > OpenLDAP supports PFS TLS cipher suites using DHE with the > DH *tlso_tmp_dh_cb(SSL*,int,int) callback in libraries/libldap/tls_o.c. > DHE-RSA/DSS cipher suites are very CPU intensive and noticeably increase latency > on low-power hardware. While OpenLDAP supports ECDH-ECDSA cipher suites these > lack the PFS offered by DHE-RSA/DSS cipher suites. > >>From my initial search it looks like the correct API to register such a callback > would be SSL_CTX_set_tmp_ecdh_callback(), but im not familiar the OpenLDAP code > base so patching it my self could have unintended consequences. > > This how the CA was generated: > CURVE=secp384r1 > > openssl ecparam -out private/ca-key.pem -name $CURVE -genkey && > openssl req -new -x509 -days 365 -key private/ca-key.pem -out > certs/ca-cert.pem > > openssl ecparam -out private/auth1-key.pem -name $CURVE -genkey && > openssl req -new -key private/auth1-key.pem -out newcerts/auth1-csr.pem && > openssl ca -config /usr/local/openssl/openssl.cnf -out certs/auth1-cert.pem > -infiles newcerts/auth1-csr.pem > > The (EC)DH paramter file was generated with: > openssl ecparam -name $CURVE > > This was tested with slapd linked against OpenSSL 1.0.1e from ports on FreeBSD > 9.1/amd64. It seems that current events have focused more attention on Perfect Forward Secrecy, now that news about NSA eavesdropping is everywhere. It's worth noting Bruce Schneier's recommendation to avoid Elliptic Curve algorithms, since their design has been heavily influenced by the NSA. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surve… (Section 5.) -- -- 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#7506) Diffie-Hellman parameters (DHParamFile) are improperly handled
by hyc＠symas.com 07 Sep '13

07 Sep '13

Howard Chu wrote: > ben(a)bjencks.net wrote: >> I suppose I should attach a test case: > > Thanks, patches applied to master (with some tweaks). >> >> cd $WORKDIR >> openssl dhparam 1536 > dh1536.pem >> openssl req -new -newkey rsa:2048 -keyout server.key \ >> -out server.crt -sha256 -nodes -subj '/CN=localhost/' -x509 >> >> For GnuTLS, load the following config: >> dn: cn=config >> objectClass: olcGlobal >> cn: config >> olcTLSCertificateFile: $WORKDIR/server.crt >> olcTLSCertificateKeyFile: $WORKDIR/server.key >> olcTLSCipherSuite: NONE:+VERS-TLS1.1:+VERS-TLS1.0:+AES-128-CBC: >> +DHE-RSA:+SHA1:+COMP-NULL >> olcTLSDHParamFile: $WORKDIR/dh1536.pem >> >> dn: olcDatabase={0}config,cn=config >> objectClass: olcDatabaseConfig >> olcDatabase: {0}config >> >> For Openssl, change olcTLSCipherSuite to: >> olcTLSCipherSuite: aRSA+AES128+kEDH >> >> Start up slapd with the config, listening on ldaps://localhost:6636. >> >> openssl s_client -connect localhost:6636 >> >> With GnuTLS this will fail negotiation; with OpenSSL it will use 1024 >> bit parameters rather than the 1536 bits params we specified. >> >> The only way I've found to find the actual parameter size is to tcpdump >> the negotiation. First, verify that the negotiated cipher suite is >> DHE-RSA-AES128-SHA according to s_client, then: >> >> tcpdump -i lo -wldap.pcap port 6636 >> wireshark ldap.pcap >> Apply the SSL decode to the traffic (right click on packet, Decode As, >> Transport tab, SSL), find the Server Key Exchange packet, select the >> Server Key Exchange portion of the handshake message, and look at the >> hex dump. >> >> It should start with 0c, followed by a three byte size, then the next >> two bytes are the length of the DH parameters: 0080 for 1024 bits, 00c0 >> for 1536 bits. For future reference, you can check this just using openssl s_client -connect localhost:6636 -debug -state SSL_connect:SSLv3 read server certificate A read from 0x16b0c20 [0x16b6cf3] (5 bytes => 5 (0x5)) 0000 - 16 03 02 03 0d ..... read from 0x16b0c20 [0x16b6cf8] (781 bytes => 781 (0x30D)) 0000 - 0c 00 03 09 01 00 a8 e0-4a 3d d1 d2 73 a8 bd 2e ........J=..s... In this case 0c 00 03 09 marks the Server Key Exchange and length, and 01 00 indicates 2048 bits (which matches the dhparams I used). -- -- 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#7506) Diffie-Hellman parameters (DHParamFile) are improperly handled
by hyc＠symas.com 07 Sep '13

07 Sep '13

ben(a)bjencks.net wrote: > I suppose I should attach a test case: Thanks, patches applied to master (with some tweaks). > > cd $WORKDIR > openssl dhparam 1536 > dh1536.pem > openssl req -new -newkey rsa:2048 -keyout server.key \ > -out server.crt -sha256 -nodes -subj '/CN=localhost/' -x509 > > For GnuTLS, load the following config: > dn: cn=config > objectClass: olcGlobal > cn: config > olcTLSCertificateFile: $WORKDIR/server.crt > olcTLSCertificateKeyFile: $WORKDIR/server.key > olcTLSCipherSuite: NONE:+VERS-TLS1.1:+VERS-TLS1.0:+AES-128-CBC: > +DHE-RSA:+SHA1:+COMP-NULL > olcTLSDHParamFile: $WORKDIR/dh1536.pem > > dn: olcDatabase={0}config,cn=config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > > For Openssl, change olcTLSCipherSuite to: > olcTLSCipherSuite: aRSA+AES128+kEDH > > Start up slapd with the config, listening on ldaps://localhost:6636. > > openssl s_client -connect localhost:6636 > > With GnuTLS this will fail negotiation; with OpenSSL it will use 1024 > bit parameters rather than the 1536 bits params we specified. > > The only way I've found to find the actual parameter size is to tcpdump > the negotiation. First, verify that the negotiated cipher suite is > DHE-RSA-AES128-SHA according to s_client, then: > > tcpdump -i lo -wldap.pcap port 6636 > wireshark ldap.pcap > Apply the SSL decode to the traffic (right click on packet, Decode As, > Transport tab, SSL), find the Server Key Exchange packet, select the > Server Key Exchange portion of the handshake message, and look at the > hex dump. > > It should start with 0c, followed by a three byte size, then the next > two bytes are the length of the DH parameters: 0080 for 1024 bits, 00c0 > for 1536 bits. -- -- 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#7685) Config directive TLSProtocolMin not converted to attribute olcTLSProtocolMin
by michael＠stroeder.com 06 Sep '13

06 Sep '13

Full_Name: Version: OS: URL: Submission from: (NULL) (79.219.124.115) I have in my static slapd.conf: TLSProtocolMin 3.2 I'd expect this to appear as attribute 'olcTLSProtocolMin' in cn=config but it's missing.

1 0

(ITS#7684) Admin Guide: Correct 'TLSEphemeralDHParamFile' to 'TLSDHParamFile'
by michael＠stroeder.com 06 Sep '13

06 Sep '13

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.219.124.115) The admin guide incorrectly mentions the configuration directive name 'TLSEphemeralDHParamFile' instead of 'TLSDHParamFile' like described in slapd.conf(5). See: http://www.openldap.org/doc/admin24/tls.html See this trivial patch: diff --git a/doc/guide/admin/aspell.en.pws b/doc/guide/admin/aspell.en.pws index 3683f98..9921963 100644 --- a/doc/guide/admin/aspell.en.pws +++ b/doc/guide/admin/aspell.en.pws @@ -23,7 +23,7 @@ ddd DAs TLSCACertificateFile BNF -TLSEphemeralDHParamFile +TLSDHParamFile ppolicy gavin ASN diff --git a/doc/guide/admin/tls.sdf b/doc/guide/admin/tls.sdf index 00bf83c..9e3243e 100644 --- a/doc/guide/admin/tls.sdf +++ b/doc/guide/admin/tls.sdf @@ -188,7 +188,7 @@ and it doesn't need very much data to work. This directive is ignored with GnuTLS and Mozilla NSS. -H4: TLSEphemeralDHParamFile <filename> +H4: TLSDHParamFile <filename> This directive specifies the file that contains parameters for Diffie-Hellman ephemeral key exchange. This is required in order

1 0

(ITS#7683) Feature request: write TLS prot/cipher to syslog
by michael＠stroeder.com 06 Sep '13

06 Sep '13

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.219.124.115) For debugging which TLS protocol version and cipher suites were actually negotiated with several LDAP clients this information would be written to the syslog message. Current logging: conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 Suggestion: conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.1 tls_cipher=DHE-RSA-AES256-SHA256

1 0

Re: (ITS#7381) Dynamically added chaining configuration stops working after restart
by hyc＠symas.com 06 Sep '13

06 Sep '13

ian(a)uns.ac.rs wrote: > Full_Name: Ivan Nejgebauer > Version: 2.4.32 > OS: CentOS 5 > URL: ftp://ftp.openldap.org/incoming/ivannejgebauer-120905.tgz > Submission from: (NULL) (2001:4170:2000:2:213:d3ff:fecf:b9ea) > > > If a minimal chaining configuration is dynamically added to a consumer server in > a provider/consumer pair running delta-syncrepl, it will stop working when the > consumer is restarted. The configuration is modelled after the one used in > test022 in the OpenLDAP source distribution: Sorry this report was neglected for so long, and thanks for the excellent test case. This is now fixed in git master. > > dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectClass: olcOverlayConfig > objectClass: olcChainConfig > olcOverlay: {0}chain > > dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectClass: olcLDAPConfig > objectClass: olcChainDatabase > olcDatabase: {0}ldap > olcDbIDAssertBind: bindmethod=simple binddn="cn=Manager,dc=example,dc=com" > credentials="secret" mode=self > olcDbURI: "ldap://localhost:6389" > > Scripts and data for replicating the issue are in the referenced archive. Quick > summary: > > # make clean-all master replica > # ./start-master.sh > # ./start-replica.sh > # ./replica-apply.sh pmod-add.ldif # returns referral > # ./replica-conf.sh chain.ldif # adds chaining configuration > # ./replica-apply.sh pmod-add.ldif # chains to master > # ./stop-replica.sh > # ./start-replica.sh > # ./replica-apply.sh pmod-del.ldif # returns referral, but shouldn't > > I have tested both 2.4.32 and git master > (54a111907b48900e1ce5de12a9d87818a334423d). > > -- -- 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#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by hyc＠symas.com 05 Sep '13

05 Sep '13

sog(a)msg.com.mx wrote: > Full_Name: Salvador Ortiz > Version: 24 > OS: Linux > URL: ftp://ftp.msg.com.mx/pub/varios/0001-In-mdb_env_copy-retry-open-if-O_DIRECT-fails.patch > Submission from: (NULL) (187.162.45.111) > > > If the OS defines O_DIRECT mdb_env_copy unconditionally uses it, but according > to open(2): "Some file systems may not implement the flag and open() will > fail with EINVAL if it is used." > > In this cases mdb_env_copy should retry without the flag. > > The attached patch implements that. > > Thanks, applied. -- -- 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#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by sog＠msg.com.mx 05 Sep '13

05 Sep '13

Full_Name: Salvador Ortiz Version: 24 OS: Linux URL: ftp://ftp.msg.com.mx/pub/varios/0001-In-mdb_env_copy-retry-open-if-O_DIRECT-fails.patch Submission from: (NULL) (187.162.45.111) If the OS defines O_DIRECT mdb_env_copy unconditionally uses it, but according to open(2): "Some file systems may not implement the flag and open() will fail with EINVAL if it is used." In this cases mdb_env_copy should retry without the flag. The attached patch implements that.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs