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<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
