openldap-software February 2007

openldap-software@openldap.org

94 participants
112 discussions

Retrieving single schema attribute from Oracle backend
by ebru.zeren＠nokia.com 27 Feb '07

27 Feb '07

Hi I am new in OpenLDAP so I would appreciate if you can help me with below questions. 1) Once a schema is built on LDAP server (no backend DB), is it possible to fetch only a single attribute of the schema from an external Oracle DB and the rest of sttributes from LDAP server itself? What is required to fulfill it? (i.e. Configuration example????) 2) Can Open LDAP server fetch different schema attributes from different external DB by configuration? Or does it require another box fulfilling proxy functionality? Thanks for answers Ebru

3 2

test007 fail for 2.3.34
by Gerard Ranke 27 Feb '07

27 Feb '07

Hi all, When compiling 2.3.34, I ran into a make test error for test007 where replication via slurpd is tested: >>>>> Starting test007-replication ... running defines.sh Starting master slapd on TCP/IP port 9011... Starting slave slapd on TCP/IP port 9012... Using ldapsearch to check that master slapd is running... Using ldapsearch to check that slave slapd is running... Starting slurpd... Using ldapadd to populate the master directory... Waiting 15 seconds for slurpd to send changes... Using ldapmodify to modify master directory... Waiting 15 seconds for slurpd to send changes... Stopping the slave... Waiting 5 seconds for slave slapd to die... Applying more changes to the master slapd... Stopping slurpd... Waiting 5 seconds for slurpd to die... Applying more changes to the master slapd... Restarting slave slapd on TCP/IP port 9012... Using ldapsearch to check that slave slapd is running... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Restarting slurpd... Waiting 15 seconds for slurpd to send changes... Try updating the slave slapd... ldapmodify failed (1)! kill: 2730635: no such process >>>>> ./scripts/test007-replication failed (exit 1) *** Error code 1 (bu21) *** Error code 1 (bu21) From the slurpd log file: ldap_connect_to_host: Trying 127.0.0.1:9012 ldap_connect_timeout: fd: 6 tm: -1 async: 0 ldap_close_socket: 6 ldap_err2string Error: ldap_simple_bind_s for localhost:9012 failed: Can't contact LDAP server ldap_unbind Retrying operation for DN cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com on replica localhost:9012 end replication thread for localhost:9012 fm: exiting slurpd: terminated. and from the slapd.2 log: backend_startup_one: starting "dc=example,dc=com" bdb_db_open: dc=example,dc=com bdb_db_open: database already in use backend_startup_one: bi_db_open failed! (-1) slapd shutdown: initiated ====> bdb_cache_release_all slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. It looked to me like maybe the old slave slapd was still running, so I looked at the process table, and found that not only that, but all slapd's from previous tests were still running. If I'm not mistaken the test scripts are trying to shut slapd with a HUP signal. However, reading in the Administrator guide I would say that slapd should be stopped with INT. Is that right and should I change HUP into INT, or is something else wrong? Best regards, Gerard Ranke

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software February 2007