openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs