On 02/04/2014 11:20 AM, J. Bruce Fields wrote: > On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote: >> On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <SteveD@xxxxxxxxxx> wrote: >>> Also how does gss-proxy come to play in all this? Maybe we >>> just use gss-proxy by default and retire rpc.svcgssd. >> >> I haven't really be following and so am only dimly aware of gss-proxy. >> It's a replacement for rpc.svcgssd - right? >> So we should get it to start in the same circumstances as rpc.svcgssd? >> >> Is there some easy test - eg something existing in the filesystem - that we >> could use to see if the kernel supports gss-proxy ? > > There's a /proc/net/rpc/use-gss-proxy file. hmm... I forget... who set this... gssproxy daemon? > > (But doesn't gss-proxy have users other than nfsd?) > >> Also, I've been wondering if we could avoid the need to explicitly enable >> the gss stuff by gating it on the existence of /etc/krb5.keytab. >> Do you think that would be reasonable? > > That would be great. I hate that people have to care about these > support daemons, they should just be started automatically when they're > needed. > > Is /etc/krb5.keytab the best indicator? > > Simplest might be to start unconditionally and just not care if it > fails. Or is there a problem cluttering up logs with unimportant > failures? I think we want to stay away (and move away) from unconditionally starting anything... Having "triggers" of when services should or should not be started is a better direction... Like what Neil is doing with rpc.statd. steved. > > --b. > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
