June 2017 - openldap-bugs

(ITS#8681) dynlist overlay fails to generate attributes when paging is used
by jengelh＠inai.de 30 Jun '17

30 Jun '17

Full_Name: Jan Engelhardt Version: 2.4.44, 2.4.45 OS: Linux 4.11, openSUSE Tumbleweed 20170626 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.178.174.83) I observed that the dynlist overlay fails to generate its attributes for certain DNs. Ultimately it appears to relate to the chosen page size with which the database is queried; the smaller, the more often it occurs. Reproduce as follows: 1. Set up dynlist in slapd.conf for the database: include rfc2307bis.schema include dyngroup.schema database hdb suffix o=da index objectClass eq rootdn cn=root,o=da overlay dynlist dynlist-attrset posixAccount labeledURI memberOf 2. Construct some entries, such as: dn: cn=users,o=da member: uid=foo,o=da cn: users objectClass: groupOfNames objectClass: top objectClass: posixGroup gidNumber: 1555 description: users memberUid: foo dn: uid=foo,o=da objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: foo displayName: Foo givenName: foo sn: foo uid: foo mail: foo(a)dagent.lh gidNumber: 1555 homeDirectory: /home/foo uidNumber: 25122 labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo)) 3. Query database with a sufficiently small page size: ## ldapsearch -xb o=da -E pr=1 dn: o=da [ a little trimmed for brevity] control: 1.2.840.113556.1.4.319 false MA0CAQAECAEAAAAAAAAA pagedresults: cookie=AQAAAAAAAAA= dn: cn=root,o=da [] pagedresults: cookie=AgAAAAAAAAA= Press [size] Enter for the next {1|size} entries. dn: cn=users,o=da [] pagedresults: cookie=CAAAAAAAAAA= Press [size] Enter for the next {1|size} entries. dn: uid=foo,o=da objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: foo displayName: Foo Beyond givenName: foo sn: foo uid: foo mail: foo(a)dagent.lh gidNumber: 1555 homeDirectory: /home/foo uidNumber: 25122 labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo)) # search result search: 5 result: 0 Success control: 1.2.840.113556.1.4.319 false MAUCAQAEAA== pagedresults: cookie= With larger pagesizes or completely omitting -E pr, memberOf does appear: labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo)) memberOf: cn=users,o=da

1 0

Re: (ITS#8680) OpenLDAP 2.4.45 for Windows
by quanah＠symas.com 30 Jun '17

30 Jun '17

--On Friday, June 30, 2017 2:12 PM +0000 muthamma.appaiah(a)wellsfargo.com wrote: > Full_Name: Svetlana > Version: 2.4.45 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2620:160:e708:6::c) > > > Hi team, > > Could you please help us with the source file of 2.4.45 for Windows > operating system from your website? Hello, The ITS system is for reporting bugs with the OpenLDAP software. It is not the proper location for asking for help. If you need assistance with compiling OpenLDAP on Windows, the correct forum for asking for that help would be the openldap-technical(a)openldap.org list. Alternatively, I would note that my company (Symas) provides pre-built binaries of OpenLDAP for Windows with options for support. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8680) OpenLDAP 2.4.45 for Windows
by muthamma.appaiah＠wellsfargo.com 30 Jun '17

30 Jun '17

Full_Name: Svetlana Version: 2.4.45 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2620:160:e708:6::c) Hi team, Could you please help us with the source file of 2.4.45 for Windows operating system from your website?

1 0

(ITS#8679) Update release download page
by quanah＠openldap.org 23 Jun '17

23 Jun '17

Full_Name: Quanah Gibson-Mount Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Download page needs updating to: a) Have links to the checksums for the release tarballs b) Have an encrypted download link option

1 0

(ITS#8678) Slow deletes of large indexed attrributes
by hyc＠openldap.org 22 Jun '17

22 Jun '17

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.31) Submitted by: hyc Related to ITS#7329 Recalculating the index values can be quite expensive when deleting a value from an attribute with many values. For 2.5 we should fix this by storing reference counts with each index slot.

1 0

