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

[Dirk Heinrichs]

--=-Cqi3hYX8jdHIeYSXvJZQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Am Samstag, den 08.12.2018, 14:08 -0500 schrieb Jeffrey Altman:
> On 12/8/2018 5:21 AM, Dirk Heinrichs wrote:
> > Dirk Heinrichs:
> >=20
> > > Did a quick test (on Debian, btw., which already ships kafs) and
> > > it
> > > works fine.
> >=20
> > 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.
>=20
> 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.
>=20
> Debian: https://wiki.debian.org/reportbug

Yep, know this.

> Fedora: https://fedoraproject.org/wiki/Bugs_and_feature_requests
>=20
> > Seems there's still some work to do until this becomes an
> > alternative
> > for the standard OpenAFS client.
>=20
> 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:
>=20
>  https://www.infradead.org/~dhowells/kafs/todo.html
>=20
> > So I wonder why RH customers would want that?
>=20
> Obviously, no one wants bugs, but at the same time this community
> does want:
>=20
>  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

--=20
Dirk Heinrichs
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de=20

--=-Cqi3hYX8jdHIeYSXvJZQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJgWJ3LIo7zNO9tmf0p7rxfc7RqsFAlwM4bAACgkQ0p7rxfc7
RqscIQ/+KGgBsEq1dIPf/OdEyWlGcUBkpQtjsEmTU5vOLYZtkprFJhuzyHTCii+5
AXe62e/2lfMPPJnY5jfLCPyXRo3DMskXQz+Qrkjeo5groiIShuhC6J6e3xUKxbL/
xsKEMVDdgRFpXVIHpSPTcu7k07liewPxiTBBr1GxSyFeitauzYhzFsVFKbsxu/GK
zXXTnUJBCuJosmZGb3uI1+edM5v0SWB289UcW4PBOS4lS1gayDnsgXjJh1+gEYcw
P1HIZh9dS5DTBfjWBFZRqCKMwsMKhL89TOXziBdd8u5wl4eQcuY+UyKIfbiPQnMm
b2ykGXNouhZzSAu/z+40299VxyHqCG8kY+KBrgDeAJWGGM66PTmXbXsd2IXXGnd5
/3PRxAsOuUP0pnFeXY2x5gbL6goavTGS1rr+Xeywlj909FtjvPD4p1glIUNtfFZZ
h/2igctr0YjIQKOF6LG/8o3KLGaWABhPrL1ZwCu5UXEy2Qlhd0v6FP9yikJS5tAU
HZAP4h4bir0cpfD8zRlBNeOWLBZKnh8npxnW8rkLC2vo76HVTMaErB72qS3KUR1E
OPZyoW7AIFKGHJmkJSaWmxEvtvJ58X8GMmqsMRtAfM2/6wdeDB+MOwDUSs5rr4PA
4vVQgiYNiTTKdtwShOCenFfXcDwlu+fQGQQgDesrvDZqqllUr08=
=Ilg2
-----END PGP SIGNATURE-----

--=-Cqi3hYX8jdHIeYSXvJZQ--