[OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8

[Dave Botsch]

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
********************************