openldap-technical July 2017

openldap-technical@openldap.org

29 participants
73 discussions

olcGlobal vs. olcFrontendConfig
by Michael Ströder 12 Jul '17

12 Jul '17

HI! I have to admit that when writing a static slapd.conf I do not make any distinction regarding global config section and frontend config section. So I wonder which criteria are applied to determine whether a parameter is put into cn=config (olcGlobal) or olcDatabase={-1}frontend (olcFrontendConfig) when converting slapd.conf to dynamic config. Looking at a concrete configuration it does not make sense to me to put attribute olcPasswordHash into olcDatabase={-1}frontend while putting olcPasswordCryptSaltFormat into cn=config. There could even be conflicting values in both entries. Background: I'd like to determine which password hash scheme and salt format is configured by searching in back-config. Ciao, Michael.

1 0

Re: Query on ldap sasl bind
by Quanah Gibson-Mount 11 Jul '17

11 Jul '17

--On Tuesday, July 11, 2017 9:13 PM +0530 Nishanth Nagendra <nishanth.amogh(a)gmail.com> wrote: > I was getting something like this above where there is a part of the > packet shown as unknown header. I am suspecting that wireshark is not > recognizing this or this is again a different problem. Look forward to > your feedback. Honestly no idea... I've never used wireshark to debug the GSSAPI exchange with OpenLDAP. And it's been over a decade since I last played writing a client with SASL/GSSAPI & OpenLDAP. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Query on ldap sasl bind
by Nishanth Nagendra 11 Jul '17

11 Jul '17

Hello Quanah, Thank you very much for your email. It worked for me (I passed GSSAPI as the string), dn as NULL and I could now see in the packet capture that an sasl bind request is being sent out using GSSAPI. Below is the snapshot. Lightweight Directory Access Protocol LDAPMessage bindRequest(1) "<ROOT>" sasl messageID: 1 protocolOp: bindRequest (0) bindRequest version: 3 name: authentication: sasl (3) sasl mechanism: GSSAPI credentials: 6d797077 GSS-API Generic Security Service Application Program Interface Unknown header (class=1, pc=1, tag=13) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Why unknown ? [Expert Info (Warn/Protocol): Unknown header (class=1, pc=1, tag=13)] [Unknown header (class=1, pc=1, tag=13)] [Severity level: Warn] [Group: Protocol] I was getting something like this above where there is a part of the packet shown as unknown header. I am suspecting that wireshark is not recognizing this or this is again a different problem. Look forward to your feedback. regards, Nishanth On Mon, Jul 10, 2017 at 11:23 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, July 10, 2017 9:02 PM +0530 Nishanth Nagendra < > nishanth.amogh(a)gmail.com> wrote: > >> >> From the openldap source code, I notice that sasl.c file has a constant >> LDAP_SASL_SIMPLE as a constant for mechanism which is a NULL value. I >> tried to pass a non NULL value in my function call to ldap_sasl_bind in >> the third parameter expecting it to hit the other code path to initiate >> SASL bind with credentials but the library does not seem to allow it and >> returns error from sasl bind. >> > > As clearly noted in the source code comments, the third argument is the > MECHANISM to use: > > /* > * ldap_sasl_bind - bind to the ldap server (and X.500). > * The dn (usually NULL), mechanism, and credentials are provided. > * The message id of the request initiated is provided upon successful > * (LDAP_SUCCESS) return. > * > * Example: > * ldap_sasl_bind( ld, NULL, "mechanism", > * cred, NULL, NULL, &msgid ) > */ > > > I.e., you would pass in "GSSAPI" for a SASl/GSSAPI bind, etc. > > It is also generally better form to use ldap_sasl_interactive_bind_s, as > noted in the man page. In that case, as noted by the manual page: > > The mechs parameter should contain > a space-separated list of candidate mechanisms to use. If > this > parameter is NULL or empty the library will query the > supportedSASLMechanisms attribute from the server's rootDSE for > the > list of SASL mechanisms the server supports. > > > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: LMDB persistent snapshots
by Howard Chu 10 Jul '17

10 Jul '17

Michael Conrad wrote: > On 07/10/2017 12:16 PM, Howard Chu wrote: >> Michael Conrad wrote: >>> Hi, I'm scoping out my options for databases that support snapshotting. >>> From what I've read so far, this is a natural feature of LMDB, >> >> Not really. The persistent state only records the 2 most recent transactions. > > Hm, well so much for that idea ;-) But could you clarify what would happen > in a scenario like: > > Proc1: Begin Read Transaction t1 > Proc2: Write Transaction t2 > Proc2: Write transaction t3 > Proc3: Begin Read Transaction t4 > Proc2: Write Transaction t5 > Proc2: Write Transaction t6 > > After those steps, are process 1 and process 3 still able to continue reading > their data, and is all the data they see consistent with the state of the > database at the time they began the transaction? Yes. They each retain an in-memory copy of the DB metadata at the start of their transaction, and none of the pages they require can be reused by any write transactions. -- -- 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: LMDB persistent snapshots
by Howard Chu 10 Jul '17

10 Jul '17

Michael Conrad wrote: > Hi, I'm scoping out my options for databases that support snapshotting. From what I've read so far, this is a natural feature of LMDB, Not really. The persistent state only records the 2 most recent transactions. > however all the documentation talks about making sure not to let read transactions linger around. What if I *want* to hold onto a read transaction long-term, hours or even months? You should probably use the mdb_copy interface to just make a copy of that snapshot. > Also, I haven't yet seen a way for a new client to re-open the database as of the point in time of an existing transaction. Is this possible? See above, only the 2 most recent transactions' metadata is preserved. So in general, no. > If I manage to do something like this, will the storage overhead be roughly equivalent to the quantity of changed data between the snapshot and the latest write? or will the overhead be more like the sum of all writes + overwrites that happened since the read transaction started? i.e. if a read transaction is held starting from t0, then data is written at t1, then overwritten at t2 can the blocks affected by t1 be reclaimed for a write at t3? No. For any read transaction started at time t, only old pages up to t-2 can be reclaimed. Once they're all consumed, only new pages will be used, for as long as that txn stays open. -- -- 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: Query on ldap sasl bind
by Quanah Gibson-Mount 10 Jul '17

10 Jul '17

--On Monday, July 10, 2017 9:02 PM +0530 Nishanth Nagendra <nishanth.amogh(a)gmail.com> wrote: > > From the openldap source code, I notice that sasl.c file has a constant > LDAP_SASL_SIMPLE as a constant for mechanism which is a NULL value. I > tried to pass a non NULL value in my function call to ldap_sasl_bind in > the third parameter expecting it to hit the other code path to initiate > SASL bind with credentials but the library does not seem to allow it and > returns error from sasl bind. As clearly noted in the source code comments, the third argument is the MECHANISM to use: /* * ldap_sasl_bind - bind to the ldap server (and X.500). * The dn (usually NULL), mechanism, and credentials are provided. * The message id of the request initiated is provided upon successful * (LDAP_SUCCESS) return. * * Example: * ldap_sasl_bind( ld, NULL, "mechanism", * cred, NULL, NULL, &msgid ) */ I.e., you would pass in "GSSAPI" for a SASl/GSSAPI bind, etc. It is also generally better form to use ldap_sasl_interactive_bind_s, as noted in the man page. In that case, as noted by the manual page: The mechs parameter should contain a space-separated list of candidate mechanisms to use. If this parameter is NULL or empty the library will query the supportedSASLMechanisms attribute from the server's rootDSE for the list of SASL mechanisms the server supports. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: [EXTERNAL] Re: back-ldap and ldaps not working
by Quanah Gibson-Mount 10 Jul '17

10 Jul '17

--On Monday, July 10, 2017 6:33 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > You didn't fail Quanah. I included the version number in my original > description of the problem 'cause I didn't want to be "that guy". :D I > am running 2.4.44. Ah, ok, good. ;) Hm, so it would seem to me there's a bug in back-ldap then. I haven't played with it enough to know for sure, however. It would probably be worthwhile following Howard's suggestion then. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Deleting old replicas on consumer?
by Quanah Gibson-Mount 10 Jul '17

10 Jul '17

--On Friday, June 30, 2017 2:44 PM -0400 Prentice Bisbal <pbisbal(a)pppl.gov> wrote: > If I delete a replication consumer, do I need to delete any > replication-related data for that consumer's replication on the producer? > If so, how? If you're talking about pure consumers (not multi-master consumers), there's nothing to do, as there's nothing stored on the provider. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Query on ldap sasl bind
by Nishanth Nagendra 10 Jul '17

10 Jul '17

Hi All, I am new to Openldap and have been doing some basic testing with an application software I am working with. This software has an ldap protocol interface that talks to an ldap server using the Openldap library version 2.4 supporting operations such as search, add, delete. I am currently facing a challenge in understanding as to how this interface can send out a bind request with sasl mechanism as not simple. The code snippet trying to initiate an asynchronous bind is as below: ldap_sasl_bind(ldaphandle, dn, NULL, cred, NULL, NULL , &msgID); This code is initiating a bind with mechanism as simple when I capture the packets on the wire which I believe is because of the third parameter in this function call being NULL. The man page for bind operations http://www.openldap.org/software/man.cgi?query=ldap_sasl_bind&apropos=0&sek… does not speak about what values should I pass to the third parameter if I want to use a specific sasl mechanism. Can this just be a user defined string or a specific string that openldap expects. >From the openldap source code, I notice that sasl.c file has a constant LDAP_SASL_SIMPLE as a constant for mechanism which is a NULL value. I tried to pass a non NULL value in my function call to ldap_sasl_bind in the third parameter expecting it to hit the other code path to initiate SASL bind with credentials but the library does not seem to allow it and returns error from sasl bind. Any inputs in this direction would be really helpful. regards, Nishanth

1 0

openldap under openbsd
by Paul B. Henson 09 Jul '17

09 Jul '17

I was curious if anybody is running openldap under openbsd? The version in their ports system has mdb disabled, it says mdb is unreliable and results in random slapd crashes. It seems openbsd lacks a unified buffer cache, so mdb can only be used with the MDB_WRITEMAP option; they added a patch to cause initialization to fail if that option isn't enabled but then ended up disabling it completely anyway. This was back in 2015, I'm not sure if they've tested it recently or what details there were behind the crashes before they ended up disabling it. I'm thinking of trying it out with the latest release and seeing what happens but was wondering if anybody else had any recent experience. Thanks...

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2017