openldap-software March 2010

openldap-software@openldap.org

55 participants
43 discussions

Re: max open files
by Matheus Morais 22 Mar '10

22 Mar '10

Well, IMHO this is a really bad excuse and I was not expecting to hear that in this list. Klements, You can get slapd source packages and change the flags as you want. Serious distribution packages as Debian packages shouldn't be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages policy are very strong and help a lot stable environments to be bug-free from recent less stable versions. I use Debian as a protection from that too early versions who can potentially threat my production environment and I was very successful with Debian packages in this attempt. You can also look for support on Debian IRC channels and lists. On Tue, Mar 16, 2010 at 3:05 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Tuesday, March 16, 2010 8:34 AM +0100 Klemens Kittan < > kittan(a)cs.uni-potsdam.de> wrote: > > Sounds like you're mostly on the right track, but I didn't hear mention >>> of compiling with a suitable OPENLDAP_FD_SETSIZE. Are your CPPFLAGS set >>> accordingly? >>> >> >> I use the OpenLDAP version from the distribution (Debian 5.0.4), >> > > There's your first mistake. > > <http://www.openldap.org/faq/data/cache/1456.html> > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

14 31

ACL
by Carlo Pradissitto 22 Mar '10

22 Mar '10

Hi, my DIT is some like this: *dc=<base>* *|__ dc=<domain_1>* *| |__ o=<org_1>* *| | |__cn=user_domain1_1* *| | |__cn=user_domain1_2* *| | |__cn=user_domain1_3* *| |__ o=<org_2>* *| |__cn=user_domain1_3* *| |__cn=user_domain1_4* *| |__cn=user_domain1_5* *|__ dc=<domain_2>* * |__ o=<org_3>* * | |__cn=user_domain2_1* * | |__cn=user_domain2_2* * | |__cn=user_domain2_3* * |__ o=<org_4>* * |__cn=user_domain2_3* * |__cn=user_domain2_4* * |__cn=**user_domain2_5* I would like to create one administrative account for each domain (<domain_1> and <domain_2>) Here is my way: I create a new branch: *dc=<base>* *|__ o=Administrators* * |__ou=<domain_1>_Administrators* * |__ cn=Administrator1* then I insert a new directive in slapd.conf *access to dn.subtree="dc=<domain_1>,dc=<base>" by dn="cn=Administrator1,ou=<domain_1>Administrators,o=Administrators,dc=<base>" write* Here the response when I try to connect with <domain_1>Administrators credentials: *Error opening connection:* *[LDAP: error code 49 - Invalid Credentials]* Here the OpenLDAP's output in debug mode *daemon: activity on 1 descriptor* *daemon: activity on: * *slap_listener_activate(7): * *daemon: epoll: listen=7 busy * *>>> slap_listener(ldap://<my_host>:1389)* *daemon: activity on 1 descriptor * *daemon: activity on: * *daemon: epoll: listen=7 active_threads=0 tvp=NULL* *daemon: listen=7, new connection on 11 * *daemon: added 11r (active) listener=(nil) * *daemon: activity on 1 descriptor * *daemon: activity on: * *daemon: epoll: listen=7 active_threads=0 tvp=NULL* *daemon: activity on 1 descriptor * *daemon: activity on: 11r * *daemon: read active on 11 * *daemon: epoll: listen=7 active_threads=0 tvp=NULL* *connection_get(11): got connid=1000 * *connection_read(11): checking for input on id=1000* *ber_get_next * *ber_get_next: tag 0x30 len 83 contents: * *op tag 0x60, time 1268990296 * *ber_get_next* *daemon: activity on 1 descriptor* *daemon: activity on:* *daemon: epoll: listen=7 active_threads=0 tvp=NULL* *conn=1000 op=0 do_bind* *ber_scanf fmt ({imt) ber:* *ber_scanf fmt (m}) ber:* *>>> dnPrettyNormal: <cn=Administrator1,ou=<domain_1>Administrators,o=Administrators,dc=<base>>* *<<< dnPrettyNormal: <cn=Administrator1,ou=**<domain_1>Administrators,o=Administrators,dc=<base>>, <cn=administrator1,ou=**<domain_1>dministrators,o=administrators,dc=<base>>* *do_bind: version=3 dn="cn=Administrator1,ou=**<domain_1>Administrators,o=Administrators,dc=<base>" method=128* *bdb_dn2entry("cn=administrator1,ou=** <domain_1>administrators,o=administrators,dc=<base>")* *=> bdb_dn2id("dc=<base>")* *<= bdb_dn2id: got id=0x1* *=> bdb_dn2id("o=administrators,dc=<base>")* *<= bdb_dn2id: got id=0x12* *=> bdb_dn2id("ou=**<domain_1>administrators,o=administrators,dc=<base>")* *<= bdb_dn2id: got id=0x13* *=> bdb_dn2id("cn=administrator1,ou=** <domain_1>administrators,o=administrators,dc=<base>")* *<= bdb_dn2id: got id=0x14* *entry_decode: "cn=Administrator1,ou=** <domain_1>Administrators,o=Administrators,dc=<base>"* *<= entry_decode(cn=Administrator1,ou=** <domain_1>Administrators,o=Administrators,dc=<base>)* *send_ldap_result: conn=1000 op=0 p=3* *send_ldap_response: msgid=1 tag=97 err=49* *ber_flush2: 14 bytes to sd 11* *daemon: activity on 1 descriptor* *daemon: activity on: 11r* *daemon: read active on 11* *daemon: epoll: listen=7 active_threads=0 tvp=NULL* *connection_get(11): got connid=1000* *connection_read(11): checking for input on id=1000* *ber_get_next* *ber_get_next on fd 11 failed errno=0 (Success)* *connection_read(11): input error=-2 id=1000, closing.* *connection_closing: readying conn=1000 sd=11 for close* *daemon: activity on 1 descriptor* *daemon: activity on:* *daemon: epoll: listen=7 active_threads=0 tvp=NULL* *connection_close: conn=1000 sd=11* *daemon: removing 11* Same result with this policy: *access to dn.subtree="dc=**<domain_1>,dc=<base>" by * write* I can access only with this policy: *access to * by * write* I compiled opneldap 2.4.21 with default settings Here my slapd.conf: *include /sw/test_domain_openldap-2.4.21/etc/openldap/schema/core.schema* *include /sw/test_domain_openldap-2.4.21/etc/openldap/schema/cosine.schema* * * *pidfile /sw/test_domain_openldap-2.4.21/var/run/slapd.pid* *argsfile /sw/test_domain_openldap-2.4.21/var/run/slapd.args* * * *#######################################################################* *# BDB database definitions* *#######################################################################* * * *database bdb* *suffix "dc=<base>"* *rootdn "cn=Manager,dc=<base>"* *rootpw testdomain* *directory /sw/test_domain_openldap-2.4.21/var/openldap-data* *index objectClass eq* * * *access to * by * write* *#access to dn.subtree="dc=<domain_1>,dc=<base>" by * write* *#access to dn.subtree="**dc=<domain_1>,dc=<base>" by dn="cn=Administrator1,ou=<domain_1>Administrators,o=Administrators,dc=<base>" write* thanks in advance! Carlo

3 3

max open files
by Klemens Kittan 19 Mar '10

19 Mar '10

Hello, the problem is, that many clients generate more than 1024 concurrent sockets to the LDAP service which block the remaining incoming sockets. I already do all the possible changes to the server (ulimit, sysctl, etc) without a solution. All the incoming connections stop at the 1024 concurrent sockets. The only solution is restarting slapd. The version of openldap is 2.4.11. In /var/log/syslog I found the following entry: Mar 1 14:45:15 ldap1 slapd[25320]: warning: /etc/hosts.allow, line 19: cannot open /etc/hosts.allow: Too many open files cat /proc/sys/fs/file-max: 203609 cat /proc/<slapd pid>/limits: Max open files 4096 4096 files Regards, Klemens -- Klemens Kittan Systemadministrator Uni-Potsdam, Inst. f. Informatik August-Bebel-Str. 89 14482 Potsdam Tel. : +49-331-9773125 Fax. : +49-331-9773122 eMail : kittan(a)cs.uni-potsdam.de gpg --recv-keys --keyserver wwwkeys.de.pgp.net 6EA09333

7 8

RE: Memory Usage Spikes
by Quanah Gibson-Mount 18 Mar '10

18 Mar '10

--On Thursday, March 18, 2010 3:47 PM -0400 "Beuerlein, Edward" <Edward_Beuerlein(a)cable.comcast.com> wrote: > Hi Quanah, > Thanks for replying! Please let us know what other info you might need > to help us figure out these large increases in memory usage. > > Here's the info you requested: > > I did a dump of the database and then ran this on it(please let me know > if that isn't what you wanted): > ># cat auth01.031610.ldif |grep dn |wc -l > 60753 So you have 60,753 entries. Just to be sure, I would have used grep ^dn: to be exact. ;) > set_cachesize 0 268435456 1 You have 256MB allocated to BDB > 69M cn.bdb > 26M dn2id.bdb > 3.7M entryCSN.bdb > 2.2M entryUUID.bdb > 160K gidNumber.bdb > 2.1G id2entry.bdb > 840K ipHostNumber.bdb > 44K memberNisNetgroup.bdb > 304K memberUid.bdb > 3.1M nisNetgroupTriple.bdb > 2.9M objectClass.bdb > 8.0K ou.bdb > 8.0K sudoUser.bdb > 3.0M uid.bdb > 364K uidNumber.bdb > 792M uniqueMember.bdb > 2.9G total Your BDB database is 2.9GB. > olcDbCacheSize 1000 > olcDbCacheFree 1 > olcDbDNcacheSize 0 > olcDBIDLcacheSize 1000 You're only allowing the first 1000 entries to be cached in OpenLDAP, and your IdlCache is quite small as well. dncachesize is fine (unlimited). While none of this explains your memory spikes, your server is definitely poorly tuned. It may be that your massive discrepancy between BDB cache allocation and actual BDB size may be causing the problem (in looking at the bdb error messages in your log). I would highly advise the following changes. For DB_CONFIG set_cachesize 4 0 1 This will increase the BDB cache to 4GB (which can hold your 2.9GB DB easily) For cn=config: olcDbCacheSize 80000 olcDbCacheFree 1000 olcDBIDLcacheSize 240000 This will allow all entries to be cached in OpenLDAP, free up a reasonable number if you exceed the cache, and allow a decent IDL size. I forgot to ask which slapd backend you are using (hdb or bdb), and which version of BDB you are using (and if it is fully patched) which is also useful information. You may also wish to read over <http://wiki.zimbra.com/index.php?title=OpenLDAP_Performance_Tuning_6.0>, I think you guys have some experience with Zimbra... ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

