[OpenAFS] Red Hat EL Support Customers - Please open a support
case for kafs in RHEL8
Gary Gatling
gsgatlin@ncsu.edu
Wed, 13 Feb 2019 15:13:06 -0500
--0000000000003070080581cc2c5e
Content-Type: text/plain; charset="UTF-8"
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
>
--0000000000003070080581cc2c5e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">No. I have my own rpms that were descended from the rpmfus=
ion repos before they were abandoned. Except the kernel module rpm is somet=
hing 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.</div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 1=
3, 2019 at 3:10 PM Dave Botsch <<a href=3D"mailto:botsch@cnf.cornell.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 rgb(204,204=
,204);padding-left:1ex">Did you use the downloadable srpm from <a href=3D"h=
ttp://openafs.org" rel=3D"noreferrer" target=3D"_blank">openafs.org</a> ?<b=
r>
<br>
On Wed, Feb 13, 2019 at 02:58:22PM -0500, Gary Gatling wrote:<br>
> I was able to get 1.8.2 to compile for RHEL 8 x86_64=C2=A0 but "k=
init" seems to<br>
> be missing. :(<br>
> <br>
> On Wed, Feb 13, 2019 at 2:23 PM Dave Botsch <<a href=3D"mailto:bots=
ch@cnf.cornell.edu" target=3D"_blank">botsch@cnf.cornell.edu</a>> wrote:=
<br>
> <br>
> > Has anyone gotten openafs to compile under RHEL8 beta? I had trie=
d<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's the<br>
> > business case.<br>
> ><br>
> > Thanks.<br>
> ><br>
> > On Sun, Dec 09, 2018 at 10:34:40AM +0100, Dirk Heinrichs wrote:<b=
r>
> > > Am Samstag, den 08.12.2018, 14:08 -0500 schrieb Jeffrey Altm=
an:<br>
> > > > On 12/8/2018 5:21 AM, Dirk Heinrichs wrote:<br>
> > > > > Dirk Heinrichs:<br>
> > > > ><br>
> > > > > > Did a quick test (on Debian, btw., which alre=
ady ships kafs) and<br>
> > > > > > it<br>
> > > > > > works fine.<br>
> > > > ><br>
> > > > > While getting tokens at login work with this setup=
, things start to<br>
> > > > > fail<br>
> > > > > once the users $HOME is set to be in /afs. While s=
imple scenarios<br>
> > > > > like<br>
> > > > > pure shell/console logins work, graphical desktop =
environments have<br>
> > > > > lots<br>
> > > > > of problems. XFCE4 doesn't even start, Plasma =
works to some degree<br>
> > > > > after<br>
> > > > > presenting lots of error dialogs to the user.<br>
> > > ><br>
> > > > As Harald indicated, "systemd --user" service=
s are a problem 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<br>
> > > 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 wi=
th "session 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 usin=
g nor am I<br>
> > > > aware<br>
> > > > of the options used to build AF_RXRPC and KAFS on Debia=
n.=C2=A0 The Linux<br>
> > > > kernel versions that are recommended are 4.19 with a co=
uple of back<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 repo=
rts with the<br>
> > > > Linux distribution describing the issues you are experi=
encing.<br>
> > > ><br>
> > > > Debian: <a href=3D"https://wiki.debian.org/reportbug" r=
el=3D"noreferrer" target=3D"_blank">https://wiki.debian.org/reportbug</a><b=
r>
> > ><br>
> > > Yep, know this.<br>
> > ><br>
> > > > Fedora: <a href=3D"https://fedoraproject.org/wiki/Bugs_=
and_feature_requests" rel=3D"noreferrer" target=3D"_blank">https://fedorapr=
oject.org/wiki/Bugs_and_feature_requests</a><br>
> > > ><br>
> > > > > Seems there's still some work to do until this=
becomes an<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 (excep=
t for the<br>
> > > systemd --user thing, which isn't OpenAFS' fault).<b=
r>
> > ><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/ka=
fs/todo.html" rel=3D"noreferrer" target=3D"_blank">https://www.infradead.or=
g/~dhowells/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" servi=
ce compatibility with AFS.<br>
> > ><br>
> > > ACK.<br>
> > ><br>
> > > >=C2=A0 =C2=A0 =C2=A0The required changes are going to re=
quire Linux distribution<br>
> > > >=C2=A0 =C2=A0 =C2=A0intervention because systemd is inte=
grated with differences<br>
> > > >=C2=A0 =C2=A0 =C2=A0to each distribution.=C2=A0 At the m=
oment there is no interest among<br>
> > > >=C2=A0 =C2=A0 =C2=A0the systemd developers to work to fi=
x a behavior they consider<br>
> > > >=C2=A0 =C2=A0 =C2=A0to be a bug in OpenAFS, an out of tr=
ee file system.<br>
> > ><br>
> > > So they need to understand it's a problem with an in-tre=
e fs as well? I<br>
> > > see...<br>
> > ><br>
> > > >=C2=A0 2. The RHEL AFS user community needs an end to th=
e repeated breakage<br>
> > > >=C2=A0 =C2=A0 =C2=A0of /afs access following each RHEL d=
ot release.=C2=A0 How many times<br>
> > > >=C2=A0 =C2=A0 =C2=A0has getcwd() broken because RHEL ker=
nels updates 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 i=
t does not ensure that they<br>
> > > >=C2=A0 =C2=A0 =C2=A0will do the right thing.=C2=A0 If th=
e community is lucky the symptoms<br>
> > > >=C2=A0 =C2=A0 =C2=A0are visible.=C2=A0 If unlucky, the s=
ymptoms are 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 mainta=
in<br>
> > > > compatibility<br>
> > > > with the mainline Linux kernel.=C2=A0 Then multiply tha=
t effort by 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.retrosh=
are.org" rel=3D"noreferrer" target=3D"_blank">http://www.retroshare.org</a>=
<br>
> > > Privacy Handbuch: <a href=3D"https://www.privacy-handbuch.de=
" rel=3D"noreferrer" 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">botsc=
h@cnf.cornell.edu</a><br>
> > ********************************<br>
> > _______________________________________________<br>
> > OpenAFS-info mailing list<br>
> > <a href=3D"mailto:OpenAFS-info@openafs.org" target=3D"_blank">Ope=
nAFS-info@openafs.org</a><br>
> > <a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-inf=
o" rel=3D"noreferrer" target=3D"_blank">https://lists.openafs.org/mailman/l=
istinfo/openafs-info</a><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>
--0000000000003070080581cc2c5e--