On Jul 9, 2013, at 10:31 AM, Rob Crittenden wrote: > Brian Vetter wrote: >> We had to shut down our FREEIPA server and move it. When I brought it back >> up again today (all same IPs, network, etc), it failed to come up. I see >> lots of various forms of the following messages when trying to start the >> ipa, named, and other services: > > What do you mean by move it? Physically move a machine or did you try to move > the configuration?
We shutdown the server and physically moved it and its network to a new physical location. When I started the server after the move, I started getting these errors and none of the freeipa services were operational. As far as I can tell, the rest of the network is OK/the same. I can ssh into the server provided I use an ip address (no DNS as this is the DNS server) and I use a native account (no kerberos/kinit required). >> "Failed to init credentials (Cannot contact any KDC for realm ..." >> "startup - The default password storage scheme SSHA could not be read or was >> not found in the file /etc/dirsrv/slapd-TESTREALM.COM/dse.ldif. It is >> mandatory." >> "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." >> "krb5kdc: Server error - while fetching master key K/M for realm >> TESTREALM.COM" >> "kinit: Cannot contact any KDC for realm 'TESTREALM.COM' while getting >> initial credentials" >> >>> From what I can surmise after seeing these, something in kerberos is messed >>> up. I don't know for sure if it is related, but I see that the files >>> referenced in /var/kerberos/krb5kdc/kdc.conf are not there. In particular, >> >> pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem >> pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem >> >> If this is likely the case (or perhaps just the first thing I've run into >> that is wrong), how do I go about recovering them? I've tried (with fingers >> crossed) "yum reinstall freeipa-server" and "yum update freeipa-server" >> hoping that they'd see the need to fix this. They didn't. Still get the same >> errors. >> >> Is there some backdoor way to recreate these files from elsewhere in the >> install? Perhaps buried in the 389 directory server's database and >> accessible using db4.4_dump or some other tools? If there is no way to >> recreate them, is there a way to reassert new keys without having to start >> all over? And if I have to start all over, is there anyway to extract some >> of the records from the dir DB so I can reload them with a new server? >> >> Thanks for any suggestions/guidance, >> >> Brian >> >> >> _______________________________________________ >> Freeipa-users mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
