Hi Rich, tombstone problem mentioned here:
http://danieljamesscott.org/documentation/12-troubleshooting/25-clean-tombstone-entries-from-freeipa-ldap-servers.html I was seeing similar symptoms. Mine is a new deployment so rather than monkey around trying to get an install on a dirty machine to work, I simply reinstalled the entire OS and changed the hostname of the replicant. The logs got blown away in the process so I'm sorry I can't give you more info about the bug I was getting. The good news is, using exactly the same install options except for the new hostname, and installing on to a pristine install of the OS, everything now seems to work fine. So I'm not insane, as I was beginning to believe I might be. There was some kind of issue with attempting to install the replica on a machine where a previous attempt at a replica had been uninstalled, but the next attempted install keeps the same hostname. I'm a noobie so I didn't get it right on the first try. I've noticed that trying to re-install clients with the same hostname causes unexpected problems also. I realize that's not something done every day but I wonder about cases where a machine is rebuilt and gets the same hostname? That is a scenario that could realistically occur. Again, I apologize for not having those logs to send. Hopefully it will be smooth sailing from here on. Next step, getting my back up and recovery strategy in place. cheers, -Aaron On Thu, Aug 9, 2012 at 7:53 AM, Rich Megginson <rmegg...@redhat.com> wrote: > On 08/09/2012 01:14 AM, bin.e...@gmail.com wrote: >> >> I think I've narrowed it down to the "tombstone" problem. > > > What "tombstone" problem? > > ls -al /etc/dirsrv/slapd-* > > Also, please post a sanitized errors log from > /var/log/dirsrv/slapd-YOUR-DOMAIN/errors > >> >> But now I'm at a loss for what to do. The only advice I can find >> involves using direct ldap code an that is way over my head. (I'd >> prefer to not completely destroy my database in the process of trying >> to clean out the zombies) >> >> Is there any kind of wrapper script I can use to kill the zombie >> {replicageneration} and nsds5replica? >> >> Thanks for any help! >> >> -Aaron >> >> On Thu, Aug 9, 2012 at 12:13 AM,<bin.e...@gmail.com> wrote: >>> >>> After installing a replica on a fresh up to date install of FC17, >>> everything seems fine until a reboot. FreeIPA is running on the new >>> machine, etc. >>> >>> But after the reboot ldap doesn't start on it's own and can't be made >>> to start manually. The origional FreeIPA instance, same software >>> versions, is runny just fine. >>> >>> Release: 1.fc17 Arch: x86_64 FreeIPA Version: 2.2.0 >>> >>> here is the short error. I can post more if this symptom isn't enough. >>> (I've replaced the names of my actual machines and domain) >>> >>> #> ipactl start >>> Starting Directory Service >>> Failed to read data from Directory Service: Unknown error when >>> retrieving list of services from LDAP: [Errno 2] No such file or >>> directory >>> Shutting down >>> >>> >>> #> tail -20 /var/log/messages >>> Aug 8 23:56:04 replica systemd[1]: dirsrv@PKI-IPA.service: control >>> process exited, code=exited status=1 >>> Aug 8 23:56:04 replica systemd[1]: Unit dirsrv@PKI-IPA.service >>> entered failed state. >>> Aug 9 00:00:16 replica dbus-daemon[610]: dbus[610]: [system] >>> Activating service name='net.reactivated.Fprint' (using servicehelper) >>> Aug 9 00:00:16 replica dbus[610]: [system] Activating service >>> name='net.reactivated.Fprint' (using servicehelper) >>> Aug 9 00:00:16 replica dbus-daemon[610]: Launching FprintObject >>> Aug 9 00:00:16 replica dbus-daemon[610]: dbus[610]: [system] >>> Successfully activated service 'net.reactivated.Fprint' >>> Aug 9 00:00:16 replica dbus[610]: [system] Successfully activated >>> service 'net.reactivated.Fprint' >>> Aug 9 00:00:16 replica dbus-daemon[610]: ** Message: D-Bus service >>> launched with name: net.reactivated.Fprint >>> Aug 9 00:00:16 replica dbus-daemon[610]: ** Message: entering main loop >>> Aug 9 00:00:46 replica dbus-daemon[610]: ** Message: No devices in use, >>> exit >>> Aug 9 00:05:01 replica ns-slapd[2265]: [09/Aug/2012:00:05:01 -0600] >>> startup - The default password storage scheme SSHA could not be read >>> or was not found in the file /etc/dirsrv/slapd-PIVOTVFX-NET/dse.ldif. >>> It is mandatory. >>> Aug 9 00:05:01 replica systemd[1]: dirsrv@EXAMPLE-COM.service: >>> control process exited, code=exited status=1 >>> Aug 9 00:05:01 replica systemd[1]: Unit dirsrv@EXAMPLE-COM.service >>> entered failed state. >>> Aug 9 00:05:01 replica ns-slapd[2266]: [09/Aug/2012:00:05:01 -0600] >>> startup - The default password storage scheme SSHA could not be read >>> or was not found in the file /etc/dirsrv/slapd-PKI-IPA/dse.ldif. It is >>> mandatory. >>> Aug 9 00:05:01 replica systemd[1]: dirsrv@PKI-IPA.service: control >>> process exited, code=exited status=1 >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users