[OpenAFS] Red Hat EL Support Customers - Please open a support
case for kafs in RHEL8
Dave Botsch
botsch@cnf.cornell.edu
Wed, 13 Feb 2019 15:16:21 -0500
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 <botsch@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 <botsch@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
> > > > botsch@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
> > botsch@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
botsch@cnf.cornell.edu
********************************