The nfs init script contains a check to determine if rpc.svcgssd is required. However, it determines this based on whether or not 'sec=' is contained in one of the options list. This is inappropriate because sec modes exist that do not require GSS, In my case I use sec=sys, which (falsely) triggers the rpc.svcgssd requirement. While an extra unnecessary service isn't a huge deal, the bigger problem is that it's possible for rpc.svcgssd to not be installed at all. The nfs-utils ebuild will only install rpc.svcgssd if the 'kerberos' USE flag is set (which is appropriate, since that's when it's required). As a result, the init script will require rpc.svcgssd, which doesn't exist, and the service to fail to start. Not cool. I discovered this bug after rebooting my NFS server and then trying to figure out why all the clients were hung... Changing the this line: if awk '!/^[[:space:]]*#/ && $2 ~ /sec=/ { found=1; nextfile } END { exit !found }' /etc/exports ; then to the following: if awk '!/^[[:space:]]*#/ && $2 ~ /sec=krb/ { found=1; nextfile } END { exit !found }' /etc/exports ; then fixes the problem. It'll only trigger the rpc.svcgssd requirement if one of the three kerberos modes are enabled. This also makes the init script functionality better match what's provided the ebuild. Reproducible: Always Steps to Reproduce: 1. install nfs-utils with USE='-kerberos -nonfsv4' 2. include an exports line like the following: /mount host(sec=sys,root_squash) 3. try to start nfs vi /etc/init.d/nfs Actual Results: nfs fails to start Expected Results: nfs should start
Heh, fix a bug, uncover a new one...
Fixed, albeit without revbump.
except your change is incorrect. if you're going to commit to other/common peoples packages, please include relevant cvs links. first, there's this: http://sources.gentoo.org/net-fs/nfs-utils/files/nfs.initd?r1=1.19&r2=1.20 no idea why you made that change when awk is only running on one file then there's the fix for this bug which is actually incorrect: http://sources.gentoo.org/net-fs/nfs-utils/files/nfs.initd?r1=1.20&r2=1.21 that is wrong because svcgssd is required for spkm based security too
I didn't see anything in the documentation about NFS require RPCGSS for anything other than krb5*. Still can't, actually, but I'm far from an expert on NFS so I'll take your word for it. In that case, how about this change: if awk '!/^[[:space:]]*#/ && ($2 ~ /sec=krb5/ || $2 ~ /sec=spkm/) { found=1; nextfile } END { exit !found }' /etc/exports ; then Did some quick tests on my conf file and it seems to do the trick. Thanks for looking into this.
Well, given that it was totally not working before, I did unbreak it with the first, if you check your original awk, it exited with status 1 even when sec=krb5 was listed in the file. As for the spkm, that might have been wrong, but given that _when I started it *never* required svcgssd_ it couldn't have made things wrong. And yes, I tested that one because I hit the bug on it on real system _and_ VM.
the docs are pretty clear: B/ svcgssd ; idmapd These supply services to nfsd and so should be started before rpc.nfsd. Where they come between mounting the nfsd filesystem and starting the nfsd server is not important. idmapd is only needed for NFSv4 support. svcgssd is only needed if exportfs NFS filesystem with crypto- security (Kerberos or SPKM3). Diego: then you should be reporting bugs instead of adding things that you arent familiar with. the correct logic is already in nfsmount and needs to be ported over.
Pot calling the kettle black, you there, uh. I actually got the bloody Kerberos server _and_ client working, so chill off, the net result (with today's commit) is _still_ one notch better than what was _before_ I touched it. Feel free to finish it by porting it over... even if that just means changing it from sec=krb5 to src=(krb5|spkm) as the rest of the logic in nfsmount is to parse fstab that is not needed here.
i dont know what you're talking about and/or what your problem is, but if you cant work here, then go help someone else and leave the nfs-utils bugs to bugzilla. probably fixed now in cvs http://sources.gentoo.org/net-fs/nfs-utils/files/nfs.initd?r1=1.21&r2=1.22
Thanks to both of you for the fix. I'm not really clear on how portage CVS works, though. Just because this is fixed CVS doesn't mean it'll automatically show up the next time I sync my portage tree, right? How/when does that happen? Don't mean to sound impatient here (I'm not), but I'm genuinely curious about how this part of the process works. If this is not an appropriate forum for this kind of question, can you direct me to someplace better? Thanks again.
cvs syncs to the public something like every 30 minutes, so by the time you read this message, it's already out there. `emerge --sync && emerge nfs-utils` and you should have the update. if it doesnt work, feel free to re-open, but please also attach your /etc/exports. there are user forums and user mailing lists where just about anything Gentoo related is fair game.
