openldap-technical May 2017

openldap-technical@openldap.org

45 participants
79 discussions

RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount 25 May '17

25 May '17

This is expected to be the final testing call for 2.4.45, with an anticipated release, depending on feedback, during the week of 2017/05/29. For this testing call, we particularly need folks to test OpenLDAP with startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and with the 1.1 series). There is currenly nothing in the test suite that covers encrypted connections (Although it's on my todo list). To build against OpenSSL 1.1 may also require cyrus-sasl HEAD out of the cyrus-sasl GIT repository, depending on your build options as the current cyrus-sasl release does not support the OpenSSL 1.1 series. It can be found at <https://github.com/cyrusimap/cyrus-sasl>. If you build with GSSAPI and use Heimdal, you will also need the Heimdal 7.1.0 or later release (as that is where OpenSSL 1.1 support was added). It can be obtained from <http://h5l.org/>. Also new with this release is the ability to run "make its" in the tests/ directory. This will run a specific set of tests around past bugs to ensure there are no regressions. While I've tested this with modular openldap builds, it has not been tested with the modules and backends built into slapd, so there could be some issues in that scenario. Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its run through the regression suite. Thanks! OpenLDAP 2.4.45 Engineering Added slapd support for OpenSSL 1.1.0 series (ITS#8353, ITS#8533, ITS#8634) Fixed libldap to fail ldap_result if the handle is already bad (ITS#8585) Fixed libldap to expose error if user specified CA doesn't exist (ITS#8529) Fixed libldap handling of Diffie-Hellman parameters (ITS#7506) Fixed libldap GnuTLS use after free (ITS#8385) Fixed libldap SASL initialization (ITS#8648) Fixed slapd bconfig rDN escape handling (ITS#8574) Fixed slapd segfault with invalid hostname (ITS#8631) Fixed slapd sasl SEGV rebind in same session (ITS#8568) Fixed slapd syncrepl filter handling (ITS#8413) Fixed slapd syncrepl infinite looping mods with delta-sync MMR (ITS#8432) Fixed slapd callback struct so older modules without writewait should function. Custom modules may need to be updated for sc_writewait callback (ITS#8435) Fixed slapd-ldap/meta broken LDAP_TAILQ macro (ITS#8576) Fixed slapd-mdb so it passes ITS6794 regression test (ITS#6794) Fixed slapd-mdb double free with size zero paged result (ITS#8655) Fixed slapd-meta uninitialized diagnostic message (ITS#8442) Fixed slapo-accesslog to honor pauses during purge for cn=config update (ITS#8423) Fixed slapo-accesslog with multiple modifications to the same attribute (ITS#6545) Fixed slapo-relay to correctly initialize sc_writewait (ITS#8428) Fixed slapo-sssvlv double free (ITS#8592) Fixed slapo-unique with empty modifications (ITS#8266) Build Environment Added test065 for proxyauthz (ITS#8571) Fix test008 to be portable (ITS#8414) Fix test064 to wait for slapd to start (ITS#8644) Fix its4336 regression test (ITS#8534) Fix its4337 regression test (ITS#8535) Fix regression tests to execute on all backends (ITS#8539) Contrib Added slapo-autogroup(5) man page (ITS#8569) Added passwd missing conversion scripts for apr1 (ITS#6826) Fixed contrib modules where the writewait callback was not correctly initialized (ITS#8435) Fixed smbk5pwd to build with newer OpenSSL releases (ITS#8525) Documentation admin24 fixed tls_cipher_suite bindconf option (ITS#8099) admin24 fixed typo cn=config to be slapd.d (ITS#8449) admin24 fixed slapo-syncprov information to be curent (ITS#8253) admin24 fixed typo in access control docs (ITS#7341, ITS#8391) admin24 fixed minor typo in tuning guide (ITS#8499) admin24 fixed information about the limits option (ITS#7700) admin24 fixed missing options for syncrepl configuration (ITS#7700) admin24 fixed accesslog documentation to note it should not be replicated (ITS#8344) Fixed ldap.conf(5) missing information on SASL_NOCANON option (ITS#7177) Fixed ldapsearch(1) information on the V[V] flag behavior (ITS#7177, ITS#6339) Fixed slapd-config(5), slapd.conf(5) clarification on interval keyword for refreshAndPersist (ITS#8538) Fixed slapd-config(5), slapd.conf(5) clarify serverID requirements (ITS#8635) Fixed slapd-config(5), slapd.conf(5) clarification on loglevel settings (ITS#8123) Fixed slapo-ppolicy(5) to clearly note rootdn requirement (ITS#8565) Fixed slapo-memberof(5) to note it is not safe to use with replication (ITS#8613) Fixed slapo-syncprov(5) documentation to be current (ITS#8253) Fixed slapadd(8) manpage to note slapd-mdb (ITS#8215) Fixed various minor grammar issues in the man pages (ITS#8544) Fixed various typos (ITS#8587) LMDB 0.9.20 Release Engineering Fix mdb_load with escaped plaintext (ITS#8558) Fix mdb_cursor_last / mdb_put interaction (ITS#8557) Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Search for primary group
by Bernard Fay 23 May '17

23 May '17

Hello, Is there a way to find the primary group of a user with ldapsesarch or other command? I run OpenLDAP version 2.4.40 on CentOS 7.2 if that matters. Thanks, Bernard

2 1

Re: mdb_dbi_open and threads
by Howard Chu 22 May '17

22 May '17

Muhammed Muneer wrote: > Hallvard wrote > "With threads 1 and 2 coexisting? When thread 2 called mdb_dbi_open(), > thread 1's prospect of using mdb_dbi_open() at all was lost." > > Yeah with both coexisting. Thats what I thought. > > @Klaus > > > Yeah. I know there can be only one write transactions. I was talking about 1 > write and 1 or more read transactions. > It is not as if I am first looking to open dbi in the read transaction. It is > because I can't guarantee whether another read transaction will > start and will attempt to open the same named dbi when a write is in progress. > > "And first looking in a read transaction whether a database exists and then > creating it in a second write transaction is definitely a bad and risky > programming style, as it carries an assumption from one transaction to the > next, which is typically not valid." > > That was not what I tried to do. > > "you still have the option to combine all your logical databases into a big > single database" > > Its a workaround that I haven't thought about before. Hoping to avoid the > extra complexity. > > Is there any prospect of implementing mdb_dbi_open or mdb_db_open_immediate to > put the dbi into the shared environment without waiting for txn commit. > I learned earlier from Howard Chu that it is not a wanted phenomenon in ACID. > But just in case, because otherwise (without opening all the dbi's in > initialization) in a multi-threaded > environment, the possibility to open a dbi on demand ending in failure goes up. No. Transaction isolation is a fundamental feature, breaking isolation is not allowed. If you want to use dbi_open in multiple threads then put it in your own wrapper function, protected by a mutex. Naturally you will also have to wrap dbi_close the same way. Note that even if you open and close on demand, you're going to have to configure maxdbs to the largest number that can possibly be open at once so there won't be much memory savings. All in all it's a stupid approach with more costs than benefits. -- -- 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 1

Re: mdb_dbi_open and threads
by Howard Chu 22 May '17

22 May '17

Muhammed Muneer wrote: > Thanks for clarifying. > I did get the impression but there was some part of it where I thought the doc > was not clear enough. It is a fundamental principle of ACID transactions. The "I" in ACID stands for Isolation. That means nothing that changes elsewhere, while a transaction is underway, can affect that particular transaction. Since we already document that LMDB is a full ACID DB engine, none of this should require any further explanation. > Thanks anyway. > > On Sat, May 20, 2017 at 10:46 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > Muhammed Muneer wrote: > > Is the following valid. > > 1) Read transaction 1 is started > 2) Read transaction 2 is started and calls mdb_dbi_open and commits > 3) Read transaction 1 uses the handle from (2) > > > Please learn how to read. The doc says more than you quoted before, and it > already quite explicitly defines its properties: > > http://www.lmdb.tech/doc/group__internal.html#gac08cad5b096925642ca359a6d6f… > <http://www.lmdb.tech/doc/group__internal.html#gac08cad5b096925642ca359a6d6f…> > > The database handle will be private to the current transaction > until the transaction is successfully committed. If the transaction is > aborted the handle will be closed automatically. After a successful commit > the handle will reside in the shared environment, and may be used by other > transactions. > > In your question above, transaction 1 is not after transaction 2 therefore > it cannot use the handle that transaction 2 commits. > > The handle does not exist in the shared environment until after its > opening transaction commits. If it doesn't exist in the shared environment > when a transaction begins, then it is not visible or valid in that > particular transaction. > > Just follow the recommendation to open all handles at the beginning of the > program. > > > > On Sat, May 20, 2017 at 6:46 PM, Muhammed Muneer <elendilm(a)gmail.com > <mailto:elendilm@gmail.com> > <mailto:elendilm@gmail.com <mailto:elendilm@gmail.com>>> wrote: > > Thanks. > > On Sat, May 20, 2017 at 6:29 PM, Klaus Malorny > <Klaus.Malorny(a)knipp.de <mailto:Klaus.Malorny@knipp.de> > <mailto:Klaus.Malorny@knipp.de <mailto:Klaus.Malorny@knipp.de>>> > wrote: > > On 5/20/17 2:02 PM, Muhammed Muneer wrote: > > So when the doc says > > * The database handle will be private to the current > transaction until > * the transaction is successfully committed. > > "the handle being private" only refers to the first > mdb_dbi_open. > Once this transaction is committed, one doesn't have to > call this > again in subsequent concurrent transactions and can use > this handle. > And then this handle won't be private at all. > > Did I get it right? > > > Yes. I do this exactly that way as part of my initial setup of my > application. Once the transaction is committed, I use the returned > handles setup from whatever thread that needs to access the > respective > database. I never call mdb_dbi_open again after the setup. > > Regards, > > Klaus > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 6

