[1460] in SIPB-AFS-requests
volume for /usr/athena on SS20's
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Tue Jul 26 14:27:33 1994
From: mhpower@MIT.EDU
To: sipb-afsreq@MIT.EDU
Cc: rtfm-maintainers@MIT.EDU, usenet@MIT.EDU
Date: Tue, 26 Jul 94 14:25:29 EDT
Currently, the directory /usr/athena on the SS20's is a symlink to
/afs/net.mit.edu/software/athena/@sys. I don't think this is a good
idea, for three reasons. First, it seems too risky to rely on the
availability of the net cell. Second, there are setuid-root programs
in /usr/athena that we might occasionally want to use, and we can't
trust setuid execution from the net cell for security reasons. Third,
we might want to compile new versions of some of the programs there,
and still have the binaries shared between all three of the SS20's.
Running du on /afs/net.mit.edu/software/athena/@sys/ gives 17.6 Mb.
I'd like to suggest copying everything there to the sipb cell, into a
new replicated volume named system.sparc.usrathena, to be mounted on
/afs/sipb/system/sun4m_412/srvd.7s/usr/athena. Once this is released,
we'd run "fs setcell net.mit.edu -nosuid" on all three machines, and
configure things in /usr/vice/etc so that also happens at boot time.
Obviously there are lots of other ways to provide /usr/athena to the
SS20's (local disk space, different AFS arrangements, etc.); I'm
suggesting this one since it seems closest to what's already set up,
and might tend to minimize the amount of other reconfiguration work
that's needed now. Also, the AFS volume name/path roughly matches the
current athena-cell set-up, so it should be obvious (?) later on why
the volume exists there, even without referring to this mail about it.
Matt
