[OpenAFS-devel] Re: [OpenAFS] 2.6 kernel support anytime soon? Workarounds?

David Botsch dwb7@ccmr.cornell.edu
Wed, 12 May 2004 08:42:33 -0400


Right. As Mitch mentioned, this issue wasn't even presented in the IBM 
AFS class I took a couple of years ago (which was very well taught, 
btw).

I saw several answers as to what the overlap range is. Is there a 
definitive answer that can be added to some documentation someplace?

On 2004.05.11 20:19 Jeffrey Hutzelman wrote:
> 
> 
> On Tuesday, May 11, 2004 19:00:57 -0400 Mitch Collinsworth 
> <mitch@ccmr.cornell.edu> wrote:
> 
>> 
>> On Tue, 11 May 2004, Jeffrey Hutzelman wrote:
>> 
>>> And the statement stands.  Either you have control over a machine, 
>>> or you
>>> don't.  If you do, then when you decide that machine is going to 
>>> run AFS,
>>> you're going to also have to commit to setting aside some GID space.
>>> Making that decision for every machine simultaneously makes the task
>>> _easier_, not harder, if you've done things right.
>> 
>> I don't recall ever being told to do this, either in the Transarc
>> training class or in the manuals.  And frankly I never gave it much
>> thought.  Until today.
>> 
>> Do you tell students and others when telling them to install the AFS
>> client if they want to use the departmental filesystem from their
>> machines that they have to avoid using a range of gids?  We don't.
>> Does anyone?
> 
> Your question assumes a model in which individual uses install and 
> maintain their own machines, with the department providing only a 
> filesystem and a few other services.  For us, that assumption is 
> false -- we provide a complete multi-platform distributed computing 
> environment.  Today AFS is an integral part of that environment.  The 
> UID and GID spaces have been centrally managed since well before AFS 
> was of any significance.
> 
> 
> But your point is well taken.  I'll bet that most AFS users and even 
> admins aren't particularly aware of the group overlap issue.  And, 
> that's probably something we should try to change, since we're 
> unlikely to be able to eliminate the problem anytime soon.
> 
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
>   Sr. Research Systems Programmer
>   School of Computer Science - Research Computing Facility
>   Carnegie Mellon University - Pittsburgh, PA
> 
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 
********************************
David William Botsch
Consultant/Advisor II
CCMR Computing Facility
dwb7@ccmr.cornell.edu
********************************