[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Serious Concurrency problem with openldap-2.0.X
To sum up, it seems that there is a serious concurrency problem in
some multi-threaded versions of openldap 2.0.X and that many users out
there might be affected without being aware of the problem. The problem
does not affect single-threaded versions (compiled with --without-threads as
is apparently the case with the version distributed with RedHat-7.2) so check
if your version is really multi-threaded before doing the simple test
given below.
In my previous post ("Search failure during update") I asked why I get no
result from a search query while an update query is running on the entry
being searched. I consider this kind of behaviour completely unacceptable
in a serious environment. Imagine for example your SMTP server bouncing
mail because the recipient is changing his password when the SMTP server
is querying the LDAP server for the recipient email address.
At first, I thought that this problem was the result of something wrong I
did during the build process but no one gave me a hint of what could solve
this problem. Later on, I made more tests with several combinations
of platforms/openldap versions/DB package and in each case I got the
problem. Is it possible to build a correctly working multi-threaded
version of openldap and if so I would like to know exactly how this can be
done on my platforms ?
Here are the combo with multi-threaded openldap I have tested. All have
the problem:
Platforms Openldap ver DB package
1) RedHat-7.2 2.0.21 Berkeley DB 3.2.9
2) AIX-4.3.3 2.0.11 gdbm-1.8
3) AIX-4.3.3 2.0.21 Berkeley DB 3.3.11
Here are the details of the build config for each combo:
1) Extremely simple:
./configure --prefix /usr/local/openldap-2.0.21
The Berkeley DB package used is the one distributed with RedHat-7.2
2) To make it build on AIX I had to follow the method described in
http://www.openldap.org/its/index.cgi/Build?id=1134
export CC=cc_r
export CFLAGS="-O2 -qmaxmem=8192"
export CPPFLAGS="-I/usr/local/include"
export LDFLAGS="-L/usr/local/lib"
./configure --prefix=/usr/local/openldap-2.0.11 \
--with-ldbm-api=gdbm \
--enable-wrappers \
--enable-shared=no
3) export CC=cc_r
export CFLAGS="-O2 -qmaxmem=8192"
export CPPFLAGS="-I/usr/local/include"
export LDFLAGS="-L/usr/local/lib"
./configure --prefix=/usr/local/openldap-2.0.21 \
--enable-wrappers \
--enable-shared=no
In all the three cases, the "make test" runs without any problem including
the "concurrency test" which is part of the tests performed by "make test".
Does this "concurrency test" test a concurrent update and search of the
same entry ? I dought it, otherwise my test (given below) would not fail.
Details of the test revealing the problem
------------------------------------------
In order to help you run the test I did, I give you all the details of
this simple test:
1) slapd.conf
#
#
# Modify this to reflect where your schema files are installed.
#
include /usr/local/openldap/etc/openldap/schema/core.schema
pidfile /usr/local/openldap/var/slapd.pid
argsfile /usr/local/openldap/var/slapd.args
loglevel 256
schemacheck on
#######################################################################
# ldbm database definitions
#######################################################################
database ldbm
suffix "dc=xyz,dc=com"
rootdn "cn=Manager,dc=xyz,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd/tools. Mode 700 recommended.
directory /tmp/test-db
# Indices to maintain
#
index cn,sn,givenName eq,sub
index objectClass pres,eq
#
# END OF SLAPD.CONF
#
2) Databse content:
Make sure your slapd is not running and create the test DB with
"slapadd -f slapd.conf -l test.ldif". With test.ldif containing:
dn: dc=xyz, dc=com
objectClass: top
dn: cn=Manager, dc=xyz, dc=com
objectClass: top
objectClass: organizationalRole
cn: Manager
dn: ou=People,dc=xyz,dc=com
objectClass: top
objectClass: organizationalUnit
ou: People
dn: cn=toto,ou=People,dc=xyz,dc=com
objectclass: top
objectclass: person
cn: toto
sn: dudu
userpassword: secret
3) Start slapd with the config file given above. Put the following
two commands in the same shell script file.
ldapmodify -x -D 'cn=Manager,dc=xyz,dc=com' -w secret -f update.ldif &
ldapsearch -x -D 'cn=Manager,dc=xyz,dc=com' -w secret -b 'dc=xyz,dc=com' '(
cn=toto)' 'cn'
the file update.ldif contains:
dn: cn=toto,ou=People,dc=xyz,dc=com
changetype: modify
replace: userpassword
userpassword: secret
4) Run the shell script just created SEVERAL times. If the version of
openldap you use is NOT affected by the problem you should ALWAYS get
the following output:
modifying entry "cn=toto,ou=People,dc=xyz,dc=com"
version: 2
#
# filter: (cn=toto)
# requesting: cn
#
# toto, People, xyz, com
dn: cn=toto,ou=People,dc=xyz,dc=com
cn: toto
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
If your version has the problem, sometimes you will get the correct output
(as above) and sometimes you will get the wrong output (which tells you that
the entry does not exist) as follows:
modifying entry "cn=toto,ou=People,dc=xyz,dc=com"
version: 2
#
# filter: (cn=toto)
# requesting: cn
#
# search result
search: 2
result: 0 Success
# numResponses: 1
Am I the only one who have this serious problem ?
Thanks for your help.
----
Michel