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. There has been discussions on this mailing list of the issues dating back more than a year. In summary, "systemd --user" services are incompatible with "session keyrings" which are used to represent AFS Process Authentication Groups. 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. 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 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. 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. 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. 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. 3. Day zero support for new kernel releases. It took OpenAFS a month to support 7.4 and two months to fix the breakage from 7.5. There were also extensive delays in fixing OpenAFS to work with 5.10 and 6.5. 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, .... RHEL 8 is in beta. The next opportunity to argue for inclusion of the in-tree AFS client will be RHEL 9. The clock is ticking .... Jeffrey Altman
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
