openldap-devel

openldap-devel@openldap.org

1416 discussions

Re: openldap.git branch symas-2.4 created. OPENLDAP_REL_ENG_2_4_42-184-g6bf99c4
by Howard Chu 03 Oct '15

03 Oct '15

openldap-commit2devel(a)OpenLDAP.org wrote: > A ref change was pushed to the OpenLDAP (openldap.git) repository. > It will be available in the public mirror shortly. > > The branch, symas-2.4 has been created > at 6bf99c4e0eadddfa1a9592f0e4bf76df974fa339 (commit) Oops. Pushed to wrong repo. I've deleted this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

str2result() and slapd-sock
by Michael Ströder 24 Sep '15

24 Sep '15

HI! I'm trying to find out why slapd-socks always outputs all lines returned by the external sock listeners with comment "unknown" although everything seems to work correctly. ----------------------------- snip ----------------------------- 5603fc08 conn=1000 op=1 BIND dn="uid=äöüÄÖÜß,ou=realdb,dc=example,dc=org" method=128 5603fc08 str2result (msgid: 2 code: 49 matched: uid=äöüÄÖÜß,ou=realdb,dc=example,dc=org info: You loose! (wrong password) ) unknown 5603fc08 str2result ( ) unknown 5603fc08 conn=1000 op=1 RESULT tag=97 err=49 text= You loose! (wrong password) ----------------------------- snip ----------------------------- The (correct) Python string returned by the listener was: 'RESULT\nmsgid: 2\ncode: 49\nmatched: uid=\xc3\xa4\xc3\xb6\xc3\xbc\xc3\x84\xc3\x96\xc3\x9c\xc3\x9f,ou=realdb,dc=example,dc=org\ninfo: You loose! (wrong password)\n\n' I tried to understand what's going on in str2result() (in file servers/slapd/result.c) but failed. AFAICS in slapd-sock(5) the external listener should always return a line with "code: <digit>" after the "RESULT" line. But to me it seems that the function would return with rc=0 if there's only a single "RESULT" line (due to break in line 1674). And I also can't see why the else clause in 1727 is reached. I wonder whether slapd-sock is confused by the two trailing line feeds. Ciao, Michael.

1 2

Big leaf nodes in LMDBv2
by Hallvard Breien Furuseth 24 Sep '15

24 Sep '15

