[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
********************************