Bugzilla Bug 180428

Even if the kerberos use flag for nfs-utils (v4) is set to off, the nfs client
init scripts ignore the setting and try to load it

 * Starting gssd ...
/etc/init.d/rpc.gssd: line 20: /usr/sbin/rpc.gssd: No such file or direc  [ !!
]
 * Starting svcgssd ...
/etc/init.d/rpc.gssd: line 20: /usr/sbin/rpc.svcgssd: No such file or di  [ !!
]

Thus, it appears that the kerberos use flag must be on and everything else
needed to use kerberos for nfs be setup in order for the nfs client v4 to work
at all.

Well, I'm no expert on this, but to me it looks like the kerberos stuff is
required for the nfs4 protocol and optional for lower versions.

A new security flavor called RPCSEC_GSS, has been added, but it's optional, not
required. Kerberos is one way to implement it, but it's entirely separate from
the  default security flavor, which doesn't require RPCSEC_GSS.

nfs4 security features are not mandatory (krb5, spkmv3), as it can be seen on
ubuntu and debian, rpc.gssd should only be started if you have a mention of GSS
secured mounts in your fstab.

Created an attachment (id=127898) [details]
nfsmount.patch

this patch against nfsmount init script makes it start rpc.gssd only if there
is mention of a krb5 secured mount in fstab. It matches the current behavior of
debian's init script and should apply on nfs init script as well.

just read bug #186037, I'll need to update this patch to allow nfsv3+krb5 it
seems.

nfs-utils-1.0.12-r4 only forces kerb stuff when options contains 'sec=krb'

err, make that 1.1.0-r1