LMDBv1 supports 1-node leaf pages so it can split a 2-node leaf to make room for a 3rd node. (ITS#8237). LMDBv2 could extend this, to use fewer pages: Allow oversized leaf nodes. mdb_cursor_put() won't create ovpages directly, but call page_split() which instead of splitting may kick an oversized node and/or the new node out to an ovpage. Usually only the biggest of the two. To assist page_split(), give such leaf pages a flag P_HAS_BIGNODE and set mp_pad = size of the biggest oversized node. That gets a bit simpler if we allow only 1 oversized node per leaf. The inverse fix is "a page has room for 3 nodes". This reduces me_nodemax from 2038 1358, max supported MDB_MAXKEYSIZE from 1982 to 1302, and uses more ovpages. Add mdb_env_set_pagesize() so LMDBv2 with bigger pages can reload an LMDBv1 DB with big keys. Hallvard

1 0

commit "ITS#8226 limit size of read txns in searches" has a bug
by Леонид Юрьев 31 Aug '15

31 Aug '15

Hi, Howard. wwctx.txn may be uninitialized, see lines 712-720 of back-mdb/search.c http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl… And therefore mdb_rtxn_snap() may segfault when will called from line 1127. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl… I think, one of the following should be: - wwctx should be initialize completely at 712; or - an additional condition should be checked at 1123-1125. Regards, Leonid.

2 1

Dynamic groups, autogroup
by Howard Chu 25 Aug '15

25 Aug '15

For the record - I've never liked the autogroup overlay. It's a fairly brute-force solution to what should be dynamic groups, making them into static ones. The limitation in dyngroup/dynlist about being unable to match member=foo filters is annoying, of course. But having worked thru a similar problem in the contrib/adremap overlay, the solution now is obvious - just use an additional search request, to find all of the dynamic groups in the scope (autogroup already does this once, at startup time) and then feed the filter attribute to each, one by one, doing the same evaluation that dyngroup's Compare handler already does. For sites with very large groups, dynamic groups are generally the right approach, for size/efficiency reasons. autogroup throws away any efficiency gains, but we can get them back. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

RE24 testing call #1 (2.4.42) LMDB RE0.9 testing call #1 (0.9.16)
by Quanah Gibson-Mount 11 Aug '15

11 Aug '15

OpenLDAP 2.4.42 Engineering Fixed liblber address length for CLDAP (ITS#8158) Fixed libldap dnssrv potential overflow with port number (ITS#7027,ITS#8195) Fixed slapd cn=config when updating olcAttributeTypes (ITS#8199) Fixed slapd-mdb to correctly update search candidates for scoped searches (ITS#8203) Fixed slapo-ppolicy with redundant mod ops on glued trees (ITS#8184) Build Environment Fixed libdb detection with gcc 5.x (ITS#8056) LMDB 0.9.16 Release Engineering Fix cursor EOF bug (ITS#8190) Fix handling of subDB records (ITS#8181) Fix mdb_midl_shrink() usage (ITS#8200) This release is primarly addressing crash related problems and to fix the configure script for gcc 5.x. Thanks! --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

5 11

warnings with gcc 5.1.1
by Michael Ströder 30 Jul '15

30 Jul '15

HI! When building OpenLDAP's contrib overlays gcc outputs lots of warnings. Are you interested in getting an ITS for that or not? Ciao, Michael.

1 0

Re: openldap.git branch master updated. b7a291a488dff3902931559670cf94c7abe2655b
by Howard Chu 24 Jul '15

24 Jul '15

openldap-commit2devel(a)OpenLDAP.org wrote: > A ref change was pushed to the OpenLDAP (openldap.git) repository. > It will be available in the public mirror shortly. > > The branch, master has been updated > via b7a291a488dff3902931559670cf94c7abe2655b (commit) > from 1ab08d2f8e4c9baf71e3c146e95d013d7b8bd656 (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log ----------------------------------------------------------------- > commit b7a291a488dff3902931559670cf94c7abe2655b > Author: Howard Chu <hyc(a)openldap.org> > Date: Wed Jul 8 14:22:29 2015 +0100 > > Experimental syslog() replacement > > 2-3x faster than libc. Add it to the Makefile yourself if you want to test it. > > ----------------------------------------------------------------------- > > Summary of changes: > servers/slapd/overlays/syncprov.c | 3 +- Oops. Ignore the above, reverted already. > servers/slapd/syslog.c | 329 +++++++++++++++++++++++++++++++++++++ The most obvious braindeadedness in glibc syslog() is that it acquires a mutex before writing to the log socket. This is utterly inane; the log socket is datagram-based and as such all writes to it are already atomic and need no mutex protection. The other big problem is that the function that generates the log timestamp also acquires 2 mutexes. I avoid all that crap too by writing my own implementation of localtime(). This overhead can be reduced further still by simply omitting the timestamp - it turns out that modern syslogds (rsyslog, syslog-ng) actually ignore the timestamp in the message and generate their own anyway. (Note that this localtime implementation is broken wrt DST.) There are a few other areas to explore here, including a log socket per thread, which would improve throughput even more in heavy workloads. These things can be explored without major overhauls of existing code. For greater throughput we need a logging mechanism that doesn't rely on sprintf. I.e., we should consider a binary log format where we simply pass around short message IDs (and relevant message parameters) and use a compiled message catalog that maps IDs to text. This would require a post-processor to read the binary log and generate human-readable messages somewhere else. (It's obviously not a new concept, IBM mainframes have done this for decades; the Microsoft system logger does this as well.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 2

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel