[OpenAFS] Pro's & Con's of /usr/local on AFS....

Todd M. Lewis Todd_Lewis@unc.edu
Wed, 27 Oct 2004 08:34:04 -0400

Joshua Johnson wrote:
  > So, at the risk of starting something here, I am going to ask what 
> 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...

So we bit the bullet and converted everything to what in retrospect 
seems an obvious better alternative. /afs is a global name space, and as 
  Jim Rees already pointed out, packages have to be tweaked to work well 
in almost any non-default tree. So we make our stuff self consistent in 
the /afs tree without trying to make it look like part of something more 
familiar. It's the only name space where we can be sure of not colliding 
with a "local" system or system administrator.

Draw your own conclusions, your millage may vary, etc., but we're happy 
with what we've got now.

> I don't want to create too large of a thread so if this has been 
> discussed, and there are pointers to studies/whitepapers/etc., please 
> feel free to post/send links to me.

I don't know of any, but it sounds like a good topic for a wiki page. Go 
for it.

At the risk of bloating an already too long message, here's how we put 
packages together in our cell.  Let's take the case of "ne" (yet another 
text editor that I happen to have contributed code to; std. self 
horn-blowing disclaimers here, see http://ne.dsi.unimi.it/ if you're 
that bored). In our cell, /afs/isis/pkg/ne/bin/ne is the path to the 
current default ne binary regardless of the architecture you happen to 
be on. '/afs/isis' is a symbolic link, leading to a mount point for 
volume 'root.cell'. /afs/isis/pkg/ne is a symbolic link to 
/afs/isis/pkg/ne-136, 'cause 1.36 is the current version. There's also 
ne-119 and ne-133 in /afs/isis, so we're doing package versioning that 
way.  Each of those is a mount point for the volumes pkg.ne-119, 
pkg.ne-133, and pkg.ne-136. The directory structure within, say ne-136 
looks like this:

lrwxr-xr-x bin -> .install/@sys/bin
lrwxr-xr-x build -> .build/@sys
drwxr-xr-x .build
lrwxr-xr-x common -> .install/common
lrwxr-xr-x dist -> .build/dist
lrwxr-xr-x doc -> .install/common/doc
lrwxr-xr-x etc -> .install/@sys/etc
lrwxr-xr-x include -> .install/@sys/include
drwxr-xr-x .info
lrwxr-xr-x install -> .install/@sys
drwxr-xr-x .install
lrwxr-xr-x lib -> .install/@sys/lib
lrwxr-xr-x libexec -> .install/@sys/libexec
lrwxr-xr-x man -> .install/common/man
lrwxr-xr-x sbin -> .install/@sys/sbin
lrwxr-xr-x share -> .install/common/share
lrwxr-xr-x src -> .build/src

The extensive use of the @sys macro and symbolic links lets us keep 
architecture specific stuff separate, but use the same paths anyway.
Note that '.build' is a mount point for volume 'pkg.nE-136', which is 
not replicated since it only contains what we need to build the package 
and isn't used otherwise. Volume pkg.ne-136 is replicated.

Of course, this is way to complicated to do by hand; we've got a script 
that sets this structure up and handles the tricky parts. (It's at 
/afs/isis.unc.edu/pkg/admin/bin/pkg if you want it, but be warned it 
taylored for our cell.) We've currently got about 314 packages built 
this way, most of which have more that one version online. It's a pain 
to manage (and not my pain btw; somebody else in our group handles most 
of it), but per package deployment effort on individual machines is zero 
most of the time.
   / Todd_Lewis@unc.edu  919-962-5273  http://www.unc.edu/~utoddl /
  /              A hangover is the wrath of grapes.              /