openldap-technical

openldap-technical@openldap.org

21 participants
9787 discussions

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

12 Jul '17

--On Saturday, July 08, 2017 4:53 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > I vaguely remember there were bugs in back-ldap/back-meta ignoring TLS > options. The work-around back then was to set env var LDAPTLS_CACERT and > friends when starting slapd to let libldap pick up the TLS options from > env. > > Should be fixed in recent releases OpenLDAP though. Ha, one of the few times I failed to ask what version of OpenLDAP was being used... Jon, what OpenLDAP release are you running? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 3

Re: olcGlobal vs. olcFrontendConfig
by Howard Chu 12 Jul '17

12 Jul '17

Michael Ströder wrote: > 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. In OpenLDAP 2.3 most global parameters were put into olcGlobal. We moved parameters into olcFrontendConfig in OpenLDAP 2.4 whenever we found an item that might depend on a loadable module, since olcModules are processed after olcGlobal. The parser still accepts these items in olcGlobal, to retain compatibility with configs migrated from 2.3, but in freshly generated configs, the 2.4 olcGlobal will omit them. > 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. A salt format is just a plain string, so it has no particular dependencies. A hash requires actual code to implement it, and may depend on olcModule. > > Background: I'd like to determine which password hash scheme and salt format is > configured by searching in back-config. > > Ciao, Michael. > -- -- 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

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical