Re: [PATCH 1/2] nfs-server: Replace rpc.svcgssd with gssproxy in systemd script

[NeilBrown <neilb@suse.de>]

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

On Fri, 19 Sep 2014 15:51:09 -0400 Steve Dickson <SteveD@redhat.com> wrote:

> Neil,
> 
> On 09/19/2014 01:10 PM, Steve Dickson wrote:
> > Have the nfs-server depend/start on the gssproxy daemon
> > instead of rpc.svcgssd to manage GSSAPI credentials
> > 
> > Signed-off-by: Steve Dickson <steved@redhat.com>
> > ---
> >  systemd/nfs-server.service | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> > index 2fa7387..3b04f84 100644
> > --- a/systemd/nfs-server.service
> > +++ b/systemd/nfs-server.service
> > @@ -2,12 +2,12 @@
> >  Description=NFS server and services
> >  Requires= network.target proc-fs-nfsd.mount rpcbind.target
> >  Requires= nfs-mountd.service
> > -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service rpc-svcgssd.service
> > +Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service gssproxy.service
> >  Wants=rpc-statd-notify.service
> >  
> >  After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service
> >  After= nfs-idmapd.service rpc-statd.service
> > -After= rpc-gssd.service rpc-svcgssd.service
> > +After= rpc-gssd.service gssproxy.service
> Is there a better way to do this, to be more backwards compatible? 
> 
> Maybe figure out that gssproxy is installed so would start that daemon
> if not fall back to rpc.svcgssd? 
> 
> Unfortunately systemd is still somewhat of a mystery to me.... :-( 
> 
> steved.
> >  Before= rpc-statd-notify.service
> >  
> >  Wants=nfs-config.service
> > 

Hi Steve,
 as gssproxy is part of a separate package, I don't think it is appropriate
 for and nfs-utils service file to 'want' it.  I don't know that there are
 any "rules" about this so I make it up as I go along, but that seems right
 to me.

 Instead, the .service file which the gssproxy package installs
 should/could/might declare

    WantedBy=nfs-server.service

 so if that is enabled, the linkage gets created.

 Either way, my idea is that starting nfs-server should try to start both
 svcgssd and gssproxy.
 rpc-svcgssd.service already declares itself as being *after* gssproxy so if
 both are available, gssproxy will be run first.
 If gssproxy starts and finds the kernel supports it, then it will be running
 when rpc-svcgssd.service starts up and the Conditions in there will cause it
 to not start the actual daemon.

 So the nfs-utils .service files should not need changing.  All that should
 be needed for gssproxy to be used is:
 - gssproxy needs to be installed (of course)
 - gssproxy.service needs to declare "WantedBy=nfs-server.service" in the
   [Install] section
 - 'systemctl enable gssproxy' needs to have been run somehow.  There are
   various ways to get this to happen at install time.


 However I haven't really tested this much.  I know I said I would do some
 testing of these unit files and I really do want to, but it just hasn't
 happened yet because ... you know, "life". 

 I had a look at the gssproxy.service file and it already has
 'WantedBy=multi-user.target' the same as nfs-server.service.
 So if they are both enabled, they should both be started at the same time,
 and if should all *just*work*.

 I assume it doesn't *just*work* at present.  What is actually happening?  Do
 you have gssproxy.service 'enabled'??

Thanks,
NeilBrown

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