Greg, Thank you very much. I was able to restore full functionality on my realm.
If you are ever out in sunny Scotts Valley, CA, shoot me an email and I'll buy you a round. Kerberos community, I do NOT recommend removing your K/M principal, but if that happens, here is a recovery path should you be so lucky as to have a slave or an old dump. Just make sure the your dump versions are compatible from the slave to the master. Thanks again, Charles On Wed, Feb 18, 2015 at 3:31 PM, Greg Hudson <ghud...@mit.edu> wrote: > On 02/18/2015 05:49 PM, Charles Adams wrote: > > slave1# kdb5_util dump -ov -verbose ~/kerbmaster-ov K/m...@my.realm.org > > slave1# kdb5_util dump -verbose ~/kerbmaster K/m...@my.realm.org > > I don't think there's ever much call to use dump -ov today, although the > documentation was unclear on that point until recently. That's a side > point. > > > master# kdb5_util load -verbose -update ~/kerbmaster > > I would expect this to work, and it works for me if I reproduce your > situation in a test realm: > > $ make testrealm > [...] > $ kdb5_util dump testdir/dump K/m...@krbtest.com > $ kadmin.local -q 'delprinc -force K/M' # XXX DO NOT DO THIS > $ kinit user # (this works as long as the KDC is still running) > $ kadmin.local # (fails with "Cannot find master key record") > $ pkill krb5kdc > $ krb5kdc # (fails with "cannot initialize realm") > $ kdb5_util load -update testdir/dump > $ krb5kdc # (succeeds) > $ kinit user # (succeeds) > $ kadmin.local # (succeeds) > > Just be very careful not to forget the -update flag, or you'll wind up > with a KDB with only K/M in it. > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
