openldap-devel

openldap-devel@openldap.org

1418 discussions

X509_V_FLAG_PARTIAL_CHAIN support in OpenLDAP
by Doug Leavitt 07 Jul '15

07 Jul '15

Hi, OpenSSL now has X509_V_FLAG_PARTIAL_CHAIN support in the code base as of 1.0.2a. I would like to submit a patch to enable X509_V_FLAG_PARTIAL_CHAIN support in OpenLDAP libldap, assuming it exists in the version of OpenSSL being use to build OpenLDAP. Before I submit any patch I would like to know that would be acceptable for integration. Should support always be enabled if the version of OpenSSL has it e.g. ifdef on X509_V_FLAG_PARTIAL_CHAIN Should it be a config time option check and ifdef enable if found in e.g. like the ifdef on HAVE_OPENSSL_CRL Are there more requirements that is required in the patch, before it would be accepted such as ldap_set_option support? Thanks in advance, Doug.

3 5

libdb detection with gcc 5.1.1
by Michael Ströder 06 Jul '15

06 Jul '15

HI! This seems to be already fixed: ITS#8056: libdb detection with gcc 5 But gcc-5.1.1 arrived on openSUSE Tumbleweed and now libdb detection fails: checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking for Berkeley DB major version in db.h... none configure: error: Unknown Berkeley DB major version in db.h From config.log: configure:20300: checking db.h usability configure:20300: cc -c -g -O0 -DSLAP_SCHEMA_EXPOSE -DLDAP_COLLECTIVE_ATTRIBUTES -DSLAP_CONFIG_DELETE -I/usr/include -I/usr/include -I/usr/include -I/usr/include conftest.c >&5 configure:20300: $? = 0 configure:20300: result: yes configure:20300: checking db.h presence configure:20300: cc -E -I/usr/include -I/usr/include -I/usr/include -I/usr/include conftest.c configure:20300: $? = 0 configure:20300: result: yes configure:20300: checking for db.h configure:20300: result: yes configure:20311: checking for Berkeley DB major version in db.h configure:20331: result: none configure:20334: error: Unknown Berkeley DB major version in db.h Any clue? Ciao, Michael.

3 5

Use of gethostbyaddr_r on openSUSE
by Michael Ströder 02 Jul '15

02 Jul '15