Seach Object
by Bruno de Oliveira Bastos 21 May '17

21 May '17

Someone know how to search a object DN and return a CN ? I have this object DN ( Q049c3Vwb3J0ZTNkYiBzdXBvcnRlIGRhIDNkYixPVT1Vc3XDoXJpb3MsREM9Y2hlc3BhZ ) and i need the CN of object.

2 1

Re: mdb_dbi_open and threads
by Howard Chu 20 May '17

20 May '17

Muhammed Muneer wrote: > Is the following valid. > > 1) Read transaction 1 is started > 2) Read transaction 2 is started and calls mdb_dbi_open and commits > 3) Read transaction 1 uses the handle from (2) Please learn how to read. The doc says more than you quoted before, and it already quite explicitly defines its properties: http://www.lmdb.tech/doc/group__internal.html#gac08cad5b096925642ca359a6d6f… The database handle will be private to the current transaction until the transaction is successfully committed. If the transaction is aborted the handle will be closed automatically. After a successful commit the handle will reside in the shared environment, and may be used by other transactions. In your question above, transaction 1 is not after transaction 2 therefore it cannot use the handle that transaction 2 commits. The handle does not exist in the shared environment until after its opening transaction commits. If it doesn't exist in the shared environment when a transaction begins, then it is not visible or valid in that particular transaction. Just follow the recommendation to open all handles at the beginning of the program. > > > On Sat, May 20, 2017 at 6:46 PM, Muhammed Muneer <elendilm(a)gmail.com > <mailto:elendilm@gmail.com>> wrote: > > Thanks. > > On Sat, May 20, 2017 at 6:29 PM, Klaus Malorny <Klaus.Malorny(a)knipp.de > <mailto:Klaus.Malorny@knipp.de>> wrote: > > On 5/20/17 2:02 PM, Muhammed Muneer wrote: > > So when the doc says > > * The database handle will be private to the current > transaction until > * the transaction is successfully committed. > > "the handle being private" only refers to the first mdb_dbi_open. > Once this transaction is committed, one doesn't have to call this > again in subsequent concurrent transactions and can use this handle. > And then this handle won't be private at all. > > Did I get it right? > > > Yes. I do this exactly that way as part of my initial setup of my > application. Once the transaction is committed, I use the returned > handles setup from whatever thread that needs to access the respective > database. I never call mdb_dbi_open again after the setup. > > Regards, > > Klaus > > > -- -- 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 1