Memory Usage Spikes
by Mathew Rowley 18 Mar '10

18 Mar '10

I have been running into some huge memory spikes, and was wondering if its normal, or if anyone has seen it before. Archtecture: OpenLDAP 2.4.21 Running on RH4 Ulimit open files upped to 4096 Masters: auth01.cmc, auth01.inflow Running n-way multimaster Slaves: rsa01.inflow, rsa02.inflow, rsa03.cmc, rsa04.cmc Syncrepl running off both masters refreshAndPersist with retry=²60 +² Here is a graph of the spikes we are seeing on auth01.cmc and auth01.inflow It also looks like the slave servers are only connecting to auth01; when looking at netstat on the auth boxes, I see: >From auth01.phil: tcp 0 0 auth01. inflow:ldap rsa04.cmc:46851 ESTABLISHED tcp 0 0 auth01.inflow:ldap rsa01.inflow:61648 ESTABLISHED tcp 0 0 auth01.inflow:ldap rsa01.inflow:61686 ESTABLISHED tcp 0 0 auth01.inflow:ldap rsa01.inflow:61683 ESTABLISHED tcp 0 0 auth01.inflow:48882 rsa02.inflow.:ldap ESTABLISHED tcp 0 109500 auth01.inflow:ldap rsa03.cmc:45798 ESTABLISHED tcp 0 0 auth01.inflow:ldap rsa02.inflow.:8773 ESTABLISHED >From auth01.cmc: tcp 0 0 auth01.cmc:ldap rsa02.inflow:8885 ESTABLISHED tcp 1 0 auth01.cmc:24310 rsa03.cmc:ldap CLOSE_WAIT tcp 0 0 auth01.cmc:ldap rsa01.inflow:61657 ESTABLISHED With refreshAndPersist, shouldn¹t each slave be connected to each host configured in syncRepl, and keep that connection? This is a pretty big issue today we had a master crash; got: Mar 18 14:39:43 auth01 slapd[17498]: bdb(dc=comcast,dc=com): malloc: 16422: Cannot allocate memory Mar 18 14:39:43 auth01 slapd[17498]: bdb(dc=comcast,dc=com): malloc: 32000: Cannot allocate memory Mar 18 14:39:43 auth01 slapd[17498]: bdb(dc=comcast,dc=com): PANIC: Cannot allocate memory Mar 18 14:39:43 auth01 slapd[17498]: bdb(dc=comcast,dc=com): PANIC: fatal region error detected; run recovery Mar 18 14:39:43 auth01 slapd[17498]: slap_graduate_commit_csn: removing 0x9b5d3ec8 20100318143943.437380Z#000000#001#000000 Mar 18 14:39:43 auth01 slapd[17498]: bdb(dc=comcast,dc=com): uniqueMember.bdb: write failed for page 35805 Mar 18 14:39:43 auth01 slapd[17498]: bdb(dc=comcast,dc=com): uniqueMember.bdb: unable to flush page: 35805 These boxes have 8gig ram; I am trying to figure out if this is normal and I just need to up the ram. Thanks for any help in advance.

