openldap-software

openldap-software@openldap.org

2719 discussions

Mysterious slow-down of slapd with hdb
by Johan Jönemo 27 Feb '07

27 Feb '07

Hello! I am trying to use openLDAP to hold a small but continuously rebuilt database with a hdb backend. Basically I build a directory under a temporary node and move it into place when its ready (hence the hdb, I want to move the hole tree into place in one go). I build a new directory, move out the current to an other temporary node and move in the new one. Lastly I delete the defunct tree and start over building a new tree. In short the idea is to always (except I suppose between moving the tree out and the new in, but I don't see any solution for that) have a complete tree in place while continuously trying to have it updated. This thing works well for a couple of hours on the machine I am running it (PIII 1 cpu, 1000MHz, 512 Mb ram, linux 2.6 kernel), but then slows down by a factor 10-20. Why is this and what can I do to stop it? (easy to ask...) free shows: # free total used free shared buffers cached Mem: 508104 501992 6112 0 31268 332556 -/+ buffers/cache: 138168 369936 Swap: 2104504 2904 2101600 This isn't brilliant of course but AFAIU not catastrophic either. I have about the same when it isn't slowed down. vmstat with a sampling rate of a few seconds show no swapping before or after slapd slows down. top shows that slapd and the script populating it runs at about 2-3% each and not much cpu consumption apart from that (consistent with a system that slows down a factor 20 I guess). The script uses Net::LDAP in perl (over local socket) so no external clients are invoked. The really puzzling bit is that if a shut down slapd and the "directory builder" - thus reclaiming memory and filedescriptors and such to the system - and then restart them I almost immediately get the same slow down. In fact, the time it takes to get the computer to slow down after firing up slapd seems proportional to how long I let it "rest". I have tried all sorts of things to analyze this and finally decided to profile slapd. I rebuilt it with -g -pg in CFLAGS and --enable-debug to configure (actually I have used that switch all along). I also discovered that I had to replace 'strip = -s' with 'strip =' in all makefiles even though --enable-debug was given (is this intentional or a bug in configure?). Finally I had to get the gprof-helper (and confirm that it was used) by Hocevar/Jönsson to be able to profile threaded applications. The result doesn't however tell me much. The slapd process seems to spend most (70-80%) of its time in the "at_next" routine. Info about system: I am running v2.3.24 of slapd. built with: ./configure --program-prefix=jj4 --with-threads=yes --enable-dynamic --enable-debug --enable-crypt --enable-lmpasswd --enable-spasswd --enable- modules --enable-backends=mod --enable-sql=no --enable-ldap=mod --enable-meta=mod --enable-monitor=mod --enable-null=mod --enable-perl=no --ena ble-relay=mod --enable-shell=mod --enable-overlays=mod --enable-denyop=mod --enable-dyngroup=mod --enable-dynlist=mod --enable-lastmod=mod --enable-proxycache=mod --enable-retcode=mod --enable-rwm=mod --enable-dependency-tracking (lots of modules are built but only hbd-backend is actually loaded when I'm running) These are the relevant and nonsensitive parts of the slapd.conf: --- sizelimit 1000000 moduleload back_hdb.la database hdb suffix *removed* rootdn *removed* rootpw *removed* directory /usr/local/lis/var/db checkpoint 512 5 dirtyread dbconfig set_cachesize 0 16777216 8 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_lg_max 16777216 dbconfig set_flags DB_LOG_AUTOREMOVE index objectClass eq --- I use dirtyread because I want to be able to read while I'm writing (which is almost always) while an occasional bad read is acceptable (it should anyway be very rare since I don't do the modifications in the "current" tree where I read). Thanks in advance Johan Jönemo

2 1

Re: Migrating openldap db backend from ibdm to bdb
by Howard Chu 27 Feb '07

27 Feb '07

Buchan Milne wrote: > But, if you were to install a vanilla Windows XP (without the hardware > vendor's customised release, or their support pack), you would be in a > similar position. I don't think comparing hardware driver support (for > hardware which has only been supported since after the distro shipped) is > necessarily the same as requiring latest and greatest versions of software > (when the distros in many cases shipped the "stable" release in the first > place). Perhaps it was a poor analogy. The point is, the distro shipped with a driver that claimed to support my hardware, and it didn't work correctly. That's different from having no driver at all, no claimed support at all... >> The problems are exacerbated by the clumsy design of the >> pam_ldap/nss_ldap mechanisms, which cause system-level functionality to >> pollute user-program namespaces. If distros would take the proper steps >> to hide the symbols of their dynamically loaded pam/nss modules from >> user code, then most of the compatibility issues would disappear. > > Should this not rather be fixed once upstream? > > Upstream software can be much better supported by the distributions when it's > default installation is sane ... I think the steps required vary depending on what other library dependencies are involved, and only the people compiling the package can determine that. > Consider that most distributions now ship with ~ 3000 packages in a somewhat > comprehensive distribution (and anything from 10 000 to 30 000 if you include > the full repos), and you'll agree that the distribution can't fix *all* bugs > in *all* software ... it works much better if it's fixed once upstream. I don't know if you can call a basic design flaw (nss architecture) a simple bug. In that case, you have to complain to the glibc maintainers - the problem goes further upstream than you realize. Also if you are releasing a distro, you are implicitly promising that all of the software you provide actually works, and works in the combination that you distribute. The upstream folks don't have any control over how you combine their individual pieces. The distro provider is the only entity that has that control, and has that ultimate responsibility. Time has shown that in practice, the majority of distro providers don't have the manpower or the competence to back up their promise. I.e., many of the players in that game should be doing something else with their lives... >> I have a feeling that not enough people complain to their distro vendors >> about these problems, and so the distros continue to pretend the >> problems don't exist. > > Or, maybe: > 1)people need to file more bugs on nss_ldap > 2)bugs filed on nss_ldap etc. should be addressed more aggressively Which is presently not a topic for the OpenLDAP-Software list. (It could become such, if someone were to contribute an nss_ldap module to the OpenLDAP repository.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ldap hot standby/backup
by Asrai khn 26 Feb '07

26 Feb '07

Hi, I have configured replica of our master ldap server "ldap.mycompany.com" using slurpd. ,replica is ldap2.mycompany.com. Everything is working fine, I checked it by changing some value 'password' at master and it got replicated to replica. Now I am wondering how to make this setup of master/slave 'hot standby" so that if master got down slave takes over, and the ldap client applications which using "ldap.ourcompany.com" never complain for unavailability of authentication backend. All our ldap clients appication (wiki, ldapphpamdin, our corporate portal etc) using ldap.ourcompany.com which point to IP of master in our DNS. ie DNS records.. ldap.ourcompany.com -----> IP of master ldap server ldap2.ourcompany.com ----> IP of replica ldap server Any suggestion will be highly appreciated. Thanks. Askar

2 1

Samba entries in openldap
by Chechu 26 Feb '07

26 Feb '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, my question is the next: I want the entries sambaLMPassword sambaNTPassword to point kerberos kdc, like userPassword does...but openldap is unable to do..and I'd like to modify this ...someone can guide me to change it? thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF24R/u1kTJztljjMRAntCAJ9b/1xKmI+wBHiKpyiE+MC7gZVVwgCeJCjV t8YjQrmTbj6V9rzg9gStX9I= =8Rjv -----END PGP SIGNATURE-----

5 5

Re: Migrating openldap db backend from ibdm to bdb
by Asrai khn 26 Feb '07

26 Feb '07

> > Actually, it would be better to have a subdirectory under /var/run > (e.g. /var/run/ldap) that is owned by the LDAP user, and use that for > argsfile/pidfile. Yes later I did the same created /var/run/slapd directory and chown to ldap > > > This usually means that the user slapd is running as does not have > permission > to create new files, so ensure that that user owns your database directory > (or log directory if you have configured via DB_CONFIG for them to be in > another directory). Thanks it has been resolved now. Thanks. Askar

1 0

Schema changes: Removal of attribute
by Wolfgang Hennerbichler 26 Feb '07

26 Feb '07

Hi ldap people, I guess this has been asked before, but I couldn't find precious information on google (other than "don't do that"). I am trying to tidy up my custom schema definition. If I remove an attribute (and restart ldap and so on), the attribute is still visible. Well, I guess it's still in the database. Is there a possibility other than slapcat | grep | slapadd to remove these attributes from the database? ldap 2.3.30-2. Thanks for a short pointer; wogri -- wogri(a)wogri.com http://www.wogri.com http://www.einradfilm.at

2 2

Sync Replication issues with bindmethod=simple
by Michael Cassaniti 25 Feb '07

25 Feb '07

Hi, I have followed the OpenLDAP v2.3 Software Administrators Guide to using Sync Replication. I have the following snippets for my LDAP servers. [provider] overlay syncprov syncprov-checkpoint 10 60 syncprov-sessionlog 100 [consumer] syncrepl rid=101 provider=ldap://192.168.0.4 type=refreshOnly interval=00:00:30:00 retry="05 +" searchbase="dc=home,dc=net" bindmethod=simple binddn="uid=ldap,ou=Users,dc=home,dc=net" credentials=secret I have checked that I can authenticate using simple authentication as user ldap (via ldapwhoami) against the sync provider server. This was successful. I also know that the credentials information, which is in SSHA form is correct. The problem is that there is a bind issue. In particular it returns the following error in the log on the consumer: do_syncrep1: ldap_sasl_bind_s failed (49) On the provider, there is not much information to determine the error. I extracted the following: Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: activity on 1 descriptor Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: activity on: Feb 24 22:13:14 Home-Server4 slapd[3749]: Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: listen=7, new connection on 12 Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: added 12r (active) listener=(nil) Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: epoll: listen=7 active_threads=1 tvp=zero Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: activity on 1 descriptor Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: activity on: Feb 24 22:13:14 Home-Server4 slapd[3749]: 12r Feb 24 22:13:14 Home-Server4 slapd[3749]: Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: read active on 12 Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: epoll: listen=7 active_threads=1 tvp=zero Feb 24 22:13:14 Home-Server4 slapd[3749]: => access_allowed: auth access to "uid=ldap,ou=Users,dc=home,dc=net" "userPassword" requested Feb 24 22:13:14 Home-Server4 slapd[3749]: => acl_get: [1] attr userPassword Feb 24 22:13:14 Home-Server4 slapd[3749]: => slap_access_allowed: no res from state (userPassword) Feb 24 22:13:14 Home-Server4 slapd[3749]: => acl_mask: access to entry "uid=ldap,ou=Users,dc=home,dc=net", attr "userPassword" requested Feb 24 22:13:14 Home-Server4 slapd[3749]: => acl_mask: to value by "", (=0) Feb 24 22:13:14 Home-Server4 slapd[3749]: <= check a_dn_pat: self Feb 24 22:13:14 Home-Server4 slapd[3749]: <= check a_dn_pat: cn=root,dc=home,dc=net Feb 24 22:13:14 Home-Server4 slapd[3749]: <= check a_dn_pat: uid=ldap,ou=users,dc=home,dc=net Feb 24 22:13:14 Home-Server4 slapd[3749]: <= check a_dn_pat: anonymous Feb 24 22:13:14 Home-Server4 slapd[3749]: <= acl_mask: [4] applying auth(=xd) (stop) Feb 24 22:13:14 Home-Server4 slapd[3749]: <= acl_mask: [4] mask: auth(=xd) Feb 24 22:13:14 Home-Server4 slapd[3749]: => slap_access_allowed: auth access granted by auth(=xd) Feb 24 22:13:14 Home-Server4 slapd[3749]: => access_allowed: auth access granted by auth(=xd) Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: activity on 1 descriptor Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: activity on: Feb 24 22:13:14 Home-Server4 slapd[3749]: 12r Feb 24 22:13:14 Home-Server4 slapd[3749]: Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: read active on 12 Feb 24 22:13:14 Home-Server4 slapd[3749]: connection_read(12): input error=-2 id=0, closing. Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: epoll: listen=7 active_threads=1 tvp=zero Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: activity on 1 descriptor Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: activity on: Feb 24 22:13:14 Home-Server4 slapd[3749]: Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: epoll: listen=7 active_threads=1 tvp=zero Feb 24 22:13:14 Home-Server4 slapd[3749]: daemon: removing 12 I don't think, though I could be wrong, that this has anything to do with poor ACLs being set. I also tried the bind using the rootdn, but this also failed. The output log from the provider gave the folllowing: Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: activity on 1 descriptor Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: activity on: Feb 24 22:16:03 Home-Server4 slapd[4083]: Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: listen=7, new connection on 12 Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: added 12r (active) listener=(nil) Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: epoll: listen=7 active_threads=1 tvp=zero Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: activity on 1 descriptor Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: activity on: Feb 24 22:16:03 Home-Server4 slapd[4083]: 12r Feb 24 22:16:03 Home-Server4 slapd[4083]: Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: read active on 12 Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: epoll: listen=7 active_threads=1 tvp=zero Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: activity on 1 descriptor Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: activity on: Feb 24 22:16:03 Home-Server4 slapd[4083]: 12r Feb 24 22:16:03 Home-Server4 slapd[4083]: Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: read active on 12 Feb 24 22:16:03 Home-Server4 slapd[4083]: connection_read(12): input error=-2 id=0, closing. Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: epoll: listen=7 active_threads=1 tvp=zero Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: activity on 1 descriptor Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: activity on: Feb 24 22:16:03 Home-Server4 slapd[4083]: Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: epoll: listen=7 active_threads=1 tvp=zero Feb 24 22:16:03 Home-Server4 slapd[4083]: daemon: removing 12 As you can see, none of this is very forthcoming for information. Log level is set to 28904, so there should be a high amount of logging done to show any/all errors. Modifying the ACLs on the provider to: access to * by * write still returned this error. What suprises me is that this is an SASL error, when SASL is not used for a simple bind. Like I have already stated, this is a configuration straight from the OpenLDAP Guide, so what have I done wrong.

2 3

Segmentation Fault
by Wolfgang Hennerbichler 24 Feb '07

24 Feb '07

Hi LDAP Folks, I do have a weird problem, I didn't have before. slapd version 2.3.30-2 (debian etch). If I alter any entry in the ldap database, the entry is stored. As soon as I read from the slapd again, it shows (in debug mode) the following message VERY often: slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 ==> limits_get: conn=0 op=22 dn="cn=admin,dc=bla,dc=bla" And finally, after watching lines scroll by, says good by with an: Segmentation fault Did I run into a bug here? I slapcat'ed the db, removed the db, slap- added the db just in case the db was corrupt, but this didn't help. Any help would be appreciated. Same slapd version working fine on another installation. Thank you for a short note... wogri -- wogri(a)wogri.com http://www.wogri.com http://www.einradfilm.at

6 12

Proxy to "other directory server" with authentication?
by Mark Colaluca 24 Feb '07

24 Feb '07

Hello: I'm looking to set up a few OpenLDAP servers as pure query-only proxies (no update at this point) to our "other directory" servers we happen to use in our environment. We'd like to keep the security settings we currently have on these "other directory" servers that only allows users with valid accounts on the said "other directory" server to query the server. What would be the simplest, quickest configuration to achieve this? Should I create a generic 'ldapuser' account on the "other directory" server and use those credentials every time? Can I "pass" a user's credentials as part of my proxy request? I've read through the Admin Guide and the sample slapd.conf files, and I'm a little stumped as to how to proceed - I only made it as far as setting up the very basic proxy server. current slapd.conf ---------------------------- database ldap lastmod off uri "ldap://ouradserver.ourdomain.com:389/DC=ourdomain,DC=com" suffix "dc=ourdomain,dc=com" Thanks for any tips and pointers, --Mark

2 1

WARNING: No dynamic config support for database ldbm
by Asrai khn 23 Feb '07

23 Feb '07

Hi, After upgrading our ldap server to FC5 and openldap-2.3.19-4 (we are using yum to update packages). We getting ... WARNING: No dynamic config support for database ldbm when starting ldap services, however it starts fine and we are not facing any issues while authentication from that openldap or adding new entries to it using phpldapadmin. I have read in archives of this mailing list that ldbm backend is going to be removed when 2.4 releases, now my concern is 1) how to fix this warning or just ignore it 2) If recommend to migrate to another backend database eg bdb, then how to convert the current records to it so that if we change 'database' directive in slapd.conf to 'bdb' it gives no error and migration would seem transparent. Another problem which we are facing is our ldap replication is broken after we upgraded our slave ldap server to FC6 which comes with newer version of openldap 'openldap-2.3.27-4', when we tries to start ldap services on slave it exit with error... Checking configuration files for slapd: WARNING: No dynamic config support for database ldbm. unable to open file "/var/run/slapd.pid": 13 (Permission denied) I am no expert of openldap neither is ldap is configured by me, now i have to fix the replication and all other warnings.. 1) Can we replication older version of openldap (master) to newer version of openldap (slave) currently master (FC5) < slave (FC6) Any help in this regards will be greatly appreciated. Thanks.

6 10

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software