Ok. I had to install krb5-workstation-1.16.1-19.el8.x86_64.rpm :) It appears to be working for me. I'm sorry I don't have this in github. But I will try to put it on the web somewhere.
I was able to create, alter. and delete files in the unity.ncsu.edu cell. There were some more minor selinux issues I have to fix and I had to make my own "EPEL" for things like dkms. But 1.8.2 seems to work for me. On Wed, Feb 13, 2019 at 2:58 PM Gary Gatling <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> ******************************** >> _______________________________________________ >> OpenAFS-info mailing list >> [email protected] >> https://lists.openafs.org/mailman/listinfo/openafs-info >> >