2 1

accesslog logpurge and disconnected syncrepl consumers
by David Hawes 17 Mar '10

17 Mar '10

I'm using delta-syncrepl and noticed that my consumers were connecting to the provider once a day. After checking the logs and a few quick tests, I realized that these reconnects correspond to accesslog purging old entries (it was set to check every day). What I observe is that the provider purges the accesslog entries and then the consumer immediately unbinds. It then takes the retry interval of the consumer for syncrepl to reconnect. If changes occur during the consumer's retry interval, the consumer will contain stale data. This is not that big of a deal for me as my refresh interval is 60 seconds, but I did not see this noted anywhere. I should note that a search using the LDAP sync control with ldapsearch does not lose its connection when the accesslog is purged. Is it expected for consumers to disconnect on an accesslog logpurge?

2 2

SASL /usr/lib/sasl2/App.conf configuration
by Francis Swasey 17 Mar '10

17 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am attempting to set up OpenLDAP 2.4 on an RHEL5 system. I have applied patches that rename the OpenLDAP binaries to append 2.4 to the name, so it can co-exist with the standard RHEL5 rpms without causing issues. However, one unexpected side effect is that I don't know what it is now using as the name of the conf file in /usr/lib/sasl2. In reading the SASL section of the Admin Guide, I was directed to read the cyrus sasl sysadmin.html which tells me to "Check your application's documentation for specifics". Sadly, I can't find the specifics about how OpenLDAP is setting the SASL configuration file name in OpenLDAP's documentation. Which of the fine documents do I need to read? Thanks, - -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLe/7IAAoJEK5S4SsZ5NvS6lwP/1dyEWZys18QLCGW8wv23J9I 4YlbPe5Ci3TsxNWZAcUkAOgp1EEhOTqkJ3yboX2xDsS+gymIciJmtNWJrZmUpZLj BGdtMmLR9NTsgngk7Wta+HUeZ6iQcyLdnYRiF6hlXTpXB49TH2a9kgkbYXjLFcFb KWI90By0IZaQFZGC4kcLKLVH0OIvsO2akIH8gJL6q6lVefLHyaL0TCuA1xC7zWvK OHk/v8RhS3m1fuBtWcRnDLIezwI29z6tk2RpuL0rHP87y13UUw0UQIkgv2gzkQuw fxjErrIM2tkmwxeIyi+s4mAek94Y8794qD/xPpHdqHH0+qGkJfwL1FTiWkH4VQZU FbU+SJIzpc4WOL1GpudS+IXGE3XdcGGTgXynDdt3LQMx9xLfBXtadj5AbJnuyfvu BZXoVdcH+Cbr35nimYSGyqI/jfVJuNezMbQYwv/R39myJ0MDuNWNulCppq40tHDU UsTAMDvC2r4PsSNMbmeb7JqC5JP+AUwKtWWEi8otCuo6/UdVl5U8OpqZ9XbxaP69 U2ca8MplczCOzC0WNLajcccrqlT8UNvUzpVJCh3crpx5GTgKElPHUxGxTeutchu3 5EC5QpPZyD7eB5McMUNA2/3CtYq7Uf1cC5xtP1up6l9rw7kh4otxuvXd/b6MrxvA BVKlfNKdwBnKFDNr3OXC =eNRN -----END PGP SIGNATURE-----

