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