openldap-devel June 2015

openldap-devel@openldap.org

8 participants
8 discussions

Fwd: LMDB and text encoding
by Timur Kristóf 07 Jun '17

07 Jun '17

> I just had a look at how BDB handled this. As you can see they used a > TO_TSTRING macro to convert incoming pathnames from UTF8 to UTF16. > > https://gitorious.org/berkeleydb/berkeleydb/source/347d239a1e44ed4f773ae927… > > https://gitorious.org/berkeleydb/berkeleydb/source/347d239a1e44ed4f773ae927… > > (And a FROM_TSTRING for the reverse, as well.) (Mea culpa, I accidentally hit "reply" instead of "reply all". Sorry. Now reposting to the mailing list.) Since we only need to do this on Windows, we could use MultiByteToWideChar with CP_UTF8. (That's what TO_TSTRING does, too.) I do not think we would ever need to do any such conversion on UNIX. https://msdn.microsoft.com/en-us/library/windows/desktop/dd319072%28v=vs.85… I'm not sure if we can just copy-paste BDB's code. Probably not, that would lead to licensing issues, wouldn't it?

4 16

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

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

Infinite loop with "mdb_search: 124xxxx1 scope not okay" while adding an entry
by Benjamin Dauvergne 02 Jun '15

02 Jun '15

Hi, I'm using OpenLDAP debian package from wheezy-backports (version 2.4.31+really2.4.40+dfsg) which is a 2.4.40 but backported I think under another version number to allow the jessie package to execute its migration when upgrade time will come. When trying to initialize a new DB by loading an LDIF file using ldapvi, looking like that: add dc=coin2,dc=fr objectClass: organization objectClass: dcObject objectClass: eduOrg objectClass: supannOrg dc: coin2 o: whatever supannEtablissement: {UAI}ccc add ou=people,dc=coin2,dc=fr objectClass: organizationalUnit ou: people add uid=admin,ou=people,dc=coin2,dc=fr objectClass: inetOrgPerson objectClass: eduPerson objectClass: supannPerson uid: admin cn: Administrateur annuaire displayName: Administrateur annuaire givenName: Administrateur sn: annuaire supannListeRouge: TRUE userPassword: xxxx supannEtablissement: {UAI}COIN It blocks on adding the ou=people. After setting loglever to 255 I got my syslog filled with such messages, soon filling the virtual machine virtual disk: Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 1 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 2 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 3 scope not okay etc... The log of the query finishing like that is: Jun 2 02:34:26 ldap1-psl slapd[12159]: connection_get(15) Jun 2 02:34:26 ldap1-psl slapd[12159]: connection_get(15): got connid=1001 Jun 2 02:34:26 ldap1-psl slapd[12159]: connection_read(15): checking for input on id=1001 Jun 2 02:34:26 ldap1-psl slapd[12159]: op tag 0x68, time 1433205266 Jun 2 02:34:26 ldap1-psl slapd[12159]: conn=1001 op=9 do_add Jun 2 02:34:26 ldap1-psl slapd[12159]: conn=1001 op=9 do_add: dn (ou=people,dc=coin2,dc=fr) Jun 2 02:34:26 ldap1-psl slapd[12159]: >>> dnPrettyNormal: <ou=people,dc=coin2,dc=fr> Jun 2 02:34:26 ldap1-psl slapd[12159]: <<< dnPrettyNormal: <ou=people,dc=coin2,dc=fr>, <ou=people,dc=coin2,dc=fr> Jun 2 02:34:26 ldap1-psl slapd[12159]: ==> unique_add <ou=people,dc=coin2,dc=fr> Jun 2 02:34:26 ldap1-psl slapd[12159]: ==> unique_search (|(objectClass=organizationalUnit)(ou=people)) Jun 2 02:34:26 ldap1-psl slapd[12159]: str2filter "(|(objectClass=organizationalUnit)(ou=people))" Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter Jun 2 02:34:26 ldap1-psl slapd[12159]: OR Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter_list Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter Jun 2 02:34:26 ldap1-psl slapd[12159]: EQUALITY Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter 0 Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter Jun 2 02:34:26 ldap1-psl slapd[12159]: EQUALITY Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter 0 Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter_list Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter 0 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_search Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_dn2entry("dc=coin2,dc=fr") Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_dn2id("dc=coin2,dc=fr") Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_dn2id: got id=0x1 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_entry_decode: Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_entry_decode Jun 2 02:34:26 ldap1-psl slapd[12159]: => access_allowed: search access to "dc=coin2,dc=fr" "entry" requested Jun 2 02:34:26 ldap1-psl slapd[12159]: <= root access granted Jun 2 02:34:26 ldap1-psl slapd[12159]: => access_allowed: search access granted by manage(=mwrscxd) Jun 2 02:34:26 ldap1-psl slapd[12159]: search_candidates: base="dc=coin2,dc=fr" (0x00000001) scope=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates Jun 2 02:34:26 ldap1-psl slapd[12159]: #011OR Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_list_candidates 0xa1 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates Jun 2 02:34:26 ldap1-psl slapd[12159]: #011EQUALITY Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_equality_candidates (objectClass) Jun 2 02:34:26 ldap1-psl slapd[12159]: => key_read Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_idl_fetch_key: [b49d1940] Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_index_read: failed (-30798) Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_equality_candidates: id=0, first=0, last=0 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=0 first=0 last=0 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates Jun 2 02:34:26 ldap1-psl slapd[12159]: #011OR Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_list_candidates 0xa1 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates Jun 2 02:34:26 ldap1-psl slapd[12159]: #011EQUALITY Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_equality_candidates (objectClass) Jun 2 02:34:26 ldap1-psl slapd[12159]: => key_read Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_idl_fetch_key: [9bee355f] Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_index_read: failed (-30798) Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_equality_candidates: id=0, first=0, last=0 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=0 first=0 last=0 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates Jun 2 02:34:26 ldap1-psl slapd[12159]: #011EQUALITY Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_equality_candidates (ou) Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_equality_candidates: (ou) not indexed Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_list_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_list_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 1 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 2 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 3 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 4 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 5 scope not okay etc... I don't know why it's doing a search on an add but seeing the message "(ou) not indexed" I though that maybe adding an equality index on this attribute would help, and effectively it did. Now the add ou=people passed, but it started looping again when adding the uid=admin entry. The infinite loop happen in server/slapd/back-mdb/search.c in mdb_search(). If you have any idea I can continue investigating or add debug logs. The debian package has the following patches applied over openldap 2.4.40: add-tlscacert-option-to-ldap-conf autogroup-makefile contrib-modules-use-dpkg-buildflags do-not-second-guess-sonames evolution-ntlm fix-build-top-mk getaddrinfo-is-threadsafe heimdal-fix index-files-created-as-root ITS6035-olcauthzregex-needs-restart.patch ITS7975-fix-mdb-onelevel-search.patch ITS8027-deref-reject-empty-attr-list.patch ITS8046-fix-vrFilter_free-crash.patch lastbind-makefile ldap-conf-tls-cacertdir ldapi-socket-place libldap-symbol-versions man-slapd no-AM_INIT_AUTOMAKE no-bdb-ABI-second-guessing pw-sha2-makefile sasl-default-path slapi-errorlog-file smbk5pwd-makefile switch-to-lt_dlopenadvise-to-get-RTLD_GLOBAL-set.diff wrong-database-location

1 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel June 2015