openldap-software

openldap-software@openldap.org

2719 discussions

openldap getting very slow
by Thomas van Oudenhove 10 Apr '09

10 Apr '09

hello, I have some problems with my ldap server. it worked perfectly until monday, march 30 : on every night, I used to extract all entries from the server, making a diff with some ldif file(s) and ldapmodify with the "diff ldif file". there was about 15,000 to 40,000 entries modified each night, and ldapmodify was running about 20 to 40 minutes (~1,000 entries per minute). on last monday, the extraction of ldap had some trouble, the extraction request never ended, and that made the server inaccessible; we had to restart it. since march 30, the update process (ldapmodify) is incredibly slow, it takes about several hours (~60 entries per minute), but the extraction request is "normal" again (about 2 seconds). we tried to restart from scratch (delete db, re-install openldap (and update) and start the process again, it is still slower than before (~400 entries per minute). we cannot figure out why it became so slow, so we are interested in any advice... we had openldap 2.3.27-8.el5_2.4 installed and tried with the update: openldap 2.3.43-3.el5 (both CentOS packages). log of the failed request: Mar 30 01:10:01 ldap slapd[27383]: conn=1772 fd=16 ACCEPT from IP=xxx.xxx.xxx.xxx:38263 (IP=0.0.0.0:389) Mar 30 01:10:01 ldap slapd[27383]: conn=1772 op=0 BIND dn="cn=Manager,dc=fr" method=128 Mar 30 01:10:01 ldap slapd[27383]: conn=1772 op=0 BIND dn="cn=Manager,dc=fr" mech=SIMPLE ssf=0 Mar 30 01:10:01 ldap slapd[27383]: conn=1772 op=0 RESULT tag=97 err=0 text= Mar 30 01:10:01 ldap slapd[27383]: conn=1772 op=1 SRCH base="dc=fr" scope=2 deref=0 filter="(objectClass=*)" [and no more traces until openldap restart about noon] log of a "normal" request: Mar 16 01:10:01 ldap slapd[23294]: conn=11 fd=15 ACCEPT from IP=xxx.xxx.xxx.xxx:53535 (IP=0.0.0.0:389) Mar 16 01:10:01 ldap slapd[23294]: conn=11 op=0 BIND dn="cn=Manager,dc=fr" method=128 Mar 16 01:10:01 ldap slapd[23294]: conn=11 op=0 BIND dn="cn=Manager,dc=fr" mech=SIMPLE ssf=0 Mar 16 01:10:01 ldap slapd[23294]: conn=11 op=0 RESULT tag=97 err=0 text= Mar 16 01:10:01 ldap slapd[23294]: conn=11 op=1 SRCH base="dc=fr" scope=2 deref=0 filter="(objectClass=*)" Mar 16 01:10:03 ldap slapd[23294]: conn=11 op=1 SEARCH RESULT tag=101 err=0 nentries=39741 text= Mar 16 01:10:03 ldap slapd[23294]: conn=11 op=2 UNBIND Mar 16 01:10:03 ldap slapd[23294]: conn=11 fd=15 closed thanks for any help, regards, -- Thomas van Oudenhove - Université de Toulouse tél: (+33) 5 61 36 60 45 jabberID: thomasvo(a)im.apinc.org

5 9

slapd-ldap and authentication
by Daniel Tiefnig 07 Apr '09

07 Apr '09

Hej, It's been a long time since I used OpenLDAP and read the lists, (like 7 years ago) so first: hello again! :-) I'm using "OpenLDAP: slapd 2.3.30" from debian/etch, trying to access two database shadows via a slapd-ldap proxy. The shadow contains these two databases holding NSS and addressbook entries: (passwords changed) ####################################################################### # The NSS databases contains NSS accounts and groups. database bdb suffix "dc=nss,dc=sipwise,dc=com" directory "/var/lib/ldap/nss" lastmod on rootdn "cn=root,dc=nss,dc=sipwise,dc=com" rootpw s1kkr1t dbconfig set_cachesize 0 20971520 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass,cn,uid,uidNumber,gidNumber eq syncrepl rid=002 provider=ldap://db1 bindmethod=simple binddn="cn=root,dc=nss,dc=sipwise,dc=com" credentials=s1kkr1t searchbase="dc=nss,dc=sipwise,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" ####################################################################### # The addressbook database contains contacts for e-mail and phone. database bdb suffix "dc=addressbook,dc=sipwise,dc=com" directory "/var/lib/ldap/addressbook" lastmod on rootdn "cn=root,dc=addressbook,dc=sipwise,dc=com" rootpw s1kkr1t dbconfig set_cachesize 0 20971520 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass,entryUUID eq index cn,sn,mail,givenName sub syncrepl rid=003 provider=ldap://db1 bindmethod=simple binddn="cn=root,dc=addressbook,dc=sipwise,dc=com" credentials=s1kkr1t searchbase="dc=addressbook,dc=sipwise,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" The simple ACL configuration is: ####################################################################### access to attrs=userPassword dn.subtree="ou=people,dc=nss,dc=sipwise,dc=com" by anonymous auth by * none access to dn.subtree="dc=nss,dc=sipwise,dc=com" by users read by * none access to dn.subtree="dc=addressbook,dc=sipwise,dc=com" by users write by * none Trying to access the two databases using ldapsearch (directly towards the shadow, not the local slapd) on the proxy machine works just fine. The slapd.conf on the proxy contains two "ldap" databases which forward requests to the shadow databases: ####################################################################### # The nss database contains NSS accounts. database ldap suffix "dc=nss,dc=sipwise,dc=com" uri "ldap://db/" ####################################################################### # The addressbook database contains contacts for e-mail and phone. database ldap suffix "dc=addressbook,dc=sipwise,dc=com" uri "ldap://db/" Now, trying to access the nss database using ldapsearch towards the proxy from a client works fine too, but I can't get any entries from the addressbook. Commandlines are: ldapsearch -x -D uid=dtiefnig,ou=people,dc=nss,dc=sipwise,dc=com \ -W -b dc=nss,dc=sipwise,dc=com cn=\* ldapsearch -x -D uid=dtiefnig,ou=people,dc=nss,dc=sipwise,dc=com \ -W -b dc=addressbook,dc=sipwise,dc=com cn=\* When running slapd with "-d 128" on the shadow, after the authentication stuff, I can see the following for the nss database: => acl_mask: access to entry "dc=nss,dc=sipwise,dc=com", attr "cn" \ requested => acl_mask: to all values by \ "uid=dtiefnig,ou=people,dc=nss,dc=sipwise,dc=com", (=0) And for the addressbook database I get: => acl_mask: access to entry "dc=addressbook,dc=sipwise,dc=com", \ attr "cn" requested => acl_mask: to all values by "", (=0) I.e. it looks like access to the addressbook database is done anonymously, even though authentication is performed right before. When doing the ldapsearches directly to the shadow, this does not happen. Am I missing something in the proxy configuration? Why does searching the nss database work? Because my bind user is within the same database? Sounds a little bit weird to me. Thanks a lot and best regards, daniel

2 2

make error
by McGranahan, Jamen 06 Apr '09

06 Apr '09

I'm trying to install OpenLDAP v. 2.4.11 on my Sun Solaris 10 box (SunOS libdig4 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Fire-V440) and I've done the following: ./configure --disable-slapd (status = seemed to complete successfully) make depend (status = seemed to complete successfully) make -> this terminates with the following: Entering subdirectory libldap make[2]: Entering directory `/home/jamen/openldap-2.4.11/libraries/libldap' /bin/sh ../..//libtool --mode=compile cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB.4.2/include -DLDAP_LIBRARY -c tls.c cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB.4.2/include -DLDAP_LIBRARY -c tls.c -KPIC -DPIC -o .libs/tls.o "tls.c", line 102: syntax error before or at: gnutls_kx_algorithm_t "tls.c", line 112: syntax error before or at: typedef "tls.c", line 114: syntax error before or at: gnutls_certificate_credentials_t "tls.c", line 127: syntax error before or at: typedef "tls.c", line 128: syntax error before or at: tls_ctx "tls.c", line 189: member cannot be function: ldap_pvt_tls_ctx_free "tls.c", line 189: warning: syntax requires ";" after last struct/union member "tls.c", line 189: syntax error before or at: { "tls.c", line 191: syntax error before or at: tls_ctx "tls.c", line 211: member cannot be function: tls_ctx_new "tls.c", line 211: warning: syntax requires ";" after last struct/union member "tls.c", line 211: syntax error before or at: { "tls.c", line 230: syntax error before or at: * "tls.c", line 231: member cannot be function: tls_ctx_ref "tls.c", line 231: warning: syntax requires ";" after last struct/union member "tls.c", line 242: warning: syntax requires ";" after last struct/union member "tls.c", line 262: warning: syntax requires ";" after last struct/union member "tls.c", line 275: syntax error before or at: * "tls.c", line 276: member cannot be function: tls_session_free "tls.c", line 276: warning: syntax requires ";" after last struct/union member "tls.c", line 285: syntax error before or at: * "tls.c", line 285: warning: undefined or missing type for: char "tls.c", line 286: member cannot be function: tls_parse_ciphers "tls.c", line 286: warning: syntax requires ";" after last struct/union member "tls.c", line 289: warning: syntax requires ";" after last struct/union member "tls.c", line 289: syntax error before or at: = "tls.c", line 292: syntax error before or at: num "tls.c", line 314: warning: syntax requires ";" after last struct/union member "tls.c", line 350: zero-sized struct/union "tls.c", line 352: warning: old-style declaration or incorrect type for: ptr "tls.c", line 352: warning: old-style declaration or incorrect type for: len "tls.c", line 352: warning: syntax error: empty declaration "tls.c", line 353: warning: old-style declaration or incorrect type for: end "tls.c", line 354: undefined symbol: nkx "tls.c", line 354: can not declare variably modified type at file scope "tls.c", line 354: warning: old-style declaration or incorrect type for: kx "tls.c", line 354: warning: {}-enclosed initializer required "tls.c", line 354: too many array initializers "tls.c", line 354: warning: variable length array can not be initialized: kx "tls.c", line 355: undefined symbol: ncipher "tls.c", line 355: can not declare variably modified type at file scope "tls.c", line 355: warning: old-style declaration or incorrect type for: cipher "tls.c", line 355: warning: {}-enclosed initializer required "tls.c", line 355: too many array initializers "tls.c", line 355: warning: variable length array can not be initialized: cipher "tls.c", line 356: undefined symbol: nmac "tls.c", line 356: can not declare variably modified type at file scope "tls.c", line 356: warning: old-style declaration or incorrect type for: mac "tls.c", line 356: warning: {}-enclosed initializer required "tls.c", line 356: too many array initializers "tls.c", line 356: warning: variable length array can not be initialized: mac "tls.c", line 357: warning: old-style declaration or incorrect type for: ctx "tls.c", line 357: syntax error before or at: -> "tls.c", line 357: warning: old-style declaration or incorrect type for: kx_list "tls.c", line 357: warning: improper pointer/integer combination: op "=" "tls.c", line 358: warning: old-style declaration or incorrect type for: ctx "tls.c", line 358: syntax error before or at: -> "tls.c", line 358: warning: old-style declaration or incorrect type for: cipher_list "tls.c", line 358: warning: improper pointer/integer combination: op "=" "tls.c", line 359: warning: old-style declaration or incorrect type for: ctx "tls.c", line 359: syntax error before or at: -> "tls.c", line 359: warning: old-style declaration or incorrect type for: mac_list "tls.c", line 359: warning: improper pointer/integer combination: op "=" "tls.c", line 360: syntax error before or at: return "tls.c", line 360: warning: syntax error: empty declaration "tls.c", line 532: cannot recover from previous errors cc: acomp failed for tls.c make[2]: *** [tls.lo] Error 1 make[2]: Leaving directory `/home/jamen/openldap-2.4.11/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/jamen/openldap-2.4.11/libraries' make: *** [all-common] Error 1 Now I am logged in as root and have the following environment variables set: LDFLAGS=-L/usr/local/lib -L/usr/local/BerkeleyDB.4.2/lib -R/usr/local/Berkeley.4.2/lib CPPFLAGS=-I/usr/local/BerkeleyDB.4.2/include LD_LIBRARY_PATH=/usr/local/BerkeleyDB.4.2/lib Can someone guide me as to what I am missing? I'm sure it's pretty obvious, but I've not been able to figure it out. Please, any help you can provide will be greatly appreciated. Thank you! ********************************* * Jamen McGranahan * Systems Services Librarian * Library Information Technology Services * Vanderbilt University * Suite 700 * 110 21st Avenue South * Nashville, TN 37240 * (615) 343-1614 * (615) 343-8834 (fax) * jamen.mcgranahan(a)vanderbilt.edu ***********************************

3 4

RE: make error
by Quanah Gibson-Mount 06 Apr '09

06 Apr '09

--On Monday, April 06, 2009 11:05 AM -0500 "McGranahan, Jamen" <jamen.mcgranahan(a)Vanderbilt.Edu> wrote: > We're using openssl 0.9.8k Please don't email me off the list. The errors you've submitted indicate that OpenSSL was not detected, so I'd guess that you didn't correctly point it at the location where you installed OpenSSL. Make sure your LDFLAGS and CPPFLAGS settings correctly direct OpenLDAP to find your installed version of OpenSSL. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Does ldap_parse_sasl_bind_result work with ldap_sasl_bind(LDAP_SASL_SIMPLE)?
by Lawrence Chan 03 Apr '09

03 Apr '09

Hi, I'm an openldap beginner and I've been experimenting with some simple openldap examples. Essentially, I had some sample code that tried to initiate an asynchronous bind to a slapd. My program made calls to the library using the following functions in this order. ldap_initialize(...); ldap_sasl_bind(..., LDAP_SASL_SIMPLE, ...); ldap_result(...); // check ldap_result return code == -1 and result pointer != NULL ldap_parse_sasl_bind_result(...); // check ldap_parse_sasl_bind_result return code ldap_unbind_ext(...); The code appears to work with a correct DN and password. But strangely enough I didn't get any errors either when I supplied an incorrect password. When I inspect the packet traffic between the client and the slapd, the slapd responds as expected to the two binds (invalid credentials -> incorrect password) and (success -> correct password). I spent hours debugging to no avail and then finally decided to try out ldapwhoami which catches the invalid credentials... Looking at the source code for ldapwhoami revealed that ldapwhoami uses ldap_parse_result when binding with ldap_sasl_bind(LDAP_SASL_SIMPLE). This practice wasn't immediately obvious to me. My questions: 1. Does ldap_parse_sasl_bind_result work for processing responses to ldap_sasl_bind(LDAP_SASL_SIMPLE)? 2. If the answer to (1.) is in fact no, wouldn't it be more intuitive to get ldap_parse_sasl_bind_result to also handle the LDAP_SASL_SIMPLE case? 3. Is there a simple way to determine whether or not a response received in ldap_result is a bind response to LDAP_SASL_SIMPLE or do I have to store my bind request type and correlate this using the message id when the response returns? Thanks, Lawrence _________________________________________________________________ Reinvent how you stay in touch with the new Windows Live Messenger. http://go.microsoft.com/?linkid=9650731

1 0

ldapsearch lower than timestamp
by Thorsten Kohlhepp 02 Apr '09

02 Apr '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, my LDAP server doesn't respond the entries when I'm trying to do a ldapsearch like this ldapsearch -x -D cn=Admin,o=netmldap -W -h ldap-dm "(netmzMRDBPortingDate<=20090310000000Z)" But it does respond the entries when I'm doing the LDAP search in reverse order ldapsearch -x -D cn=Admin,o=netmldap -W -h ldap-dm "(netmzMRDBPortingDate>=20090301000000Z)" the schema to netmzMRDBPortingDate is this: attributetype ( 1.3.6.1.4.1.13255.1.2.1.2 NAME 'netmzMRDBPortingDate' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) I've set an index on that attribute in slapd.conf as well. And I also ran several times a slapindex but it doesn't help. Does anybody know how to check if the indexing of this attribute worked and why it isn't responding the entries? Thanks for your help Ciao Thorsten - -- Systemadministrator First Telecom GmbH Lyoner Straße 15 60528 Frankfurt am Main Tel: +49 (0) 69 65006 577 Mob: +49 (0) 172 5397 083 thorsten.kohlhepp(a)first-telecom.de www.first-telecom.de Sitz der Gesellschaft: Frankfurt am Main Handelsregister: Amtsgericht Frankfurt am Main, HRB 56145 Geschäftsführer: Dieter Plassmann Diese E-Mail einschließlich ihrer Anhänge ist vertraulich. Wir bitten eine fehlgeleitete E-Mail unverzüglich vollständig zu löschen und uns eine Nachricht zukommen zu lassen. Wir haben die E-Mail vor dem Versenden auf Virenfreiheit geprüft. Eine Haftung für Virenfreiheit schließen wir aus. This email including its attachments are confidential. If you are not the intended recipient of this email, please delete it immediately and inform us accordingly. This email was checked for viruses when sent, however, we are not liable for any virus contamination. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknUctoACgkQd7jm+sUEqbWcLACfcBv2dQx8MGPOxY1X5ZYiZPDH bysAnRQU2qWOiqxsgZQfIFAYeTyd4Gst =jEYR -----END PGP SIGNATURE-----

1 0

slapd syncrepl failure in OpenLDAP 2.3.43
by Magne Land 02 Apr '09

02 Apr '09

Hi, I am using OpenLDAP 2.3.43 with BDB 4.5.20. I wonder if anyone has seen this error before? It happened 37 times during a timespan of 6 hours or so (with the same missing key/data pair). The replica 001 would not replicate during this time. The "solution" was to shut it down and copy data over from another replica. Excerpt from syslog: Mar 27 08:42:57 accdir2 slapd[3810]: => bdb_idl_insert_key: c_get next_dup failed: DB_NOTFOUND: No matching key/data pair found (-30989) Mar 27 08:42:57 accdir2 slapd[3810]: null_callback: error code 0x50 Mar 27 08:42:57 accdir2 slapd[3810]: conn=79260530 fd=39 ACCEPT from IP=10.21.10.23:50796 (IP=0.0.0.0:389) Mar 27 08:42:57 accdir2 slapd[3810]: syncrepl_entry: rid 001 be_add failed (80) Mar 27 08:42:57 accdir2 slapd[3810]: do_syncrepl: rid 001 retrying I'm pretty sure that the first line is generated in OpenLDAP-2.3.43/servers/slapd/back-bdb/idl.c but the code is too tense for me to understand (or vice versa). Regards, Magne Land

1 0

Setup access rights via cn=config - segmentatin fault
by Michal Rejda 01 Apr '09

01 Apr '09

Hi, Im trying to setup access rights using cn=config. When I setup the rights and then try to connect to the server as non-rootdn user, the server often ends with segmentation fault. When I perform this as rootdn user, the server run correctly. When I setup the rights and the server didnt crash, the new rights arent used. If I restart the server, the rights are correct. Im using OpenLDAP version 2.4.11. I thing this behavior is a bug. Regards, Michal Last few lines from console, where the server was running: >>> slap_listener(ldap:///) connection_get(18): got connid=7 connection_read(18): checking for input on id=7 ber_get_next ldap_read: want=8, got=8 0000: 30 36 02 01 01 60 31 02 06...`1. ldap_read: want=48, got=48 0000: 01 03 04 25 63 6e 3d 6d 72 65 6a 64 61 2c 64 63 ...%cn=mrejda,dc 0010: 3d 6d 61 6a 2d 75 6b 2c 64 63 3d 6b 65 72 69 6f =maj-uk,dc=kerio 0020: 2c 64 63 3d 6c 6f 63 61 6c 80 05 68 65 73 6c 6f ,dc=local..heslo ber_get_next: tag 0x30 len 54 contents: ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=7 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=mrejda,dc=maj-uk,dc=kerio,dc=local> <<< dnPrettyNormal: <cn=mrejda,dc=maj-uk,dc=kerio,dc=local>, <cn=mrejda,dc=maj-uk,dc=kerio,dc=local> do_bind: version=3 dn="cn=mrejda,dc=maj-uk,dc=kerio,dc=local" method=128 bdb_dn2entry("cn=mrejda,dc=maj-uk,dc=kerio,dc=local") Segmentation fault __________ Informace od ESET NOD32 Antivirus, verze databaze 3979 (20090331) __________ Tuto zpravu proveril ESET NOD32 Antivirus. http://www.eset.cz

2 1

RE: can't delete bdb backend from cn=config
by Michal Rejda 01 Apr '09

01 Apr '09

> Am Montag 30 März 2009 09:41:30 schrieb Michal Rejda: > > > Am Freitag 27 März 2009 08:51:57 schrieb Michal Rejda: > > > > Hello, > > > > > > > > Im trying to delete olcDatabase={1}bdb,cn=config using > ldapmodify: > > > > > > > > dn: olcDatabase={1}bdb,cn=config > > > > changetype: delete > > > > > > > > But the server answer is: > > > > > > > > deleting entry "olcDatabase={1}bdb,cn=config" > > > > ldap_delete: Server is unwilling to perform (53) > > > > > > > > I'm performing this operation as rootdn why can I not delete the > entry? > > > > > > back-config does not support the deletion of complete database, > overlay > > > or schema entries by default. There is however experimental delete > > > support for databases and overlays. You can enable that by building > with > > > -DSLAP_CONFIG_DELETE. > > > > I'm able to delete the overlay now. But I cannot delete the database. > What > > I'm doing wrong? > The code for deleting databases is only available in HEAD currently it > seems. > If you really need that feature you might want to try backporting it. > IIRC it > is mostly in the config_back_delete() function in > servers/slapd/bconfig.c. But > this is experimental code, so you have been warned ;). Thank you Ralf, I will try it :) Michal

1 0

RE: can't delete bdb backend from cn=config
by Michal Rejda 31 Mar '09

31 Mar '09

> Am Freitag 27 März 2009 08:51:57 schrieb Michal Rejda: > > Hello, > > > > Im trying to delete olcDatabase={1}bdb,cn=config using ldapmodify: > > > > dn: olcDatabase={1}bdb,cn=config > > changetype: delete > > > > But the server answer is: > > > > deleting entry "olcDatabase={1}bdb,cn=config" > > ldap_delete: Server is unwilling to perform (53) > > > > I'm performing this operation as rootdn why can I not delete the entry? > back-config does not support the deletion of complete database, overlay or > schema entries by default. There is however experimental delete support for > databases and overlays. You can enable that by building with > -DSLAP_CONFIG_DELETE. I'm able to delete the overlay now. But I cannot delete the database. What I'm doing wrong? > > > My OpenLDAP version is 2.4.11 > > > > Thanks, > > Michal > > -- > regards, > Ralf Thanks, Michal

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software