Re: (ITS#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations
by quanah＠symas.com 22 Jun '17

22 Jun '17

--On Thursday, April 09, 2015 5:42 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.25.188.166) > > > When one has an MMR setup using delta-syncrepl, and the masters get into a > situation where one is out of sync, or adding a new MMR node to an > existing cluster, things will be broken until the new/reloaded node has a > write op that goes to the accesslog DB. In an existing cluster, where a > node is being reloaded, it causes all nodes to go into an endless looping > fallback sync until that write occurs. One possible fix for this, would be to refuse to delete the final entry in the accesslog during the purge phase. That way, the accesslog would never be empty. I'm not sure how difficult this would be to implement, code wise. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8677) back-sock segfaults on CONTINUE (database sock)
by michael＠stroeder.com 21 Jun '17

21 Jun '17

hyc(a)symas.com wrote: >> When using back-sock (database sock) and the external sock listener returns >> CONTINUE then slapd seg faults. >> >> Yes, returning CONTINUE is only allowed when using back-sock as overlay. >> But slapd should not seg fault and rather return as LDAP result: > > No. This is a configuration error and it's appropriate to halt the server and > force it to be fixed. Even if I follow your argument this message does not look like the server was deliberately halted: slapd: result.c:83: sock_read_and_send_results: Assertion `si->si_ops != 0' failed. ./start-slapd.sh: line 21: 30179 Aborted (core dumped) ${OPENLDAP_EXEC} -d stats,shell -h "ldap://0.0.0.0:9876 ${LDAPI_URI}" -n slapd-sock-test -f slapd.conf Also the args and PID files are not cleaned up. I guess database environment(s) of other backend(s) is/are also not closed in a controlled manner. So at least it should properly log a message and shutdown cleanly. Ciao, Michael.

1 0

Re: (ITS#8677) back-sock segfaults on CONTINUE (database sock)
by hyc＠symas.com 21 Jun '17

21 Jun '17

michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.45 > OS: Linux > URL: > Submission from: (NULL) (213.240.182.98) > > > When using back-sock (database sock) and the external sock listener returns > CONTINUE then slapd seg faults. > > Yes, returning CONTINUE is only allowed when using back-sock as overlay. > But slapd should not seg fault and rather return as LDAP result: > > result: 80 Other (e.g., implementation specific) error > text: CONTINUE not allowed for back-sock No. This is a configuration error and it's appropriate to halt the server and force it to be fixed. -- -- 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#8677) back-sock segfaults on CONTINUE (database sock)
by michael＠stroeder.com 21 Jun '17

21 Jun '17

Full_Name: Version: 2.4.45 OS: Linux URL: Submission from: (NULL) (213.240.182.98) When using back-sock (database sock) and the external sock listener returns CONTINUE then slapd seg faults. Yes, returning CONTINUE is only allowed when using back-sock as overlay. But slapd should not seg fault and rather return as LDAP result: result: 80 Other (e.g., implementation specific) error text: CONTINUE not allowed for back-sock

1 0

Re: (ITS#8676) openldap source uses implicit functoin declarations
by h.b.furuseth＠usit.uio.no 20 Jun '17

20 Jun '17

On 19. juni 2017 23:19, slyfox(a)gentoo.org wrote: > Why those are problems? implicit function declarations mean the > function type will be defaulted to int(int, int). > For functions like > int slap_sasl_cbinding( Connection *conn, struct berval *cbv ); > it might cause pointer-to-int truncation on 64-bit platforms. No, implicit declarations are defaulted to int(), and function call args are not converted other than integer promotions. So it's not a problem when the function are called with args of the correct types. But yeah, it won't hurt to clean up. -- Hallvard

1 0

(ITS#8676) openldap source uses implicit functoin declarations
by slyfox＠gentoo.org 19 Jun '17

19 Jun '17

Full_Name: Sergei Trofimovich Version: 2.4.44 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.154.9.158) When openldap package is being built in Gentoo GCC C compiler highlights a few problems of implicit function declaration usage as [1]. I've hacked up patches against current master: [2] Why those are problems? implicit function declarations mean the function type will be defaulted to int(int, int). For functions like int slap_sasl_cbinding( Connection *conn, struct berval *cbv ); it might cause pointer-to-int truncation on 64-bit platforms. Simplest way to reproduce the failure is to switch warning into failure as: ./configure CFLAGS="-Werror=implicit-function-declaration" make Many projects enable -Werror=implicit-function-declaration by default to catch that type of failure at development time. Thank you! [1]: * QA Notice: Package triggers severe warnings which indicate that it * may exhibit random runtime failures. * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap/open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_i s_ldapi_url? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap_r/thr_posix.c:93:9: warning: implicit declaration of function pthread_setconcurrency; did you m ean pthread_setcanceltype? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap_r/thr_posix.c:107:9: warning: implicit declaration of function pthread_getconcurrency; did you mean ldap_pvt_thread_get_concurrency? [-Wimplicit-function-declaration] * open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap/open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_i s_ldapi_url? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap_r/thr_posix.c:93:9: warning: implicit declaration of function pthread_setconcurrency; did you m ean pthread_setcanceltype? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap_r/thr_posix.c:107:9: warning: implicit declaration of function pthread_getconcurrency; did you mean ldap_pvt_thread_get_concurrency? [-Wimplicit-function-declaration] * open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/back-ldap/bind.c:722:2: warning: implicit declaration of function slap_client_keepalive; did you me an slap_client_connect? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/back-meta/conn.c:424:2: warning: implicit declaration of function slap_client_keepalive; did you me an slap_client_connect? [-Wimplicit-function-declaration] * cloak.c:246:4: warning: implicit declaration of function attr_clean; did you mean entry_clean? [-Wimplicit-function-declaration] * Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: http://www.OpenLDAP.org/ [2]: http://dev.gentoo.org/~slyfox/patches/openldap/0001-tls2.c-fix-implicit-lda… http://dev.gentoo.org/~slyfox/patches/openldap/0002-thr_posix.c-fix-implici… http://dev.gentoo.org/~slyfox/patches/openldap/0003-servers-slapd-config.c-… http://dev.gentoo.org/~slyfox/patches/openldap/0004-servers-slapd-connectio…

1 0

Re: (ITS#8668) Cache overlay, unexpected behaviour and occasional segfaults
by acrow＠integrafin.co.uk 19 Jun '17

19 Jun '17

On 06/06/17 16:42, quanah(a)symas.com wrote: > --On Monday, June 05, 2017 6:08 PM +0000 acrow(a)integrafin.co.uk wrote: > >> Full_Name: Alex Crow >> Version: 2.4.40-13.el7 >> OS: Centos 7.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (95.172.237.70) >> >> >> I'm using OpenLDAP with the caching overlay as a proxy to AD, mostly for >> use with Postfix and Dovecot. >> >> I have been experiencing a strange issue whereby, when a user is moved to >> a different OU in AD, the caching server initially returns only the >> original OU until the cache entry expires. However, after this time, it >> returns both the entry in the original OU and the entry in the new OU. >> This does not seem to change even after the next expiry time has elapsed. >> I can only seem to clear out the "old" result by wiping the cache's >> database. > Hi Alex, > > The first thing to do would be to upgrade to OpenLDAP 2.4.44 or 2.4.45 and > confirm you can reproduce the issue in a current release. If you can, then > you need to provide a full backtrace, where debug symbols are enabled (the > "-g" flag for CFLAGS for gcc), and the slapd binary is not stripped (or if > using packaged RPMs, the debuginfo etc bits are installed). > > You can grab pre-compiled packages for OpenLDAP 2.4.44 from the LTB project > at <http://ltb-project.org/wiki/download#openldap>. I expect they'll have > 2.4.45 packages available soon as well. > > Thanks, > Quanah > Hi Quanah, I've installed a new VM with the current LTB release and the crashes don't seem to be happening. However, we're still seeing problems with the cache overlay not working as expected. We had a user account moved between OUs this morning shortly after 9am, and now at after 2pm the cache is still returning both the entry from the old OU and the new one (where postfix can only deal with one result in this case). Given my configuration I'd expect the cache to at least return the correct result after an hour at the most - or have I made a mistake? pcacheAttrset 0 mail x-mailHost x-mailStore unixHomeDirectory displayName pcacheTemplate (sn=) 0 3600 0 0 1800 pcacheTemplate (cn=) 0 3600 0 0 1800 pcacheTemplate (displayName=) 0 3600 0 0 1800 pcacheTemplate (mail=) 0 3600 0 0 1800 pcacheTemplate (&(objectClass=)(mail=)) 0 3600 0 0 1800 pcacheTemplate (&(objectClass=)(mail=*)) 0 3600 0 0 1800 Postfix is set up as below: ldaptransport_server_host = ldap://ldapcache2 ldap://ldapcache ldaptransport_timeout = 2 ldaptransport_search_base = OU=foo,DC=bar,DC=baz,DC=net ldaptransport_query_filter = (mail=%s) ldaptransport_result_attribute = x-mailHost ldaptransport_result_filter = relay:%s ldaptransport_expansion_limit = 1 Best regards Alex > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > > > -- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. This email is not intended to, nor should it be taken to, constitute advice. The information provided is correct to our knowledge & belief and must not be used as a substitute for obtaining tax, regulatory, investment, legal or any other appropriate advice. "Transact" is operated by Integrated Financial Arrangements Ltd. 29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300. (Registered office: as above; Registered in England and Wales under number: 3727592). Authorised and regulated by the Financial Conduct Authority (entered on the Financial Services Register; no. 190856).

1 0

Re: (ITS#8675) tools continuing after ldap_start_tls_ returns non-LDAP error
by kurt＠boolean.net 19 Jun '17

19 Jun '17

it's standard conformance issue.... The spec says that upon StartTLS 'success', both TLS communications is = established on the octet following the Start TLS response (and the = request)... and that once one starts TLS communications, one can never = go back to LDAP without TLS. So if there's a TLS failure (whether as = part of TLS nego or later), LDAP communications cannot be continued = (without TLS). Only ignoring LDAP errors (rc > 0) ensures that if TLS negotiation = fails, we don't attempt to send LDAP operations without TLS. -- Kurt=

1 0

Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
by wferi＠niif.hu 19 Jun '17

19 Jun '17

I guess e338789d is supposed to fix this, and it's present in 2.4.40, but still I'm affected on that version: olcUniqueURI: ldap:///o=niifi,o=niif,c=hu?gidNumber?sub?objectClass=posixGroup rejects setting the gidNumber of a posixAccount to that of an existing posixGroup. The usual workaround of using more specific base DNs doesn't work well for me, because there are multiple branches containing groups. Specifying multiple URIs on the above light might work (man slapd-unique doesn't tell precisely), but requires extra maintenance. -- Feri

1 0

Re: (ITS#8675) tools continuing after ldap_start_tls_ returns non-LDAP error
by hyc＠symas.com 16 Jun '17

16 Jun '17

kurt(a)openldap.org wrote: > Full_Name: Kurt Zeilenga > Version: most every > OS: MacOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:f052:8000:7cca:294:b2d:2652) > > > The client tools were designed to support optimistic encryption (-Z)... in > cases where the server says "yes, let's start TLS...", TLS negotiations must be > entered into and, if they fail, no further LDAP traffic should be allowed on the > stream. Upon TLS alert, the session should no longer usable. Further attempts > to send any PDU should fail. I guess this was never stated clearly. "-ZZ" meant require TLS, drop the session if TLS fails. "-Z" meant proceed if TLS fails. No one ever specified exactly what types of failures were intended in either situation. > > But one could argue that the bug is simply the LDAP application software > ignoring the local (non-LDAP) errors coming from ldap_start_tls_s(). In this > case, the following trivial patch would address the issue. > > diff --git a/clients/tools/common.c b/clients/tools/common.c > index 7f758cb..089dd9b 100644 > --- a/clients/tools/common.c > +++ b/clients/tools/common.c > @@ -1367,7 +1367,7 @@ dnssrv_free:; > ldap_get_option( ld, > LDAP_OPT_DIAGNOSTIC_MESSAGE, (void*)&msg); > tool_perror( "ldap_start_tls", rc, NULL, NULL, > msg, NULL ); > ldap_memfree(msg); > - if ( use_tls > 1 ) { > + if ( use_tls > 1 || rc < 0) { > tool_exit( ld, EXIT_FAILURE ); > } > } > > However, it might be better to do something at a lower level to ensure that all > subsequent attempts to send LDAP PDUs over the wire after a TLS Alert fail. > > I hereby place the above patch into the public domain. > > -- -- 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#8675) tools continuing after ldap_start_tls_ returns non-LDAP error
by kurt＠openldap.org 16 Jun '17

16 Jun '17

Full_Name: Kurt Zeilenga Version: most every OS: MacOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:f052:8000:7cca:294:b2d:2652) The client tools were designed to support optimistic encryption (-Z)... in cases where the server says "yes, let's start TLS...", TLS negotiations must be entered into and, if they fail, no further LDAP traffic should be allowed on the stream. Upon TLS alert, the session should no longer usable. Further attempts to send any PDU should fail. But one could argue that the bug is simply the LDAP application software ignoring the local (non-LDAP) errors coming from ldap_start_tls_s(). In this case, the following trivial patch would address the issue. diff --git a/clients/tools/common.c b/clients/tools/common.c index 7f758cb..089dd9b 100644 --- a/clients/tools/common.c +++ b/clients/tools/common.c @@ -1367,7 +1367,7 @@ dnssrv_free:; ldap_get_option( ld, LDAP_OPT_DIAGNOSTIC_MESSAGE, (void*)&msg); tool_perror( "ldap_start_tls", rc, NULL, NULL, msg, NULL ); ldap_memfree(msg); - if ( use_tls > 1 ) { + if ( use_tls > 1 || rc < 0) { tool_exit( ld, EXIT_FAILURE ); } } However, it might be better to do something at a lower level to ensure that all subsequent attempts to send LDAP PDUs over the wire after a TLS Alert fail. I hereby place the above patch into the public domain.

1 0

(ITS#8674) Leak in ldap_create_assertion_control
by matt.johnson＠hpe.com 14 Jun '17

14 Jun '17

Full_Name: Matt Johnson Version: 2.4.40 OS: RedHat 7.2 (Maipo) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.203.233.86) The LDAPClient::modify logic has a leak within the ldap_create_assertion_control method. The leaky code occurs when the existing ld_errno is anything but 0 when the method is invoked. Not only that, but your assertion returned is NULL. The workaround is to call the following before calling ldap_create_assertion_control. int lvErrno = 0; ldap_set_option(myLDAPPtr, LDAP_OPT_RESULT_CODE, &lvErrno);

1 0

Re: (ITS#8672) syncrepl with openldap 2.4.{40,42} and mdb backend
by remy.dernat＠univ-montp2.fr 12 Jun '17

12 Jun '17

Hi Ryan, Quanah, Le 11/06/2017 à 03:57, Ryan Tandy a écrit : > On Thu, Jun 08, 2017 at 01:06:21PM +0000, remy.dernat(a)umontpellier.fr > wrote: >> I am able to reproduce the bug quite easily. > > I'm afraid I have not been able to. I followed the steps you posted > (with s/hdb/mdb/) with both servers running slapd 2.4.40+dfsg-1+deb8u3 > and syncrepl seems to work fine. > > https://bugs.debian.org/798964 seems quite similar. R�my, do you think > this problem started for you right after you upgraded to +deb8u3? Indeed, I am afraid that this upgrade causes this issue, or maybe rather the previous one. `2.4.40+dfsg-1+deb8u2` were upgraded on my system in February and syncrepl does not work from this moment. Concerning tests from the latest source, I am not able to reproduce this bug as I get a weird error, with some stuff remaining from my previous install: ``` LDAP vendor version mismatch: library 20440, header 20445 ``` Google leads me to this topics : https://bbs.archlinux.org/viewtopic.php?id=56872 http://www.openldap.org/lists/openldap-software/200307/msg00399.html Although I removed every previous packages. Using ldd : ``` ldd `which ldapadd` linux-vdso.so.1 (0x00007ffe19765000) libldap-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap-2.4.so.2 (0x00007fef25b0d000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007fef258fe000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fef256e1000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fef254aa000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fef25293000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fef24ee7000) libgnutls-deb0.so.28 => /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 (0x00007fef24bc7000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fef249aa000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fef247a5000) /lib64/ld-linux-x86-64.so.2 (0x000055776c6be000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fef2458a000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fef24344000) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fef2412f000) libnettle.so.4 => /usr/lib/x86_64-linux-gnu/libnettle.so.4 (0x00007fef23efd000) libhogweed.so.2 => /usr/lib/x86_64-linux-gnu/libhogweed.so.2 (0x00007fef23cce000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fef23a4a000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fef23842000) ``` with strace : http://paste.debian.net/971168/ And no result with: ``` for file in `ldd /usr/local/bin/ldapadd |awk '{print $3}'`; do echo $file && objdump -T $file |grep 2044; done ``` (and nothing in /var/log/slapd.log) I should try to install it from a fresh install, it would be easier. Anyway, as you said, if installing it from a fresh install did not gave you this bug, I think you can close it... In the meantime, I am working with two other servers for production. As it works for me now (with hdb), I think I will remove the 2 others. This bug already took me too many time. Best regards, Rémy -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M

1 0

Re: (ITS#8672) syncrepl with openldap 2.4.{40,42} and mdb backend
by ryan＠nardis.ca 10 Jun '17

10 Jun '17

On Thu, Jun 08, 2017 at 01:06:21PM +0000, remy.dernat(a)umontpellier.fr wrote: >I am able to reproduce the bug quite easily. I'm afraid I have not been able to. I followed the steps you posted (with s/hdb/mdb/) with both servers running slapd 2.4.40+dfsg-1+deb8u3 and syncrepl seems to work fine. https://bugs.debian.org/798964 seems quite similar. Rémy, do you think this problem started for you right after you upgraded to +deb8u3?

1 0

Re: (ITS#8664) lmdb fragmentation leads to DDoS for consumers
by quanah＠symas.com 09 Jun '17

09 Jun '17

--On Thursday, June 01, 2017 12:22 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) Going to close this out, as the problem statement & other bits is incorrect. I will file a new ITS with a better summary of the issues. Looking forward to a different bug tracker that allows modification of the bug summary, etc. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8673) Need duration logging for sync ops
by quanah＠openldap.org 08 Jun '17

08 Jun '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) We log the duration of an operation at stats level which allows being able to see how long a write OP took on a master. However we do not have any duration logging at the sync log level and therefore cannot determine how long a write op takes on a replica for the same modification. This is problematic when attempting to debug issues related to replication.

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com 08 Jun '17

08 Jun '17

A more self-contained log of the same issue, available at ftp://ftp.openldap.org/incoming/its8444.log (line numbers below are against current master, commit 91f4d3a6b75e73bf4ea498e83e2e4cb4e7a320e0) There are some things that occur in all the failures I have seen so far: - the server that received the operation (#1) sends the accesslog entry with no CSN in the cookie, then another provider (#2) picks up this message and relays it to its consumers, this one with a CSN in the cookie - a consumer picks up these two in short succession, in the log above, processing of the one from #2 is finished first (they are being processed concurrently) Usually, once one of them gets processed, the new CSN should be noted and the other threads should just skip it (syncrepl.c:943 and onwards). In this one, having no CSN in the cookie seems to allow both to process so far as to run syncrepl_message_to_op(), and one of them will then inevitably fail to add the entry. I don't understand yet why server #1 sends the operations without a CSN in the cookie and (especially if I reorder the overlays to set up memberof last), the race goes the other way around and the operation to fail is the one from server #2. My take on it was that in a delta-sync environment all entries would be passed with a new CSN and that should end up in the cookie, allowing syncrepl.c:986 to do its job. --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8672) syncrepl with openldap 2.4.{40,42} and mdb backend
by quanah＠symas.com 08 Jun '17

08 Jun '17

--On Thursday, June 08, 2017 2:06 PM +0000 remy.dernat(a)umontpellier.fr wrote: > Best regards, > R?my Hi, Thanks for the report. Please confirm you can reproduce the issue with OpenLDAP 2.4.45. If you can, then please provide your /initial/ cn=config database prior to doing the modifications as well. Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8672) syncrepl with openldap 2.4.{40,42} and mdb backend
by remy.dernat＠umontpellier.fr 08 Jun '17

08 Jun '17

Full_Name: Dernat R.my Version: 2.4.40+dfsg-1+deb8u3 and 2.4.42+dfsg-2ubuntu3.2 OS: Debian and Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (162.38.181.76) Hi, Since I moved my OpenLDAP to another server my replication between 2 ldap servers through syncrepl does not work anymore. I tested many many things. Finally, I decided to backup the database and restore it on another server (so, I have 3 ldap servers) and (...) it worked. After many other tests, I was able to determine the source of this issue. With a HDB backend on my provider my replication works, while it did not work with a MDB backend on the provider. I had this kind of logs on the provider (with MDB): ============================================================================= Jun 8 12:22:03 ldap2 slapd[15083]: send_search_entry: conn 20855 ber write failed. Jun 8 12:24:03 ldap2 slapd[15083]: send_search_entry: conn 20888 ber write failed. ... ============================================================================= While, on the slave, I get: ============================================================================= Jun 8 09:33:32 ldap3-bis slapd[88560]: do_syncrepl: rid=010 rc -1 retrying Jun 8 09:38:32 ldap3-bis slapd[88560]: do_syncrep2: rid=010 got search entry without Sync State control (dc=my,dc=domain,dc=com) Jun 8 09:38:32 ldap3-bis slapd[88560]: do_syncrepl: rid=010 rc -1 retrying Jun 8 09:43:32 ldap3-bis slapd[88560]: do_syncrep2: rid=010 got search entry without Sync State control (dc=my,dc=domain,dc=com) ... ============================================================================= I am able to reproduce the bug quite easily. I added only two schemas : autofs and quota. With ============================================================================= ldapadd -Q -Y EXTERNAL -H ldapi:/// -f autofs.ldif ldapadd -Q -Y EXTERNAL -H ldapi:/// -f quota.ldif ============================================================================= I also loaded accesslog module (I am creating a specific directory for accesslog(*)) on the provider and the syncprov module on both sides. ============================================================================= (*) mdkir /var/lib/ldap/accesslog chown openldap:openldap /var/lib/ldap/accesslog ============================================================================= Here is what I am doing to setup the syncrepl : ldapadd -Q -Y EXTERNAL -H ldapi:/// -f file.ldif With file.ldif, on the provider site (replication.ldif ; replacing HDB with MDB to test with a MDB backend): ============================================================================= #Load the syncprov and accesslog modules. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov - add: olcModuleLoad olcModuleLoad: accesslog # Accesslog database definitions dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=XXXX,dc=YYYY,dc=ZZ olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart # Accesslog db syncprov. dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE # syncrepl Provider for primary db dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE # accesslog overlay definitions for primary db dn: olcOverlay=accesslog,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE # scan the accesslog DB every day, and purge entries older than 7 days olcAccessLogPurge: 07+00:00 01+00:00 ============================================================================= On the consumer (with a unique rid, and by replacing HDB with MDB to test with a MDB backend), the file.ldif looks like: ============================================================================= #Load the syncprov module. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov # syncrepl specific indices dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryUUID eq - add: olcSyncRepl olcSyncRepl: rid=1 provider=ldaps://consumer.mydomain.fr bindmethod=simple binddn="cn=XXXXX,dc=mydomain,dc=fr" credentials=XXXX searchbase="dc=mydomain,dc=fr" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0)) schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog - add: olcUpdateRef olcUpdateRef: ldaps://consumer.mydomain.fr ============================================================================= On the provider I am using: ============================================================================= lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.8 (jessie) Release: 8.8 Codename: jessie dpkg -l slapd ii slapd 2.4.40+dfsg-1+de amd64 OpenLDAP server (slapd) ============================================================================= Same configuration on one slave, and on the other slave, I am using: ============================================================================= Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial dpkg -l slapd ii slapd 2.4.42+dfsg-2ubu amd64 OpenLDAP server (slapd) ============================================================================= Best regards, Rémy

1 0

Re: ITS#8504 fix breaks Solaris builds
by quanah＠symas.com 07 Jun '17

07 Jun '17

--On Wednesday, June 07, 2017 4:11 PM +0000 quanah(a)symas.com wrote: > --On Wednesday, June 07, 2017 3:35 PM +0200 Hallvard Breien Furuseth > <h.b.furuseth(a)usit.uio.no> wrote: > >> On 06. juni 2017 21:59, quanah(a)openldap.org wrote: >>> /usr/include/signal.h:233:12: note: declared here >>> extern int sigwait(sigset_t *); >>> ^ >> >> POSIX says it has two arguments: >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigwait.html >> Is there a two-argument version of sigwait in the Solaris headers >> somewhere, >> maybe enabled by #define POSIX_C_SOURCE 1 or something like that? > > It's insanely long.... This patch fixed it on my box: quanah@sol11-3:~/git/sold-2445/openldap$ git diff diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 8a62eff..1976340 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -113,6 +113,9 @@ typedef SSIZE_T ssize_t; /* Most platforms have posix_memalign, older may only have memalign */ #define HAVE_MEMALIGN 1 #include <malloc.h> +#if defined (__sun) +#define _POSIX_PTHREAD_SEMANTICS 1 +#endif #endif #if !(defined(BYTE_ORDER) || defined(__BYTE_ORDER)) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2017