2 5

back-ldap: using sasl external authentication with ldapi:///
by Kartik Subbarao 17 Mar '10

17 Mar '10

With 2.4.21, I'm trying to use SASL EXTERNAL authentication with a back-ldap instance pointed to another ldap server listening on the same host -- ldapi:///. Here is the config: database ldap suffix o=llnw uri ldapi:/// rebind-as-user true idassert-bind bindmethod=sasl saslmech=EXTERNAL This doesn't seem to work, it just results in a plain anonymous bind over ldapi: Mar 16 14:01:30 ed1-dev slapd[28774]: conn=1140 fd=22 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) Mar 16 14:01:30 ed1-dev slapd[28774]: conn=1140 op=0 BIND dn="" method=128 Mar 16 14:01:30 ed1-dev slapd[28774]: conn=1140 op=0 RESULT tag=97 err=0 text= [...] I've tried the various mode= arguments and even tried setting authcId/authzId, but ran into various errors. What I'm looking for is to have all incoming anonymous connections be mapped to the equivalent of this ldapsearch command: ldapsearch -H ldapi:/// -Y EXTERNAL <...> Which shows up in the slapd log like so: Mar 16 14:04:44 ed1-dev slapd[28774]: conn=1143 fd=62 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) Mar 16 14:04:44 ed1-dev slapd[28774]: conn=1143 op=0 BIND dn="" method=163 Mar 16 14:04:44 ed1-dev slapd[28774]: conn=1143 op=0 BIND authcid="gidNumber=389+uidNumber=389,cn=peercred,cn=external,cn=auth(a)LLNW.COM" authzid="gidNumber=389+uidNumber=389,cn=peercred,cn=external,cn=auth(a)LLNW.COM" Mar 16 14:04:44 ed1-dev slapd[28774]: conn=1143 op=0 BIND dn="gidNumber=389+uidNumber=389,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=112 Thanks, -Kartik

1 0

certificate warnings
by Brett ＠Google 16 Mar '10

16 Mar '10

Hello, Is there any way of supressing the SSL warning/error "TLS: hostname (XXXXX) does not match common name in certificate" for a syncrepl client ? This error is being returned by a syncrepl client which is negotiating SSL talking to a syncrepl server by using it's (actual / real) server name, but as the server name returns a certificate based on its (external / content switch) server name, the ssl library on the client waits for a randomly long time, and then returns the error above as the cert returned does not exactly match the hostname configured in the provider="" line, in the syncrepl client configuration. If it's indeed a warning, then the sycrepl client should ignore it, but it does not, so effectively it is an error as it causes the syncrepl client to abort it's connection. A hack might be to add the "external" name to /etc/hosts on each syncrepl client with the correct ip for each syncrepl server, but was hoping for something better. Cheers Brett

8 8

Re: Authentication Issue
by Quanah Gibson-Mount 16 Mar '10

16 Mar '10

--On Tuesday, March 16, 2010 5:42 PM +0000 Richard Golding <richard.golding(a)zen.co.uk> wrote: > Many Thanks - That did the trick Glad to hear it worked. Please keep replies at least cc'd to the list though. Thanks! --Quanah > Quanah Gibson-Mount wrote: >> --On Friday, March 12, 2010 7:24 AM +0000 Richard Golding >> <richard.golding(a)zen.co.uk> wrote: >> >>> I am trying to setup a server and running into an issue whereby I cannot >>> authenticate using the rootdn. (I am new to OPENLDAP so apologies in >>> advance if this is a basic question) >>> >>> The problem is I get "Invalid Credentials" returned >>> >>> >>> Here is an excerpt from my Slapd.conf file >>> >>> database bdb >>> suffix "dc=my-domain,dc=com" >>> checkpoint 1024 15 >>> rootdn "cn=Manager,dc=my-domain,dc=com" >>> # Cleartext passwords, especially for the rootdn, should >>> # be avoided. See slappasswd(8) and slapd.conf(5) for details. >>> # Use of strong authentication encouraged. >>> rootpw secret >>> rootpw {crypt}ijFYNcSNctBYg >> >> Don't use crypt passwords. Use the slappasswd command to generate >> yourself a nice SSHA hash. >> >> --Quanah >> >> >> >> -- >> >> Quanah Gibson-Mount >> Principal Software Engineer >> Zimbra, Inc >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software March 2010