openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

group membership search performance
by Rébeli-Szabó Tamás 12 Oct '16

12 Oct '16

Hi, we are on OpenLDAP 2.4.41 + MDB, Oracle Linux 6 (2.6 x86_64). In our DIT we have around 300 groups, with tens of thousands of members in each group. When we want to know which groups a certain user belongs to, it takes OpenLDAP several seconds to perform such a search. Here is a log excerpt showing that it took 6 seconds for the server to answer: Oct 10 15:39:38 ldap-srv1 slapd[14776]: conn=1062 op=1 SRCH base="ou=groups,dc=tt,dc=hu" scope=1 deref=0 filter="(&(uniqueMember=uid=o10011,ou=users,dc=tt,dc=hu)(objectClass=groupOfUniqueNames))" Oct 10 15:39:44 ldap-srv1 slapd[14776]: conn=1062 op=1 SEARCH RESULT tag=101 err=0 nentries=127 text= We have eq indices on objectClass and uniqueMember, and the latter is also listed after sortvals. The machine running OpenLDAP has 2 virtual cores of Intel Xeon E5 2637 v2 (3.5GHz). During such searches, one of the CPU cores is almost fully loaded, but the system is not overloaded (the average load is around 0.8). Our whole dataset is under 1 GB, and there are several gigabytes of free RAM with no swapping. Our expectation would be for OpenLDAP to give an answer to a group membership question under 1 second. Is that a realistic expectation, and if so, how should we tune OpenLDAP or what do you suggest we change? Version 2.4.41 is more than a year old, so the question is if there is any significant performance enhancement (an order of magnitude) possible with this setup described above, or that's about all we can get from OpenLDAP+MDB (or perhaps any in-memory LDAP)? Regards, tamas

1 0

Returned mail: Data format error
by dieter＠dkluenter.de 12 Oct '16

12 Oct '16

Dear user openldap-technical(a)openldap.org, Your account has been used to send a huge amount of junk e-mail during this week. Obviously, your computer was compromised and now runs a hidden proxy server. Please follow instructions in order to keep your computer safe. Virtually yours, openldap.org user support team.

1 0

Paged Result support in proxy cache
by laurent2.perrin＠orange.com 10 Oct '16

10 Oct '16

Hello, I have configured a proxy LDAP with cache but when I try to do request with paged results, I can see this error message in logs: Oct 7 14:07:55 ldap-cache slapd[18615]: conn=1017 op=1 SRCH base="dc=***,dc=***,dc=****,dc=**" scope=2 deref=0 filter="(&(memberOf=cn=gg-oab-pa-openstack,ou=profils applicatifs,ou=groupes de securite \28gg\29,ou=***,dc=***,dc=***,dc=***,dc=***)(objectClass=person)(?SAMACCOUNTNAME=*))" Oct 7 14:07:55 ldap-cache slapd[18615]: conn=1017 op=1 SRCH attr=samaccountname userPassword userAccountControl mail description Oct 7 14:07:55 ldap-cache slapd[18615]: conn=1017 op=1: critical pagedResults control disabled with proxy cache. Oct 7 14:07:55 ldap-cache slapd[18615]: conn=1017 op=1: critical control "1.2.840.113556.1.4.1339" not supported. Oct 7 14:07:55 ldap-cache slapd[18615]: send_ldap_result: conn=1017 op=1 p=3 Oct 7 14:07:55 ldap-cache slapd[18615]: send_ldap_result: err=12 matched="" text="" Oct 7 14:07:55 ldap-cache slapd[18615]: send_ldap_response: msgid=2 tag=101 err=12 Oct 7 14:07:55 ldap-cache slapd[18615]: conn=1017 op=1 SEARCH RESULT tag=101 err=12 nentries=0 text= When the cache is not configured, all requests are OK and return results Here is the configuration used: dn: olcDatabase=ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: ldap olcSuffix: dc=ad-***,dc=***,dc=***,dc=** olcRootDN: cn=compte_service,OU=***,dc=***,dc=***,dc=***,dc=*** olcRootPW: password olcDbURI: "ldap://ad.local" olcDbChaseReferrals: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbACLBind: bindmethod=simple binddn="cn= ***,OU=***,dc=***,dc=*,dc=***,dc=***" credentials="password" olcLimits: * size.prtotal=unlimited size.pr=1000 size.hard=5000 dn: olcOverlay=pcache,olcDatabase={2}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: pcache olcPcache: hdb 100000 1 1000 100 olcPcacheAttrset: 0 * olcPcacheTemplate: "(sn=)" 0 3600 0 0 0 olcPcacheTemplate: "(memberof=)" 0 3600 dn: olcDatabase=hdb,olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config objectClass: olcHdbConfig objectClass: olcPcacheDatabase olcDatabase: hdb olcDbDirectory: /var/lib/ldap olcDbCacheSize: 200 olcDbIndex: objectClass eq olcDbIndex: cn pres,eq,sub I tried to add size.pr option to the Cache database but it seems to not be supported. So does proxy cache support the use of paged results ? Regards, [cid:image001.gif@01CBF2E5.34FD28F0] Laurent PERRIN Service Infra aux Projets Orange Applications for Business SCE/OAB/DPO/DSPM/IOP tel. +33 4 37 24 62 85 Mob : 07 84 12 78 79 laurent2.perrin(a)orange.com<mailto:laurent2.perrin@orange.com> 139 rue Vendôme 69006 Lyon www.orange-business.com<http://www.orange-business.com/> [cid:image002.gif@01CBF2E5.34FD28F0] _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

