--On Wednesday, January 07, 2009 1:01 PM -0600 Adam Williams awilliam@mdah.state.ms.us wrote:
Quanah Gibson-Mount wrote:
And are you sure that's the slapd.conf used by your running process? I don't see how slapd could be running with valid data with all the database files missing. If they were somehow rm -f'd, I'd use ldapsearch with both regular & operational attrs to get a dump before it loses any more data.
--Quanah
that is the only slapd.conf on my system and I'm using the fedora provided RPMs for openldap so it has to be loading it. also, updatedb && locate id2index.dbd returns no results.
ahh thanks, totally forgot about that. I ran ldapsearch -x -b 'dc=mdah,dc=state,dc=ms,dc=us' '(objectclass=*)' > /root/backup-ldapsearch.ldif
This won't include the operational attributes. And I'd search as the root user, so that you can be sure to have all attributes regardless of ACLs. Right now you are doing an anonymous search.
For example:
ldapsearch -x -h freelancer.lab.zimbra.com -D "cn=config" -W + "*"
I think that got everything from looking at /root/backup-ldapsearch.ldif. do you think I need to run anything else to get any other information from the directory? So what do you think I should do now? stop slapd, run slapindex, and see if it regenerates the files? and if that fails, delete /var/lib/ldap/*, start slapd, and ldapadd -D "cn=Manager,dc=mdah,dc=state,dc=ms,dc=us" -w xxxxxxxxxxxxx -x -v -f root/backup-ldapsearch.ldif and keep my fingers crossed?
I doubt slapindex will do anything. You'll need to stop slapd, and slapadd the correctly exported ldif from ldapsearch, as I outline above.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration