- openldap-bugs - openldap.org

(ITS#8759) mixed overlay nops & memberof cause segfault
by zhixu.liu＠gmail.com 20 Oct '17

20 Oct '17

Full_Name: Z. Liu Version: 2.4.44 OS: Gentoo URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (221.218.169.84) if we enable overlay nops & memberof together, then doing a member MODDN operation, slapd will segfault and exit immediately. Example operation: dn: uid=test,ou=People,dc=example,dc=dc=com changetype: moddn newrdn: uid=chenln deleteoldrdn: 1 newsuperior: ou=Leave,dc=example,dc=com The reason is: in servers/slapd/overlays/memberof.c, function memberof_value_modify define mod/values/nvalues in the stack, which will be passed to other overlays, nops will try to free them if no attribute is changed.

1 0

(ITS#8758) New Mirror in the Netherlands
by mirror＠koddos.net 19 Oct '17

19 Oct '17

Full_Name: Martin Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.123.96.17) Hello, We wish to create a new public mirror in the Netherlands for OpenLDAP. Is there any server we can use for rsync? Regards, Martin

1 0

Re: (ITS#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by quanah＠symas.com 19 Oct '17

19 Oct '17

Hi Patrick, What we need is for you to simply reply to this ITS with your IPR statement, and the patch attached. This will allow us to include it. IPR guidelines are here: <https://www.openldap.org/devel/contributing.html#notice> Thanks, 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#8671) Declare ldap_init_fd() in ldap.h to help external consumers
by quanah＠symas.com 19 Oct '17

19 Oct '17

--On Thursday, October 19, 2017 10:20 AM +0300 Alexander Bokovoy <abokovoy(a)redhat.com> wrote: > Hi Quanah, > > On ti, 12 syys 2017, Quanah Gibson-Mount wrote: >> Hi Alexander, >> >> Your submission appears to be missing an IPR statement as noted at >> <https://www.openldap.org/devel/contributing.html#notice>. This is >> required for your submission to be evaluated. Please add an IPR at >> your earliest convenience. > Attached is a re-based patch set since there were changes in git master > in last month or so that affected the same area. > > There are two patches: one for git master, one for 2.4 branch. Since > there is no functional change in the code, I'd like to see the 2.4 > version in an upcoming release as that would greatly help Samba. > > I'm also including an IPR notice below: > > Red Hat, Inc. hereby place 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. Thanks very much! I'll get this into my scratch repo for review. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8757) RFE: let slapd MMR instances vote primary master
by michael＠stroeder.com 19 Oct '17

19 Oct '17

Full_Name: Michael Str.der Version: OS: URL: Submission from: (NULL) (217.145.44.194) In some situations having a "primary" master would be very useful (e.g. where to assign numeric IDs). The providers connected with MMR could try to vote a primary master with the raft algorithm: https://raft.github.io/ Ideally it should be visible in cn=monitor whether a provider replica is the current primary master. Let's discuss this at LDAPcon dinner this evening... ;-)

1 0

Re: (ITS#8671) Declare ldap_init_fd() in ldap.h to help external consumers
by abokovoy＠redhat.com 18 Oct '17

18 Oct '17

--cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Hi Quanah, On ti, 12 syys 2017, Quanah Gibson-Mount wrote: >Hi Alexander, > >Your submission appears to be missing an IPR statement as noted at ><https://www.openldap.org/devel/contributing.html#notice>. This is >required for your submission to be evaluated. Please add an IPR at >your earliest convenience. Attached is a re-based patch set since there were changes in git master in last month or so that affected the same area. There are two patches: one for git master, one for 2.4 branch. Since there is no functional change in the code, I'd like to see the 2.4 version in an upcoming release as that would greatly help Samba. I'm also including an IPR notice below: Red Hat, Inc. hereby place 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. Regards, -- / Alexander Bokovoy --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="abokovoy-master-ldap_init_fd-move-ldap_init_fd-definition-to-ldap.h.patch" Content-Transfer-Encoding: quoted-printable =46rom 7abe0a2be015d8c169e5d25078a91adaaa4d799f Mon Sep 17 00:00:00 2001 =46rom: Alexander Bokovoy <abokovoy(a)redhat.com> Date: Mon, 5 Jun 2017 14:43:58 +0300 Subject: [PATCH] ldap_init_fd: move ldap_init_fd() definition to ldap.h While OpenLDAP team position is that all code in OpenLDAP source distribution can be used by users, most distributions do not ship ldap_pvt.h as part of openldap-devel (sub)package. Move ldap_init_fd() to ldap.h to facilitate external users who have a need to integrate OpenLDAP with their own event loop processing. --- doc/man/man3/ldap_open.3 | 5 +---- include/ldap.h | 7 +++++++ include/ldap_pvt.h | 2 -- 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/doc/man/man3/ldap_open.3 b/doc/man/man3/ldap_open.3 index 66b0b98f8..ac2c13a86 100644 --- a/doc/man/man3/ldap_open.3 +++ b/doc/man/man3/ldap_open.3 @@ -3,7 +3,7 @@ .\" Copyright 1998-2017 The OpenLDAP Foundation All Rights Reserved. .\" Copying restrictions apply. See COPYRIGHT/LICENSE. .SH NAME -ldap_init, ldap_initialize, ldap_open \- Initialize the LDAP library and o= pen a connection to an LDAP server +ldap_init, ldap_initialize, ldap_open, ldap_init_fd \- Initialize the LDAP= library and open a connection to an LDAP server .SH LIBRARY OpenLDAP LDAP (libldap, \-lldap) .SH SYNOPSIS @@ -50,9 +50,6 @@ LDAPURLDesc **url; void *params; .LP .ft B -#include <ldap_pvt.h> -.LP -.ft B int ldap_init_fd(fd, proto, uri, ldp) .ft ber_socket_t fd; diff --git a/include/ldap.h b/include/ldap.h index e3f292dba..46de9ecf1 100644 --- a/include/ldap.h +++ b/include/ldap.h @@ -1551,6 +1551,13 @@ ldap_dup LDAP_P(( LDAP_F( int ) ldap_connect( LDAP *ld ); =20 +LDAP_F (int) +ldap_init_fd LDAP_P(( + ber_socket_t fd, + int proto, + LDAP_CONST char *url, + LDAP **ldp )); + /* * in tls.c */ diff --git a/include/ldap_pvt.h b/include/ldap_pvt.h index f1d93ac37..49f674ce5 100644 --- a/include/ldap_pvt.h +++ b/include/ldap_pvt.h @@ -344,8 +344,6 @@ ldap_get_message_ber LDAP_P(( /* open */ LDAP_F (int) ldap_open_internal_connection LDAP_P(( struct ldap **ldp, ber_socket_t *fdp )); -LDAP_F (int) ldap_init_fd LDAP_P(( - ber_socket_t fd, int proto, LDAP_CONST char *url, struct ldap **ldp )); =20 /* sasl.c */ LDAP_F (int) ldap_pvt_sasl_generic_install LDAP_P(( Sockbuf *sb, --=20 2.13.6 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="abokovoy-v2.4-ldap_init_fd-move-ldap_init_fd-definition-to-ldap.h.patch" Content-Transfer-Encoding: quoted-printable =46rom f03eb7efe69d0a929e85df4cb5b4f47c7017e0d4 Mon Sep 17 00:00:00 2001 =46rom: Alexander Bokovoy <abokovoy(a)redhat.com> Date: Mon, 5 Jun 2017 14:43:58 +0300 Subject: [PATCH] ldap_init_fd: move ldap_init_fd() definition to ldap.h While OpenLDAP team position is that all code in OpenLDAP source distribution can be used by users, most distributions do not ship ldap_pvt.h as part of openldap-devel (sub)package. Move ldap_init_fd() to ldap.h to facilitate external users who have a need to integrate OpenLDAP with their own event loop processing. --- doc/man/man3/ldap_open.3 | 5 +---- include/ldap.h | 7 +++++++ include/ldap_pvt.h | 2 -- 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/doc/man/man3/ldap_open.3 b/doc/man/man3/ldap_open.3 index 1d5e2b5e2..4f980f2cb 100644 --- a/doc/man/man3/ldap_open.3 +++ b/doc/man/man3/ldap_open.3 @@ -3,7 +3,7 @@ .\" Copyright 1998-2017 The OpenLDAP Foundation All Rights Reserved. .\" Copying restrictions apply. See COPYRIGHT/LICENSE. .SH NAME -ldap_init, ldap_initialize, ldap_open \- Initialize the LDAP library and o= pen a connection to an LDAP server +ldap_init, ldap_initialize, ldap_open, ldap_init_fd \- Initialize the LDAP= library and open a connection to an LDAP server .SH LIBRARY OpenLDAP LDAP (libldap, \-lldap) .SH SYNOPSIS @@ -45,9 +45,6 @@ LDAPURLDesc **url; void *params; .LP .ft B -#include <ldap_pvt.h> -.LP -.ft B int ldap_init_fd(fd, proto, uri, ldp) .ft ber_socket_t fd; diff --git a/include/ldap.h b/include/ldap.h index db6869da8..b39d985dc 100644 --- a/include/ldap.h +++ b/include/ldap.h @@ -1526,6 +1526,13 @@ LDAP_F( LDAP * ) ldap_dup LDAP_P(( LDAP *old )); =20 +LDAP_F (int) +ldap_init_fd LDAP_P(( + ber_socket_t fd, + int proto, + LDAP_CONST char *url, + LDAP **ldp )); + /* * in tls.c */ diff --git a/include/ldap_pvt.h b/include/ldap_pvt.h index ce53cf157..bf09d6c4c 100644 --- a/include/ldap_pvt.h +++ b/include/ldap_pvt.h @@ -333,8 +333,6 @@ ldap_get_message_ber LDAP_P(( /* open */ LDAP_F (int) ldap_open_internal_connection LDAP_P(( struct ldap **ldp, ber_socket_t *fdp )); -LDAP_F (int) ldap_init_fd LDAP_P(( - ber_socket_t fd, int proto, LDAP_CONST char *url, struct ldap **ldp )); =20 /* sasl.c */ LDAP_F (int) ldap_pvt_sasl_generic_install LDAP_P(( Sockbuf *sb, --=20 2.13.6 --cWoXeonUoKmBZSoM--

1 0

(ITS#8756) assertion in mdb_page_dirty() due to loose pages
by h.b.furuseth＠usit.uio.no 18 Oct '17

18 Oct '17

Full_Name: Hallvard B Furuseth Version: mdb.master, bb8502f08800a44a6b91a94d6478aa7101c4cc77 OS: URL: Submission from: (NULL) (193.71.61.52) Submitted by: hallvard Described here with a fix, and with discussion in the thread: http://www.openldap.org/lists/openldap-devel/201710/msg00019.html "Inside freelist_save() the mt_loose_pages could be merged into the mt_free_pgs. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… But at this point all loose_pages also still present in the mt_u.dirty_list. On the next loop inside freelist_save() a one more page could be requested, and page_alloc() could return a page which is already in the mt_u.dirty_list. In this case mdb_mid2l_insert() will return -1." We could catch and handle the error when WRITEMAP is not in use. Another fix is for freelist_save() to quit messing with loose pages and just reserve room for them, like it does for me_pghead. In LMDB 1.0, we'll have more options.

1 0

Re: (ITS#8376)
by christian.kornacker＠gmail.com 15 Oct '17

15 Oct '17

The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by SUSE Linux GmbH. SUSE Linux GmbH has not assigned rights and/or interest in this work to any party. I, Christian Kornacker am authorized by SUSE Linux GmbH, my employer, to release this work under the following terms. SUSE Linux GmbH hereby places the referenced 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.

1 0

(ITS#8755) invalid file descriptor when closing tls connection
by info＠christianknueppel.de 12 Oct '17

12 Oct '17

Full_Name: Christian Knueppel Version: 2.4.45 OS: Ubuntu 16.04.3 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.12.132.220) I currently developing on a c software which is using Openldap with TLS authentication. My software is working fine, but when i test it with valgrind, i always get an invalid file descriptor when closing the connection. Here is the stacktrace from valgrind: ==17517== Warning: invalid file descriptor -1 in syscall write() ==17517== at 0x4E4A4BD: ??? (syscall-template.S:84) ==17517== by 0x61BF5E7: sb_debug_write (in /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.5) ==17517== by 0x7261644: _gnutls_writev_emu (gnutls_buffers.c:447) ==17517== by 0x7261644: _gnutls_writev (gnutls_buffers.c:505) ==17517== by 0x7261644: _gnutls_io_write_flush (gnutls_buffers.c:699) ==17517== by 0x725BDFF: _gnutls_send_tlen_int (gnutls_record.c:464) ==17517== by 0x727E0D7: _gnutls_send_int (gnutls_record.h:43) ==17517== by 0x727E0D7: gnutls_alert_send (gnutls_alert.c:165) ==17517== by 0x725DCD8: gnutls_bye (gnutls_record.c:289) ==17517== by 0x5F9F181: tlsg_sb_close (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.5) ==17517== by 0x61C07B1: ber_int_sb_close (in /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.5) ==17517== by 0x61C08A3: ber_sockbuf_free (in /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.5) ==17517== by 0x5F815CD: ldap_ld_free (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.5) ==17517== by 0x41618F: ldap_close_handle (ldap_connection.c:481) --> In function ldap_close_handle i call ldap_unbind_ext_s(ld, NULL, NULL). The connection is built with ldap_initialize(&ld, config.ldap_url) and ldap_start_tls_s(ld, NULL, NULL). Options set with ldap_set_option() are LDAP_OPT_X_TLS_REQUIRE_CERT to 2 (LDAP_OPT_X_TLS_DEMAND) and LDAP_OPT_X_TLS_CACERTFILE are set to all SSL CA-Certificates (/etc/ssl/certs/ca-certificates.crt). I run the ldap_unbind_ext_s command (for test purpose) shortly after the start_tls command is finished. When i use ldap_sasl_interactive_bind_s with DIGEST-MD5 instead of ldap_start_tls_s, the warning doesn't appear. When i use both, tls and sasl, the warning also appears. My computer running on Ubuntu 16.04.3 LTS (uname: 4.4.0-97-generic x86_64) with libldap-2.4-2 (2.4.42+dfsg-2ubuntu3.2) and libgnutls30 (3.4.10-4ubuntu1.4). I also tested it with the newest Ubuntu Artful Aardvark and the newest openldap (2.4.45+dfsg-1ubuntu1) and gnutls(3.5.8-6ubuntu3) release, but it didn't has any effect in my case. I also tryed to compiled openldap against openssl to see, if it might be a gnutls bug, but the invalid file descriptor occurs again. The lower valgrind stacktrace is done with openldap 2.4.45 and openssl 1.0.2g on the newest Artful Aardvark 17.10. ==2638== Warning: invalid file descriptor -1 in syscall write() ==2638== at 0x4E4DCC0: write (write.c:26) ==2638== by 0x61C6E87: sb_debug_write (sockbuf.c:854) ==2638== by 0x5FAAB4A: tlso_bio_write.part.8 (tls_o.c:790) ==2638== by 0x516B94A: BIO_write (bio_lib.c:243) ==2638== by 0x5B20C61: ssl3_write_pending (s3_pkt.c:1105) ==2638== by 0x5B22E82: ssl3_dispatch_alert (s3_pkt.c:1733) ==2638== by 0x5B1EAE6: ssl3_shutdown (s3_lib.c:4372) ==2638== by 0x5FAA749: tlso_sb_close (tls_o.c:899) ==2638== by 0x61C7D8A: ber_int_sb_close (sockbuf.c:383) ==2638== by 0x61C7E73: ber_sockbuf_free (sockbuf.c:74) ==2638== by 0x5F8D006: ldap_ld_free (unbind.c:134) ==2638== by 0x1277B7: ldap_close_handle (ldap_connection.c:481)

1 0

(ITS#8754) ldpasearch IPv5 only
by dpa-openldap＠aegee.org 11 Oct '17

11 Oct '17

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4.45 OS: Linux URL: Submission from: (NULL) (87.193.154.82) After `./configure --disable-ipv6` I expect, that `ldapsearch` will not contact severs over IPv6, which is achieved with the fix below. diff --git a/libraries/libldap/os-ip.c b/libraries/libldap/os-ip.c --- a/libraries/libldap/os-ip.c +++ b/libraries/libldap/os-ip.c @@ -623,6 +623,9 @@ ldap_connect_to_host(LDAP *ld, Sockbuf *sb, continue; } +#ifndef LDAP_PF_INET6 + if (sai->ai_family == AF_INET6) continue; +#endif /* we assume AF_x and PF_x are equal for all x */ s = ldap_int_socket( ld, sai->ai_family, socktype ); if ( s == AC_SOCKET_INVALID ) {

1 0

(ITS#8753) Public key pinning support in libldap
by ondra＠openldap.org 10 Oct '17

10 Oct '17

Full_Name: Ondrej Kuznik Version: master OS: URL: https://github.com/mistotebe/openldap/tree/its8753 Submission from: (NULL) (82.10.24.68) Some programs might want to pin the server's public key instead of/in addition to certificate validation. The patch linked implements this option and provides OpenSSL/GnuTLS support code. A new libldap option LDAP_OPT_X_TLS_PEERKEY_HASH that accepts a string 'hashname/base64_hash_of_public_key'. If a TLS session is already present on the main connection, it is also checked immediately. It introduces a dependency on liblutil by depending on the symbol lutil_b64_pton. Somehow, this breaks the build for the ldap* tools, not sure why or how to fix that yet.

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 06 Oct '17

06 Oct '17

On Fri, Sep 15, 2017 at 07:54:22PM -0700, Paul B. Henson wrote: > I've been running 2.4.44 with the test patch since May and haven't seen > a crash since, for what that's worth. We upgraded to 2.4.45 last week, > without that patch. I'm going to see if the crash shows up again, and if > it does, apply the patch to 2.4.45 and see if it goes away again. Well, since upgrading, I've now seen two crashes; I don't have it compiled with debugging right now so the trace is limited: #0 0x0000000000483eb9 in modify_add_values () #1 0x00007f7b80d45bc3 in mdb_modify_internal () from /usr/lib64/openldap/openldap/back_mdb.so #2 0x00007f7b80d46f55 in mdb_modify () from /usr/lib64/openldap/openldap/back_mdb.so #3 0x000000000049a6d2 in overlay_op_walk () #4 0x000000000049a82a in ?? () #5 0x000000000048bbef in ?? () #6 0x000000000048f8cf in ?? () #7 0x0000000000493ae3 in ?? () #8 0x00007f7b858327f2 in ?? () from /usr/lib64/libldap_r-2.4.so.2 #9 0x00007f7b84bb03e4 in start_thread () from /lib64/libpthread.so.0 #10 0x00007f7b848f23ed in clone () from /lib64/libc.so.6 but it looks like the same issue to me. I'm going to go ahead and recompile 2.4.45 with the ignore-invalid-accesslog-ops.patch and run that for a while and see what happens. Thanks...

1 0

(ITS#8752) MMR delta-sync deadlock using slapd.conf
by quanah＠openldap.org 04 Oct '17

04 Oct '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) There is a reproducible lockup with delta-sync based multimaster replication. The more masters exist the easier it is to trigger, with 100% reproducibility at 4 masters. Generally: Load a database onto a server with no syncprov/accesslog configuration. Stop slapd Reconfigure slapd.conf to include syncprov/accesslog overlays, and cn=accesslog DB for changes, and replication agreements with other servers Configure other servers for syncprov/accesslog, but no database start slapd on all servers execute a MOD operation sequentially across the servers (1, 2, 3, 4) slapd will deadlock on server 3 or 4 100% of the time

1 0

(ITS#8751) deref aliases with back meta goes wrong in db_cache_find_ndn()
by paul＠subsignal.org 04 Oct '17

04 Oct '17

Full_Name: Paul K.lle Version: 24.44 OS: omnios URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.43.201.48) Disclaimer: I don't know C very well and I'm a complete noob wrt OpenLDAP source meta (dc=btu,dc=local) with two olcMetaSub URI: 0 -> olcDbURI ldap://localhost/ou=Fak6,dc=btu,dc=local olcDbRewrite {0}suffixmassage "ou=Fak6,dc=btu,dc=local" "ou=Fak6,dc=IT,dc=local" 1 -> olcDbURI ldap://ldap.xxxxx.de/ou=People,dc=btu,dc=local olcDbRewrite » {0}suffixmassage "ou=People,dc=btu,dc=local" "ou=People,o=XXXXXXXXXXXXX XXXXX,c=De" no deref search: [root@smb01 ~]# ldapsearch -x -h 192.168.70.101 -b ou=users,ou=Fak6,dc=btu,dc=local '(cn=Paul*)' '*' # extended LDIF # # LDAPv3 # base <ou=users,ou=Fak6,dc=btu,dc=local> with scope subtree # filter: (cn=Paul*) # requesting: * # # Paul Koelle, Users, Fak6, btu.local dn: cn=Paul Koelle,ou=Users,ou=Fak6,dc=btu,dc=local aliasedObjectName: cn=Paul Koelle,ou=People,dc=btu,dc=local cn: Paul Koelle objectClass: alias objectClass: extensibleObject # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 with deref: [root@smb01 ~]# ldapsearch -a always -x -h 192.168.70.101 -b ou=users,ou=Fak6,dc=btu,dc=local '(cn=Paul*)' '*' # extended LDIF # # LDAPv3 # base <ou=users,ou=Fak6,dc=btu,dc=local> with scope subtree # filter: (cn=Paul*) # requesting: * # # search result search: 2 result: 0 Success # numResponses: 1 debug log reveals: 59d38a50 bdb_idl_fetch_key: [01872a84] 59d38a50 <= bdb_index_read 1 candidates 59d38a50 <= bdb_equality_candidates: id=1, first=19, last=19 59d38a50 <= bdb_filter_candidates: id=1 first=19 last=19 59d38a50 => hdb_dn2idl("ou=users,ou=fak6,dc=it,dc=local") 59d38a50 bdb_dn2entry("cn=paul koelle,ou=people,dc=btu,dc=local") 59d38a50 => hdb_dn2id("c=btu,dc=local") 59d38a50 <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) 59d38a50 bdb_search_candidates: failed (rc=33) breakpoint for hdb_dn2id (gdb) bt #0 hdb_dn2id (op=0xa05510, in=0xfffffd7ffc87f208, ei=0xfffffd7ffc87f1f0, txn=0x8e6950, cursor=0xfffffd7ffc87f1e0) at dn2id.c:705 #1 0x000000000059beed in hdb_cache_find_ndn (op=0xa05510, txn=0x8e6950, ndn=0xfffffd7ffc87f350, res=0xfffffd7ffc87f2e0) at cache.c:462 #2 0x00000000005a3d81 in hdb_dn2entry (op=0xa05510, tid=0x8e6950, dn=0xfffffd7ffc87f350, e=0xfffffd7ffc87f348, matched=0, lock=0xfffffd7ffc87f330) at dn2entry.c:47 #3 0x000000000053756c in deref_base (op=0xa05510, rs=0xfffffd7ffc9ffb40, e=0x91c0b8, matched=0xfffffd7ffc87f460, txn=0x8e6950, lock=0xfffffd7ffc87f3c0, tmp=0x10e3010, visited=0xf63010) at search.c:104 #4 0x0000000000537be7 in search_aliases (op=0xa05510, rs=0xfffffd7ffc9ffb40, e=0xfffffd7ffc87f750, txn=0x8e6950, ids=0xfffffd7ffc8ff7a0, scopes=0xfffffd7ffc87f7a0, stack=0xde3010) at search.c:250 #5 0x000000000053ab3d in search_candidates (op=0xa05510, rs=0xfffffd7ffc9ffb40, e=0xfffffd7ffc87f750, txn=0x8e6950, ids=0xfffffd7ffc8ff7a0, scopes=0xfffffd7ffc87f7a0) at search.c:1258 #6 0x0000000000538e27 in hdb_search (op=0xa05510, rs=0xfffffd7ffc9ffb40) at search.c:616 #7 0x000000000048438d in fe_op_search (op=0xa05510, rs=0xfffffd7ffc9ffb40) at search.c:402 #8 0x0000000000483bcc in do_search (op=0xa05510, rs=0xfffffd7ffc9ffb40) at search.c:247 #9 0x0000000000480537 in connection_operation (ctx=0xfffffd7ffc9ffc70, arg_v=0xa05510) at connection.c:1158 #10 0x0000000000480acc in connection_read_thread (ctx=0xfffffd7ffc9ffc70, argv=0xf) at connection.c:1294 #11 0x0000000000622afd in ldap_int_thread_pool_wrapper (xpool=0x7d8840) at tpool.c:696 #12 0xfffffd7ffeb9e43a in _thrp_setup () from /lib/64/libc.so.1 #13 0xfffffd7ffeb9e750 in ?? () from /lib/64/libc.so.1 #14 0x0000000000000000 in ?? () if you look at the arguments in (h|b)db_cache_find_ndn there are mixed values from pre/post meta rewrite? #1 0x000000000059beed in hdb_cache_find_ndn (op=0xa05510, txn=0x8e6950, ndn=0xfffffd7ffc87f350, res=0xfffffd7ffc87f2e0) at cache.c:462 462 rc = bdb_dn2id( op, &ei.bei_nrdn, &ei, txn, &cursor ); (gdb) p *ndn $8 = {bv_len = 40, bv_val = 0x9fdd06 "cn=paul koelle,ou=people,dc=btu,dc=local"} (gdb) p *res $9 = (EntryInfo *) 0x0 (gdb) p ndn->bv_val $13 = 0x9fdd06 "cn=paul koelle,ou=people,dc=btu,dc=local" (gdb) p op->o_bd->be_nsuffix[0] $16 = {bv_len = 14, bv_val = 0x9f17d0 "dc=it,dc=local"} and the code in bdb_cache_find_ndn constructs a new BV from *ndn and *op which have different bases (cache.c line 426): /* we're searching a full DN from the root */ ptr = ndn->bv_val + ndn->bv_len - op->o_bd->be_nsuffix[0].bv_len; ei.bei_nrdn.bv_val = ptr; ei.bei_nrdn.bv_len = op->o_bd->be_nsuffix[0].bv_len; where op->o_bd_>be_nsuffix[0] is the post-rewrite suffix and ndn has the pre-rewrite suffix?? continuing lead to the following debug output: 59d38434 => hdb_dn2id("c=btu,dc=local") 59d38434 <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) note the incomplete "c=btu,dc=local" probably because "dc=it,dc=local" is one char less than "dc=btu,dc=local"

1 0

Re: (ITS#8747) LDAP load balancer daemon (lloadd)
by ondra＠mistotebe.net 02 Oct '17

02 Oct '17

On Thu, Sep 28, 2017 at 04:13:46PM +0000, ondra(a)openldap.org wrote: > The 'lloadd' branch linked above contains the load balancer code that > is now ready for review. > > This adds a new server to the OpenLDAP project, a load balancing proxy > (prototype). To summarise the reasons for this project to exist and highlight its features, limitations: - most LDAP load balancers pin a connection to another server and then just ship data, lloadd can distribute operations from a single client connection across LDAP servers - to make the above possible, lloadd sets up connections to the backend servers on startup and manages them as per configuration (independent on the clients) - bind operations are forwarded over dedicated bind connections or using the VC exop if feature 'vc' is enabled in its config, the designated identity is then passed on with the operations with proxyauth control (if feature 'proxyauthz' is enabled) - it is expected that all backends are indistinguishable (same features, suffixes, data) - no SASL bind support yet - if an operation cannot be processed or forwarded for any reason (overload, connection loss, ...), it is never re-sent, client will however still be sent an appropriate result in that case The lloadd.8 and lloadd.conf.5 manpages are provided, Admin guide and further documentation will come as the implementation matures. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: AW: (ITS#8749) Proxy: LDAP-querry doesn't work for e.g(userAccountControl:1.2.840.113556.1.4.803:=2)
by michael＠stroeder.com 01 Oct '17

01 Oct '17

steffen.krahl(a)nexio.de wrote: > Regarding segmentation fault: that's true, but I have to investigate > further Please make sure to install with debug symbols and read how to use gdb to obtain a stack back trace: https://www.openldap.org/faq/data/cache/59.html Ciao, Michael.

1 0

AW: (ITS#8749) Proxy: LDAP-querry doesn't work for e.g (userAccountControl:1.2.840.113556.1.4.803:=2)
by Steffen.Krahl＠nexio.de 01 Oct '17

01 Oct '17

RGVhciBNaWNoYWVsLA0KDQptYW55IHRoYW5rcyBmb3IgeW91ciBleHBsYWluYXRpb24uIFJlZ2FyZGlu ZyBzZWdtZW50YXRpb24gZmF1bHQ6IHRoYXQncyB0cnVlLCBidXQgSSBoYXZlIHRvIGludmVzdGlnYXRl IGZ1cnRoZXINCg0KQlINClN0ZWZmZW4gDQoNCi0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0t LS0NClZvbjogTWljaGFlbCBTdHLDtmRlciBbbWFpbHRvOm1pY2hhZWxAc3Ryb2VkZXIuY29tXSANCkdl c2VuZGV0OiBTb25udGFnLCAxLiBPa3RvYmVyIDIwMTcgMTA6MjUNCkFuOiBLcmFobCwgU3RlZmZlbjsg b3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZw0KQmV0cmVmZjogUmU6IChJVFMjODc0OSkgUHJveHk6IExE QVAtcXVlcnJ5IGRvZXNuJ3Qgd29yayBmb3IgZS5nICh1c2VyQWNjb3VudENvbnRyb2w6MS4yLjg0MC4x MTM1NTYuMS40LjgwMzo9MikNCg0Kc3RlZmZlbi5rcmFobEBuZXhpby5kZSB3cm90ZToNCj4gSSdtIHVz aW5nIE9wZW5MREFQIHdpdGggTERBUC1iYWNrZW5kIGFzIHByb3h5IGZvciBBY3RpdmVEaXJlY3Rvcnkg DQo+IEl0J3Mgd29ya2luZyB3ZWxsIHNvIGZhciwgb25seSBMREFQLXF1ZXJpZXMgd2hpY2ggc2hvdWxk IGV4Y2x1ZGUNCj4gZGVhY3RpdmF0ZWQgdXNlcnMgZG9uJ3Qgd29yay4gSXQgc2VlbXMgc2xhcGQgZG9l cyBub3QgYWNjZXB0IHF1ZXJpZXMNCj4gbGlrZSAoYXR0cmlidXRlOk9JRDo9dmFsdWUpDQoNCk9wZW5M REFQIGRvZXMgc3VwcG9ydCBleHRlbmRlZCBmaWx0ZXJzIHdpdGggYSBtYXRjaGluZyBydWxlLiBCdXQg b25seQ0Kd2l0aCBtYXRjaGluZyBydWxlcyBpbXBsZW1lbnRlZCBpbiBPcGVuTERBUC4NCg0KPiBpbiBw YXJ0aWN1bGFyDQo+ICghKHVzZXJBY2NvdW50Q29udHJvbDoxLjIuODQwLjExMzU1Ni4xLjQuODAzOj0y KSkpDQoNClRoZSBtYXRjaGluZyBydWxlIGRlZmluZWQgYnkgMS4yLjg0MC4xMTM1NTYuMS40LjgwMyBp cyBhIHByb3ByaWV0YXJ5DQptYXRjaGluZyBydWxlIGRlZmluZWQgYnkgTWljcm9zb2Z0IGZvciBiaXQt d2lzZSBtYXRjaGluZy4gQUZBSUNTIHRoZXkNCm5ldmVyIHdyb3RlIGEgcHVibGljIGZvcm1hbCBzcGVj IGZvciBpdC4gU28gdGhpcyBwYXJ0aWN1bGFyIG1hdGNoaW5nDQpydWxlIGlzIG5vdCBpbXBsZW1lbnRl ZCBpbiBPcGVuTERBUC4NCg0KPiBwZXJmb3JtaW5nIHVwcGVyIHF1ZXJ5IGdldHM6IE9jdCAgMSAwMDo0 NTozMyBueGxkMDEgc2xhcGRbMzAwMl06DQo+IHN0cjJmaWx0ZXIgIigmKHNBTUFjY291bnRUeXBlPSA4 MDUzMDYzNjgpKD89ZXJyb3IpKSIgT2N0ICAxIDAwOjQ1OjMzDQo+IG54bGQwMSBrZXJuZWw6IFs0OTQz Ni45MzM3MzVdIHNsYXBkWzMwMDVdOiBzZWdmYXVsdCBhdCAxOCBpcCANCj4gMDAwMDdmZjRmNzgzZDUx MiBzcCAwMDAwN2ZmNGYxYWZjODEwIGVycm9yIDQgaW4gDQo+IGxpYmMtMi4yMy5zb1s3ZmY0Zjc3Yjkw MDArMWMwMDAwXQ0KDQpEb2VzIHRoYXQgbWVhbiBzbGFwZCBzZWcgZmF1bHRzPyBJdCBzaG91bGRuJ3Qu DQoNCj4gcGVyZm9ybWluZyB0aGUgZm9sbG93aW5nIHF1ZXJ5DQo+ICAoJihvYmplY3RDbGFzcz0qKSh1 c2VyQWNjb3VudENvbnRyb2w6MS4yLjg0MC4xMTM1NTYuMS40LjgwMzo9MikpDQo+IHdpbGwgZ2V0IGZv bGxvd2luZyBsb2cgd250cnk6DQo+IE9jdCAgMSAwMDo0OTowNyBueGxkMDEgc2xhcGRbMzAzM106IHN0 cjJmaWx0ZXINCj4gIigmKG9iamVjdENsYXNzPSopKCEob2JqZWN0Q2xhc3M9KikpKSINCg0KSU1PIGl0 IG1ha2VzIHBlcmZlY3Qgc2Vuc2UgdG8gdHJlYXQgZXh0ZW5kZWQgZmlsdGVyIHBhcnQgd2l0aCBhDQpu b24tc3VwcG9ydGVkIG1hdGNoaW5nIHJ1bGUgYXMgYSBmaWx0ZXIgd2hpY2ggYWx3YXlzIGV2YWx1YXRl cyB0byBGYWxzZS4NCg0KQ2lhbywgTWljaGFlbC4NCg0KCgpTaXR6IGRlciBHZXNlbGxzY2hhZnQ6IE5p ZWRlci1PbG0gCkFtdHNnZXJpY2h0IE1haW56LCBIUkIgNzE4NQpVU3QuLUlEOiBERSAyMDggMzAzIDY2 NgpHZXNjaMOkZnRzZsO8aHJlcjogQW5kcmVhIE1hbmRhbmljaQoKRGllc2UgRS1NYWlsIGVudGjDpGx0 IHZlcnRyYXVsaWNoZSBvZGVyIHJlY2h0bGljaCBnZXNjaMO8dHp0ZSBJbmZvcm1hdGlvbmVuLiBXZW5u IFNpZSBuaWNodCBkZXIgcmljaHRpZ2UgQWRyZXNzYXQgc2luZCBvZGVyIGRpZXNlIEUtTWFpbCBpcnJ0 w7xtbGljaCBlcmhhbHRlbiBoYWJlbiwgaW5mb3JtaWVyZW4gU2llIGJpdHRlIHNvZm9ydCBkZW4gQWJz ZW5kZXIgdW5kIHZlcm5pY2h0ZW4gU2llIGRpZXNlIEUtTWFpbC4gRGFzIHVuZXJsYXVidGUgS29waWVy ZW4gc293aWUgZGllIHVuYmVmdWd0ZSBXZWl0ZXJnYWJlIGRpZXNlciBFLU1haWwgaXN0IG5pY2h0IGdl c3RhdHRldC4KClRoaXMgRS1NYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCAob3Ig aGF2ZSByZWNlaXZlZCB0aGlzIEUtTWFpbCBpbiBlcnJvcikgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkZXN0cm95IHRoaXMgRS1NYWlsLiBBbnkgdW5hdXRob3Jpc2VkIGNvcHlp bmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoZSBtYXRlcmlhbCBpbiB0aGlzIEUtTWFp bCBpcyBzdHJpY3RseSBmb3JiaWRkZW4u

1 0

(ITS#8750) About the implementation of mutex lock(li_log_mutex) in accesslog_purge()
by yos-nishino＠ys.jp.nec.com 01 Oct '17

01 Oct '17

Full_Name: Yoshinori Nishino Version: 2.4.45 OS: CentOS 7.3.1611 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.143.35.20) Dear sir, I saw the deadlock between accesslog_purge() and accesslog_responce(), both of which are implemented in servers/slapd/overlays/accesslog.c. The deadlock was caused by __db_hybrid_mutex_suspend() in libdb-5.3.so(hdb). ==[the output of pstack]== Thread 22 (Thread 0x7f1c845ec700 (LWP 23001)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 21 (Thread 0x7f1c82dea700 (LWP 23002)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 20 (Thread 0x7f1c825e9700 (LWP 23003)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 19 (Thread 0x7f1c81de8700 (LWP 23004)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 18 (Thread 0x7f1c815e7700 (LWP 23005)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 17 (Thread 0x7f1c80de6700 (LWP 23006)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x7f1c477f0700 (LWP 23007)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 15 (Thread 0x7f1c46fef700 (LWP 23009)): #0 0x00007f2e17e856d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f2e1860b2f3 in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007f2e1860a640 in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007f2e186b4d3a in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007f2e186b5820 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007f2e186e1142 in __db_lget () from /lib64/libdb-5.3.so #6 0x00007f2e18612602 in __bamc_writelock () from /lib64/libdb-5.3.so #7 0x00007f2e186cd079 in __dbc_idel () from /lib64/libdb-5.3.so #8 0x00007f2e186d1113 in __dbc_del () from /lib64/libdb-5.3.so #9 0x00007f2e186dc3db in __dbc_del_pp () from /lib64/libdb-5.3.so #10 0x00007f2e1913b382 in hdb_dn2id_delete () #11 0x00007f2e191394ca in hdb_delete () #12 0x00007f2e190d6996 in overlay_op_walk () #13 0x00007f2e190d6b04 in over_op_func () #14 0x00007f2e110f3399 in accesslog_purge () from /usr/lib64/openldap/accesslog-2.4.so.2 #15 0x00007f2e18bb9fba in ldap_int_thread_pool_wrapper () from /lib64/libldap_r-2.4.so.2 #16 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #17 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 14 (Thread 0x7f1c467ee700 (LWP 23008)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x7f1c45fed700 (LWP 23010)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7f1c457ec700 (LWP 23011)): #0 0x00007f2e17e856d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f2e18bba00b in ldap_int_thread_pool_wrapper () from /lib64/libldap_r-2.4.so.2 #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x7f1c44feb700 (LWP 23012)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x7f1c447ea700 (LWP 23013)): #0 0x00007f2e17e856d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f2e18bba00b in ldap_int_thread_pool_wrapper () from /lib64/libldap_r-2.4.so.2 #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x7f1c43fe9700 (LWP 23014)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x7f1c437e8700 (LWP 23015)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x7f1c42fe7700 (LWP 23016)): #0 0x00007f2e17e856d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f2e1860b2f3 in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007f2e1860a640 in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007f2e186b4d3a in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007f2e186b5820 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007f2e186e1142 in __db_lget () from /lib64/libdb-5.3.so #6 0x00007f2e18628605 in __bam_search () from /lib64/libdb-5.3.so #7 0x00007f2e18613256 in __bamc_search () from /lib64/libdb-5.3.so #8 0x00007f2e1861790f in __bamc_put () from /lib64/libdb-5.3.so #9 0x00007f2e186ce514 in __dbc_iput () from /lib64/libdb-5.3.so #10 0x00007f2e186c9a0e in __db_put () from /lib64/libdb-5.3.so #11 0x00007f2e186defa4 in __db_put_pp () from /lib64/libdb-5.3.so #12 0x00007f2e1913acec in hdb_dn2id_add () #13 0x00007f2e1913261b in hdb_add () #14 0x00007f2e190d6996 in overlay_op_walk () #15 0x00007f2e190d6b04 in over_op_func () #16 0x00007f2e110f44e4 in accesslog_response () from /usr/lib64/openldap/accesslog-2.4.so.2 #17 0x00007f2e190d5d48 in over_back_response () #18 0x00007f2e19078243 in slap_response_play () #19 0x00007f2e19078800 in send_ldap_response () #20 0x00007f2e19079392 in slap_send_ldap_result () #21 0x00007f2e190f438d in hdb_modify () #22 0x00007f2e190d6996 in overlay_op_walk () #23 0x00007f2e190d6b04 in over_op_func () #24 0x00007f2e190c7bae in syncrepl_message_to_op () #25 0x00007f2e190cab57 in do_syncrep2 () #26 0x00007f2e190cf95b in do_syncrepl () #27 0x00007f2e190689f1 in connection_read_thread () #28 0x00007f2e18bb9fba in ldap_int_thread_pool_wrapper () from /lib64/libldap_r-2.4.so.2 #29 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #30 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x7f1c427e6700 (LWP 23018)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x7f1c41fe5700 (LWP 23017)): #0 0x00007f2e17e881bd in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f2e17e83d02 in _L_lock_791 () from /lib64/libpthread.so.0 #2 0x00007f2e17e83c08 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f2e110f3f54 in accesslog_response () from /usr/lib64/openldap/accesslog-2.4.so.2 #4 0x00007f2e190d5d48 in over_back_response () #5 0x00007f2e19078243 in slap_response_play () #6 0x00007f2e19078800 in send_ldap_response () #7 0x00007f2e19079392 in slap_send_ldap_result () #8 0x00007f2e190f438d in hdb_modify () #9 0x00007f2e190d6996 in overlay_op_walk () #10 0x00007f2e190d6b04 in over_op_func () #11 0x00007f2e1909d7d3 in passwd_extop () #12 0x00007f2e1909bccc in fe_extended () #13 0x00007f2e1909ba7d in do_extended () #14 0x00007f2e19067d0c in connection_operation () #15 0x00007f2e1906807b in connection_read_thread () #16 0x00007f2e18bb9fba in ldap_int_thread_pool_wrapper () from /lib64/libldap_r-2.4.so.2 #17 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #18 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7f1c417e4700 (LWP 23019)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f1c40fe3700 (LWP 23020)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f1c3bfff700 (LWP 23021)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f2e1900d740 (LWP 22992)): #0 0x00007f2e17e82ef7 in pthread_join () from /lib64/libpthread.so.0 #1 0x00007f2e19064de1 in slapd_daemon () #2 0x00007f2e1904bb62 in main () ==== ==[the output of "db_stat -C A"]== Default locking region information: 9 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 3600 Initial number of locks allocated 0 Initial number of lockers allocated 3600 Initial number of lock objects allocated 26000 Maximum number of locks possible 26000 Maximum number of lockers possible 26000 Maximum number of lock objects possible 3600 Current number of locks allocated 18 Current number of lockers allocated 3600 Current number of lock objects allocated 720 Number of lock object partitions 32771 Size of object hash table 15 Number of current locks 2044 Maximum number of locks at any one time 4 Maximum number of locks in any one bucket 1 Maximum number of locks stolen by for an empty partition 1 Maximum number of locks stolen for any one partition 17 Number of current lockers 17 Maximum number of lockers at any one time 11 Number of current lock objects 1456 Maximum number of lock objects at any one time 3 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 301M Total number of locks requested (301292352) 301M Total number of locks released (301292334) 0 Total number of locks upgraded 7 Total number of locks downgraded 3 Lock requests not available due to conflicts, for which we waited 2 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 2GB 524MB 688KB Region size 0 The number of partition locks that required waiting (0%) 0 The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 0 The number of locker allocations that required waiting (0%) 0 The number of region locks that required waiting (0%) 3 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Environment Region type 1 Region ID /var/lib/ldap/accesslog_db/__db.001 Region name 0x7f0ffe75b000 Region address 0x7f0ffe75b0a0 Region allocation head 0x7f0ffe95b5b0 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 1032145 allocations, 0 failures, 1030659 frees, 1 longest Allocations by power-of-two sizes: 1KB 1032140 2KB 0 4KB 0 8KB 0 16KB 0 32KB 0 64KB 1 128KB 0 256KB 0 512KB 0 1024KB 4 REGION_SHARED Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 2 Lock region region mutex [0/11M 0% 6376/139709380257600] 32771 locker table size 32771 object table size 2099280 obj_off 5570968 locker_off 0 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd= 0 locks held 1 write locks 0 pid/thread 22992/139835964708672 flags 10 priority 100 1 READ 1 HELD id2entry.bdb handle 0 2 dd= 0 locks held 1 write locks 0 pid/thread 22992/139835964708672 flags 10 priority 100 2 READ 1 HELD dn2id.bdb handle 0 3 dd= 0 locks held 0 write locks 0 pid/thread 22992/139835964708672 flags 0 priority 100 4 dd= 0 locks held 1 write locks 0 pid/thread 22992/139760456615680 flags 10 priority 100 4 READ 1 HELD entryCSN.bdb handle 0 5 dd= 0 locks held 0 write locks 0 pid/thread 22992/139759426926336 flags 0 priority 100 6 dd= 0 locks held 1 write locks 0 pid/thread 22992/139759426926336 flags 10 priority 100 6 READ 1 HELD objectClass.bdb handle 0 7 dd= 0 locks held 1 write locks 0 pid/thread 22992/139759426926336 flags 10 priority 100 7 READ 1 HELD reqStart.bdb handle 0 8 dd= 0 locks held 1 write locks 0 pid/thread 22992/139759384962816 flags 10 priority 100 8 READ 1 HELD reqEnd.bdb handle 0 9 dd= 0 locks held 1 write locks 0 pid/thread 22992/139759384962816 flags 10 priority 100 9 READ 1 HELD reqResult.bdb handle 0 80000003 dd= 0 locks held 0 write locks 0 pid/thread 22992/139835964708672 flags 0 priority 100 80000004 dd= 0 locks held 0 write locks 0 pid/thread 22992/139835964708672 flags 0 priority 100 80000006 dd= 0 locks held 0 write locks 0 pid/thread 22992/139759384962816 flags 0 priority 100 80000007 dd= 0 locks held 0 write locks 0 pid/thread 22992/139759426926336 flags 0 priority 100 8007dd08 dd= 0 locks held 2 write locks 0 pid/thread 22992/139759359784704 flags 0 priority 100 8007dd08 READ 1 HELD 0x652a90 len: 9 data: 010000000000000000 8007dd08 READ 1 HELD dn2id.bdb page 3 8007dd09 dd= 0 locks held 2 write locks 0 pid/thread 22992/139759426926336 flags 0 priority 100 8007dd09 READ 1 HELD 0x652a90 len: 9 data: 010000000000000000 8007dd09 READ 1 HELD 0x6716e8 len: 9 data: cfea8d000000000000 8007dd0a dd= 0 locks held 2 write locks 0 pid/thread 22992/139759426926336 flags 0 priority 100 8007dd0a WRITE 1 WAIT dn2id.bdb page 3 8007dd0a READ 1 HELD dn2id.bdb page 3 8007dd0a READ 1 HELD dn2id.bdb page 444591 8007dd0b dd= 0 locks held 0 write locks 0 pid/thread 22992/139759359784704 flags 0 priority 100 8007dd0b WRITE 1 WAIT dn2id.bdb page 3 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 8007dd08 READ 1 HELD dn2id.bdb page 3 8007dd0a READ 1 HELD dn2id.bdb page 3 8007dd0b WRITE 1 WAIT dn2id.bdb page 3 8007dd0a WRITE 1 WAIT dn2id.bdb page 3 2 READ 1 HELD dn2id.bdb handle 0 1 READ 1 HELD id2entry.bdb handle 0 4 READ 1 HELD entryCSN.bdb handle 0 8007dd09 READ 1 HELD 0x652a90 len: 9 data: 010000000000000000 8007dd08 READ 1 HELD 0x652a90 len: 9 data: 010000000000000000 9 READ 1 HELD reqResult.bdb handle 0 8 READ 1 HELD reqEnd.bdb handle 0 8007dd0a READ 1 HELD dn2id.bdb page 444591 7 READ 1 HELD reqStart.bdb handle 0 8007dd09 READ 1 HELD 0x6716e8 len: 9 data: cfea8d000000000000 6 READ 1 HELD objectClass.bdb handle 0 ==== #pid/thread 22992/139759426926336:Thread 7f1c46fef700 - accesslog_purge() #pid/thread 22992/139759359784704:Thread 7f1c42fe7700 - accesslog_responce() I am going to consider the tentative fix for openldap because I anticipate it would take so long time to pursue the fix for bdb(hdb), The tentative fix is like the following. Would you let me know whethere or not there are any concern about the fix? ==[accesslog_purge() in accesslog.c]== for (i=0; i<pd.used; i++) { op->o_req_dn = pd.dn[i]; op->o_req_ndn = pd.ndn[i]; if ( !slapd_shutdown ) { ldap_pvt_thread_mutex_lock( &li->li_log_mutex ); rs_reinit( &rs, REP_RESULT ); op->o_bd->be_delete( op, &rs ); ldap_pvt_thread_mutex_unlock( &li->li_log_mutex ); } ch_free( pd.ndn[i].bv_val ); ch_free( pd.dn[i].bv_val ); ldap_pvt_thread_pool_pausecheck( &connection_pool ); } ==== I know openldap itself currently recommend NOT using hdb/bdb as backend database. However, I should seek any workaround in the hdb backend case. Best Regards,

1 0

Re: (ITS#8749) Proxy: LDAP-querry doesn't work for e.g (userAccountControl:1.2.840.113556.1.4.803:=2)
by michael＠stroeder.com 01 Oct '17

01 Oct '17

This is a cryptographically signed message in MIME format. --------------ms020703060800000901000202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable steffen.krahl(a)nexio.de wrote: > I'm using OpenLDAP with LDAP-backend as proxy for ActiveDirectory=20 > It's working well so far, only LDAP-queries which should exclude > deactivated users don't work. It seems slapd does not accept queries > like (attribute:OID:=3Dvalue) OpenLDAP does support extended filters with a matching rule. But only with matching rules implemented in OpenLDAP. > in particular > (!(userAccountControl:1.2.840.113556.1.4.803:=3D2))) The matching rule defined by 1.2.840.113556.1.4.803 is a proprietary matching rule defined by Microsoft for bit-wise matching. AFAICS they never wrote a public formal spec for it. So this particular matching rule is not implemented in OpenLDAP. > performing upper query gets: Oct 1 00:45:33 nxld01 slapd[3002]: > str2filter "(&(sAMAccountType=3D 805306368)(?=3Derror))" Oct 1 00:45:3= 3 > nxld01 kernel: [49436.933735] slapd[3005]: segfault at 18 ip=20 > 00007ff4f783d512 sp 00007ff4f1afc810 error 4 in=20 > libc-2.23.so[7ff4f77b9000+1c0000] Does that mean slapd seg faults? It shouldn't. > performing the following query > (&(objectClass=3D*)(userAccountControl:1.2.840.113556.1.4.803:=3D2)) > will get following log wntry: > Oct 1 00:49:07 nxld01 slapd[3033]: str2filter > "(&(objectClass=3D*)(!(objectClass=3D*)))" IMO it makes perfect sense to treat extended filter part with a non-supported matching rule as a filter which always evaluates to False. Ciao, Michael. --------------ms020703060800000901000202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMDAxMDgyNDQ2WjAvBgkq hkiG9w0BCQQxIgQgjVnm8ahsW8UjSaHg8/QsoGPfsTkcNQMlzcj5iApV0cQwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAGnpf1uxiIUjLgQv+x7RBn79145ns9HfcJUDIVtW3QOwB1uXmjJBwIuaEWqtFAy9r2OOC zLsp8GYgc4OAl/2BFOCq+CR09TkGxDHK+n6UBG5vQ0oeSUSbMQD2wgTSNChQ2gdCOhrRAjWP AQiN7YyYOM2sJBdJEVkruG0NlzPa/9lSHHH8ljMkmIhDjFukAME5L0TTbLQN3PDo8C+IITHH OuYzwBsQ/ZBnXBZ1D9RrkdkfnT4aSYUv0bJ93t++tv4bI6yQvax7WbIJ5BuOlLUpNaLEd+4R rCKf/fO5QUkMxFICJG7Jd+qq8LpQuRcb02985OnKKgvPFM3L3e9oNn/fqgAAAAAAAA== --------------ms020703060800000901000202--

1 0

(ITS#8749) Proxy: LDAP-querry doesn't work for e.g (userAccountControl:1.2.840.113556.1.4.803:=2)
by steffen.krahl＠nexio.de 30 Sep '17

30 Sep '17

Full_Name: Steffen Krahl Version: 2.4-2 OS: Ubuntu 16.04.3 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.168.136.108) I'm using OpenLDAP with LDAP-backend as proxy for ActiveDirectory It's working well so far, only LDAP-queries which should exclude deactivated users don't work. It seems slapd does not accept queries like (attribute:OID:=value) in particular (&(sAMAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) fails due to the part ":1.2.840.113556.1.4.803:". The query itself works fine for ActiveDirectory itself. to make blind test: (userAccountControl:1.2.840.113556.1.4.803:=2) will not get any object back (but should) I'm quite new to OpenLDAP, but it seems an issue. performing upper query gets: Oct 1 00:45:33 nxld01 slapd[3002]: str2filter "(&(sAMAccountType= 805306368)(?=error))" Oct 1 00:45:33 nxld01 kernel: [49436.933735] slapd[3005]: segfault at 18 ip 00007ff4f783d512 sp 00007ff4f1afc810 error 4 in libc-2.23.so[7ff4f77b9000+1c0000] performing the following query (&(objectClass=*)(userAccountControl:1.2.840.113556.1.4.803:=2)) will get following log wntry: Oct 1 00:49:07 nxld01 slapd[3033]: str2filter "(&(objectClass=*)(!(objectClass=*)))" seems a little bit strange BR Steffen

1 0

Re: (ITS#8745) Need to join Windows server 2012 R2 to open lapd as a client
by ryan＠openldap.org 29 Sep '17

29 Sep '17

On Thu, Sep 28, 2017 at 07:11:35AM +0000, ramkumar(a)mgtechsoft.com wrote: >Request you to inform whether can we join windows 2012 server to Open Ldap as >client? > >and if it is possible please share the procedure with us. The ITS system is for reporting software bugs, not for support questions. If you have a question about OpenLDAP, please contact the openldap-technical(a)openldap.org mailing list. In your specific case, it sounds like your question is actually about Samba, not about OpenLDAP. As well, "opeldap.sdef.com" sounds like it might be a typo, so please check your spelling carefully. This ITS will be closed.

1 0

Re: (ITS#8748)
by quanah＠symas.com 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 9:19 PM +0000 rouzier(a)gmail.com wrote: > --94eb2c1913c4df2dad055a59bed1 > Content-Type: text/plain; charset="UTF-8" > > I, James Rouzier, hereby place 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. 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#8748)
by rouzier＠gmail.com 29 Sep '17

29 Sep '17

--94eb2c1913c4df2dad055a59bed1 Content-Type: text/plain; charset="UTF-8" I, James Rouzier, hereby place 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. --94eb2c1913c4df2dad055a59bed1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>I, James Rouzier, hereby place the following mod= ifications to OpenLDAP Software (and only these modifications) into the pub= lic domain. Hence, these modifications may be freely used and/or redistribu= ted for any purpose with or without attribution and/or other notice.</div><= /div><div><br></div></div> --94eb2c1913c4df2dad055a59bed1--

1 0

Re: (ITS#8748) New feature for LMDB
by quanah＠symas.com 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 8:53 PM +0000 rouzier(a)gmail.com wrote: > Full_Name: James Rouzier > Version: N/A > OS: N/A > URL: ftp://ftp.openldap.org/incoming/rouzier-170929.patch > Submission from: (NULL) (192.222.197.109) > > > Add the ability to not block when opening a write transaction for LMDB Hi James, This submission is missing an IPR as per: <http://www.openldap.org/devel/contributing.html#notice> 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#8748) New feature for LMDB
by rouzier＠gmail.com 29 Sep '17

29 Sep '17

Full_Name: James Rouzier Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/rouzier-170929.patch Submission from: (NULL) (192.222.197.109) Add the ability to not block when opening a write transaction for LMDB

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs