On Tue, 2005-02-01 at 09:47 -0600, Brian Fahrlander wrote: > On Tue, 2005-02-01 at 08:08 -0700, Craig White wrote: > > cd /var/lib/ldap #or wherever your ldap *.dbd files are located > > db_recover > > It was strangely quiet. I tried it in /var/lib/ldap and in the > directory where my data's located....very quiet. Shouldn't it report > something? ---- it might log something in syslog or other log - otherwise proof is in the pudding - service ldap restart either works or doesn't work. Of course, it may not be damaged dbd files at all - see other message about logging...logging is your friend and typically the way to find out what is wrong. ---- > > does your slapd.conf use ldbm or dbd? - that may be an important > > question > > It's bdb. Lucky I changed to that, I suppose. ---- yes, helps to log (dbd logs are different from ldap logging) and checkpoint - make db_recover much more effective ---- > > > grep ldbm /etc/openldap/slapd.conf > > grep dbd /etc/openldap/slapd.conf > > > > one of those is going to tell you this > > > > and db_recover - I'm not sure how/if it works with ldbm > > Well I sure appreciate your help; I'd otherwise have no recourse, I > suppose... ---- Set up ldap to log as per previous. Start ldap service - look at logs - problem should be evident If dbd files are hosed, then delete them - perhaps only an index or two are hosed, you can delete those files and re-index (slapindex) fix the permissions, start ldap and you're on your way. If the main db is damaged and can't be fixed by db_recover, then you will have to toast the files and reload from your last slapcat (you do slapcat once in a while don't you?) Craig
