openldap-technical

openldap-technical@openldap.org

22 participants
9789 discussions

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

Using of Collective attributes in 2.4.42
by Andrew Podko 19 May '17

19 May '17

Hello! I rebuilt the OpenLdap with -DLDAP_COLLECTIVE_ATTRIBUTES Added in slapd.conf include collective.schema moduleload collect overlay collect collectinfo cn=coll,dc=exadel,dc=com c-PhysicalDeliveryOfficeName,c-TelephoneNumber # also i tried with collectinfo cn=coll,dc=exadel,dc=com PhysicalDeliveryOfficeName,TelephoneNumber I created element: dn: cn=coll,dc=exadel,dc=com objectClass: subentry objectClass: extensibleObject objectClass: collectiveAttributeSubentry objectClass: top structuralObjectClass: subentry c-PhysicalDeliveryOfficeName: Test office c-TelephoneNumber: +8888888888 cn: coll subtreeSpecification: {base "ou=Test Group"} But when I query with ldapsearch, I don't see what users from ou=Test Group,dc=example,dc=com have attributes PhysicalDeliveryOfficeName, TelephoneNumber I can not understand what else needs to be done to make it work. Could you tell me what I missed? I checked it on versions 2.4.42 and 2.4.44. -- With Best Wishes Andrew Podko System Administrator Exadel apodko(a)exadel.com <mailto:apodko@exadel.com> -- CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.

1 0

Re: Antw: Re: TLSCACertificateFile directive and multiple CA certificates
by Dameon Wagner 18 May '17

18 May '17

On Thu, May 18 2017 at 20:17:16 +0900, Alexandre Rosenberg scribbled in "Re: Antw: Re: TLSCACertificateFile directive and multiple CA certificates": > Hello, > > I test and the issue only happen if 2 CA have the same DN. > I regenerated the new CA with a different DN and it's working. > > As I am mentioned I am not sure what the proper behavior of > OpenLDAP/OpenSSL should be in case 2 CA have the same DN. > > I am not sure I misunderstanding what TLSCACertificateFile is used > for. The main use it to let OpenLDAP though which CA if should trust > when validating certificate. That is clearly what is in the doc. > > Best, > > Alex Hi Alex, Glad you got it working. I think the proper behaviour would be to not have 2 CAs with the same DN, as the first-match-wins. As the DN is used to identify the issuer of the certificate you're attempting to authenticate, it would make little sense to have a naming collision. I realise the docs say that order doesn't matter, but that assumes that all included certificates would have clearly distinguished subject names (hence "DN"). Cheers. Dameon. -- ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <>< Dr. Dameon Wagner, Systems Development and Support IT Services, University of Oxford ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><

1 0

knowing which schema(s) to use
by Prentice Bisbal 17 May '17

17 May '17

Over the past few days or weeks, I've asked a number of questions related to schemas as I move my LDAP directory to a newer OS and newer version of OpenLDAP. As has happened in the past, I have run into schema issues when importing the database (LDIF file) into the new directory with slapadd. This time I got the following errors: 1. Kerberos attributes in "new" kerberos schema start with 'krb' instead of 'krb5' 2. I got a schema structural error because user accounts have both objectclasses "account" and "krbPrincipal", which is not good. 3. We were using solaris.schema on the old system, which CentOS 6 doesn't provide, but it does provide duaconf.schema, which seemed be be similar if not identical to solaris.schema. Both of these are easy to fix - just use sed to change 'krb5' to 'krb', and then change 'krbPrincipal' to 'krbPrincipalAux', but is this really the best/safest way to make these changes. Also, what happens to apps that are looking for the 'krb5' instead of 'krb' and vice-versa? I think many system admins would say just copy the schemas from the old server to the new server and forget about it, but I don't think this is a good approach. After doing that several times, I imagine the newer applications on the newer OS versions will be looking for different objectclass or attribute names (like krb instead of krb5), and things will eventually break, anyway. So my questions are this: 1. How do the rest of you handle situations like this? 2. Who/what is the authoritative source for current schema definitions? Are they all defined in RFCs? In an earlier e-mail, regarding my kerberos schema issues, Michael Ströder wrote > You should use the current schema file shipped with your particular Kerberos installation. That's exactly what I'm trying to do, which led to the kerberos schema issues. And in the past there have been times when the current version of the OS didn't provide the same schemas as the old version, and I was left searching the Internet to find the modern equivalent of the schema from the old system. -- Prentice

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical