2)I don't think the Fedora packages run db recovery automatically.
I don't seeing anything like that, so I don't think so ... I will
look into this.
Stop, slapd, and run database recovery ('slapd_db_recover -h
/home/services/ldap/za/db' or similar), check the permissions on the
db files, and start slapd.
When the DB get's corrupt, no need to stop slap, have delete the
default DB and my DB and restart from scratch and slapadd in my
current DB ... with is only 1000 entries.
Will a slapd_db_recover not lose any data?
Well, a resync would be *much* easier with sync-repl ... trash the DB
and restart it. But, you probably want 2.3.x for that ..
At the slave sites, I have rsync over what is there, it's quick
because most of the data is fine, just something is not ...
I'm really waiting for FC to dump there OpenLDAP packages to
2.3.11 ... Messed with sync-repl for test in 2.2, but it's a little
buggy ...
Get a better init script if you're going to stick with 2.2.x. 2.3.x
does recovery itself when necessary (and
What do you mean, get a better init script ... I think the one in
FC4 is not bad ... Given me a bit of trouble when I wanted to funny
thing like use included for my conf files so not to have to duplicate
too much ...
FYI, I'm running the Mandriva 2.3.11 packages I maintain (and rebuild
on RHEL3/RHEL4), you may want to take a look ...
Taken a look, where is the srpm? I can download that and compile
a package to play with on a test system.
I could be convinced to get an FC3 or FC4 chroot installed (x86 or
x86_64).
I can't seem to find a pattern, it's not like we doing allot of
updates or something ... I see somebody in the list asking if it's
because of using different LDAP clients and browsers, but I can't see
how that would be a problem.
So, I don't really want to waste your time by setting up a chroot
system, I would like to find what is causing this ... Thanks.
I have added the the checkpoint options and put the logs way up,
hoping I will see something.
Thanks again.
Mailed
Lee