openldap-bugs December 2014

openldap-bugs@openldap.org

24 participants
95 discussions

(ITS#7993) proxyauth with saslmech EXTERNAL not working
by dkastens＠uos.de 05 Dec '14

05 Dec '14

Full_Name: Dirk Kastens Version: 2.4.39 OS: RedHat SL 6.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:508:3d0:12a:32c6:740c:8971) We installed an ldap cluster with a mirrored master and several replicas on RedHat SL 6.5 with openldap 2.4.23-34.el6_5.1.x86_64. Write requests to the replicas are referred to the master server. The chain overlay follows the referral. It connects with the saslmech EXTERNAL to the master. The master maps the DN of the certificate to the replica admin. The replica admin has its authzTo attribute set to the write admin. This way the writing perfectly worked on our replica servers for all admins that are listed in the authzTo attribute. Shortly the machines were updated to SL 6.6 with openldap 2.4.39-8.el6.x86_64. The proxyauth stopped working. Write requests to the replica servers end with the error "ldap_modify: Other (e.g., implementationpepecific) error (80)". I installed another replica under SL 7.0 with openldap-2.4.39-3.el7.x86_64: same result. When I configure the idassertbind attribute to use simple bind with a binddn and credentials, the proxyauth works. This is the chain configuration that doesn't work any longer: olcDbURI: "ldap://ldap-master" olcDbStartTLS: none starttls=no olcDbIDAssertAuthzFrom: {0}* olcDbIDAssertBind: mode=self bindmethod=sasl saslmech=EXTERNAL starttls=yes tls_cert="/etc/openldap/certs/ldap-replica.pem" tls_key="/etc/openldap/certs/ldap-replica.key" tls_cacert="/etc/openldap/cacerts/cacerts.pem" tls_cacertdir="/etc/openldap/cacerts" tls_reqcert=demand This is the configuration that works now: olcDbStartTLS: none starttls=no olcDbURI: "ldap://ldap-master" olcDbIDAssertAuthzFrom: {0}* olcDbIDAssertBind: mode=self bindmethod=simple binddn="cn=proxyuser" credentials="secret" starttls=yes tls_cert="/etc/openldap/certs/ldap-replica.pem" tls_key="/etc/openldap/certs/ldap-replica.key" tls_cacert="/etc/openldap/cacerts/cacerts.pem" tls_cacertdir="/etc/openldap/cacerts" tls_reqcert=demand I looked through the manual pages, but I didn't find a difference between 2.4.23 and 2.4.39. In 2.4.23 we had to load the chain module and now we load the back_ldap module. But that's all. Dirk

1 0

(ITS#7992) lmdb: Windows: assume file paths are UTF-8, encode to UTF-16 for WinAPI and enable compiling when UNICODE is defined
by oskari.timperi＠iki.fi 05 Dec '14

05 Dec '14

Full_Name: Oskari Timperi Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/oskari-timperi-141205.zip Submission from: (NULL) (109.204.204.106) The patches make some changes so that compiling lmdb when UNICODE is defined is possible. This is achieved by using the A-versions of WinApi functions where they are needed. Also use CreateFileW to open files so that one can use exotic characters in paths. The library interface is not modified, but the code makes an assumption that paths passed to lmdb functions are encoded as UTF-8. The UTF-8 encoded paths are encoded to UTF-16 which is then passed to CreateFileW.

1 0

Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by h.b.furuseth＠usit.uio.no 04 Dec '14

04 Dec '14

On 12/04/2014 11:31 AM, leo(a)yuriev.ru wrote: > Could you suggest something other instead of "oomkiller"? Don't have a particularly good idea. oom_func, maybe. >> This feature could make it interesting to let readers and writers >> tell each other things: Reserve some unused space in the reader >> table slots for stuff the reader's caller could put there, and >> some space for an impatient writer to leave a note. Could go >> in an independent commit if there is any demand for it though. > > Communications between readers and writers may be interesting, but I > think it is over-engineering in the LMDB context. Yes... I guess I was thinking mostly of the prototype, in case we want to add something like it later. Might be useful to add a void* argument which would be NULL now but could be used later, if needed. -- Hallvard

1 0

Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by leo＠yuriev.ru 04 Dec '14

04 Dec '14

Hallvard, thank for your comments. 2014-12-02 14:20 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: > On 10/23/2014 07:13 AM, leo(a)yuriev.ru wrote: >> >> Subject: [PATCH 1/2] lmdb: ITS#7974 oomkiller feature. >> (...) >> +typedef int (MDB_oomkiller_func)(MDB_env *env, int pid, void* thread_id, >> size_t txn); > > > Some thoughts about this: > > Instead of trusting the return value, it seems safer to re-check > with mdb_reader_pid(). Like mdb_reader_check0() does. Maybe > except on Windows, where file locks from dead processes may > linger for a while until the OS reclaims them. I agree that usign mdb_reader_pid() is a better way. > Don't call it OOMkiller just because that's how you use it. > Others might do something else, like sending a reader a signal > which it interprets as "please wake up and finish your txn". > Or it might decide this process is the one which should give up. Could you suggest something other instead of "oomkiller"? Be noted, the "dreamcatcher" feature has a critical bug, which I has found and made fix while work on ITS#7968 & ITS#7987. Currently we hard testing a new code. So, in a week I plan to update both of the patches. > This feature could make it interesting to let readers and writers > tell each other things: Reserve some unused space in the reader > table slots for stuff the reader's caller could put there, and > some space for an impatient writer to leave a note. Could go > in an independent commit if there is any demand for it though. Communications between readers and writers may be interesting, but I think it is over-engineering in the LMDB context. IMHO the LMDB's code has a lot of technical debt, so it is more usefull to re-implement all of from a scratch, under a rules of perfectly-clean codestyle. May be I will do this, but on a basis and after a release of 1Hippeus - it is a extreme performance engine for zero-copy mesaging in a shared memory, partially like Intel DPDK. Leonid.

1 0

(ITS#7991) problem trying to call ldap_set_option
by shupilov＠tut.by 03 Dec '14

03 Dec '14

Full_Name: Dmitry Shupilov Version: 2.4.39 OS: RHEL 6.5 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.57.254.70) Hello all! It's my first time to post here, so sorry if I will do something wrong :) I have to write shared library which task is to check if the user is correct LDAP user. First of all I prepare env and call ldap_initialize - nothing special here. The ldap_create function sets ld properly (e.g. ld = '0x7fffe40837d0') and in gdb I can read it by (p *ld) or even deeper (p *ld.ldc). But the next function cannot do its job - ldap_set_option failed with "-1" status. I tried to create separate binary which use my shared *.so to do the same job - check a user in LDAP and it works fine: ldap_create assigns "short" address (e.g. 0x602a30). In this case ldap_set_option do what it needs to do. My question is: is the problem of ldap_set_option in that "very long value of address" or is something else? How can I catch the reason of this problem and solve it? BR, Dmitry

1 0

(ITS#7990) (docs) Admin guide: bad link in password policy overlay section
by frederic.poisson＠admin.gmessaging.net 02 Dec '14

02 Dec '14

Full_Name: Frederic POISSON Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.51.12.20) Hello, I'm looking to Password Policy overlay and admin guide 2.4, and i see that Howard CHU has corrected a link (ITS#6264) about "Password Management Issues". But on that link on Symas blog i do not see anything on that subject ? I have also another question about Password policy draft. Does OpenLDAP project already receive a feature request to support the draft in release 10 ? Thanks, Regards,

1 0

Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by h.b.furuseth＠usit.uio.no 02 Dec '14

02 Dec '14

On 10/23/2014 07:13 AM, leo(a)yuriev.ru wrote: > Subject: [PATCH 1/2] lmdb: ITS#7974 oomkiller feature. > (...) > +typedef int (MDB_oomkiller_func)(MDB_env *env, int pid, void* thread_id, size_t txn); Some thoughts about this: Instead of trusting the return value, it seems safer to re-check with mdb_reader_pid(). Like mdb_reader_check0() does. Maybe except on Windows, where file locks from dead processes may linger for a while until the OS reclaims them. Don't call it OOMkiller just because that's how you use it. Others might do something else, like sending a reader a signal which it interprets as "please wake up and finish your txn". Or it might decide this process is the one which should give up. This feature could make it interesting to let readers and writers tell each other things: Reserve some unused space in the reader table slots for stuff the reader's caller could put there, and some space for an impatient writer to leave a note. Could go in an independent commit if there is any demand for it though. -- Hallvard

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 02 Dec '14

02 Dec '14

This is a multi-part message in MIME format. --------------090506050608000200000309 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit (1) I can сonfirm once again - the bug is fixed. (2) Previously noted failure "DN index delete failed" caused by another (local) bug. (3) Feature "single write txn" need a minor fix, patch attached. Leonid. --- The attached files is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights and/or interest in this work to any party. I, Leonid Yuriev am authorized by Peter-Service LLC, my employer, to release this work under the following terms. Peter-Service LLC hereby places the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --------------090506050608000200000309 Content-Type: text/x-patch; name="excessive-space-single-write-txn.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="excessive-space-single-write-txn.patch" commit 02094a10018e1ebcae32b920f9d93d300a810f29 Author: Leo Yuriev <leo(a)yuriev.ru> Date: 2014-12-02 14:02:02 +0300 fix excessive space (likely a typo) for single write txn. diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 6e9119d..7587434 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -4589,7 +4589,7 @@ mdb_env_open(MDB_env *env, const char *path, unsigned int flags, mdb_mode_t mode if (!(flags & MDB_RDONLY)) { MDB_txn *txn; int tsize = sizeof(MDB_txn), size = tsize + env->me_maxdbs * - (sizeof(MDB_db)+sizeof(MDB_cursor)+sizeof(unsigned int)+1); + (sizeof(MDB_db)+sizeof(MDB_cursor *)+sizeof(unsigned int)+1); txn = calloc(1, size); if (txn) { txn->mt_dbs = (MDB_db *)((char *)txn + tsize); --------------090506050608000200000309--

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 02 Dec '14

02 Dec '14

> 2014-12-02 6:09 GMT+03:00 Howard Chu <hyc(a)symas.com>: >> Leonid Yuriev wrote: >>> Partially fixed. >>> Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master. >> >> Thanks, the patch makes sense. But if only partial, what else is still >> crashing? > Stable crash in a 5 seconds after the 4x-cluster resumes from > split-brain condition: > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 __memcpy_sse2_unaligned () at > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 > 116 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: Нет такого > файла или каталога. > (gdb) bt > #0 __memcpy_sse2_unaligned () at > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 > #1 0x00000000004aee11 in memcpy (__len=<optimised out>, > __src=<optimised out>, __dest=<optimised out>) at > /usr/include/x86_64-linux-gnu/bits/string3.h:51 > #2 mdb_search (op=0x7f16b4ffa7c0, rs=0x7f16b4e697b0) at search.c:993 Seems to be fixed completely. The last SIGSEGV is inducted by a "dreamcatcher" feature (ITS#7974). I already fixed the "dreamcatcher", currently we are re-testing it. Leonid.

1 0

Fwd: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 01 Dec '14

01 Dec '14

2014-12-02 6:09 GMT+03:00 Howard Chu <hyc(a)symas.com>: > Leonid Yuriev wrote: >> >> Partially fixed. >> Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master. > > > Thanks, the patch makes sense. But if only partial, what else is still > crashing? Stable crash in a 5 seconds after the 4x-cluster resumes from split-brain condition: Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 116 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: =D0=9D=D0=B5=D1=82= =D1=82=D0=B0=D0=BA=D0=BE=D0=B3=D0=BE =D1=84=D0=B0=D0=B9=D0=BB=D0=B0 =D0=B8=D0=BB=D0=B8 =D0=BA=D0=B0=D1=82=D0=B0= =D0=BB=D0=BE=D0=B3=D0=B0. (gdb) bt #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 #1 0x00000000004aee11 in memcpy (__len=3D<optimised out>, __src=3D<optimised out>, __dest=3D<optimised out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:51 #2 mdb_search (op=3D0x7f16b4ffa7c0, rs=3D0x7f16b4e697b0) at search.c:993 #3 0x000000000048a52a in overlay_op_walk (op=3Dop@entry=3D0x7f16b4ffa7c0, rs=3D0x7f16b4ff9c40, which=3Dop_search, oi=3D0xc31a30, on=3D<optimised out>= ) at backover.c:676 #4 0x000000000048a681 in over_op_func (op=3D0x7f16b4ffa7c0, rs=3D<optimised out>, which=3D<optimised out>) at backover.c:729 #5 0x000000000047de37 in syncrepl_del_nonpresent (op=3D0x7f16b4ffa7c0, si=3D0xc31490, uuids=3D<optimised out>, m=3D3, sc=3D<optimised out>, sc=3D<optimised out>) at syncrepl.c:3400 #6 0x0000000000481a0e in do_syncrep2 (op=3D0x7f16b4ffa7c0, si=3D0xc31490) at syncrepl.c:1346 #7 0x00000000004839e3 in do_syncrepl (ctx=3D<optimised out>, arg=3D0xc319d0) at syncrepl.c:1550 #8 0x00007f170283ecf2 in ldap_int_thread_pool_wrapper (xpool=3D0xbe4090) at tpool.c:688

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2014