HI! I'm still fighting with building newer OpenLDAP RPMs for openSUSE. Originally Ralf Haferkamp generated the .spec files several years ago but is not involved anymore. He added this patch: https://build.opensuse.org/package/view_file/home:stroeder:branches:network… This patch seems to fail now (see below). I'm inclined to remove it but I wonder whether it might be still needed/useful today. Ciao, Michael. ------------------------ snip ------------------------ [ 85s] configure:20167: cc -c -Wno-format-extra-args -fno-strict-aliasing -DSLAP_CONFIG_DELETE -DSLAP_SCHEMA_EXPOSE -DLDAP_COLLECTIVE_ATTRIBUTES conftest.c >&5 [ 85s] configure:20167: $? = 0 [ 85s] configure:20189: result: 6 [ 85s] configure:20204: checking number of arguments of gethostbyaddr_r [ 85s] configure:20229: cc -c -Wno-format-extra-args -fno-strict-aliasing -DSLAP_CONFIG_DELETE -DSLAP_SCHEMA_EXPOSE -DLDAP_COLLECTIVE_ATTRIBUTES conftest.c >&5 [ 85s] conftest.c: In function 'main': [ 85s] conftest.c:139:43: warning: passing argument 7 of 'gethostbyaddr_r' from incompatible pointer type [-Wincompatible-pointer-types] [ 85s] alen, AF_INET, &hent, buffer, bufsize, &h_errno); [ 85s] ^ [ 85s] In file included from conftest.c:129:0: [ 85s] /usr/include/netdb.h:172:12: note: expected 'struct hostent ** restrict' but argument is of type 'int *' [ 85s] extern int gethostbyaddr_r (const void *__restrict __addr, __socklen_t __len, [ 85s] ^ [ 85s] conftest.c:138:9: error: too few arguments to function 'gethostbyaddr_r' [ 85s] (void)gethostbyaddr_r( (void *)&(add.s_addr), [ 85s] ^ [ 85s] In file included from conftest.c:129:0: [ 85s] /usr/include/netdb.h:172:12: note: declared here [ 85s] extern int gethostbyaddr_r (const void *__restrict __addr, __socklen_t __len, [ 85s] ^ [ 85s] configure:20229: $? = 1 [ 85s] configure: failed program was: [ 85s] | /* confdefs.h */

2 2

Re: OpenLDAP 2.4.41 available
by Clément OUDOT 02 Jul '15

02 Jul '15

Hi, congratulations for the release! It seems the changelog has not been updated on this page: http://www.openldap.org/software/release/changes.html Clément. 2015-07-01 22:11 GMT+02:00 OpenLDAP Project <project(a)openldap.org>: > OpenLDAP 2.4.41 is now available for download as detailed on our download > page: > > http://www.openldap.org/software/download/ > > and should soon be available on all official mirrors: > > ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS > > This is a maintenance release and is made available for general use. Users > of OpenLDAP Software are encouraged to upgrade. > > > Significant contributors are: > > Howard Chu (Symas Corp) > Hallvard Furuseth (University of Oslo) > Quanah Gibson-Mount (Zimbra, Inc) > Ryan Tandy > > > OpenLDAP 2.4.41 Release (2015/06/21) > Fixed ldapsearch to explicitly flush its buffer (ITS#8118) > Fixed libldap async connections (ITS#8090) > Fixed libldap double free of request during abandon (ITS#7967) > Fixed libldap error string for LDAP_X_CONNECTING (ITS#8093) > Fixed libldap segfault in ldap_sync_initialize (ITS#8001) > Fixed libldap ldif-wrap off by one error (ITS#8003) > Fixed libldap handling of TLS in async mode (ITS#8022) > Fixed libldap null pointer dereference (ITS#8028) > Fixed libldap mutex handling with LDAP_OPT_SESSION_REFCNT (ITS#8050) > Fixed slapd slapadd config db import of minimal frontend entry > (ITS#8150) > Fixed slapd slapadd onetime leak with -w (ITS#8014) > Fixed slapd sasl auxprop crash with invalid config (ITS#8092) > Fixed slapd syncrepl delta-mmr issue with overlays and slapd.conf > (ITS#7976) > Fixed slapd syncrepl mutex for cookie state (ITS#7968) > Fixed slapd syncrepl memory leaks (ITS#8035) > Fixed slapd syncrepl to free presentlist at end of refresh mode > (ITS#8038) > Fixed slapd syncrepl to streamline presentlist (ITS#8042) > Fixed slapd syncrepl concurrency when CHECK_CSN is enabled (ITS#8120) > Fixed slapd rootdn checks for hidden backends (ITS#8108) > Fixed slapd segfault when using matched values control (ITS#8046) > Fixed slapd-ldap reconnection behavior on remote failure (ITS#8142) > Fixed slapd-mdb minor case typo (ITS#8049) > Fixed slapd-mdb one-level search (ITS#7975) > Fixed slapd-mdb heap corruption (ITS#7965) > Fixed slapd-mdb crash after deleting in-use schema (ITS#7995) > Fixed slapd-mdb minor code cleanup (ITS#8011) > Fixed slapd-mdb to return errors when using incorrect env flags > (ITS#8016) > Fixed slapd-mdb to correctly update search candidates (ITS#8036, > ITS#7904) > Fixed slapd-mdb when there were more than 65535 aliases in scope > (ITS#8103) > Fixed slapd-mdb alias deref when objectClass is not indexed > (ITS#8146) > Fixed slapd-meta TLS initialization with ldaps URIs (ITS#8022) > Fixed slapd-meta to have better error logging (ITS#8131) > Fixed slapd-perl conversion to cn=config (ITS#8105) > Fixed slapd-sql autocommit config variable (ITS#8129,ITS#6613) > Fixed slapo-collect segfault (ITS#7797) > Fixed slapo-constraint with 0 count constraint (ITS#7780,ITS#7781) > Fixed slapo-deref with empty attribute list (ITS#8027) > Fixed slapo-memberof to correctly reject invalid members (ITS#8107) > Fixed slapo-sock result parser for CONTINUE (ITS#8048) > Fixed slapo-syncprov synprov_matchops usage of test_filter (ITS#8013) > Fixed slapo-syncprov segfault on disconnect/abandon > (ITS#5452,ITS#8012) > Fixed slapo-syncprov memory leak (ITS#8039) > Fixed slapo-syncprov segfault on disconnect/abandon (ITS#8043) > Fixed slapo-syncprov deadlock when autogroup is in use (ITS#8063) > Fixed slapo-syncprov potential loss of changes when under load > (ITS#8081) > Fixed slapo-unique enforcement of uniqueness with manageDSAit control > (ITS#8057) > Build Environment > Fixed libdb detection with gcc 5.x (ITS#8056) > Fixed ftello reference for Win32 (ITS#8127) > Enhanced contrib modules build paths (ITS#7782) > Fixed contrib/autogroup internal operation identity > (ITS#8006) > Fixed contrib/autogroup to skip internal ops with accesslog > (ITS#8065) > Fixed contrib/passwd/sha2 compiler warning (ITS#8000) > Fixed contrib/noopsrch compiler warning (ITS#7998) > Fixed contrib/dupent compiler warnings (ITS#7997) > Test suite: Added vrFilter test (ITS#8046) > Contrib > Added pbkdf2 sha256 and sha512 schemes (ITS#7977) > Fixed autogroup modification callback responses (ITS#6970) > Fixed nssov compare with usergroup (ITS#8079) > Fixed nssov password change behavior (ITS#8080) > Fixed nssov updated to 0.9.4 (ITS#8097) > Documentation > Added ldap_get_option(3) LDAP_FEATURE_INFO_VERSION > information (ITS#8032) > Added ldap_get_option(3) LDAP_OPT_API_INFO_VERSION > information (ITS#8032) > Fixed slapd-config(5), slapd.conf(5) tls_cipher_suite option > (ITS#8099) > Fixed slapd-meta(5), slapd-ldap(5) tls_cipher_suite option > (ITS#8099) > Fixed slapd-meta(5) fix minor typo (ITS#7769) > > > MD5 (openldap-2.4.41.tgz) = 3f1a4cea52827e18feaedfdc1634b5d0 > SHA1 (openldap-2.4.41.tgz) = c6880df9fec928a5f010b78a4285b497e8a12d6b > >

2 2

unbind requests to all backends?
by Michael Ströder 01 Jul '15

01 Jul '15

HI! Are unbind requests always propagated to all backends? Ciao, Michael.

2 1

back-sock: Format of RESULT
by Michael Ströder 27 Jun '15

27 Jun '15

HI! I'm really confused by this part of slapd-sock(5): ----------------------------- snip ----------------------------- If the overlay is configured to send response messages to the external program, they will appear as an extended RESULT message or as an ENTRY message, defined below. The RESULT message is similar to the one above, but also includes the msgid and any configured extensions: RESULT msgid: <message id> code: <integer> matched: <matched DN> info: <text> <blank line> Typically both the msgid and the connid will be needed to match a result message to a request. The ENTRY message has the form ENTRY msgid: <message id> <entry in LDIF format> <blank line> ----------------------------- snip ----------------------------- Especially the wording "both the msgid and the connid will be needed" seems logical to me but does not match any format description in the man-page. I'd also appreciate if the back-sock protocol would be more robust: Why not require connid and msgid consistently in *every* operation sock request and result sock request and *all* responses returned by the external listener even in CONTINUE? Ciao, Michael.

1 0

enhancements for back-sock, especially MONITOR
by Michael Ströder 26 Jun '15

26 Jun '15

HI! I'm currently working on implementing a generic back-sock listener in Python and two special instances of it. Mainly the current use-case is overlay usage intercepting bind requests. Of course I'd like to monitor the back-sock listeners (internal state like counters etc.), probably via LDAP ideally with access control enforced by slapd itself. Accessing the monitoring data could be done via search operations but I'd like to avoid mandating a generic "sockops search" overlay configuration just for monitoring data because every search request would be passed to the external listener even though the listener does not handle them (except for the monitoring data). I could add additional backends with own suffixes pointing to the same back-sock listener. But having two or three separate listeners would require configuring the same number of database sections. Also having to implement to much access control in the database listeners is also not ideal. It would be really nice if requests going to a back-sock listener configured as overlay could be pre-filtered by slapd configuration. Something like sockops search ldap:///cn=sock-listener-monitor,dc=example,dc=com??base?(objectClass=monitorSubEntry) Would pass the search request only to the external listener of the search operation matches all parameters in the given LDAP URL. This would be also handy for other operations. What do you think? Ciao, Michael. P.S.: These ITS would also improve back-sock (overlay) usage: (ITS#8172) RFE: back-sock CONTINUE to get modified parameters (ITS#8177) RFE: back-sock to receive controls (ITS#8178) back-sock: Timeout to avoid locking

1 0

Update/drop cruft: LDAP_DEPRECATED, CLDAP, C version
by Hallvard Breien Furuseth 21 Jun '15

21 Jun '15

Some wishes for RE25: Expose most LDAP_DEPRECATED functions again. This code is not going away, or it'd be gone by now after 16 years of deprecation. I usually #define LDAP_DEPRECATED anyway. What's the point of trying to make me pass 2 extra NULL args to a bunch of functions? And making a "SASL bind" function the proper way to do Simple Bind is silly and confusing. OTOH some depreciation make sense, like ldap_get_values() which returns char** instead of berval**. Add --enable-cldap as "experimental". Add tests and some fixes. The CLDAP code isn't going away either, so i seems better to support it properly. People are submitting libldap ITSes, but slapd and ldapsearch usage remain broken. slapd looks easy to fix, ldapsearch depends on vestiges of libldap code to ignore Bind requests. Dunno if I want to bother tracking that down in libldap or just omit the Bind in ldapsearch. Maybe RedHat has a fix. ...or do the opposite, kill LDAP_DEPRECATED and CLDAP. I hope not, but that's better than eternally deprecated/code-rotting features. Kill K&R1 support, i.e. the LDAP_P(()) stuff. Supposedly the headers support K&R1, but OpenLDAP-2.0 broke this (ITS#6171). Nobody has cared enough to fix it, and I refuse to fix it. See if we can require C99 to build OpenLDAP, but keep the headers C90-compliant. In particular, replace Debug() with a varargs macro, initially without changing the calls to Debug(). If we get away with that, we can kill the extra ,0,0,0 arguments to Debug() later so gcc -Wformat will catch missing/spurious args. -- Hallvard

3 4

slapd-sock: extensions always UTF-8
by Michael Ströder 19 Jun '15

19 Jun '15

HI! Are these extensions guaranteed to be always sent by back-sock as raw UTF-8 in one line? Or does the listener also has to handle base64 encoding and line-folding like in LDIF for these extension lines? binddn: <bound DN> peername: IP=<address>:<port> ssf: <SSF value> connid: <connection ID> Ciao, Michael.

1 0

Relaxed mode for delta-sync MMR
by Quanah Gibson-Mount 10 Jun '15

10 Jun '15

After having deployed delta-sync MMR at several customer sites, the general handling of conflict resolution in MMR mode is significantly sub optimal, and routinely causes the MMR nodes to get further out of sync, worsening things significantly (Mainly due to ITS#8125). The main issues I see are the following: a) Two masters get different change requests at approximately the same time to add a value X to an attribute. b) Two masters get different change requests at approximately the same time to delete a value X from an attribute. In these two specific cases, in relaxed mode, rather than falling back and re-syncing the entire database, I think the conflict should be discarded (skipped), and logged as such. I.e., there is no actual discrepancy in the object. It still has X present in the add case, and X gone in the delete case. At best, if we're going to do fallback, then we should only see about resyncing the specific entry. The overall behavior I'm seeing from OpenLDAP is the masters get in an endless cycle of re-sync, and the more they do so, the more out of sync they become, leading to a point at which you have to stop all masters, export all their DBs, sort them, find missing entries between all sets of masters, and build a brand new DB with which to reload them, until they get massively out of sync again. I.e., the current strategy of resync is doing no favors to anyone. It may work OK on very small DBs, where a resync only takes seconds, but on larger dbs were such syncs take 30+ minutes to hours, it is not a useful methodology. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

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-devel