[Date Prev][Date Next]
I set up an ldap server three years ago in our university in order to
have a single password via samba and lib???-ldap.
Later on I requested an OID from IANA then created my own schema. It was
working quite well.
A few months ago another organization's data was migrated to ldap (it is
in testing now). In the meanwhile I switched to the latest openldap
release (2.3). The older setup used ldbm backend the newer one is bdb
based as ldbm is gone.
To get some kind of separation first I created two backends and with the
help of an OpenLDAP core developer I set up slapo-glue to be able to
search in both ldap suffix (needed for the mailserver which is the same
for the two organization, other services are separated now). It was
working, but I get weird timeouts on the mail server (it worked
perfectly in the previous setup) and on the file server too. Syncrepl
did not work at all so in order to get my replica back to work again
I put all in one backend. Now I use a round-robin dns to distribute the
load as before (slurpd replication).
I tuned the indices to avoid the timeouts and ran slapindex. I get no
more index_param failed messages so I suspect all the needed indices are
here. But the timeouts were still here.
My last hope was DB_CONFIG but it did not fix my problem.
here is my DB_CONFIG:
set_cachesize 0 134217728 2
# Automatically remove log files that are no longer needed.
# Setting set_tas_spins reduces resource contention from multiple
# clients on systems with multiple CPU's.
I was unable to set up set_lg_* values right so they are commented out.
I have 768Mb RAM. Debian Sarge. OpenLDAP 2.3 HEAD as 2006-09-25. libdb4.2.
I turned up loglevel and the message which annoyes me most is:
<= bdb_index_read: failed (-30990)
In db.h I found:
#define DB_NOTFOUND (-30990)/* Key/data pair not found (EOF). */
but I do not know what does it mean in this context.
Please tell me what to do.
Thanks in advance!
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
-- Brian W. Kernighan
CSILLAG Tamas (cstamas) - http://digitus.itk.ppke.hu/~cstamas