Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Comment 11Steve Whitehouse
2017-04-04 11:34:44 UTC
Bearing in mind where we are on the 7.4 schedule, we should not be adding new features that (at least as far as I can tell from above) are not yet upstream. Unless there is a pressing customer need I'm going to propose that we move this to 7.5 at this stage. Does that sound reasonable?
(In reply to Steve Whitehouse from comment #11)
> Bearing in mind where we are on the 7.4 schedule, we should not be adding
> new features that (at least as far as I can tell from above) are not yet
> upstream. Unless there is a pressing customer need I'm going to propose that
> we move this to 7.5 at this stage. Does that sound reasonable?
I don't know if I'd call this a new feature or not. rpc.gssd and rpc.idmapd both allow you to specify a different value for the rpc_pipefs mountpoint, but the systemd configuration that sets up the rpc_pipefs mountpoint is hard-coded. To me that seems like a bug.
With the changes I'm proposing, instead of manually overriding a bunch of configs as in comment #8, it's simply a matter of editing one setting in the /etc/nfs.conf and rebooting:
[root@fedora25 ~]# lsof -p `pidof rpc.idmapd` | grep rpc_pipefs
rpc.idmap 670 root 9r DIR 0,42 0 103 /var/lib/nfs/rpc_pipefs/nfs
[root@fedora25 ~]# lsof -p `pidof rpc.gssd` | grep rpc_pipefs
rpc.gssd 671 root cwd DIR 0,42 0 20769 /var/lib/nfs/rpc_pipefs
rpc.gssd 671 root 7r DIR 0,42 0 20769 /var/lib/nfs/rpc_pipefs
rpc.gssd 671 root 11u FIFO 0,42 0t0 112 /var/lib/nfs/rpc_pipefs/gssd/clntXX/gssd
[root@fedora25 ~]# vi /etc/nfs.conf
[root@fedora25 ~]# cat /etc/nfs.conf
#
# This is a general configuration for the
# NFS daemons and tools
#
[general]
pipefs-directory=/run/rpc_pipefs
...
[root@fedora25 ~]# reboot
Connection to fedora25 closed by remote host.
Connection to fedora25 closed.
[smayhew@coeurl ~]$
[smayhew@coeurl ~]$ ssh root@fedora25
Last login: Thu Apr 6 14:10:18 2017 from 192.168.122.1
[root@fedora25 ~]# lsof -p `pidof rpc.idmapd` | grep rpc_pipefs
rpc.idmap 667 root 9r DIR 0,42 0 103 /run/rpc_pipefs/nfs
[root@fedora25 ~]# lsof -p `pidof rpc.gssd` | grep rpc_pipefs
rpc.gssd 669 root cwd DIR 0,42 0 20706 /run/rpc_pipefs
rpc.gssd 669 root 7r DIR 0,42 0 20706 /run/rpc_pipefs
rpc.gssd 669 root 11u FIFO 0,42 0t0 112 /run/rpc_pipefs/gssd/clntXX/gssd
Instead of rebooting, one can do this instead after editing /etc/nfs.conf:
[root@fedora25 ~]# systemctl daemon-reload
[root@fedora25 ~]# systemctl restart rpc_pipefs.target
[root@fedora25 ~]# systemctl restart nfs-idmapd
[root@fedora25 ~]# systemctl restart rpc-gssd
[root@fedora25 ~]# umount /var/lib/nfs/rpc_pipefs
I only see 1 case attached to the bug, and zero cases attached to the kbase article, so I guess we can move this off to 7.5. You're correct that the changes aren't upstream yet, but I think we're close.
Here are the upstream patches that are needed.
commit 3892174834ea1a4729348f0ecd3078cc1d5458e4
Author: Scott Mayhew <smayhew>
Date: Mon Apr 10 07:10:45 2017 -0400
systemd: add a generator for the rpc_pipefs mountpoint
commit da866d7f6a787045e2c9f4a700e23b58ec71400a
Author: Scott Mayhew <smayhew>
Date: Sun Apr 9 15:20:31 2017 -0400
blkmapd: allow the rpc_pipefs mountpoint to be overridden
commit 29c322e391ad377f3e3902df0997d402c55aa0ce
Author: Scott Mayhew <smayhew>
Date: Sun Apr 9 15:20:06 2017 -0400
gssd: add a deprecation warning for pipefs-directory in gssd section
commit abe0774b0f39bdb32790e6ed20627e6fc43682f3
Author: Scott Mayhew <smayhew>
Date: Sun Apr 9 15:19:02 2017 -0400
idmapd: move the pipefs-directory config option to nfs.conf
This were also needed
commit 2cc5d272402e72cb2e064de6350012de676b33fd
Author: Steve Dickson <steved>
Date: Wed Aug 24 14:56:07 2016 -0400
rpc-gssd: Make the path to the keytab configurable.
commit a9135cc015757bdd21679b4d5a1e2dcdf7ce27e9
Author: Mike Frysinger <vapier>
Date: Wed Apr 27 12:57:08 2016 -0400
fix building w/newer C libraries
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:0981