[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).