[2258] in Kerberos
Re: Kerberized NFS
daemon@ATHENA.MIT.EDU (John Hascall)
Tue Oct 6 23:03:33 1992
Date: Wed, 7 Oct 1992 02:26:21 GMT
From: john@iastate.edu (John Hascall)
To: kerberos@shelby.Stanford.EDU
} >Is anyone using MIT's Kerberized NFS in production?
} From: dyer@spdcc.com (Steve Dyer)
} Customers of DEC's DECathena service are.
} [ An excellent description of MIT's Kerberized NFS has been
} omitted.]
tytso@ATHENA.MIT.EDU (Theodore Ts'o) writes:
}I should point out that you do not need to be a Customer of DECathena to
}obtain a copy of MIT's Kerberized NFS. Indeed, MIT Project Athena is
}using it in full production, and has been for a number of years.
First, I should note we are running a hodge-podge of an *old* MITathena
which we have mangled mercilessly and DECathena parts.
Our major problem with KerbyNFS has to do with shutdown/startup.
In a normal NFS with hard mounts, you can shutdown the NFS server
and bring it backup with your clients none the wiser (other than
the time delay). The KNFS mods add state to the NFS server (the
uid maps). So if you have a server crash you lose this state.
If you have a planned outage you can do:
nfsc dump uidmapfile.dmp
and have your /etc/rc* file do:
[ -f uidmapfile.dmp ] && {
mv uidmapfile.dmp uidmapfile.dmp~
nfsc load uidmapfile.dmp~
}
(or some such). This, however, can take a very long time (both the
load and the dump).
What would be nice is if the maps where stored in a file as well as
in the kernel when created (so you don't loose state over a crash)
and some way to make "load" a lot faster (seems like it takes
about a half second per uid-map -- and we have many hundreds at
any given time). Someday, perhaps we will get time to look at
this ourselves, but maybe someone else already has?
John
--
John Hascall ``Live with it pink-boy!''
Project Vincent
Iowa State University Computation Center john@iastate.edu
Ames, IA 50011 515/294-9551 [fax -1717]
