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

[Todd Lewis]

Norman,

There's nothing wrong with a short name symlink to your cell's fully qualified 
path per se, but it's incredibly difficult to keep it from creeping into places 
is shouldn't be: hard-coded paths in package builds, scripts, documentation and 
services that might eventually be available to -- but broken for -- people 
coming in from foreign cells. If you don't believe me, and your cell has been 
up for any length of time (like since before breakfast), try deleting that link 
for a day and see how much stuff quits working. That's what you're going to run 
into when your visit another site and say to your new friends there "Let me 
show you how we do thus-n-such in our cell", authenticate to your cell, cd 
there, and try to run something. Been there, got the t-shirt. It doesn't make 
for a good demo.
--
Todd_Lewis@unc.edu (who first posted the line below that Jim Rees replied to, 
not that I'm proud of it. Ugh, on the contrary.)

Norman P. B. Joseph wrote:

> Excuse me for being dense, (and I was in one of those Transarc training
> classes back in the day), but what's the harm in that symbolic link?
> 
> -norm
> 
> 
> 
> On Wed, 2004-10-27 at 11:34, Mitch Collinsworth wrote:
> 
>>On Wed, 27 Oct 2004, Jim Rees wrote:
>>
>>
>>>  '/afs/isis' is a symbolic link, leading to a mount point for
>>>  volume 'root.cell'.
>>>
>>>So you broke one of the most important features of afs, the global name
>>>space.  Why?
>>
>>Huh?  Transarc trainers specifically taught to do exactly this 15
>>years ago.  The recommendation was there to still use the FQDN in
>>all symlinks, scripts, etc.  But it was recommended to have it for
>>typing ease.  Remember /afs/tr ?
>>
>>-Mitch
>>_______________________________________________
>>OpenAFS-info mailing list
>>OpenAFS-info@openafs.org
>>https://lists.openafs.org/mailman/listinfo/openafs-info