2 1

Re: OpenLDAP with OpenSSL 1.1.0
by Quanah Gibson-Mount 07 Oct '16

07 Oct '16

--On Wednesday, October 05, 2016 11:43 AM -0700 Norm Green <norm.green(a)gemtalksystems.com> wrote: > I am trying to build OpenLDAP from source on Linux with OpenSSL 1.1.0. I > first tried version 2.4.44 and found that didn't work due to the API > changes in OpenSSL 1.1.0. I then filed ITS 8488 on the problem, which > was quickly closed with the comment " Already supported in git master. > Closing this ITS.". > > So I then got a copy of the git master and tried a build and it still > fails in configure a follows: > > conftest.c:106: undefined reference to `SSL_library_init' > ... > configure:15618: result: no > configure:15864: error: Could not locate TLS/SSL package > > > This function is no longer present in OpenSSL 1.1.0 so it would appear > the OpenLDAP configure script should be checking the version of OpenSSL > before looking for the SSL_library_init symbol. > > Is this a known problem? Should I file a bug? Or is support for OpenSSL > 1.1.0 known to be incomplete? Follow up to ITS8353, noting that there is more to be done. --Quanah -- Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: User Import Problem with n-way multimaster setup
by Quanah Gibson-Mount 05 Oct '16

05 Oct '16

--On Wednesday, October 05, 2016 12:40 PM +0000 robert.lindner(a)delivion.de wrote: > Hi, > I have a Problem importing a large batch of users into the following > setup: Two Nodes of openldap running n-way multimaster replication with > mdb backend, version is 2.4.44. Everything looks good, replication is > working. > > Now I am trying to import a ldif file with 110362 Users to be added and > 956419 group modify operations: Hi Robert, I would generally suggest using dynamic rather than static groups. You've definitely found the downside to static groups -- They require an excessive number of write ops that could otherwise be avoided. You may want to look into how you're currently implementing your group data and re-adjust. Hope that helps, Quanah -- Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

OpenLDAP with OpenSSL 1.1.0
by Norm Green 05 Oct '16

05 Oct '16

I am trying to build OpenLDAP from source on Linux with OpenSSL 1.1.0. I first tried version 2.4.44 and found that didn't work due to the API changes in OpenSSL 1.1.0. I then filed ITS 8488 on the problem, which was quickly closed with the comment " Already supported in git master. Closing this ITS.". So I then got a copy of the git master and tried a build and it still fails in configure a follows: conftest.c:106: undefined reference to `SSL_library_init' ... configure:15618: result: no configure:15864: error: Could not locate TLS/SSL package This function is no longer present in OpenSSL 1.1.0 so it would appear the OpenLDAP configure script should be checking the version of OpenSSL before looking for the SSL_library_init symbol. Is this a known problem? Should I file a bug? Or is support for OpenSSL 1.1.0 known to be incomplete? Norm Green

1 0

Re: Syncrepl and missing entries
by Quanah Gibson-Mount 05 Oct '16

05 Oct '16

--On Wednesday, October 05, 2016 12:17 PM +0200 Thomas Hummel <thomas.hummel(a)pasteur.fr> wrote: > I'm answering some parts of my own question : > > as a matter of fact, the entry missing in my replica has an entryCSN > lesser than the contestCSN. I guess that's the reason why it is not > synchronised. > > Does that mean that, if for some reason, the replica gets out of sync in > a similar manner, missing entries will never get synch'ed again unless - > by "chance" - touched (modified) again (in which case they'll get a new > entryCSN) ? Correct > Of course, I still don't undestand why this entry disapeared in the first > place... What release? There are known issues with syncrepl in various releases. --Quanah -- Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 4

User Import Problem with n-way multimaster setup
by robert.lindner＠delivion.de 05 Oct '16

05 Oct '16

Hi, I have a Problem importing a large batch of users into the following setup: Two Nodes of openldap running n-way multimaster replication with mdb backend, version is 2.4.44. Everything looks good, replication is working. Now I am trying to import a ldif file with 110362 Users to be added and 956419 group modify operations: 1. When both nodes are online and replication is running, after slapd on the importing node quickly starts using all available memory until the kernel oom-killer decides it uses too much and kills the process. This seems to be caused by the group modifications: It did not happen before, when we had an error in the ldif which caused the group modify statements to be ignored, so only users were imported. We tried to circumvent this behavior by adding up to 32GB of Memory, but this only postponed the problem. 2. When I shut down the second node, so no replication is happening, then start the user and group membership import, this runs fine (takes about 10 hours) without exhausting memory, but if I join the second node afterwards none of the new entries is replicated to the second node. Does anyone have an idea what I might be doing wrong? Currently I try to batch import with the ldif split into chunks of 1000 entries, with a 30s pause in between. Best Regards, Robert Lindner Cloud Platform Engineer | Delivion GmbH Nachbarsweg 25a | D-45481 Mülheim an der Ruhr Tel.: [+49] 170 7727967 | Web: www.delivion.de This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

1 0

Syncrepl and missing entries
by Thomas Hummel 05 Oct '16

05 Oct '16

Hello, I'm planning a migration from openldap-2.4.35 (FreeBSD 9.1-RELEASE-p12) to openldap-2.4.40 (CentOS 7). On BSD, I have 3 slapd.conf/hdb servers : one provider and 2 consumers (classical syncprov overlay / syncrepl refreshAndPersist setup). On linux, I've set up 3 new cn=config/lmdb servers in a simliar manner. For a smooth migration, I also configured syncrepl on the linux provider so that it is also a consumer of the BSD provider. So this is a simple BSD provider -> linux provider-and-consumer -> linux consumer chain, not a multi-master setup. Everything worked fine and I could indeed check that modifying, say an attribute of my dn, on the FreeBSD provider was replicated to the BSD consumers, the Linux provider and then the Linux consumers. Unfortunately, I noticed that, after a while (at least it seems that it occurred after a while, I'd swear the entry was there from the start), the sssd entry (cn=sssd,ou=ldap,dc=pasteur,dc=fr) - used by sssd to bind - was missing on the Linux provider-and-consumer. That in itself may be an mystery I must figure out. But more important, I noticed that this entry would not be replicated although it IS present on the BSD provider, even after slapd restarts. Only if I remove the database files and restart from scratch get all the entries - including this one - get replicated from the BSD provider to the linux provider-consumer. Is my setup only supposed to work ? Is the difference of slapd versions a problem ? Is the fact that both providers manage the same rootDSE a problem ? Thanks -- Thomas HUMMEL

1 1

Mapping attribute from ppolicy shemas to shadowaccount
by Alexis Lameire 05 Oct '16

05 Oct '16

Hello, Despite my search I can't find a good solution to my issue. I would like to implement passord policy inside my LDAP server. So I will use the password policy overlay. The policy applyed to the user is located on the pwdPolicySubentry attribute of the user entry. I would like to configure the password expiration warning on my policy. I would also that this warning will be displayed on my linux based server. Due to the deprecation of pam_ldap module on recent system, I'm using SSSD. Despite my search, SSSD is only able to fetch the password expiration attribut inside the shadowAccount objectClass (so on the user entry). To be able to define my policy once, I have to show and rename the ppolicy objectClass attribut referenced by the pwdPolicySubentry dn inside the user entry. with the slapo-rwm I can map the attribute of the same leaf objectClass to another name but I'm not able to follow the pwdPolicySubentry DN and map the value of this object inside the posixAccount objectClass. How to acheave this ? Regards

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical