Thanks for the help everyone.  Turns out that the tech coord was mis-typing the chown command, thus the *db* files weren't being reset properly to be owned by ldap. Once he noticed this, and correctly set ownership of /var/lib/ldap to 
ldap.ldap, everything started up properly.  I have now found that it is very difficult to troubleshoot typos. :)<br><br>I do have backups running nightly for the database, but trying to walk the tech coord through the steps via the phone when he is being pressured by teachers/etc is not a fun thing.  I wouldn't have an issue with resetting the database from the backups, but not something I want to try remotely just yet.
<br><br>Anyhow, thanks! thanks! Now, I can get back to my vacation.  <br><br>Sincerely,<br>Dave Hopkins<br><br><br><div><span class="gmail_quote">On 2/15/07, <b class="gmail_sendername">David Trask</b> <<a href="mailto:dtrask@vcsvikings.org">
dtrask@vcsvikings.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Have you been backing up your ldap database?  If so go to the
<br>smbldap_installer support site and read about disaster recovery<br><a href="http://www.vcsvikings.org/docuwiki/cgi-bin/moin.cgi/">http://www.vcsvikings.org/docuwiki/cgi-bin/moin.cgi/</a><br><br><br>"Support list for open source software in schools." <
<a href="mailto:k12osn@redhat.com">k12osn@redhat.com</a>><br>writes:<br>>I go on vacation, so of course the server has problems :)<br>><br>>The linux server used for ldap authentication crashed yesterday.  Now,
<br>>ldap will not start successfully.  This means that samba will not start<br>>and that means users can' t log onto the windows servers..  Also, I have<br>>a slave ldap server running and we are currently authenticating against
<br>>that server for the linux logins.  However, my windows terminal servers<br>>want to use the main authentication server.<br>><br>>So, I had the tech coordinator try running the following.<br>><br>>sladp_db_recover -v -h /var/lib/ldap
<br>><br>>but this does not correct the issue since then running<br>><br>>/etc/init.d/ldap start will not start ldap.  It returns a message that<br>>slapd failed to start.<br>><br>>The tech director is now trying:
<br>><br>>slapd_db_recover -v -h /var/lib/ldap<br>>chown -R ldap.ldap /var/lib/ldap<br>>/etc/init.d/ldap start<br>><br>>but I am not overly optimistic.  So, the question:<br>><br>>Can I just delete all of the 
db.001, db.0002, etc files and have slapd<br>>rebuild them without losing the database?  Then, I can run the above<br>>commands again?  Finally, there is a replog.lck file which I had him<br>>delete (it was size zero), but this had not effect on ldap starting.
<br>><br>>Sincerely,<br>>Dave Hopkins<br>><br>>_______________________________________________<br>>K12OSN mailing list<br>><a href="mailto:K12OSN@redhat.com">K12OSN@redhat.com</a><br>><a href="https://www.redhat.com/mailman/listinfo/k12osn">
https://www.redhat.com/mailman/listinfo/k12osn</a><br>>For more info see <<a href="http://www.k12os.org">http://www.k12os.org</a>><br><br><br><br>David N. Trask<br>Technology Teacher/Director<br>Vassalboro Community School
<br><a href="mailto:dtrask@vcsvikings.org">dtrask@vcsvikings.org</a><br>(207)923-3100<br><br><br>_______________________________________________<br>K12OSN mailing list<br><a href="mailto:K12OSN@redhat.com">K12OSN@redhat.com
</a><br><a href="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</a><br>For more info see <<a href="http://www.k12os.org">http://www.k12os.org</a>><br></blockquote></div>
<br>