openldap-software February 2009

openldap-software@openldap.org

48 participants
51 discussions

ldapmodify command line tool results in 'deferring operation: too many executing'
by Sean Burford 26 Feb '09

26 Feb '09

[originally sent to wrong list] Hi, During a recent ldapmodify of 1000 records, I got some "deferring operation: too many executing" messages from OpenLDAP slapd 2.3.39. I am surprised by this, since I thought that since ldapmodify waited for the result of each operation nothing would be queued. Could this be caused by there being too many operations in progress across the entire server? This was the ldapmodify command line: ldapmodify -v -H "ldaps://master.example.com" -x -W -D "uid=person,ou=people,dc=example,dc=com" -c -f file.ldif The ldif only contained OpenLDAPaci attribute deletes that fit this template: dn: cn=host1000.example.com,ou=servers,dc=example,dc=com changetype: modify delete: OpenLDAPaci The ldapmodify output looked normal: delete OpenLDAPaci: modifying entry "cn=host1000.example.com,ou=servers,dc=example,dc=com" modify complete delete OpenLDAPaci: modifying entry "cn=host1001.example.com,ou=servers,dc=example,dc=com" modify complete But the logs show the 'deferring operation: too many executing': Feb 24 08:27:54 server slapd[9433]: conn=19226 op=640 MOD dn="cn= host1000.example.com,ou=servers,dc=example,dc=com" Feb 24 08:27:54 server slapd[9433]: conn=19226 op=640 MOD attr=OpenLDAPaci Feb 24 08:27:54 server slapd[9433]: conn=19226 op=640 RESULT tag=103 err=0 text= Feb 24 08:27:54 server slapd[9433]: connection_input: conn=19226 deferring operation: too many executing Feb 24 08:27:54 server slapd[9433]: conn=19226 op=641 MOD dn="cn= host1001.example.com,ou=servers,dc=example,dc=com" Feb 24 08:27:54 server slapd[9433]: conn=19226 op=641 MOD attr=OpenLDAPaci Feb 24 08:27:54 server slapd[9433]: conn=19226 op=641 RESULT tag=103 err=0 text= -- Thanks, Sean Burford -- Thanks, Sean Burford

2 1

Oracle back_sql support question openldap-2.4.11
by King, Leon C 25 Feb '09

25 Feb '09

Does OpenLdap support an oracle backend database? I have an existing database with users that I'd like to put an LDAP interface in front of to service other clients. Is this possible? Thanks, Leon

3 6

Delta-syncrepl problem
by Jeff Schroeder 24 Feb '09

24 Feb '09

Hello, I'm attempting to setup a delta-syncrepl replication scheme to replace an aging slurpd installation and am having troubles. After trying about 4 different tutorials and going through the docs this is almost working. When bringing up a new ldap slave, it copies the database down from the provider and seems to mirror it locally. When making additions to the master, they do not replicate down to the slaves. The slave's syslog has lots of entries like this: Feb 24 17:50:37.012 ns1.mad01.mtt slapd[21033]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (32) No such object Feb 24 17:50:37.057 ns1.mad01.mtt slapd[21033]: do_syncrep2: rid=000 (32) No such object Feb 24 17:50:37.086 ns1.mad01.mtt slapd[21033]: do_syncrepl: rid=000 retrying ldapsearch -x -b 'o=mtt' 'uid=newlyaddeduser' -H ldap://provider # Shows the user ldapsearch -x -b 'o=mtt' 'uid=newlyaddeduser' -H ldap://slave # Does not show anything If anyone has ANY suggestions or pointers towards the source of this problem I'd really appreciate it. Thanks! ========= PROVIDER slapd.conf =========== include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema access to attrs=userPassword by self write by anonymous read by dn.base="cn=Manager,o=mtt" write by dn.base="cn=Replicator,o=mtt" read by * read access to * by self write by anonymous read by dn.base="cn=Manager,o=mtt" write by dn.base="cn=Replicator,o=mtt" read by * read by * read pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel none modulepath /usr/lib64/openldap/ moduleload syncprov moduleload accesslog sizelimit 500 tool-threads 2 backend hdb database config database hdb directory /var/lib/ldap suffix cn=accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart database hdb suffix "o=mtt" directory /var/lib/ldap rootdn "cn=Manager,o=mtt" rootpw <SHA1 HASH HERE> overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE syncprov-checkpoint 1000 60 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 limits dn.exact="cn=Replicator,o=mtt" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq lastmod on checkpoint 512 30 database monitor monitoring on ===================================== =========== SLAVE slapd.conf ============ include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema access to attrs=userPassword by self write by anonymous read by dn.base="cn=Manager,o=mtt" write by dn.base="cn=Replicator,o=mtt" read by * read access to * by self write by anonymous read by dn.base="cn=Manager,o=mtt" write by dn.base="cn=Replicator,o=mtt" read by * read by * read pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel none sizelimit 500 tool-threads 2 backend hdb database monitor monitoring on database hdb suffix "o=mtt" directory /var/lib/ldap rootdn "cn=Manager,o=mtt" rootpw <SHA1 PASSWORD HASH HERE> syncrepl rid=0 provider=ldap://ldap.lax03.mtt:389 bindmethod=simple binddn="cn=Replicator,o=mtt" credentials=<PLAINTEXT PASSWORD HERE> searchbase="o=mtt" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog updateref ldap://ldap.lax03.mtt ===================================== -- Jeff Schroeder Don't drink and derive, alcohol and analysis don't mix. http://www.digitalprognosis.com

2 1

how to change the umask of dbd fies by slapd
by zhangweiwu＠realss.com 20 Feb '09

20 Feb '09

Hello. I run a backup script on hdb backended slapd. The backup script which uses slapcat, for security reasons, does not run as user 'openldap' but as 'backup', which is a user of the openldap group. At first the script couldn't work because all dbd files are owned by openldap:openldap with permission 600. I changed to 660 then it works. However the new files created by slapd in bdb directory is still 600. Since the default umask on the system is 022 (file permission should be 644), it's clear slapd did not follow the default umask, then I think changing umask before launching slapd wouldn't work neither. I RTFM (slapd) and didn't find a way to control umask for BDB files. Is my approach of doing the backup wrong, or are there other ways to control default umask for bdb files for slapd? Thanks. I searched the f*** web before posting.

2 1

Re: OpenLDAP crashes with segfault
by Quanah Gibson-Mount 20 Feb '09

20 Feb '09

--On Friday, February 20, 2009 9:34 AM +0100 Tim Stone <tmstn68(a)googlemail.com> wrote: >>> >>> Can anyone help me? >> >> >> What openldap release are you using? > > @(#) $OpenLDAP: slapd 2.4.9 (Aug 12 2008 23:57:15) $ > abuild@james:/usr/src/packages/BUILD/openldap-2.4.9/servers/slapd > > It is the latest official release on OpenSuse 11! Please keep replies on the list. I'm going to move this particular thread to OpenLDAP-software, however. >> Also, in general, you probably have to >> set one of {kernel,fs}.suid_dumpable (the name of it depends on the >> kernel version) to 2 and you may need to modify /etc/profile to allow >> subprocesses to get ulimit -c unlimited. > > Thanx for this advise, I'll try this!! Please upgrade to OpenLDAP 2.4.14 first. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Verify Connection to LDAP with Oracle backend.
by King, Leon C 18 Feb '09

18 Feb '09

I've finally configured openldap-2.4.11, back_sql, and oracle. I've imported the test database implemented by database scripts online which creates the tables ( persons, documents, etc ). Now my problem is how do I view all of the LDAP entries? I'm a newbie at this, so any help would be appreciated. include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema # Define global ACLs to disable default read access. #include /usr/local/etc/openldap/slapd.access.conf # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/slapd.pid argsfile /usr/local/var/slapd.args defaultsearchbase dc=example,dc=com #make sure you have (or the apropriate monitor module) moduleload back_sql access to * by * read ####################################################################### # sql database definitions ####################################################################### database sql suffix "dc=example,dc=com" dbname OracleODBC-10g dbuser XXX dbpasswd XXX subtree_cond "UPPER(ldap_entries.dn) LIKE CONCAT('%',UPPER(?))" insentry_stmt "INSERT INTO ldap_entries (id,dn,oc_map_id,parent,keyval) VALUES (ldap_entry_ids.nextval,?,?,?,?)" upper_func UPPER Thanks, Leon King Development Team Lead OASIS/ICIS WEB Service Assurance Outside: 919-378-6626 v-net: 965-6626

2 5

Performance of search with filter (entryDN=<DN>)
by Michael Ströder 18 Feb '09

18 Feb '09

HI! Not sure whether this has discussed before. I have to deal with a third-party application where single entries are read by sub-tree search with filter (entryDN=<DN>). That cannot be easily changed. The database is rather small (<10000 entries) so I simply tried to generate an equality index for entryDN which does not seem to be possible (slapd shows error message when reading config). So I wonder whether this sort of filter is already optimized out with the dn2id.bdb index. Ciao, Michael.

2 1

shared memory vs memory mapped files
by Brett ＠Google 17 Feb '09

17 Feb '09

Hello, Does anyone have any opinions on the merits of bdb/hdb backends, in conjunction with using shared memory (adding shm_key <n> to a hdb or bdb backend) vs., in comparison with plain-old memory mapped files ? I've performed a quick / simple benchmark via a slapd load, and performance with shared memory appears at least, to be approximately 5 minutes faster, on what was originally a 20 minute load (on the same hardware) using slapadd -q for approx 90k entries. Shared memory does not seem to write any transactional bdb logs to the disk, so i was wondering how robust it is with respect to recovery in the face if improper or unexpected server shutdowns, when compared to memory mapped files, whih can be recovered with db_recover to get back to a consistant state ? I assume shared memory either does not have bdb transaction logs, or they are stored in memory so would be lost in the event of a server crash. I note the benchmark files from Symas use memory mapped files, so i'm assuming there is a clear performance benefit, is this true ? So if there is a clear query performance or other benefit, is there any additional risk of corruption over memory mapped files (vs. the 25% load speed improvement) ? Cheers Brett

3 2

2.4.14 : compilation fails with "--with-tls=gnutls"
by COMBES Julien - CETE Lyon/DI/ET/PAMELA 17 Feb '09

17 Feb '09

Hello, When I try to build openldap 2.4.14. with the option "--with-tls=gnutls", the compilation fails with this error: /bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls2.c cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls2.c -fPIC -DPIC -o .libs/tls2.o tls2.c: In function 'ldap_pvt_tls_get_option': tls2.c:642: error: 'struct ldapoptions' has no member named 'ldo_tls_crlcheck' tls2.c: In function 'ldap_pvt_tls_set_option': tls2.c:773: error: 'struct ldapoptions' has no member named 'ldo_tls_crlcheck' make[2]: *** [tls2.lo] Erreur 1 With the option "--with-tls=openssl", the compilation ends correctly. I have compiled openldap 2.4.13 on the same computer with the option "--with-tls=gnutls" without problem. I have looked in to the code, I don't understand why some of the "#ifdef HAVE_(OPENSSL|GNTUTLS)*" have disappeared in the new file tls2.c. Regrards, Julien

2 2

Precluding hardware-dependent issues
by Michael Ströder 17 Feb '09

17 Feb '09

HI! I have strange seg faults when sending a SASL/DIGEST-MD5 bind with OpenLDAP 2.4.11 running with BDB 4.6.21p1 on different VMware machines running with SLES 10. I plan to update both software packages anyway but, as usual, the customer is a little bit scared of upgrading. ;-) I'd also like to figure out what the real problem is since on one machine it simply works and it does not on another. I've checked pre-installed SuSE packages, all related config files, file ownership/permissions and dynamic linking of slapd (ldd output). Everything seems ok. Start over with slapadd-ing to an empty DB didn't help either. Running slapd -d 32767 on the concole shows that the SASL user is correctly mapped to the user's entry DN but immediately after that slapd crashes. (Can't grab a useful backtrace with the installed build though.) Both machines are identical except that one VMware machine is running on an AMD processor where also the build was made and the other VMware machine is running on an Intel processor where the built files were just copied to. (This copying worked from one AMD machine to another). So I currently suspect that there's a processor-dependent optimization done especially in the BDB build. How can I avoid that? See the current BDB build script below. Any other suspectible compile time option? Many thanks in advance. Ciao, Michael. ------------------------------ snip ------------------------------ export CFLAGS="-O2" cd build_unix rm config.status make clean ../dist/configure \ --prefix=/appserver/bdb-4.6 \ --with-uniquenames \ --enable-diagnostic \ --enable-shared \ --enable-static \ --enable-rpc \ --disable-java \ --enable-posixmutexes \ --enable-largefile \ --enable-cxx \ --disable-compat185 \ i686-suse-linux make

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software February 2009