[OpenAFS] Red Hat EL Support Customers - Please open a support
case for kafs in RHEL8
Gary Gatling
gsgatlin@ncsu.edu
Wed, 13 Feb 2019 17:27:11 -0500
--000000000000adc1950581ce0b7e
Content-Type: text/plain; charset="UTF-8"
Hello,
The rpms I have been using are at:
https://linux.itecs.ncsu.edu/redhat/public/openafs/rhel8/
They are flawed in 2 ways.
1. There is no EPEL repository yet. I am a fedora contributor and have a
couple of packages in EPEL. But they did not make a branch in EPEL for RHEL
8 yet. So that would make it hard to use these since we need Simone
Caronni's "dkms" rpm which is in fedora but is not in RHEL/CentOS.
2. It does not build on aarch64 platform. I am unsure why. It just gives
the error:
Makefile:68: *** mixed implicit and normal rules. Stop.
I will try to put these into a repo on github.com in case it is useful to
others. I guess I need to make a 1.6.X branch and make master be these
1.8.X. I'll need to give it some further thought. I was mainly working on
these for a fedora 29 laptop I use but I'm glad its also useful for
RHEL/CentOS 8 when it comes out.
On Wed, Feb 13, 2019 at 3:16 PM Dave Botsch <botsch@cnf.cornell.edu> wrote:
> Ok. I just openafs-1.8.2-1.src.rpm, and it does not build.
>
> Thanks.
>
> On Wed, Feb 13, 2019 at 03:13:06PM -0500, Gary Gatling wrote:
> > 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
> > >
>
> --
> ********************************
> 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
>
--000000000000adc1950581ce0b7e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hello,<=
div><br></div><div>The rpms I have been using are at:</div><div><br></div><=
div><a href=3D"https://linux.itecs.ncsu.edu/redhat/public/openafs/rhel8/">h=
ttps://linux.itecs.ncsu.edu/redhat/public/openafs/rhel8/</a><br></div><div>=
<br></div><div>They are flawed in 2 ways.</div><div><br></div><div>1. There=
is no EPEL repository yet. I am a fedora contributor and have a couple of =
packages in EPEL. But they did not make a branch in EPEL for RHEL 8 yet. So=
that would make it hard to use these since we need Simone Caronni's &q=
uot;dkms" rpm which is in fedora but is not in RHEL/CentOS.</div><div>=
<br></div><div>2. It does not build on aarch64 platform. I am unsure why. I=
t just gives the error:</div><div><br></div><div>Makefile:68: *** mixed imp=
licit and normal rules.=C2=A0 Stop.</div><div><br></div><div>I will try to =
put these into a repo on <a href=3D"http://github.com">github.com</a> in ca=
se it is useful to others. I guess I need to make a 1.6.X branch and make m=
aster be these 1.8.X. I'll need to give it some further thought. I was =
mainly working on these for a fedora 29 laptop I use but I'm glad its a=
lso useful for RHEL/CentOS 8 when it comes out.</div><div><br></div><div><b=
r></div></div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Wed, Feb 13, 2019 at 3:16 PM Dave Botsch <<=
a href=3D"mailto:botsch@cnf.cornell.edu">botsch@cnf.cornell.edu</a>> wro=
te:<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">Ok. I just o=
penafs-1.8.2-1.src.rpm, and it does not build.<br>
<br>
Thanks.<br>
<br>
On Wed, Feb 13, 2019 at 03:13:06PM -0500, Gary Gatling wrote:<br>
> No. I have my own rpms that were descended from the rpmfusion repos be=
fore<br>
> they were abandoned. Except the kernel module rpm is something someone=
else<br>
> made here at NCSU that I heavily modified. I will try to upload those =
to a<br>
> yum repo as soon as I fix my selinux issues.<br>
> <br>
> On Wed, Feb 13, 2019 at 3:10 PM Dave Botsch <<a href=3D"mailto:bots=
ch@cnf.cornell.edu" target=3D"_blank">botsch@cnf.cornell.edu</a>> wrote:=
<br>
> <br>
> > Did you use the downloadable srpm from <a href=3D"http://openafs.=
org" rel=3D"noreferrer" target=3D"_blank">openafs.org</a> ?<br>
> ><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 b=
ut "kinit" seems<br>
> > to<br>
> > > be missing. :(<br>
> > ><br>
> > > On Wed, Feb 13, 2019 at 2:23 PM Dave Botsch <<a href=3D"m=
ailto:botsch@cnf.cornell.edu" target=3D"_blank">botsch@cnf.cornell.edu</a>&=
gt;<br>
> > wrote:<br>
> > ><br>
> > > > 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 s=
tuff" and here's the<br>
> > > > business case.<br>
> > > ><br>
> > > > Thanks.<br>
> > > ><br>
> > > > On Sun, Dec 09, 2018 at 10:34:40AM +0100, Dirk Heinrich=
s wrote:<br>
> > > > > Am Samstag, den 08.12.2018, 14:08 -0500 schrieb Je=
ffrey Altman:<br>
> > > > > > On 12/8/2018 5:21 AM, Dirk Heinrichs wrote:<b=
r>
> > > > > > > Dirk Heinrichs:<br>
> > > > > > ><br>
> > > > > > > > Did a quick test (on Debian, btw., =
which already ships kafs)<br>
> > and<br>
> > > > > > > > it<br>
> > > > > > > > works fine.<br>
> > > > > > ><br>
> > > > > > > While getting tokens at login work with =
this setup, things start<br>
> > to<br>
> > > > > > > fail<br>
> > > > > > > once the users $HOME is set to be in /af=
s. While simple scenarios<br>
> > > > > > > like<br>
> > > > > > > pure shell/console logins work, graphica=
l desktop environments<br>
> > have<br>
> > > > > > > lots<br>
> > > > > > > of problems. XFCE4 doesn't even star=
t, Plasma works to some<br>
> > degree<br>
> > > > > > > after<br>
> > > > > > > presenting lots of error dialogs to the =
user.<br>
> > > > > ><br>
> > > > > > As Harald indicated, "systemd --user&quo=
t; services are a problem not<br>
> > just<br>
> > > > > > for kafs but for openafs as well.<br>
> > > > ><br>
> > > > > But that's not the problem here. Both work fin=
e with the OpenAFS<br>
> > > > > client.<br>
> > > > ><br>
> > > > > >=C2=A0 =C2=A0There has been discussions on thi=
s<br>
> > > > > > mailing list of the issues dating back more t=
han a year.<br>
> > > > ><br>
> > > > > I know. I've been involved ;-)<br>
> > > > ><br>
> > > > > >=C2=A0 =C2=A0In summary,<br>
> > > > > > "systemd --user" services are incom=
patible with "session keyrings"<br>
> > > > > > which<br>
> > > > > > are used to represent AFS Process Authenticat=
ion Groups.<br>
> > > > ><br>
> > > > > Yes.<br>
> > > > ><br>
> > > > > > You have no indicated which kernel version yo=
u are using nor am I<br>
> > > > > > aware<br>
> > > > > > of the options used to build AF_RXRPC and KAF=
S on Debian.=C2=A0 The<br>
> > Linux<br>
> > > > > > kernel versions that are recommended are 4.19=
with a couple of back<br>
> > > > > > port<br>
> > > > > > patches from the forthcoming 4.20 and the 4.2=
0 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 fil=
e bug reports with the<br>
> > > > > > Linux distribution describing the issues you =
are experiencing.<br>
> > > > > ><br>
> > > > > > Debian: <a href=3D"https://wiki.debian.org/re=
portbug" rel=3D"noreferrer" target=3D"_blank">https://wiki.debian.org/repor=
tbug</a><br>
> > > > ><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:=
//fedoraproject.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 wo=
rks (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/~d=
howells/kafs/todo.html" rel=3D"noreferrer" target=3D"_blank">https://www.in=
fradead.org/~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&q=
uot; service compatibility with AFS.<br>
> > > > ><br>
> > > > > ACK.<br>
> > > > ><br>
> > > > > >=C2=A0 =C2=A0 =C2=A0The required changes are g=
oing to require Linux distribution<br>
> > > > > >=C2=A0 =C2=A0 =C2=A0intervention because syste=
md is integrated with differences<br>
> > > > > >=C2=A0 =C2=A0 =C2=A0to each distribution.=C2=
=A0 At the moment there is no interest among<br>
> > > > > >=C2=A0 =C2=A0 =C2=A0the systemd developers to =
work to fix a behavior they consider<br>
> > > > > >=C2=A0 =C2=A0 =C2=A0to be a bug in OpenAFS, an=
out of tree file system.<br>
> > > > ><br>
> > > > > So they need to understand it's a problem with=
an in-tree fs as<br>
> > well? I<br>
> > > > > see...<br>
> > > > ><br>
> > > > > >=C2=A0 2. The RHEL AFS user community needs an=
end to the repeated<br>
> > breakage<br>
> > > > > >=C2=A0 =C2=A0 =C2=A0of /afs access following e=
ach RHEL dot release.=C2=A0 How many times<br>
> > > > > >=C2=A0 =C2=A0 =C2=A0has getcwd() broken becaus=
e RHEL kernels updates preserve the<br>
> > API<br>
> > > > > >=C2=A0 =C2=A0 =C2=A0between releases but do no=
t preserve the ABI.=C2=A0 While this<br>
> > 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 community is lucky the<br>
> > symptoms<br>
> > > > > >=C2=A0 =C2=A0 =C2=A0are visible.=C2=A0 If unlu=
cky, the symptoms are hidden until someone<br>
> > > > > >=C2=A0 =C2=A0 =C2=A0reports silent data corrup=
tion.<br>
> > > > ><br>
> > > > > As a Debian user I didn't have these kind of p=
roblems in the past<br>
> > > > > *HINT* :-) But, OTOH, mine is just a small home se=
tup.<br>
> > > > ><br>
> > > > > > The need for an in-tree Linux AFS client exte=
nds to all Linux<br>
> > > > > > distributions not just Red Hat.=C2=A0 Any Ope=
nAFS 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 mu=
ltiply that effort by all<br>
> > of<br>
> > > > > > the<br>
> > > > > > Linux distributions that ship modified kernel=
s 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: D01B367761B0F7CE6E6D81AAD5A2E54246=
986015<br>
> > > > > Sichere Internetkommunikation: <a href=3D"http://w=
ww.retroshare.org" rel=3D"noreferrer" target=3D"_blank">http://www.retrosha=
re.org</a><br>
> > > > > Privacy Handbuch: <a href=3D"https://www.privacy-h=
andbuch.de" rel=3D"noreferrer" target=3D"_blank">https://www.privacy-handbu=
ch.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"_bl=
ank">botsch@cnf.cornell.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/o=
penafs-info" rel=3D"noreferrer" target=3D"_blank">https://lists.openafs.org=
/mailman/listinfo/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">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>
--000000000000adc1950581ce0b7e--