- 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

I wrote: > 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. https://bugzilla.redhat.com/show_bug.cgi?id=1008073 Simpler fix, at least on Linux: #ifdef O_DIRECT if ((rc = fcntl(fd, F_GETFL)) != -1) (void) fcntl(fd, F_SETFL, rc | O_DIRECT); #endif But that could fail elsewhere, if some OS only accepts O_DIRECT to open() and not to fcntl(). BTW, does the nearby Apple code need to fail if fcntl(newfd, F_NOCACHE, 1) fails? Could ignore errors. -- Hallvard

1 0

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 13 Sep '13

13 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 12 Sep '13

12 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 12 Sep '13

12 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 12 Sep '13

12 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs