openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

Very slow ldapserach
by Saša-Stjepan Bakša 07 Apr '15

07 Apr '15

Hi, Year ago we have tested openldap with back_mdb and it was fantastic. Search worked as a charm. Database was filled with 20 mil. users and serach returned some 20 k results per sec (my colegue did the test). Now we need that setup for some tests and we encountered very slow response - 1 search for user data with some aliased data need 8 to 20 seconds to be retrieved. ldapsearch -h 10.14.252.104 -p 389 -D cn=admin,dc=spr -w test -s sub -a always -b num=1234563123,dc=num,dc=SPR ObjectClass=* num=1234563123,dc=num,dc=SPR is alias to uid aliasedObjectName: uid=1234563123,ds=USERS,o=STANDARD,dc=spr We build our openldap from git source. We have tried new as older versions as well and no change is seen. Hardware: SuperMicro, 2xQuad core, 32 GB RAM, RAID 10 storage. HP blade 2xQuad core, 64 GB RAM sorage 2 disks in mirror. Results are the same and not depending on hardware. Openldap ver: root@centdevel openldap# git log commit 68d9aa207f51b4d1ef29bb9876e7da8c7eaf0eee Author: Quanah Gibson-Mount <quanah(a)openldap.org> Date: Tue Apr 8 21:16:52 2014 -0500 ITS#7430, ITS#6359 OS is Centos 6.4 (also tryed on Centos 6.6)numx mdb config part is: [root@spr2 cn=config]# cat olcDatabase\=\{1\}mdb.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 2c245069 dn: olcDatabase={1}mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /opt/openldap/var/openldap-data olcSuffix: dc=spr olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=spr" write by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by self write by dn="cn=admin,dc=spr" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=spr olcRootPW:: xyzdgsdsadeew olcDbCheckpoint: 4096 10 olcDbNoSync: TRUE olcDbIndex: objectClass eq olcDbIndex: uid eq olcDbIndex: num eq olcDbIndex: numx eq olcDbIndex: Username eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: contextCSN eq olcDbMaxSize: 16106127360 structuralObjectClass: olcMdbConfig entryUUID: 21ac150c-6b30-1034-9009-81396a683c5e creatorsName: cn=admin,cn=config createTimestamp: 20150330135513Z entryCSN: 20150330135513.544218Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20150330135513Z MDB database stat: [root@spr2 openldap]# /opt/openldap/sbin/mdb_stat /opt/openldap/var/openldap-data/ -e -rr -a Environment Info Map address: (nil) Map size: 16106127360 Page size: 4096 Max pages: 3932160 Number of pages used: 1523336 Last transaction ID: 16058165 Max readers: 126 Number of readers used: 0 Reader Table Status (no active readers) 0 stale readers cleared. (no active readers) Status of Main DB Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 11 Status of ad2i Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 38 Status of contextCSN Tree depth: 0 Branch pages: 0 Leaf pages: 0 Overflow pages: 0 Entries: 0 Status of dn2i Tree depth: 4 Branch pages: 2937 Leaf pages: 333338 Overflow pages: 0 Entries: 16000069 Status of entryCSN Tree depth: 3 Branch pages: 3 Leaf pages: 307 Overflow pages: 0 Entries: 8000034 Status of entryUUID Tree depth: 3 Branch pages: 259 Leaf pages: 62932 Overflow pages: 0 Entries: 8000034 Status of id2e Tree depth: 4 Branch pages: 4446 Leaf pages: 1000005 Overflow pages: 0 Entries: 8000034 Status of numx Tree depth: 3 Branch pages: 128 Leaf pages: 22295 Overflow pages: 0 Entries: 2000004 Status of num Tree depth: 3 Branch pages: 129 Leaf pages: 22325 Overflow pages: 0 Entries: 2000004 Status of objectClass Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 29 Status of Username Tree depth: 0 Branch pages: 0 Leaf pages: 0 Overflow pages: 0 Entries: 0 Status of uid Tree depth: 3 Branch pages: 34 Leaf pages: 7883 Overflow pages: 0 Entries: 1000004 Build config: make clean ./configure --enable-hdb=no \ --enable-bdb=no \ --enable-monitor=yes \ --prefix=/opt/openldap \ --enable-local=yes \ --enable-accesslog=yes \ --enable-syncprov=yes \ --enable-debug=yes make depend make #STRIP='' rm -r /opt/openldap/etc/openldap/schema make install #STRIP='' removing debug has no efect Do you have any hint for us? Br Sasa

4 8

Multiple programs not able to read LMDB concurrently
by Sravan Kumar Reddy Javaji 02 Apr '15

02 Apr '15

Hello Everyone, I am trying to access same LMDB source using multiple programs at the same time. I set max_readers to 2 at the time of creating environment by the first program, but still second program is not able to read the LMDB. Could some one please let me know how could I implement this feature? - Thanks and Regards, Sravan

2 2

how to enable debug message
by Shu, Xinxin 02 Apr '15

02 Apr '15

Hi list , I want to enable debug message for lmdb, I have noticed MDB_DEBUG Macro, and I define MDB_DEBUG when compiling lmdb, but did not get any debug message, how can I enable debug message ?

2 1

mirror entries with rewrite?
by Christian Bösch 01 Apr '15

01 Apr '15

Hi, I want to mirror entries from a subtree to another virtual tree. I tried with rwm-rewrite which works for rewriting but I want to keep the real entries. Is therefor rwm-rewrite the wrong approach or is that possible? Thanks in advance, Chris

1 0

Sorting the NAME Attribute
by Tim Gustafson 01 Apr '15

01 Apr '15

In the following post: http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/201001/msg… Quanah said: > However, I will note, the definitions of these attributes are RFC > defined. They have no ORDERING rule on purpose. I was not able to find what that purpose was. Does anyone have any idea why it was decided that something as critical as "name" attributes shouldn't have an ORDERING rule? In my case, I have users who have a lower-case first-letter in their last name, which makes them appear at the bottom of all lists of people when sorted on the LDAP server. Needless to say, this makes them unhappy. For most of my purposes, I simply sort the data in my code once it is retrieved from the LDAP server, but in some cases I don't have control over the software being used and therefore can't change it, and in other cases this is terribly inefficient or impractical. Other than "because the RFC says so", what's the reasoning behind not defining an ORDERING rule for "name" attributes", preferably one that is case-insensitive? Could it at least be made a build option to enable or disable an ORDERING rule on at least that attribute (or perhaps in a more general configurable way for other attributes as well), even if it's not truly RFC-compliant? -- Tim Gustafson tjg(a)ucsc.edu 831-459-5354 Baskin Engineering, Room 313A

1 1

disable logins with ACLs
by Igor Shmukler 31 Mar '15

31 Mar '15

Hello, I am trying to disable user logins for expired trial users. After searching online, finally found a useful thread from this very list archived http://www.openldap.org/lists/openldap-technical/201111/msg00165.html I accidentally tried to mess with userPassword hash, but it did not work me. Since in that thread Michael showed/shared a better way to achieve the same goal of disabling users with ACLs, I am trying to copy his method. I attempted to follow Michael's example. It has not worked yet. Below is my script: dn: olcDatabase={3}hdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange filter=(&(objectClass=inetOrgPerson)(serviceLevel=suspended)) by dn="cn=config" write by * none olcAccess: {1}to attrs=userPassword,shadowLastChange filter=(&(objectClass=inetOrgPerson)(!(serviceLevel=suspended))) by self write by anonymous auth by dn="cn=admin,dc=directory,dc=apple,dc=com" write by dn="cn=config" write by * none olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * filter=(&(objectClass=inetOrgPerson)(serviceLevel=suspended)) by dn="cn=config" write by * none olcAccess: {4}to * filter=(&(objectClass=inetOrgPerson)(!(serviceLevel=suspended))) by self write by dn="cn=admin,dc=directory,dc=apple,dc=com" write by dn="cn=config" write by * read Currently, ldapmodify(1) is failing with an implementation specific error, likely due to messed-up syntax or something. The additional info: <olcAccess> handler exited with 1 Michael's example is not written for OLC, so I managed to do something wrong. Any ideas? Thank you, Igor Shmukler

1 0

sane ppolicy choices
by Igor Shmukler 31 Mar '15

31 Mar '15

Hello, I am trying to implement a trial [period] for new customers, using the OpenLDAP password policy overlay. I was thinking about setting a combination of pwdMaxAge, pwdMustChange and pwdAllowUserChange. Basically, the best idea I have had is to set MaxAge to the length of trial [in seconds] then in a user changes the password while in trial mode, calculate MaxAge as (trial_length - time_passed), then at the end setting MustChange to true and AllowUserChange to false [until the trial has been converted]. Is that a sane policy? Should I be doing something totally different? Please advise. Sincerely, Igor Shmukler

3 5

Re: Q: different SSF settings for ldapi:// than for ldap:
by Michael Ströder 30 Mar '15

30 Mar '15

Ulrich Windl wrote: > Isn't the SSF strength for ldapi:// zero? The SSF strength of ldapi:// is whatever you set with configuration directive localSSF. It's your local security policy decision. Personally on my systems I don't see any problem with setting it to an equal strength like a strongly encrypted TLS connection. YMMV. Ciao, Michael.

1 0

Re: Antw: Re: Q: different SSF settings for ldapi:// than for ldap:
by Michael Ströder 30 Mar '15

30 Mar '15

Ulrich Windl wrote: >>>> Michael Ströder<michael(a)stroeder.com> schrieb am 30.03.2015 um 11:24 in > Nachricht <55191633.90204(a)stroeder.com>: >> Ulrich Windl wrote: >>>>>> Michael Ströder<michael(a)stroeder.com> schrieb am 29.03.2015 um 12:12 in >>>> I have this in my config: >>>> >>>> # SSF value for ldapi:// >>>> localSSF 256 >>> >>> What I don't understand here is: Doesn't "256" _require_ encryption for >>> ldapi:// then? >> >> There is a reason for everything I write, especially this sentence: >> >> >> See slapd.conf(5) for details. >> >> Learn to read the fine docs. > > What really annoys me in this list are answers like "I know, you dont't. Try > to find out yourself!". Is it really too demanding to look up the text yourself when I point out a particular configuration directive *and* point to the relevant man page? My impression was that you did not read the text before asking back. > Here's what the manual page says: > -- > localSSF <SSF> > Specifies the Security Strength Factor (SSF) to be given > local > LDAP sessions, such as those to the ldapi:// listener. For > a > description of SSF values, see sasl-secprops's minssf > option > description. The default is 71. > -- > So where is the answer what 255 means? And what is the meaning of 71? (I guess > 71 bit encryption; so I guess 255 means 255-bit encryption, but you say I'm > wrong) Yes, the default is 71 which is lower than what you specified as minssf. Ciao, Michael.

1 0

Re: Antw: Re: external authentication source
by Hallvard Breien Furuseth 30 Mar '15

30 Mar '15

On 23. mars 2015 12:45, Ulrich Windl wrote: > Related question: If the command above fails with "stronger confidentiality required", and adding "-ZZ" fails with " TLS: hostname does not match CN in peer certificate", how should a proper certificate look like? Read the OpenLDAP Admin Guide, section 16 (TLS). In particular 16.1.1. Server Certificates. -- Hallvard

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical