Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
On Tue, May 7, 2019 at 1:38 PM Jeffrey Altman wrote: > Gary, > > As far as I am aware there is no final decision either way with regards to > inclusion of kafs in rhel8. There are several components that were not > merged into Linux mainline until after the 4.18 kernel on which rhel8.0 is > based. These include not only AuriStorFS feature and openafs compatibility > enhancements to kafs but the new Linux mount API which provides namespace > support that kafs leverages and namespacing for keyrings which is needed > for filesystem credential management on behalf of containers. > > There is no business case for Red Hat to commit a ten year investment > simply to support legacy AFS deployments. The justification for including > kafs is to support functionality that will result in new deployments. That > functionality requires the new mount API, keyring namespacing, and even > some features that have yet to be implemented in AuriStorFS. > > The door is not closed. David Howells and the AuriStor team continue to > fill in the gaps. This week a request was filed to add /afs to the File > Hierarchy System (FHS). Inclusion in the FHS is required by some Linux > Distributions before a new roof directory can be added to the distribution. > Cool. Hopefully they might consider it for a "point" release then. Cheers,
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
It looks like Red Hat decided no concerning kafs and RHEL. This makes me sad since they couldn't even be bothered to tell us... [root@localhost ~]# modprobe kafs modprobe: FATAL: Module kafs not found in directory /lib/modules/4.18.0-80.el8.x86_64 [root@localhost ~]# cat /etc/redhat-release Red Hat Enterprise Linux release 8.0 (Ootpa) On Thu, Dec 6, 2018 at 6:33 PM Jeffrey Altman wrote: > To all AuriStorFS licensees and OpenAFS users, > > After more than seventeen years of development led by David Howells, the > Linux kernel now includes a production ready AFS/AuriStorFS client > (kafs) and RX RPC protocol implementation (AF_RXRPC)[1]. These are not > add-ons. kafs and af_rxrpc are baked into the mainline kernel. > > Jonathan Billings has been building kafs enabled Fedora Core kernels via > COPR[1] since July[3]. Beginning with the 4.19 kernel, Fedora Core > kernels now ship with kafs and af_rxrpc enabled. > > It was my hope that Red Hat would include kafs and af_rxrpc in RHEL8 > Beta as an experimental technology. Unfortunately, the RHEL8 Beta > announced on Nov 15th did not include either. > > Thankfully it is not too late to for kafs and af_rxrpc to be added > before a final release of RHEL8 but RHEL support customers must make the > case by registering for the RHEL8 Beta[4] and opening a Support Case[5]. > > When opening a support case please specify: > > Product: Red Hat Enterprise Linux > Version: 8.0 Beta > Case Type:Feature / Enhancement Request > Hostname: hostname of the system on which RHEL8 beta was installed > Problem > Statement:Request inclusion of kafs > Case > Description; Explain why your organization uses AFS/AuriStorFS in >addition to RHEL support storage systems and how the >inclusion of kafs and af_rxrpc in RHEL8 will benefit >your organization. > > It is very important that the Case Description be specific to your > organization. Each organization's reasons for using AFS/AuriStorFS are > different just as each organization's use cases are different. > > If you are eligible, please attempt to open a support request by > December 11th. Although this is not a hard deadline, many individuals > will begin taking end of year vacation time the middle of next week. > > Frequently Asked Questions: > > 1. Is the kafs kernel module a replacement for the OpenAFS and > AuriStorFS kernel modules? > > The best way to think of kafs is that it is an alternative to the > AFS/AuriStorFS and OpenAFS clients. When kafs is provided as part of a > Linux distribution and it is enabled, it is not necessary to install any > of the OpenAFS or AuriStorFS client packages. > > 2. Is kafs compatible with IBM AFS, OpenAFS and AuriStorFS servers? > > Yes. kafs is compatible with IBM AFS 3.6 and all versions of OpenAFS > and AuriStorFS servers. > > 3. Does enabling kafs and af_rxrpc in RHEL8 prevent installation of > AuriStorFS or OpenAFS clients? > > No. Not only can the AuriStorFS kernel module be installed on Linux > kernels built with kafs and af_rxrpc but both AuriStorFS and kafs can be > enabled at the same time. Runtime choices have to be made to decide > which will service the /afs mount point, which will use port 7001/udp > for the callback service, etc. However, there is nothing that prevents > co-existence. > > OpenAFS developers will need to ensure compatibility with the latest > RHEL kernels and build configurations. It is likely that minor coding > adjustments will need to be implemented. > > 4. How does kafs/af_rxrpc performance compare to OpenAFS and AuriStorFS > clients? > > In many workflows the kafs/af_rxrpc client is faster and more efficient > than either OpenAFS or AuriStorFS clients. kafs/af_rxrpc are tightly > integrated into the Linux network stack and virtual file system layer. > There is significantly less overhead in the network stack (no double > buffering) and no global locks. Building the Linux kernel from source > in /afs with kafs is at least 30% faster than the AuriStorFS cache > manager without encryption. > > 5. Are there features that OpenAFS has that kafs does not? > > Yes. kafs does not split horizon caching, it does not have an > equivalent of cache bypass, it does not implement any of the rxdebug or > xstat_cm statistics collection. Nor does it provide pioctls and there is > no fs, vos, pts, bos command suite. kafs does not export afs2nfs. > > 6. Are there features that AuriStorFS has that kafs does not? > > In addition to the items mentioned in the prior answer, kafs does not > yet support the yfs-rxgk security class and aes256-cts-hmac-sha1-96 or > aes256-cts-hmac-sha512-384 encryption. O_DIRECT support is not yet > complete. kafs is a fairly complete AuriStorFS client including support > for IPv6 and AuriStorFS RPC suites. > > 7. Does kafs have capabilities that are implemented in neither OpenAFS > nor AuriStorS? > > kafs auto-mounts each afs volume as a separate device
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
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 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 > 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 > > > 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). > > > > >
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
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 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 > > 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
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
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 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 > 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
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
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 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,
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
Ok. I had to install krb5-workstation-1.16.1-19.el8.x86_64.rpm :) It appears to be working for me. I'm sorry I don't have this in github. But I will try to put it on the web somewhere. I was able to create, alter. and delete files in the unity.ncsu.edu cell. There were some more minor selinux issues I have to fix and I had to make my own "EPEL" for things like dkms. But 1.8.2 seems to work for me. On Wed, Feb 13, 2019 at 2:58 PM 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 > 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
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
kinit comes from krb5, not openafs. -Ben 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. :( ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
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 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 >
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
On Wed, Feb 13, 2019 at 2:24 PM Dave Botsch 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.-- > > kafs's aklog still uses session keyrings, so it essentially has the same problem as OpenAFS. If we moved it into the user keyring along with the KRB5 credential cache, kafs might be ok. -- Jonathan Billings College of Engineering - CAEN - Unix and Linux Support
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
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 bot...@cnf.cornell.edu ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
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 signature.asc Description: This is a digitally signed message part
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8,Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
Am Sat, 08 Dec 2018 13:32:08 +0100 (CET) schrieb Harald Barth : > Is this a problem due to AFS or due to the startup of the graphical > environment which nowadays may involve systemd --user services > instead of running all processes in the same session? No, it's not. Both desktop environments work fine with the OpenAFS client. The systemd --user thing is a different story. Bye... Dirk -- Dirk Heinrichs GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015 Sichere Internetkommunikation: http://www.retroshare.org Privacy Handbuch: https://www.privacy-handbuch.de signature.asc Description: This is a digitally signed message part
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
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. There has been discussions on this mailing list of the issues dating back more than a year. In summary, "systemd --user" services are incompatible with "session keyrings" which are used to represent AFS Process Authentication Groups. 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. 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 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. 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. 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. 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. 3. Day zero support for new kernel releases. It took OpenAFS a month to support 7.4 and two months to fix the breakage from 7.5. There were also extensive delays in fixing OpenAFS to work with 5.10 and 6.5. 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, RHEL 8 is in beta. The next opportunity to argue for inclusion of the in-tree AFS client will be RHEL 9. The clock is ticking Jeffrey Altman <> smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8,Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
> 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. Is this a problem due to AFS or due to the startup of the graphical environment which nowadays may involve systemd --user services instead of running all processes in the same session? > Seems there's still some work to do until this becomes an alternative > for the standard OpenAFS client. It may make a "beta", so yes. > So I wonder why RH customers would want that? RH decided that their customers wanted systemd ;-> Harald. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
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. Seems there's still some work to do until this becomes an alternative for the standard OpenAFS client. So I wonder why RH customers would want that? Bye... Dirk -- Dirk Heinrichs GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015 Sichere Internetkommunikation: http://www.retroshare.org Privacy Handbuch: https://www.privacy-handbuch.de signature.asc Description: OpenPGP digital signature
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
On 12/7/2018 4:00 AM, Harald Barth wrote: > > Hi Jeff, hi David! > > Has it been 17 years? Well, we are all getting - mature ;-) > > Obviously a file system is ready for use if it's old enough to buy > liquor (which difffers a little between countries). > >> When opening a support case please specify: >> >> Product: Red Hat Enterprise Linux >> Version: 8.0 Beta >> Case Type:Feature / Enhancement Request >> Hostname: hostname of the system on which RHEL8 beta was installed > > We have a hen and egg problem here: Why would I install 8.0b on > if it does not have kafs? Install a Fedora > test, sure, but RHEL 8.0b? You need to register for and install the RHEL 8.0 Beta to be eligible to submit a feature / enhancement request. RHEL 8.0 Beta does not include kafs. Hence the need to request its inclusion as a feature request. >> If you are eligible, please attempt to open a support request by >> December 11th. > > 3 workdays. Optimistic. If you personally are unable to do so, then you won't. However, others have already submitted feature requests in response to this thread. To them the community owes thanks. The more requests that are received the better. >> As part of the Linux kernel source tree, kafs is indirectly supported by >> the entire Linux kernel development community. All of the automated >> testing performed against the mainline kernel is also performed against >> kafs. > > But the automated testing does probably not (yet) fetch a single file > from an AFS server. The automated testing performed by Red Hat doesn't as yet perform such testing but AuriStor's testing does. > Testing that requires infrastructure is a lot of work to > automate. Not true. At the 2015 AFSBPW Marc Dionne presented on AuriStor's docker based infrastructure for automated testing of multi-server cells including clients. http://workshop.openafs.org/afsbpw15/talks/friday/dionne-docker.pdf Since that time AuriStor has added live testing of kernel modules. Each run currently performs approximately 7000 individual tests. > Sorry, I may sound much more pessimistic here than I am actually are. > This _might_ fly. I wish :-) There is ample reason to be pessimistic Its really easy for Fedora Core and Debian to ship kernels built with kafs and AF_RXRPC enabled because there are no guarantees. I believe that if Red Hat enables kafs in Enterprise Linux there are substantial costs and commitments associated with that decision: * Documentation of AFS and AuriStorFS capabilities and limitations not only as a filesystem but with regards to interactions with other Red Hat supported components. * Training for system engineers. * Integration of AFS and AuriStorFS support into other Red Hat supported technologies * Development of Certification and Training programs for partners. * A ten year commitment to develop, maintain and fix kafs and AF_RXRPC * Development and maintenance of test infrastructure. The truth is that the costs associated with code development is a small component of the total costs. As such Red Hat must be convinced that inclusion of kafs and AF_RXRPC will provide functional capabilities to end users that cannot be achieved via other Red Hat supported storage technologies; and that supporting kafs and AF_RXRPC will provide a long-term benefit to their bottom line. That said, I believe a case can be made by the members of this community. In 2001 Red Hat couldn't support AFS because of GPL vs IPL10 conflicts. Now that kafs is available, it becomes possible for Red Hat to do so. Its up to all OpenAFS and AuriStorFS end user organizations to make the case. Good luck to all. Jeffrey Altman <> smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
Jonathan Billings: > On my systems, I install the kafs-client package (currently in COPR, but > eventually to be in Fedora 29) that includes a kafs-aware aklog package, > and use pam_exec to have it run aklog as part of the PAM stack. Here's the > source: http://git.infradead.org/users/dhowells/kafs-client.git Nice. Wasn't aware of this. > I append this to my PAM config, where I use pam_sss to get kerberos tickets > for UMICH.EDU. > session optional pam_exec.so quiet seteuid /usr/bin/aklog umich.edu Did a quick test (on Debian, btw., which already ships kafs) and it works fine. > I've not tried getting pam-afs-session to work with the kafs version of > aklog. It does look like program=/path/to/kafs-aklog would work. Turns out this module checks for the "traditional" AFS client, so it doesn't work with kafs. Anyway, the pam_exec method makes for a good workaround ;-) Bye... Dirk -- Dirk Heinrichs GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015 Sichere Internetkommunikation: http://www.retroshare.org Privacy Handbuch: https://www.privacy-handbuch.de signature.asc Description: OpenPGP digital signature
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
On my systems, I install the kafs-client package (currently in COPR, but eventually to be in Fedora 29) that includes a kafs-aware aklog package, and use pam_exec to have it run aklog as part of the PAM stack. Here's the source: http://git.infradead.org/users/dhowells/kafs-client.git I append this to my PAM config, where I use pam_sss to get kerberos tickets for UMICH.EDU. session optional pam_exec.so quiet seteuid /usr/bin/aklog umich.edu I've not tried getting pam-afs-session to work with the kafs version of aklog. It does look like program=/path/to/kafs-aklog would work. On Fri, Dec 7, 2018 at 11:26 AM Dirk Heinrichs wrote: > Am 07.12.18 um 00:33 schrieb Jeffrey Altman: > > > 5. Are there features that OpenAFS has that kafs does not? > > > > Yes. kafs does not split horizon caching, it does not have an > > equivalent of cache bypass, it does not implement any of the rxdebug or > > xstat_cm statistics collection. Nor does it provide pioctls and there is > > no fs, vos, pts, bos command suite. kafs does not export afs2nfs. > > What about PAM integration? Does pam-afs-session also work with kafs? Or > is there any other way for users to get access to their $HOME in /afs? > > From the documentation inside the kernel tree I take it that there's > currently only a klog program, which needs to be invoked explicitly (so > AFTER the user has logged in). Or can it be used by said PAM module by > using its "program=path" configuration option (see pam_afs_session(5))? > > Bye... > > Dirk > > -- > Dirk Heinrichs > GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015 > Sichere Internetkommunikation: http://www.retroshare.org > Privacy Handbuch: https://www.privacy-handbuch.de > > > ___ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- Jonathan Billings College of Engineering - CAEN - Unix and Linux Support
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
Am 07.12.18 um 00:33 schrieb Jeffrey Altman: > 5. Are there features that OpenAFS has that kafs does not? > > Yes. kafs does not split horizon caching, it does not have an > equivalent of cache bypass, it does not implement any of the rxdebug or > xstat_cm statistics collection. Nor does it provide pioctls and there is > no fs, vos, pts, bos command suite. kafs does not export afs2nfs. What about PAM integration? Does pam-afs-session also work with kafs? Or is there any other way for users to get access to their $HOME in /afs? From the documentation inside the kernel tree I take it that there's currently only a klog program, which needs to be invoked explicitly (so AFTER the user has logged in). Or can it be used by said PAM module by using its "program=path" configuration option (see pam_afs_session(5))? Bye... Dirk -- Dirk Heinrichs GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015 Sichere Internetkommunikation: http://www.retroshare.org Privacy Handbuch: https://www.privacy-handbuch.de ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
Hi Jeff, hi David! Has it been 17 years? Well, we are all getting - mature ;-) Obviously a file system is ready for use if it's old enough to buy liquor (which difffers a little between countries). > When opening a support case please specify: > > Product: Red Hat Enterprise Linux > Version: 8.0 Beta > Case Type:Feature / Enhancement Request > Hostname: hostname of the system on which RHEL8 beta was installed We have a hen and egg problem here: Why would I install 8.0b on if it does not have kafs? Install a Fedora test, sure, but RHEL 8.0b? > If you are eligible, please attempt to open a support request by > December 11th. 3 workdays. Optimistic. > As part of the Linux kernel source tree, kafs is indirectly supported by > the entire Linux kernel development community. All of the automated > testing performed against the mainline kernel is also performed against > kafs. But the automated testing does probably not (yet) fetch a single file from an AFS server. (Compare to how the gssapi-key-exchange features in ssh are never tested in the ssh/scp shipped with distributions as the testing never fetched a single file with that feature - with known results). Testing that requires infrastructure is a lot of work to automate. Sorry, I may sound much more pessimistic here than I am actually are. This _might_ fly. I wish :-) Season's greetings, Harald. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
