Re: [Freeipa-users] Fedora 17 FreeIPA Replica not starting up
On 08/10/2012 01:26 AM, bin.e...@gmail.com wrote: 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. Ok. Note that F-17 and later (389-ds-base-1.2.11 and later) have a much improved CLEANALLRUV process - http://port389.org/wiki/Howto:CLEANRUV 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 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, 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 _
Re: [Freeipa-users] Fedora 17 FreeIPA Replica not starting up
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 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, 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@red
Re: [Freeipa-users] Fedora 17 FreeIPA Replica not starting up
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, 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
Re: [Freeipa-users] Fedora 17 FreeIPA Replica not starting up
I think I've narrowed it down to the "tombstone" problem. 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, 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