With Systemd and new nfs-utils I get this Error's in Syslog. Cannot add dependency job for unit gssproxy.service, ignoring: Unit gssproxy.service failed to load: No such file or directory. Cannot add dependency job for unit rpc-gssd.service, ignoring: Unit rpc-gssd.service failed to load: No such file or directory. Cannot add dependency job for unit rpc-svcgssd.service, ignoring: Unit rpc-svcgssd.service failed to load: No such file or directory. See also here: https://bugs.archlinux.org/task/42635
Created attachment 432462 [details, diff] Patch against nfs-utils-1.3.3 to add svcgssd back
Created attachment 432464 [details] Patched nfs-utils-1.3.3-r1 ebuild
*** Bug 559586 has been marked as a duplicate of this bug. ***
upstream is moving away/killing svcgssd in favor of gss-proxy, so we should do the same https://fedorahosted.org/gss-proxy/
i've added net-nds/gssproxy to the tree now. can you guys give it a try and see how it goes ? i don't use nfsv4 or kerberos, so it's hard to verify.
This looks promising - the build went smoothly and the systemd plumbing is configured such that if you have gssproxy installed it'll automatically come up and rpc-svcgssd will not. Results not so good in practice though. 1. After install it refused to start citing this error: gssproxy[3255]: Failed to create Unix Socket! (2:No such file or directory) the fix for this rather misleading error turned out to be: mkdir -p /var/lib/gssproxy/clients/ (I suspect it wants a path to write its socket file /var/lib/gssproxy/default.sock, which annoyingly is not mentioned anywhere in the default config). After getting the daemon started though (with a server reboot per the instructions), no joy in mounting from clients, all of them showing access denied while mounting. These clients work perfectly with rpc-svcgssd on the server side. I suspect the following bug report is timely: https://bbs.archlinux.org/viewtopic.php?id=213272 Per that report, any chance of getting the trivial patch here: https://git.fedorahosted.org/cgit/gss-proxy.git/commit/?id=b5d1a189da2037d87283eac8998af4bfb1aefa79 applied to the gentoo ebuild? An alternative would be to do an ebuild for 0.4.1, but that seems like a backwards step.
(In reply to Paul Sobey from comment #6) seems weird upstream hasn't provided a tmpfiles.d entry. i'm guessing you want something like: $ cat /etc/tmpfiles.d/gssproxy.conf d /var/lib/gssproxy/clients 0755 root root that should take care of the startup path errors. have you checked that that patch fixes the permission problems you've seen ?
Agreed re the tmpfiles.d entry. I haven't confirmed that the patch works, merely that the arch bug report matches the symptoms I see. My ebuild-fu is a little rusty and I have little free time at the moment. If it's easy to patch I'll gladly test an updated ebuild, if you'd like me to do one of my own to confirm that might take a little longer for when I have some free time on a weekend. Thanks for your speedy responses so far!
(In reply to Paul Sobey from comment #8) add to the ebuild: inherit eutils src_prepare() { epatch_user; } then stick that patch in /etc/portage/patches/net-nds/gss-proxy/. then when you emerge the ebuild, it should say it's applying that patch.
(In reply to optiz0r from comment #2) > Created attachment 432464 [details] > Patched nfs-utils-1.3.3-r1 ebuild Yes please! I am also having problems with gss-proxy and on top of that OpenRC does not know what what to do: /etc/init.d/nfs start * Caching service dependencies ... [ ok ] * Starting svcgssd ... * start-stop-daemon: /usr/sbin/rpc.svcgssd does not exist [ !! ] * ERROR: rpc.svcgssd failed to start * ERROR: cannot start nfs as rpc.svcgssd would not start
Not having svcgssd built breaks existing installs, please add it back(or at least mask the broken versions). Installing svcgssd does not hinder gss-proxy, they can be installed at the same time.
Guys, OpenRC is still broken w.r.t gssproxy
Just to come back to this thread a little later, gssproxy 0.5.1 (now in tree), works perfectly on my system as a replacement for rpc.svcgssd. The one caveat is that the systemd unit contains: Environment=KRB5RCACHEDIR=/var/lib/gssproxy/rcache Similar to one of my comments above, that directory has to exist, or mount requests will silently fail. I'd suggest gentoo install tmpfiles.d entries for these two paths, or create them with the ebuild in some other way.
nfs-utils-1.3.4 is about to go stable, see bug: https://bugs.gentoo.org/show_bug.cgi?id=608152 Has this problem been fixed? I cannot see that it has but didn't dig too deep. If not fixed, nfs-utils-1.3.4 will break all openrc nfs users
This bug is getting a real annoyance. Just add in: $(use_enable kerberos svcgss) and you are done, pretty please?
Hi, today I ran into this block on libevent. The current stable version of nfs-utils blocks the new version of libevent. All later versions of nfs-utils are not marked stable yet because they wait for this gssproxy-bug to be fixed. Please hurry?
Sorry, forgot to include the blocking message. Here it is: dev-libs/libevent:0 (dev-libs/libevent-2.1.8:0/2.1-6::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (dev-libs/libevent-2.0.22:0/0::gentoo, installed) pulled in by <=dev-libs/libevent-2.1 required by (net-fs/nfs-utils-1.3.1-r5:0/0::gentoo, installed) ^^ ^^^
Oops, this was the wrong bug, sjould have benn: https://bugs.gentoo.org/show_bug.cgi?id=603472 although I this it is related.
(In reply to Joakim Tjernlund from comment #18) > Oops, this was the wrong bug, sjould have benn: > https://bugs.gentoo.org/show_bug.cgi?id=603472 > although I this it is related. Wrong bug again :( sorry
I was able to get my kerberized NFS mounts working again after installing gssproxy. The changes to /etc/init.d/nfs: # diff /etc/init.d/nfs /root/nfs.new 26d25 < print "rpc.svcgssd" 33c32 < use ypbind net dns rpc.rquotad rpc.idmapd rpc.svcgssd --- > use ypbind net dns rpc.rquotad rpc.idmapd Then in /etc/conf.d/nfs: # diff /etc/conf.d/nfs /root/nfs.new.confd 8c8 < NFS_NEEDED_SERVICES="rpc.idmapd rpc.gssd" --- > NFS_NEEDED_SERVICES="rpc.idmapd rpc.gssd gssproxy" Package versions on server: # eix -cI nfs-utils [I] net-fs/nfs-utils (1.3.4@03/09/2017): NFS client and server daemons # eix -cI gss-proxy [I] net-nds/gss-proxy (0.6.2@03/09/2017): daemon to proxy GSSAPI context establishment and channel handling I was able to read (immediately after mounting) and write (albeit with a long delay, around 1 minute). This delay might be something related to gss-proxy, or maybe an nfs-utils version mismatch?
Sorry for the double post. There's another issue with the provided /etc/gssproxy/80-httpd.conf file: Mar 9 15:17:41 antioch gssproxy[4816]: Option 'euid' is missing from [service/HTTP]. Mar 9 15:17:41 antioch gssproxy[4816]: Error reading configuration 22: Invalid argument I just commented everything in that file since I'm not using httpd + kerberos. gssproxy starts up properly afterwards.
(In reply to godlike64 from comment #20) > I was able to get my kerberized NFS mounts working again after installing > gssproxy. The changes to /etc/init.d/nfs: > > # diff /etc/init.d/nfs /root/nfs.new > 26d25 > < print "rpc.svcgssd" > 33c32 > < use ypbind net dns rpc.rquotad rpc.idmapd rpc.svcgssd > --- > > use ypbind net dns rpc.rquotad rpc.idmapd I thought gssproxy was a replacement for rpc.svcgssd so I would have tried: use ypbind net dns rpc.rquotad rpc.idmapd gssproxy is this assumption wrong? > > Then in /etc/conf.d/nfs: > > # diff /etc/conf.d/nfs /root/nfs.new.confd > 8c8 > < NFS_NEEDED_SERVICES="rpc.idmapd rpc.gssd" > --- > > NFS_NEEDED_SERVICES="rpc.idmapd rpc.gssd gssproxy" > > Package versions on server: > > # eix -cI nfs-utils > [I] net-fs/nfs-utils (1.3.4@03/09/2017): NFS client and server daemons > # eix -cI gss-proxy > [I] net-nds/gss-proxy (0.6.2@03/09/2017): daemon to proxy GSSAPI context > establishment and channel handling > > > I was able to read (immediately after mounting) and write (albeit with a > long delay, around 1 minute). This delay might be something related to > gss-proxy, or maybe an nfs-utils version mismatch? We tried gssproxy briefly but NFS just hanged so we stopped. If you figure out what is different, please report.
Added to /etc/portage/package.keywords: # required by net-nds/gss-proxy-0.6.2::gentoo # required by gss-proxy (argument) =dev-libs/ding-libs-0.6.0 ~amd64 # required by gss-proxy (argument) =net-nds/gss-proxy-0.6.2 ~amd64 emerge gss-proxy Manually nstalled The patches in comment #20 Rebooted linux version 4.9.16-gentoo (gcc version 4.9.4 (Gentoo 4.9.4 p1.0, pie-0.6.4) ) and everything works properly.
Can someone summarize what adding support for gssproxy to nfs-utils would entail?
gssproxy works for me (pretty awful to configure though). There doesn't seem to be anything we should do to the nfs-utils ebuilds.
