[Date Prev][Date Next]
Re: Corrupt LDAP DB ...
I also have seen this problem. I have a master and syncrepl OpenLDAP
pair on various versions from 2.2.18
to 2.2.2x and get seemingly random database corruption problems on the
master. To fix this, I slapcat the slave,
delete the master db and slapadd it to the master, delete the slave
database and restart both - this of course fixes
When the problem presents itself, the master refuses to answer queries
and usually hangs the connection, often
there are quite a few active conenctions to slapd, all hung. If I
slapcat the master's database, the slapcat will
get to a certain point and then hang.
I have no idea what could be causing this, we never caught it on a log
:( It's odd as we are not doing much
that is clever, not many updates but quite a few reads (ISP auth
system). I did have a DB_CONFIG
but deleted it as performance was fine without it and I removed it to
rule it out.
At the moment I am testing 2.3.11 on some lab boxes, but as per the last
posts syncrepl does not seem
to work at the moment.. On the subject of which, does anybody know why
this would happen wioth
ldap 2.3.11 and bdb 4.3.29
root@server1:/database/openldap/openldap-data# slapadd -vwl /root/test.ldif
slapadd: database doesn't support necessary operations.
Obviously I am doing something stupid here ;-)
C.Lee Taylor wrote:
Thanks for you input ...
Quanah Gibson-Mount wrote:
Try reading the man page specific to the BDB backend: slapd-bdb
Thanks, found it.
RedHat's support of OpenLDAP has always been bad. They have been the
absolute worst linux distro to run LDAP on using what they ship that
Well, can't have everything for free and expect it to be perfect,
where would the fun be in that ...
You aren't stopping slapd when you wipe your database? That's really
bad.... And you need to stop slapd to run slapadd or to run db recovery.
No, I don't need to stop slapd, because it's not in memory, as
there is no pid and there are no files open for the LDAP DB ... I was
just saying that by the time we see that LDAP has crash, it has crash
... We can't even start it up again.
Then we move the DB dir to a backup location and create the
complete DB structure from scratch, then import the LDAP DB by doing a
slapadd and then an slapindex just to make sure it's all in place.
Then change owner and perms. Then restart the LDAP server and all is
well again for a few days ...
I highly suggest moving to 2.3, because it will take care of a number
of issues. However, you seem to have a lack of the basic concepts
necessary to run an LDAP server, so I also suggest you do a bit of
I would like to move to 2.3, and have been watching it's
development for a while, as I did 2.1, and 2.2, but that did not put
me off using them.
I have been running OpenLDAP for a long time, and believe myself
enough read to be able to mange my small setup, it's that the basic
install of a FC/RH system does seem to have a problem, and that is why
I have ask the people that use, if they have any ideas of what I might
be doing wrong. I have searched the net to see if anyone else might
have had similar problems, but it's seem I'm the only bloke that can
corrupt his LDAP DB without doing all his homework!?
I have found ways around this corruption, written a few scripts to
backup, restore and sync the LDAP DB with little effort at the moment,
but I don't believe that LDAP should just stop working for no reason
I'm able to find at the moment.
If it's is a miss configuration, please help me, to find it and
fix it, and document it so that nobody else runs into this problem.