Am Samstag, den 08.12.2018, 14:08 -0500 schrieb Jeffrey Altman:
> On 12/8/2018 5:21 AM, Dirk Heinrichs wrote:
> > Dirk Heinrichs:
> >
> > > Did a quick test (on Debian, btw., which already ships kafs) and
> > > it
> > > works fine.
> >
> > While getting tokens at login work with this setup, things start to
> > fail
> > once the users $HOME is set to be in /afs. While simple scenarios
> > like
> > pure shell/console logins work, graphical desktop environments have
> > lots
> > of problems. XFCE4 doesn't even start, Plasma works to some degree
> > after
> > presenting lots of error dialogs to the user.
>
> As Harald indicated, "systemd --user" services are a problem not just
> for kafs but for openafs as well.
But that's not the problem here. Both work fine with the OpenAFS
client.
> There has been discussions on this
> mailing list of the issues dating back more than a year.
I know. I've been involved ;-)
> In summary,
> "systemd --user" services are incompatible with "session keyrings"
> which
> are used to represent AFS Process Authentication Groups.
Yes.
> You have no indicated which kernel version you are using nor am I
> aware
> of the options used to build AF_RXRPC and KAFS on Debian. The Linux
> kernel versions that are recommended are 4.19 with a couple of back
> port
> patches from the forthcoming 4.20 and the 4.20 release candidate
> series.
Ah, OK. Debian buster is still on 4.18. Will give it another try once
4.20 is out...
> Regardless, it would be useful for you to file bug reports with the
> Linux distribution describing the issues you are experiencing.
>
> Debian: https://wiki.debian.org/reportbug
Yep, know this.
> Fedora: https://fedoraproject.org/wiki/Bugs_and_feature_requests
>
> > Seems there's still some work to do until this becomes an
> > alternative
> > for the standard OpenAFS client.
>
> All software including OpenAFS has work to do.
Sure. But the OpenAFS client is mature and just works (except for the
systemd --user thing, which isn't OpenAFS' fault).
> The kafs to-do list of known work items is here:
>
> https://www.infradead.org/~dhowells/kafs/todo.html
>
> > So I wonder why RH customers would want that?
>
> Obviously, no one wants bugs, but at the same time this community
> does want:
>
> 1. A solution to "systemd --user" service compatibility with AFS.
ACK.
> The required changes are going to require Linux distribution
> intervention because systemd is integrated with differences
> to each distribution. At the moment there is no interest among
> the systemd developers to work to fix a behavior they consider
> to be a bug in OpenAFS, an out of tree file system.
So they need to understand it's a problem with an in-tree fs as well? I
see...
> 2. The RHEL AFS user community needs an end to the repeated breakage
> of /afs access following each RHEL dot release. How many times
> has getcwd() broken because RHEL kernels updates preserve the API
> between releases but do not preserve the ABI. While this permits
> third party kernel modules to load it does not ensure that they
> will do the right thing. If the community is lucky the symptoms
> are visible. If unlucky, the symptoms are hidden until someone
> reports silent data corruption.
As a Debian user I didn't have these kind of problems in the past
*HINT* :-) But, OTOH, mine is just a small home setup.
> The need for an in-tree Linux AFS client extends to all Linux
> distributions not just Red Hat. Any OpenAFS Linux developer can
> attest
> to the extensive effort that must be expended to maintain
> compatibility
> with the mainline Linux kernel. Then multiply that effort by all of
> the
> Linux distributions that ship modified kernels such as RHEL, SuSE,
> Ubuntu, Oracle,
ACK
Bye...
Dirk
--
Dirk Heinrichs
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de
signature.asc
Description: This is a digitally signed message part
