On Fri, 19 Sep 2014 15:51:09 -0400 Steve Dickson <SteveD@xxxxxxxxxx> 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@xxxxxxxxxx>
> > ---
> > 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:
signature.asc
Description: PGP signature
