[OpenAFS] Pro's & Con's of /usr/local on AFS....
John Rudd
jrudd@ucsc.edu
Wed, 27 Oct 2004 09:32:18 -0700
On Oct 27, 2004, at 5:34 AM, Todd M. Lewis wrote:
>
>
> Joshua Johnson wrote:
> > So, at the risk of starting something here, I am going to ask what
> other
>> peoples experiences are with placing /usr/local in AFS and sharing
>> among machines of same @sys type (much like the AdminGuide suggests).
>
> I think it depends on how much administrative control you expect to
> have over the machines in your local cell. When we first put our cell
> together, we had complete control and put /usr/local in AFS. (We made
> a complete mess of it, too, but it was totally our mess, so we could
> deal with it. That's another story though.) Eventually, however, other
> research groups and departments joined the cell and local admins had
> their own notion of what the "local" in /usr/local meant. At least one
> group already had a shared /usr/local that wasn't in AFS...
>
That's really the age-old question of "what does the local in
/usr/local mean?"
The last two places that I have worked have decided that:
- "/usr/local" means "local to the corner of the network we control".
It points into a particular spot in our AFS cell isn't advertised to
the other departments (and that we refuse to answer questions about if
they find it).
- Some people insist that it should be "local to the machine itself"
... for that we use "/local". Those utilities are installed on the
machine itself, and are things that we feel should NEVER live in any
kind of network location (kerberos and ssh being the big ones, but also
things which are essential to the stand-alone operation of the system
so that it doesn't hang or become useless if AFS goes down, or becomes
unreachable, for those systems we feel need to stay up even when AFS is
down).
- For "local to the larger concept of our site" and "things we have to
let sysadmins and maybe users in other departments look at", there's
something that gets referenced as "/usr/athena" which is then a symlink
out into AFS space. It's called that because we have been using
athena, but in the future we could decide to call it "/usr/ucsc" or
something.
Putting the 1st and 3rd out in AFS has worked pretty well for us. What
didn't work for us was having certain key utilities in AFS (before I
got here, the "/local" thing didn't exist, yet we had machines leaving
a lot of their main functionality out in AFS, which caused us no end of
headaches -- not being able to access a machine to shut it down because
its kerberos libraries are out in AFS , and there's some problem
interfering with the network which keeps it from accessing its kerberos
libraries, is just WRONG).