> We do that and it works well here. On clients, we have a symbolic link:
> /usr/afsws => /afs/aixssc.uk.ibm.com/@sys/usr/afsws
>
> I like this because there is one master copy: updates propagate pretty quickly!
> I'd like to understand why you think it is better to have local /usr/afsws.
My point wasn't so much that it should be on the workstation's disk,
although that's important as well - it's hard for a user to run "fs
checkservers" if the server on which fs lives is down. I just don't see
any reason for placing AFS stuff in their own directory - this shouldn't
be the MS-DOS world, where every user has to have every application
directorFrom [EMAIL PROTECTED] Wed Jun 28 15:35:38 1995
Received: (daemon@localhost) by speedy.cs.pitt.edu (8.6.10/8.6.5) id PAA11991 for
afs-managers-list; Wed, 28 Jun 1995 15:35:34 -0400
Received: from po2.transarc.com (po2.transarc.com [192.54.226.2]) by
speedy.cs.pitt.edu (8.6.10/8.6.5) with SMTP id PAA11988 for
<[EMAIL PROTECTED]>; Wed, 28 Jun 1995 15:35:31 -0400
Received: by po2.transarc.com (5.54/3.15) id <AA07037>; Wed, 28 Jun 95 14:11:58 EDT
Received: via switchmail; Wed, 28 Jun 1995 14:11:56 -0400 (EDT)
Received: from po2.transarc.com via qmail
ID </afs/transarc.com/service/mailqs/sq1/QF.wjwNgSD0Bi82A1=0cM>;
Wed, 28 Jun 1995 14:10:38 -0400 (EDT)
Received: from transarc.com via qmail
ID </afs/transarc.com/service/mailqs/sq1/QF.ojwNapD0Bi8101bUML>;
Wed, 28 Jun 1995 14:04:38 -0400 (EDT)
Received: from po2.transarc.com via qmail
ID </afs/transarc.com/service/mailqs/q1/QF.UjwNVk=0Bi824On05i>;
Wed, 28 Jun 1995 13:59:12 -0400 (EDT)
Received: from lamb.sas.com (lamb.sas.com, [192.35.83.8]) by po2.transarc.com
(5.54/3.15) id <AA06855> for info-afs; Wed, 28 Jun 95 13:59:00 EDT
Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95)
id AA09153; Wed, 28 Jun 1995 13:58:57 -0400
Received: from stargaze.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90)
id AA14074; Wed, 28 Jun 1995 13:58:51 -0400
Received: from localhost.unx.sas.com by stargaze.unx.sas.com (5.65c/SAS/Generic
9.01/3-26-93)
id AA14281; Wed, 28 Jun 1995 13:58:50 -0400
Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: AFS client file ownership and mode bits recommendations
Date: Wed, 28 Jun 95 13:58:49 EDT
From: [EMAIL PROTECTED]
Status: RO
We have /usr/afsws -> /afs/@cell/@sys/usr/afsws and then replicate the
volume holding the AFS client binaries (as well as most other tools).
This way, we gain the benefit of fewer copies to keep current and yet
have at least one copy available at all times.
We create a symlink of /afs/@cell -> <current cell name> for each of our
internal cells. This allows us to have a single client image across cells.
Just my $.02 :-)
========================================================================
Bob Janka SAS Institute, Inc. Any opinions
Systems Developer SAS Campus Drive expressed are
Development Source Management Cary, NC 27513 mine, of course
[EMAIL PROTECTED] (919) 677-8000 x7788
------- Forwarded Message
Date: Wed, 28 Jun 95 08:42:51 -0700
From: Scott Grosch <[EMAIL PROTECTED]>
To: Paul Blackburn <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: Re: AFS client file ownership and mode bits recommendations
Message dated Wednesday, 28 Jun 191995, 1:03pm BST
from "Paul Blackburn <[EMAIL PROTECTED]>"
> We do that and it works well here. On clients, we have a symbolic link:
> /usr/afsws => /afs/aixssc.uk.ibm.com/@sys/usr/afsws
>
> I like this because there is one master copy: updates propagate pretty quickl
y!
> I'd like to understand why you think it is better to have local /usr/afsws.
We do this as well, but the advantage to having /usr/afsws local is that
if you lose your fileservers you still have the AFS commands on the local
machine to fix things with.
-- Scott
------- End of Forwarded Message
