Without any changes to my ldap server, it's decided to no longer sucessfully start slapd. Sure, it makes the motion, but it appears to just die upon startup and it's game-over.
The only thing I see in the logs is a sucessful startup; there's nothing to tell me it's died, other than the fact it doesn't work, and a lack of a 'slapd' entry in ps.
Anyone have any ideas? This is SO annoying!
On Tue, 2005-02-01 at 08:33 -0600, Brian Fahrlander wrote:
Without any changes to my ldap server, it's decided to no longersucessfully start slapd. Sure, it makes the motion, but it appears to just die upon startup and it's game-over.
The only thing I see in the logs is a sucessful startup; there'snothing to tell me it's died, other than the fact it doesn't work, and a lack of a 'slapd' entry in ps.
Anyone have any ideas? This is SO annoying!
---- perhaps you need to db_recover if it is dbd files. If it is ldbm, I am not clear on method to recover. FWIW - I run a weekly script that slapcat's the db to a backup directory and thus I could nuke the files and slapadd/slapindex in no time.
Craig
On Tue, 2005-02-01 at 07:40 -0700, Craig White wrote:
perhaps you need to db_recover if it is dbd files. If it is ldbm, I am not clear on method to recover. FWIW - I run a weekly script that slapcat's the db to a backup directory and thus I could nuke the files and slapadd/slapindex in no time.
Thanks for the fast reply. Did you know there's no man page for db_recover? There's also something called /usr/sbin/slapd_db_recover; is that likely to be any use? (db_recover, alone seems to go nowhere and I'm guessing at the 'usage' statement)
Thanks again!
On Tue, 2005-02-01 at 08:53 -0600, Brian Fahrlander wrote:
On Tue, 2005-02-01 at 07:40 -0700, Craig White wrote:
perhaps you need to db_recover if it is dbd files. If it is ldbm, I am not clear on method to recover. FWIW - I run a weekly script that slapcat's the db to a backup directory and thus I could nuke the files and slapadd/slapindex in no time.
Thanks for the fast reply. Did you know there's no man page for db_recover? There's also something called /usr/sbin/slapd_db_recover; is that likely to be any use? (db_recover, alone seems to go nowhere and I'm guessing at the 'usage' statement)
---- cd /var/lib/ldap #or wherever your ldap *.dbd files are located db_recover
does your slapd.conf use ldbm or dbd? - that may be an important question
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
Craig
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?
does your slapd.conf use ldbm or dbd? - that may be an important question
It's bdb. Lucky I changed to that, I suppose.
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...
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 thedirectory 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
On Tue, 2005-02-01 at 08:53 -0600, Brian Fahrlander wrote:
On Tue, 2005-02-01 at 07:40 -0700, Craig White wrote:
perhaps you need to db_recover if it is dbd files. If it is ldbm, I am not clear on method to recover. FWIW - I run a weekly script that slapcat's the db to a backup directory and thus I could nuke the files and slapadd/slapindex in no time.
Thanks for the fast reply. Did you know there's no man page for db_recover? There's also something called /usr/sbin/slapd_db_recover; is that likely to be any use? (db_recover, alone seems to go nowhere and I'm guessing at the 'usage' statement)
---- oh and by the way...logging is your friend
loglevel -1 #setting in /etc/openldap/slapd.conf
will flood your syslog if you haven't caught ldap stuff in syslog.conf with something like... local4.* /var/log/slapd.log
but the logs will surely tell you what is going on
Craig
On Tue, 2005-02-01 at 08:10 -0700, Craig White wrote:
oh and by the way...logging is your friend
loglevel -1 #setting in /etc/openldap/slapd.conf
will flood your syslog if you haven't caught ldap stuff in syslog.conf with something like... local4.* /var/log/slapd.log
but the logs will surely tell you what is going on
Cool; for now, it's running- I suppose the fix worked.
Now what was this about your slick little backup routine?
:>
On Tue, 2005-02-01 at 09:52 -0600, Brian Fahrlander wrote:
On Tue, 2005-02-01 at 08:10 -0700, Craig White wrote:
oh and by the way...logging is your friend
loglevel -1 #setting in /etc/openldap/slapd.conf
will flood your syslog if you haven't caught ldap stuff in syslog.conf with something like... local4.* /var/log/slapd.log
but the logs will surely tell you what is going on
Cool; for now, it's running- I suppose the fix worked. Now what was this about your slick little backup routine?
---- you're lucky to get your horse back
service ldap stop slapcat -l /home/backup/ldap/slapdump.ldif service ldap start
do this manually till you get it right create a script to do this set the script in cron to do this on a regular basis
Craig
-
Brian Fahrlander -
Craig White