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