Search for primary group
by Bernard Fay
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
6 years
Re: mdb_dbi_open and threads
by Howard Chu
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/
6 years
Re: mdb_dbi_open and threads
by Howard Chu
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#gac08cad5b096925642ca359a6d...
> <http://www.lmdb.tech/doc/group__internal.html#gac08cad5b096925642ca359a6d...>
>
> 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/
6 years
Seach Object
by Bruno de Oliveira Bastos
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.
6 years
Re: mdb_dbi_open and threads
by Howard Chu
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#gac08cad5b096925642ca359a6d...
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/
6 years
mdb_dbi_open and threads
by Muhammed Muneer
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?
6 years
Re: ACL to authenticate gitlab users
by Quanah Gibson-Mount
--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>
6 years
ldapcompare vs ldapsearch
by Roger Szabo
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 :)
6 years
Re: ldapcompare vs ldapsearch
by Roger Szabo
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
6 years
Using of Collective attributes in 2.4.42
by Andrew Podko
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.
6 years
