--On Saturday, October 28, 2006 7:47 PM +0200 Mohamed AR
> I'm using BDB
> I need to know is this problem related to openldap or bdb
> and what cause of this problem
> I restored my data from backup and now it's working
If you wish continued help, please keep replies to the list.
Frankly, you supplied no information that helps one determine the cause of
the problem. I understand you are using sleepycat BDB as your database
software. Which OpenLDAP database backend are you using? See the
"database XXX" part of slapd.conf. It would be one of ldbm, bdb, or hdb.
In any case, you are using ancient versions of the OpenLDAP software, with
many known (and since fixed) bugs. 2.2.13 had many serious problems,
including security holes. You really should be upgrade to at least 2.2.30.
Principal Software Developer
ITS/Shared Application Services
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Hi openldap guys
I'm working with
kernel 2.6.9-22.EL with Centos 4
the system handle about 1200 record for 3 months without any problem but
suddenly when I run slapcat I got this error
# no data for entry id=0000000a
*** glibc detected *** malloc(): memory corruption: 0x08910b88 ***
I need to know what's up with my system although the system is still running
for authentication without any problem
Hi guys, i'm having a little problem with back-perl behaving a little
oddly, i recently dug out some code I wrote last year and i've setup
openldap 2.2 on my laptop to do some development work, i've compiled it
with back-perl (Against perl 5.8.8) and dropped the module in and almost
Except bind, when doing any kind of bind operation openldap doesn't call
the bind method, ever, i had no problems with the code previously under
openldap 2.2 and perl 5.8.6 and i'm damned if i can figure out why bind
Any suggestions would be greatly appreciated.
Is there any way to specify sasl-secprops separately for each transport type?
For ldapi:/// is want "sasl-secprops noanonymous,noplain",
and "sasl-secprops noanonymous,noplain,noactive" for the rest.
The idea is to require SASL GSSAPI for everyone with only exception
for clients connecting via ldapi (like heimdal KDC) - they need SASL
I have two OpenLDAP servers using Linux debian etch and openldap version
2.3.27. The second server is using syncrepl for replication against the first
If I update the master server whatsover the operation, slapd on the master
segfault. When I restart slapd, everything goes fine and the slave comes up
to date. If syncprov is disabled when updating the master, everything goes
I provide the log while doing /usr/sbin/slapd -h ldaps://0.0.0.0/
ldap://0.0.0.0/ -g openldap -u openldap -d 9
I get the following when using OpenLDAP:
ldap_new_connection 1 1 0
ldap_connect_to_host: TCP discovery.adtest.process.com:636
ldap_connect_to_host: Trying 188.8.131.52:636
ldap_connect_timeout: fd: 4 tm: -1 async: 0
TLS: could not load verify locations (file:`VAM:DISCOVERY.PEM',dir:`').
What exactly does this mean?
| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |
Hi, I'm experimenting a strange behaviour using back-meta +
slapo-pcache + glue, I have a configuration similar to this:
proxycache bdb 10000 3 100 100
suffixmassage "dc=dir1,dc=ext,dc=blabla,dc=com" "dc=w2k3,dc=blabla,dc=local"
If I do a search under "dc=dir1,dc=blabla,dc=com" and this search is
not in cache, everything works ok, but if the search is obtained from
cache, I obtain two different answers to the same 'search' request
from slapd, one of them with result code '0' (success) and another one
with code 53 (unwilling to perform), although I also obtain the
correct result entries. Digging a bit with gdb, I see that the
'unwilling to perform' error is sended in backglue.c (glue_op_search
function). Am I maybe doing something wrong on the configuration or is
that a normal behaviour?
For some reason, I'm now getting a ERROR: Constraint violation:
entryCSN: no user modification allowed
when replicating between two 2.3.19 LDAP servers. I just rebuilt
replication on the slave box. What could be wrong?
Ceterum censeo, Carthago delenda est.
Sr. Systems Administrator