Re: [OpenAFS] Limiting mount point to known cells

2022-08-27 Thread Ed Rude
I have faced similar issues at times. If you like everything about the
current behavior of AFS aside from the impact it can have on git you might
attack it from the git side. Maybe there is a way to stop git from
recursing all the way to /afs/ ? Similar solutions have worked for me with
things other than git. You probably don’t want git to check that directory
anyway, even if you can make it happen much faster.

Ed

On Fri, Aug 26, 2022 at 22:14 Jeffrey E Altman  wrote:

> On 8/26/2022 5:13 PM, Ingo van Lil (ing...@gmx.de) wrote:
>
> Hello OpenAFS experts,
>
> is there any way to run an AFS client with both the -dynroot and -afsdb
> options, but still limit the /afs mount point to known cells
> (specifically: only my home cell)?
>
> There is no explicit support for this behavior in OpenAFS but you might be
> able to approximate it by
>
>- enabling -dynroot
>- disabling -afsdb
>- removing the OpenAFS distributed CellServDB file
>- creating a CellServDB file contain only one line for the cell and no
>servers
>>my.cell # My personal cell
>
> A cell entry with no servers is an implicit request to lookup the servers
> via DNS.
> I do not remember if this works with -afsdb disabled but it might.
>
>
> Longer explanation of my problem:
>
> When I run "git status" somewhere inside the AFS hierarchy it freezes
> for a minute or two. git tries to access the directory /afs/.git, and I
> see that afsd sends multiple DNS requests to the loopback address
> 127.0.0.53. Not sure why it does that, it seems to be somehow related to
> systemd-resolved in Fedora Linux.
>
> Running without -dynroot solves the issue, but according to the manual
> it will keep my machine from booting in case my home cell can't be
> contacted. Not very attractive.
>
> Running without -afsdb solves the issue. That's what I do now, but it
> requires to manually specify the servers for my home cell in CellServDB.
> Ideally I'd like to get that info from DNS.
>
> Thanks in advance for any advice you can give!
>
> Regards,
> Ingo
>
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
> --
Edward A. Rude
Systems Administrator - Unix Systems
Division of Information Technology


Re: [OpenAFS] Question for admins regarding pts membership output

2022-07-13 Thread Ed Rude
I second the inclusion of an explicit way of requesting one behavior or the
other. As long as I have a way to explicitly specify both behaviors working
around the change in anything that wraps the pts command should be simple
enough.

I think I prefer the new behavior you are suggesting as the default.

Thank you,
Ed

On Wed, Jul 13, 2022 at 10:08 Dave Botsch  wrote:

> I suspect our user deprovisioning scripts would break by trying to
> explicitly remove users from those groups. Though would be easy enough
> to fix. And I'm in favor of having this extra output.
>
> Two questions/thoughts would be:
>
> 1) If this is a "backwards-incompatible" change (is it?) should it be
> reserved for the next major version upgrade (2.0) ?
>
> 2) Use of a flag to pts membership to include (or not include) explicit
> and implicit membership, as I might very well want to filter the
> output... the question then becomes which way should be the "default"?
>
> thanks.
>
> On Wed, Jul 13, 2022 at 09:49:29AM -0400, Jeffrey E Altman wrote:
> > The Protection Service groups fall into two categories.   Those with
> > explicit membership lists and those with implicit membership lists.   For
> > example, the "system:anyuser" and "system:authuser" groups are implicit
> > whereas "system:administrators", "system:ptsviewers", and
> > "system:authuser@foreign-realm" groups are explicit.
> >
> > The output of "pts membership" only includes memberships in explicit
> > membership groups.   This has a negative impact inexperienced end users
> that
> > might be unaware that they are members of the "system:anyuser" and
> > "system:authuser" groups. This behavior also leads to an inconsistency
> > between the behavior for foreign and local users because foreign users
> are
> > not members of "system:authuser" and are members of
> > "system:authuser@foreign" which is included in the membership list
> because
> > that group has an explicit membership list.
> >
> > The AuriStorFS  Protection service also makes a distinction between
> "user"
> > and "machine" or "network" entities where "machine" and "network"
> entities
> > are not members of the "system:authuser" or "system:authuser@foreign"
> > groups.   This distinction is not apparent from the output of "pts
> > membership" because of the exclusion of implicit groups.
> >
> > AuriStor is considering a change to "pts membership" output to include
> > implicit memberships in the output of "pts membership". With this change
> the
> > output of these commands
> >
> >   $ pts membership anonymous
> >   Groups anonymous (id: 32766) is a member of:
> >
> >   $ pts membership testuser
> >   Groups anonymous (id: 112) is a member of:
> >
> >   $ pts membership testuser@foreign
> >   Groups anonymous (id: 43282) is a member of:
> > system:authuser@foreign
> >
> > becomes
> >
> >   $ pts membership anonymous
> >   Groups anonymous (id: 32766) is a member of:
> > system:anyuser
> >
> >   $ pts membership testuser
> >   Groups anonymous (id: 112) is a member of:
> > system:anyuser
> > system:authuser
> >
> >   $ pts membership testuser@foreign
> >   Groups anonymous (id: 43282) is a member of:
> > system:authuser@foreign
> > system:anyuser
> >
> > The question for cell admins is whether anyone is aware of any internal
> > scripts which process the output of "pts membership" which will break as
> a
> > result of the inclusion of the implicit groups "system:anyuser" and
> > "system:authuser" in output.
> >
> > Your assistance is appreciated.
> >
> > Jeffrey Altman
> > AuriStor, Inc.
> >
>
>
>
> --
> 
> David William Botsch
> Programmer/Analyst
> @CornellCNF
> bot...@cnf.cornell.edu
> 
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
-- 
Edward A. Rude
Systems Administrator - Unix Systems
Division of Information Technology