RX Kerberos 5 security class requirements of Kerberos library

Jeffrey Hutzelman jhutz at cmu.edu
Mon Jan 8 18:59:28 EST 2007

On Wednesday, January 03, 2007 08:38:21 AM -0500 Sam Hartman 
<hartmans at MIT.EDU> wrote:

> AFS clearly expects as high availability
> as possible and expects minimum latency.

Correct.  Let me put on my operator hat for a while...

The reason I haven't commented on this thread before is that while you all 
were having it, I was involved in planning and executing a full shutdown of 
our facility to allow for testing and maintenance of power switch gear that 
feeds us.

One recurring problem we have during events like this is the amount of time 
it takes to shut everything down.  One of the biggest problems there is the 
number of machines that take ~forever to shut down, because they are doing 
things like trying to unmount NFS filesystems from servers that are no 
longer up.  Now, those machines tend to belong to individual research 
projects, and one of the prices they pay for that behavior is that 
sometimes their machines get shut down the hard way.

That is not acceptable for an AFS fileserver, which provides services to 
and stores critical data for our entire user community.  Those machines 
must shut down cleanly in a short time, and that includes running a command 
like 'bos shutdown localhost -wait -localauth'.  In a situation calling for 
quick shutdown (catastrophic power failure, flood, etc), operations like 
shutting down a server must not sit around waiting for KDC's that have 
already shut down or are unreachable because a network switch has failed.

As long as I retain that functionality, I don't much care what the API 
looks like.  However, I would point out that it is the application, not 
whoever wrote some system-wide configuration file, that is likely to know 
things like whether a KDC is expected to be available and whether we feel 
like waiting around to find out.

> But if the server doesn't fully want
> to trust someone with its key...

Then it is screwed.

-- Jeff

More information about the krbdev mailing list