[OpenAFS] Red Hat EL Support Customers - Please open a support
case for kafs in RHEL8
Gary Gatling
gsgatlin@ncsu.edu
Wed, 13 Feb 2019 14:58:22 -0500
--00000000000078544d0581cbf734
Content-Type: text/plain; charset="UTF-8"
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
>
--00000000000078544d0581cbf734
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">I was able to get 1.8.2 to compile for RH=
EL 8 x86_64=C2=A0 but "kinit" seems to be missing. :(</div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed=
, Feb 13, 2019 at 2:23 PM Dave Botsch <<a href=3D"mailto:botsch@cnf.corn=
ell.edu">botsch@cnf.cornell.edu</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Has anyone gotten openafs to compile under=
RHEL8 beta? I had tried<br>
previously and no gold. If so, one could then test and again file a bug<br>
report with RedHat saying "systemd --user breaks stuff" and here&=
#39;s the<br>
business case.<br>
<br>
Thanks.<br>
<br>
On Sun, Dec 09, 2018 at 10:34:40AM +0100, Dirk Heinrichs wrote:<br>
> Am Samstag, den 08.12.2018, 14:08 -0500 schrieb Jeffrey Altman:<br>
> > On 12/8/2018 5:21 AM, Dirk Heinrichs wrote:<br>
> > > Dirk Heinrichs:<br>
> > > <br>
> > > > Did a quick test (on Debian, btw., which already ships =
kafs) and<br>
> > > > it<br>
> > > > works fine.<br>
> > > <br>
> > > While getting tokens at login work with this setup, things s=
tart to<br>
> > > fail<br>
> > > once the users $HOME is set to be in /afs. While simple scen=
arios<br>
> > > like<br>
> > > pure shell/console logins work, graphical desktop environmen=
ts have<br>
> > > lots<br>
> > > of problems. XFCE4 doesn't even start, Plasma works to s=
ome degree<br>
> > > after<br>
> > > presenting lots of error dialogs to the user.<br>
> > <br>
> > As Harald indicated, "systemd --user" services are a pr=
oblem not just<br>
> > for kafs but for openafs as well.<br>
> <br>
> But that's not the problem here. Both work fine with the OpenAFS<b=
r>
> client.<br>
> <br>
> >=C2=A0 =C2=A0There has been discussions on this<br>
> > mailing list of the issues dating back more than a year.<br>
> <br>
> I know. I've been involved ;-)<br>
> <br>
> >=C2=A0 =C2=A0In summary,<br>
> > "systemd --user" services are incompatible with "s=
ession keyrings"<br>
> > which<br>
> > are used to represent AFS Process Authentication Groups.<br>
> <br>
> Yes.<br>
> <br>
> > You have no indicated which kernel version you are using nor am I=
<br>
> > aware<br>
> > of the options used to build AF_RXRPC and KAFS on Debian.=C2=A0 T=
he Linux<br>
> > kernel versions that are recommended are 4.19 with a couple of ba=
ck<br>
> > port<br>
> > patches from the forthcoming 4.20 and the 4.20 release candidate<=
br>
> > series.<br>
> <br>
> Ah, OK. Debian buster is still on 4.18. Will give it another try once<=
br>
> 4.20 is out...<br>
> <br>
> > Regardless, it would be useful for you to file bug reports with t=
he<br>
> > Linux distribution describing the issues you are experiencing.<br=
>
> > <br>
> > Debian: <a href=3D"https://wiki.debian.org/reportbug" rel=3D"nore=
ferrer" target=3D"_blank">https://wiki.debian.org/reportbug</a><br>
> <br>
> Yep, know this.<br>
> <br>
> > Fedora: <a href=3D"https://fedoraproject.org/wiki/Bugs_and_featur=
e_requests" rel=3D"noreferrer" target=3D"_blank">https://fedoraproject.org/=
wiki/Bugs_and_feature_requests</a><br>
> > <br>
> > > Seems there's still some work to do until this becomes a=
n<br>
> > > alternative<br>
> > > for the standard OpenAFS client.<br>
> > <br>
> > All software including OpenAFS has work to do.<br>
> <br>
> Sure. But the OpenAFS client is mature and just works (except for the<=
br>
> systemd --user thing, which isn't OpenAFS' fault).<br>
> <br>
> >=C2=A0 =C2=A0The kafs to-do list of known work items is here:<br>
> > <br>
> >=C2=A0 <a href=3D"https://www.infradead.org/~dhowells/kafs/todo.ht=
ml" rel=3D"noreferrer" target=3D"_blank">https://www.infradead.org/~dhowell=
s/kafs/todo.html</a><br>
> > <br>
> > > So I wonder why RH customers would want that?<br>
> > <br>
> > Obviously, no one wants bugs, but at the same time this community=
<br>
> > does want:<br>
> > <br>
> >=C2=A0 1. A solution to "systemd --user" service compati=
bility with AFS.<br>
> <br>
> ACK.<br>
> <br>
> >=C2=A0 =C2=A0 =C2=A0The required changes are going to require Linu=
x distribution<br>
> >=C2=A0 =C2=A0 =C2=A0intervention because systemd is integrated wit=
h differences<br>
> >=C2=A0 =C2=A0 =C2=A0to each distribution.=C2=A0 At the moment ther=
e is no interest among<br>
> >=C2=A0 =C2=A0 =C2=A0the systemd developers to work to fix a behavi=
or they consider<br>
> >=C2=A0 =C2=A0 =C2=A0to be a bug in OpenAFS, an out of tree file sy=
stem.<br>
> <br>
> So they need to understand it's a problem with an in-tree fs as we=
ll? I<br>
> see...<br>
> <br>
> >=C2=A0 2. The RHEL AFS user community needs an end to the repeated=
breakage<br>
> >=C2=A0 =C2=A0 =C2=A0of /afs access following each RHEL dot release=
.=C2=A0 How many times<br>
> >=C2=A0 =C2=A0 =C2=A0has getcwd() broken because RHEL kernels updat=
es preserve the API<br>
> >=C2=A0 =C2=A0 =C2=A0between releases but do not preserve the ABI.=
=C2=A0 While this permits<br>
> >=C2=A0 =C2=A0 =C2=A0third party kernel modules to load it does not=
ensure that they<br>
> >=C2=A0 =C2=A0 =C2=A0will do the right thing.=C2=A0 If the communit=
y is lucky the symptoms<br>
> >=C2=A0 =C2=A0 =C2=A0are visible.=C2=A0 If unlucky, the symptoms ar=
e hidden until someone<br>
> >=C2=A0 =C2=A0 =C2=A0reports silent data corruption.<br>
> <br>
> As a Debian user I didn't have these kind of problems in the past<=
br>
> *HINT* :-) But, OTOH, mine is just a small home setup.<br>
> <br>
> > The need for an in-tree Linux AFS client extends to all Linux<br>
> > distributions not just Red Hat.=C2=A0 Any OpenAFS Linux developer=
can<br>
> > attest<br>
> > to the extensive effort that must be expended to maintain<br>
> > compatibility<br>
> > with the mainline Linux kernel.=C2=A0 Then multiply that effort b=
y all of<br>
> > the<br>
> > Linux distributions that ship modified kernels such as RHEL, SuSE=
,<br>
> > Ubuntu, Oracle, ....<br>
> <br>
> ACK<br>
> <br>
> Bye...<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Dirk<br>
> <br>
> -- <br>
> Dirk Heinrichs<br>
> GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015<br>
> Sichere Internetkommunikation: <a href=3D"http://www.retroshare.org" r=
el=3D"noreferrer" target=3D"_blank">http://www.retroshare.org</a><br>
> Privacy Handbuch: <a href=3D"https://www.privacy-handbuch.de" rel=3D"n=
oreferrer" target=3D"_blank">https://www.privacy-handbuch.de</a> <br>
<br>
<br>
<br>
-- <br>
********************************<br>
David William Botsch<br>
Programmer/Analyst<br>
@CNFComputing<br>
<a href=3D"mailto:botsch@cnf.cornell.edu" target=3D"_blank">botsch@cnf.corn=
ell.edu</a><br>
********************************<br>
_______________________________________________<br>
OpenAFS-info mailing list<br>
<a href=3D"mailto:OpenAFS-info@openafs.org" target=3D"_blank">OpenAFS-info@=
openafs.org</a><br>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info" rel=3D"=
noreferrer" target=3D"_blank">https://lists.openafs.org/mailman/listinfo/op=
enafs-info</a><br>
</blockquote></div>
--00000000000078544d0581cbf734--