[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:09:55 -0500
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
********************************