Summary: | net-fs/nfs-utils - /etc/init.d/nfs and /etc/init.d/nfsmount calculate their dependencies incorrectly with regards to rpc.idmapd rpc.gssd and rpc.svcgssd | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Justus Ranvier <gentoo> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dan, henson, maxime.deroucy, orzel |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/gentoo/gentoo/pull/35536 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 415625 |
Description
Justus Ranvier
2012-04-22 23:58:34 UTC
that is not what the nfs-utils README says. gssd is for client, and svcgssd is for the server. rpc.idmapd logic is correct if CONFIG_NFS_USE_NEW_IDMAPPER=n. we aren't going to change it to require a recent kernel with that set to y. if there is a way to detect that config at runtime, i can update the nfs.idmapd script to do so. otherwise, it's not changing. (In reply to comment #1) > that is not what the nfs-utils README says. gssd is for client, and svcgssd > is for the server. I spent all weekend trying to make kerberos authentication work with NFS and the only way I could get it to work is loading both processes on the client and on the server. For example, without rpc.svcgssd on the client I can mount shares and view their contents but any attempt to write fails even if I have the correct kerberos credentials to do so. Also attempting to mount with sec=krb5i or sec=krb5p fails. Loading rpc.svcgssd on the client fixes both of these problems. In addition from looking at my logs with both of them set to extra verbose mode (-vvv) I can see that both the client and the server are using both services (gssd and svcgssd). Perhaps the documentation is outdated? > rpc.idmapd logic is correct if CONFIG_NFS_USE_NEW_IDMAPPER=n. we aren't > going to change it to require a recent kernel with that set to y. if there > is a way to detect that config at runtime, i can update the nfs.idmapd > script to do so. otherwise, it's not changing. Starting with kernel 3.4 CONFIG_NFS_USE_NEW_IDMAPPER=y effectively becomes the default. The old method of using rpc.idmapd as a daemon still will work but it's a fallback instead of the default expected behavior. https://github.com/torvalds/linux/commit/e6499c6f4b5f56a16f8b8ef60529c1da28b13aea My suggestion is that USE="nfsidmap" should check for CONFIG_NFS_USE_NEW_IDMAPPER=y at build time and sys-apps/keyutils (which is pulled in as a dependency) should include the correct line in the default /etc/request-key.conf to make the new upcall routine work. Another option would be to make /etc/init.d/nfsmount use NFS_NEEDED_SERVICES in /etc/conf.d/nfs to pull in rpc.idmapd just like /etc/init.d/nfs does. That would allow people who do not need rpc.idmapd on the client to disable it without editing /etc/init.d/nfsmount. build time checks aren't going to cut it. i'm running 3.4-rc1, but i don't think the new idmap changes were merged for that, so i can't poke around /proc to see if there's anything useful in there. guess i'll wait until 3.4 final is released. as for gssd/etc..., feel free to inquire on the nfs lists. i don't have any need for encrypted nfs services, so i have kerberos disabled everywhere. (In reply to comment #4) > build time checks aren't going to cut it. i'm running 3.4-rc1, but i don't > think the new idmap changes were merged for that, so i can't poke around > /proc to see if there's anything useful in there. guess i'll wait until 3.4 > final is released. I don't know exactly when the change went it but I do know it's included in -rc4. i'm not really seeing any info in /proc to tell whether the system supports the new mapper. i'm not terribly keen on doing `uname` check at runtime, but we might not have a choice here. I guess, but i'm not sure, that I have the same problem. It happens only since yesterday (with update to net-fs/nfs-utils-1.3.2-r6). Now at boot i have a mail saying Service `nfsclient' needs non existent service `rpc.idmapd` (it's not "nfsmount' but I think this init file changed name recently). nfs-utils is installed with the following use flag (there's nfsidmap, but not nfsv4) : Installed versions: 1.3.2-r6^t(23:56:47 05/02/2015)(libmount nfsidmap tcpd uuid -caps -ipv6 -kerberos -nfsdcld -nfsv4 -nfsv41 -selinux) *** Bug 554196 has been marked as a duplicate of this bug. *** If a kernel is using the new nfsidmapper then the id_resolver keyring will show up in /proc/keys: # cat /proc/keys 016c5d86 I--Q--- 1 perm 1f3f0000 0 65534 keyring _uid_ses.0: 1 1558a32a I--Q--- 2 perm 1f3f0000 0 65534 keyring _uid.0: empty 1bbe499e I------ 1 perm 1f030000 0 0 keyring .id_resolver: empty 372baaaf I------ 1 perm 1f030000 0 0 keyring .dns_resolver: empty So iff /etc/request-key.d/id_resolver.conf exists and the keyring exists you shouldn't start rpc.idmapd? (In reply to Justus Ranvier from comment #2) > (In reply to comment #1) > > that is not what the nfs-utils README says. gssd is for client, and svcgssd > > is for the server. > > I spent all weekend trying to make kerberos authentication work with NFS and > the only way I could get it to work is loading both processes on the client > and on the server. I have a working NFSv4/Kerberos installation working and I only have rpc.svcgssd running on the server and rpc.gssd on the client. (I didn't try krb5i and krb5p). I described everything here : https://pelican.craoc.fr/nfsv4.html https://pelican.craoc.fr/kerberos.html (it's in french, sorry) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b088105deeb5406690698f092535767f71546570 commit b088105deeb5406690698f092535767f71546570 Author: David Seifert <soap@gentoo.org> AuthorDate: 2024-02-26 10:36:28 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2024-02-26 10:36:28 +0000 net-fs/nfs-utils: drop 2.6.3-r3, 2.6.4-r4 Closes: https://bugs.gentoo.org/413173 Closes: https://bugs.gentoo.org/694288 Closes: https://bugs.gentoo.org/798831 Closes: https://bugs.gentoo.org/914203 Signed-off-by: David Seifert <soap@gentoo.org> net-fs/nfs-utils/Manifest | 1 - net-fs/nfs-utils/files/nfs.confd | 38 ----- net-fs/nfs-utils/files/nfsclient.confd | 18 --- net-fs/nfs-utils/files/nfsmount.initd-1.3.1 | 26 ---- net-fs/nfs-utils/metadata.xml | 35 ++--- net-fs/nfs-utils/nfs-utils-2.6.3-r3.ebuild | 233 --------------------------- net-fs/nfs-utils/nfs-utils-2.6.4-r4.ebuild | 234 ---------------------------- 7 files changed, 16 insertions(+), 569 deletions(-) |