[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Corrupt LDAP DB ...

Hiya All,

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
it all..

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:

Greetings ...

    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 I've seen.

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 reading.

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.