ldapmodify command line tool results in 'deferring operation: too many executing'
by Sean Burford
[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
14 years, 7 months
Oracle back_sql support question openldap-2.4.11
by King, Leon C
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
14 years, 7 months
Delta-syncrepl problem
by Jeff Schroeder
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
14 years, 7 months
how to change the umask of dbd fies by slapd
by zhangweiwu＠realss.com
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.
14 years, 7 months
Re: OpenLDAP crashes with segfault
by Quanah Gibson-Mount
--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
14 years, 7 months
Verify Connection to LDAP with Oracle backend.
by King, Leon C
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
14 years, 7 months
Performance of search with filter (entryDN=<DN>)
by Michael Ströder
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.
14 years, 7 months
shared memory vs memory mapped files
by Brett ＠Google
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
14 years, 7 months
2.4.14 : compilation fails with "--with-tls=gnutls"
by COMBES Julien - CETE Lyon/DI/ET/PAMELA
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
14 years, 7 months
Precluding hardware-dependent issues
by Michael Ströder
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
14 years, 7 months
