On Tue, 2009-03-03 at 11:22 -0600, Will Fiveash wrote: > On Tue, Mar 03, 2009 at 10:54:30AM +0100, Mark Phalan wrote: > > > > On Mon, 2009-03-02 at 13:24 -0600, Will Fiveash wrote: > > > On Mon, Mar 02, 2009 at 11:09:30AM +0100, Mark Phalan wrote: > > > > > > > > Unfortunately 'kdb5_util destroy' only works reliably if you have the > > > > same krb5.conf as was used to create the kdb in the first place (well at > > > > least the original realm must be the same). > > > > > > Not sure what you mean, aren't there command line flags to specify the > > > realm on so on? In fact I removed both krb5.conf and kdc.conf and ran > > > > > > kdb5_util -r MY.REALM destroy > > > > Yes this will work. I was complaining about the asymmetry of (when a new > > realm is introduced): > > > > zup# kdb5_util create -s > > Initializing database '/var/krb5/principal' for realm 'ACME2.COM', > > master key name 'K/M at ACME2.COM' > > You will be prompted for the database Master Password. > > It is important that you NOT FORGET this password. > > Enter KDC database master key: > > Re-enter KDC database master key to verify: > > kdb5_util: File exists while creating database '/var/krb5/principal' > > zup# kdb5_util destroy > > kdb5_util: No such entry in the database while retrieving master entry > > zup# > > > > In the above example the admin now has to dig around and try to > > determine what was the original realm if he wants to successfully > > destroy the kdb with kdb5_util. This is a usability problem. > > If a stash file was created for that realm then > > ls -a /var/krb5/.k5* > > will reveal the realm.
Yup. I've never seen this documented though. > > > I thought that "kdcmgr destroy" works better in this situation but it > > seems like it's even worse: > > > > zup# kdcmgr destroy > > > > Some of the following files are present on this system: > > /etc/krb5/krb5.keytab > > /var/krb5/principal > > /var/krb5/principal.old > > /var/krb5/.k5.* > > > > All of these files will be removed, okay to proceed? [y/n]: y > > zup# echo $? > > 0 > > zup# ls /var/krb5/principal > > /var/krb5/principal > > > > There should be a way to simply blow-away the old Kerberos db which > > doesn't rely on the admin remembering what realm was originally > > specified. > > Certainly this is a usability bug with kdb5_util (there are several > associated with the destroy subcommand). Please open a CR with the > above info. > Will do. > > > > 'kdcmgr' is relatively new and NV only so I can imagine that people > > > > when faced with 'kdb5_util' failing due to configuration change they > > > > don't have much choice but to manually try to delete the kdb and > > > > related files. > > > > > > I hope that is not the case. Sun has never supported using 'rm -rf *' > > > in /var/krb5 (or that was documented that was a mistake). > > > > I don't believe that I've ever seen 'rm -rf *' as a documented way to > > clear out the kdb. I do see it as a last resort some people use due to > > the above described usability issues. > > That may be but doing so violates system integrity which is not the > correct way to admin a Solaris system. Agreed. I was speculating why people might do it - it's not supported. -M
