Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3836 bytes --]

On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields" <bfields@fieldses.org>
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@redhat.com> 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.
> 
> (But doesn't gss-proxy have users other than nfsd?)

So presumably gss-proxy would come with its own unit file (looks ... oh yes,
it does. awesome), and we only want to start rpc.svcgssd if:
  - gss-proxy is not active
  - /etc/krpb5.keytab is present.

The second is easy to test in a unit file, an 'and' is generally trivial, but
testing if another unit is *not* present is not.
There is "Requisite" to test if it is, but you cannot do
    "Requisite=!gssproxy.service"
or
    "ConditionUnitStarted=!gssproxy.service"
or anything similar that I can find.

"Conflicts=gss-proxy.service" is closest, but that might cause
gss-proxy.service to stop.

Maybe we have to manage testing the .pid file thus:

   After=gssproxy.service
   ConditionPathExists=|!@localstatedir@/run/gssproxy.pid
   ConditionPathExists=|!/proc/net/rpc/use-gss-proxy
   ConditionPathExists=/etc/krb5.keytab

so we wait until the gssproxy.service has started if it will be starting at
all, then look for the pid file and if it is missing, or if use-gss-proxy is
missing, we run rpc.svcgssd, providing /etc/krb5.keytab is present.

> 
> > 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?

I was hoping you would tell me. :-)

It occurred to me as a good test when I tried running rpc.svcgssd in a fresh
VM and it wouldn't start.  I eventually found the error message complaining
that it couldn't find that file.

It isn't perfect as an empty /etc/krb5.keytab will still result in failure
and exit.  However if a sysadmin has created a keytab and is using NFS, it
seems reasonable to be ready to provide gss services.

rpc.gssd doesn't fail in the same way, but it does complain if the file
doesn't exist, so I suspect it is at least a good indicator.

The only thing that bothers me is that gssd is theoretically more general
than krb5.  However as the reality seems to be that it is exactly krb5, I
don't let that bother me too much.

> 
> Simplest might be to start unconditionally and just not care if it
> fails.  Or is there a problem cluttering up logs with unimportant
> failures?

More a problem with starting things that aren't necessary, and possibly
leaving them running.
Every process you start adds a little to the boot time.  We only get the best
experience if everyone contributes a little bit, no matter how little.
Also, every running process theoretically adds the to the attack service.
So some people will definitely not want these processes to be started.  If we
make it really easy for them, I think that is a good thing.
i.e. I agree with SteveD: 
> I think we want to stay away (and move away) from unconditionally
> starting anything... 

Thanks,
NeilBrown




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]