mdb_dbi_open and threads
by Muhammed Muneer 20 May '17

20 May '17

Hi, I have been using LMDB for over a year now. It has been a wonderful experience. A great thank you for the wonderful work that you guys have done. Till now I have used it on the main thread. And for the info, I only make use of LMDB named dbi. I was trying to make it work in threads. Reading the docs on mdb_dbi_open got me confused. The doc says " * The database handle will be private to the current transaction until * the transaction is successfully committed. " and " * This function must not be called from multiple concurrent * transactions in the same process. A transaction that uses * this function must finish (either commit or abort) before * any other transaction in the process may use this function. " I use MDB_NOTLS. Does the doc mean I can't simultaneously read the same named dbi from multiple threads because I have to wait for readers in other threads to commit before starting a read of the same named dbi?

3 5

Re: ACL to authenticate gitlab users
by Quanah Gibson-Mount 19 May '17

19 May '17

--On Sunday, May 07, 2017 5:49 PM +0200 Xaar <xaar(a)linux.pl> wrote: > Hello, > > I want to authenticate users via OpenLDAP to Gitlab. In Gitlab > configuration there is a gitlab.rb file, where I can write some special > user (let it be gitlabuser) with credentials who will be bind to ldap > server. Now my question is, what acl should I provide to this user on > OpenLDAP server to allow other users authenticate to Gitlab ? > > Now my DIT looks like this: > > dc=company,dc=com >| >| > - cn=admin > - cn=gitlabuser >| >| > - ou=Groups > - ou=Users -> here are users which I want to give access to Gitlab > > Is this entry is fair enough ? > > dn: olcDatabase={1}hdb,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0} to attrs=userPassword by anonymous auth by > dn=„cn=admin,dc=company,dc=com" write by * none olcAccess: {1} to > dn.base=„" by * read > olcAccess: {2} to * by * read It would allow anyone (anonymous or authenticated) to read all your entries, minus the userPassword attribute. Depending on your security requirements, this may or may not be desirable. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ldapcompare vs ldapsearch
by Roger Szabo 19 May '17

