Hello, The rpms I have been using are at:
https://linux.itecs.ncsu.edu/redhat/public/openafs/rhel8/ They are flawed in 2 ways. 1. There is no EPEL repository yet. I am a fedora contributor and have a couple of packages in EPEL. But they did not make a branch in EPEL for RHEL 8 yet. So that would make it hard to use these since we need Simone Caronni's "dkms" rpm which is in fedora but is not in RHEL/CentOS. 2. It does not build on aarch64 platform. I am unsure why. It just gives the error: Makefile:68: *** mixed implicit and normal rules. Stop. I will try to put these into a repo on github.com in case it is useful to others. I guess I need to make a 1.6.X branch and make master be these 1.8.X. I'll need to give it some further thought. I was mainly working on these for a fedora 29 laptop I use but I'm glad its also useful for RHEL/CentOS 8 when it comes out. On Wed, Feb 13, 2019 at 3:16 PM Dave Botsch <bot...@cnf.cornell.edu> wrote: > Ok. I just openafs-1.8.2-1.src.rpm, and it does not build. > > Thanks. > > On Wed, Feb 13, 2019 at 03:13:06PM -0500, Gary Gatling wrote: > > No. I have my own rpms that were descended from the rpmfusion repos > before > > they were abandoned. Except the kernel module rpm is something someone > else > > made here at NCSU that I heavily modified. I will try to upload those to > a > > yum repo as soon as I fix my selinux issues. > > > > On Wed, Feb 13, 2019 at 3:10 PM Dave Botsch <bot...@cnf.cornell.edu> > wrote: > > > > > 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 > > > > > -- > ******************************** > 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 >
