Hello,
On 09/22/2014 09:23 PM, NeilBrown wrote:
>
> 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.
I was wondering about this... From a distro its easy... Just add a
requirement in the spec file and you'll know the package will exist...
But upstream it may not so straightforward...
>
> 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.
Right... this is the general consensuses...
> rpc-svcgssd.service already declares itself as being *after* gssproxy so if
> both are available, gssproxy will be run first.
Ah.. I did miss this fact... That is very important!
> 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.
Those ConditionPathExists do indeed work... I think both of them need to stay...
>
> 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
Right now gssproxy.service has:
[Unit]
Before=nfs-secure.service nfs-secure-server.service
Requires=proc-fs-nfsd.mount
^^^^ this Requires actually loads sunrpc, nfsd, auth_rpcgss
another important fact!
[Install]
WantedBy=multi-user.target
So I went ahead and added "WantedBy=nfs-server.service" to the
gssproxy.service file and re-installed the package... I didn't
see it make much difference.... both packages have to be enabled
for them to be started.
> - 'systemctl enable gssproxy' needs to have been run somehow. There are
> various ways to get this to happen at install time.
When gssproxy is enabled, it will be *always* started, whether the server
is running or not... I was working toward only starting gssproxy when its
needed, like rpc.svcgssd is today.
>
>
> 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".
No problem... ;-) thanks for the help!
>
> 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*.
They do... I enable them both... everything comes up just fine...
>
> I assume it doesn't *just*work* at present. What is actually happening? Do
> you have gssproxy.service 'enabled'??
This is the problem... gssproxy has to be enabled... I don't think that's is
good... and not necessary... What (I think) is necessary is we create a
dependency on gssproxy (like we do for rpcbind, keyutils, libevent, etc) and
have the server bring up gssproxy when it comes up. That is achieved by
simply adding gssproxy.service to the nfs-server.service files:
diff -up f21/systemd/nfs-server.service.orig f21/systemd/nfs-server.service
--- f21/systemd/nfs-server.service.orig 2014-09-23 10:38:39.572726403 -0400
+++ f21/systemd/nfs-server.service 2014-09-23 10:39:17.604412641 -0400
@@ -2,12 +2,13 @@
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
+Wants=rpc-gssd.service gssproxy.service rpc-svcgssd.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 rpc-svcgssd.service
Before= rpc-statd-notify.service
Wants=nfs-config.service
The patch does not require gssproxy to be enabled so gssproxy will be started
only when the server is started. Now if an admin what to enable gssproxy for
some other reason so be it... Things will still work.
Through this discussion both of my concerns about this patch have been address:
1) Having both gssproxy and rpc.gssd started/running at the same time because
systemd starts everything at once... but that can't happen because of
the 'After=gssproxy.service' in rpc-svcgssd.service. That's something I
missed... thank you for pointing that out! That is very good foresight
on your part! IMHO...
2) This whole business about how auth_rpcgss gets loaded... It is crystal
to me that the "Requires=proc-fs-nfsd.mount" in gssproxy.service is
loading the modules. You disable the server, disable the client and
enable gssproxy then reboot... lsmod | grep rpc show sunrpc, nfsd, and
auth_rpcgss are loaded. So nothing has to change in gssproxy.service and
another unit file to load the modules is not needed.
So I guess at the end of the day... I want to break the 'Unknown' Wants rule... ;-)
By adding a dependency to gssproxy and by having nfs-server 'want' the gssproxy
service... Its the cleanest way... IMHO...
steved.
--
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