19 May '17

Hi, The goal is to perform frequent periodic calls to check the health of OpenLDAP using anonymous bind. Someone at http://stackoverflow.com/questions/16077473/ldap-bind-vs-search suggested that a ldapcompare would perform better than a ldapsearch because "there is only a single response per entry (a compare result) rather than two (a search result entry and a search result done)". This explanation makes sense but it would be really great to hear the opinion of an expert on this, thank you very much :)

4 4

Re: ldapcompare vs ldapsearch
by Roger Szabo 19 May '17

19 May '17

2017-05-17 23:14 GMT+08:00 Aaron Richton <richton(a)nbcs.rutgers.edu>: > On Wed, 17 May 2017, Roger Szabo wrote: > > The goal is to perform frequent periodic calls to check the health of >> OpenLDAP using anonymous bind. >> >> Someone at http://stackoverflow.com/questions/16077473/ldap-bind- >> vs-search suggested that a ldapcompare would perform better than a >> ldapsearch because "there is only a single response per entry (a compare >> result) rather than two (a search result entry and a search result done)". >> >> This explanation makes sense but it would be really great to hear the >> opinion of an expert on this, thank you very much :) >> > > Overall, seems a bit oversimplified. I suppose the common case compare > would typically be cheaper than a search, but you could just as easily be > comparing against some dynamic membership where the matching is expensive, > potentially invoking multiple internal searches (there goes your savings). > On the other hand, if the search requires access to unindexed data, maybe > the search is more expensive. If the result set is large, maybe the search > is more expensive even if it is indexed! > > Yeah, to offer a more precise example: ldapcompare -x -H ldaps://xxxxxx:xxx "o=test" "o:test" This method simply checks whether the attribute "o" of the DIT's root element "o=test" actually contains the value "test". For this example it looks like there would theoretically be no ldapsearch on the same root element that would perform equally or even better, wouldn't it? > But you're talking about health, so the entire conversation may need to be > reframed. There's nothing in the RFC that says you have to search nor > compare. You could do something definitely in-core, i.e. ldapwhoami(1) ... > or a simple "can I speak the protocol properly?" could be connect, BIND, > UNBIND, close. > > Yeah, but would a bind (even without being configured to auto-write last login time etc.) perform better than an anonymous ldapsearch like the example above? > > As with most things, you'd have to think through your precise cases and > plan accordingly. If you're only concerned with general health of slapd(8), > a back-null or back-monitor would both be fairly cheap (back-null literally > being as cheap as it gets). But it IS possible to have backend(s) fail > while the slapd(8) frontend remains operational, so monitoring of > individual backends may be warranted too. (This is my practice -- each > backend gets an indexed monitoring search, with a search congruent with the > common use case for each backend.) > > If I'm not mistaken, with the ldapcompare example above, supposedly the backend's health is checked as well. I would be really interested though in the monitoring search you mentioned, maybe it would be possible to provide an anonymised example? > > > The counterargument to all of this, across any network service, is "if > your monitoring strains your capacity limits you're probably running too > hot anyway." Hehe, absolutely, looks like this could actually summarize the result of this discussion :D

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical May 2017