Did you use the downloadable srpm from openafs.org ? On Wed, Feb 13, 2019 at 02:58:22PM -0500, Gary Gatling wrote: > I was able to get 1.8.2 to compile for RHEL 8 x86_64 but "kinit" seems to > be missing. :( > > On Wed, Feb 13, 2019 at 2:23 PM Dave Botsch <bot...@cnf.cornell.edu> wrote: > > > Has anyone gotten openafs to compile under RHEL8 beta? I had tried > > previously and no gold. If so, one could then test and again file a bug > > report with RedHat saying "systemd --user breaks stuff" and here's the > > business case. > > > > Thanks. > > > > On Sun, Dec 09, 2018 at 10:34:40AM +0100, Dirk Heinrichs wrote: > > > 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 > > > > > > > > -- > > ******************************** > > David William Botsch > > Programmer/Analyst > > @CNFComputing > > bot...@cnf.cornell.edu > > ******************************** > > _______________________________________________ > > OpenAFS-info mailing list > > OpenAFS-info@openafs.org > > https://lists.openafs.org/mailman/listinfo/openafs-info > >
-- ******************************** David William Botsch Programmer/Analyst @CNFComputing bot...@cnf.cornell.edu ******************************** _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info