On Tue, 30 Sep 2014 11:54:47 -0400 Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > On 09/30/2014 11:31 AM, Simo Sorce wrote: > > On Tue, 30 Sep 2014 11:05:14 -0400 > > Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > >> On 09/29/2014 02:22 PM, Simo Sorce wrote: > >>> This way either gssproxy or rpc.svcgssd are started only if the > >>> auth module is requested, and it finds a keytab. > >>> If the wants are in the main nfs-client or nfs-server unit files > >>> then the two deamons are started unconditionally and would require > >>> conditions which we can test once and for all in a single unit > >>> file instead. > >>> > >>> Signed-off-by: Simo Sorce <simo@xxxxxxxxxx> > >>> --- > >>> systemd/auth-rpcgss-module.service | 3 ++- > >>> systemd/nfs-client.target | 4 ++-- > >>> systemd/nfs-server.service | 1 - > >>> 3 files changed, 4 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/systemd/auth-rpcgss-module.service > >>> b/systemd/auth-rpcgss-module.service index > >>> 3fc2f4ac924f7e9d6e24969bb9a21d88a5c144fc..0355e13e009528632e97373332db9fa3acdfd1a9 > >>> 100644 --- a/systemd/auth-rpcgss-module.service +++ > >>> b/systemd/auth-rpcgss-module.service @@ -6,7 +6,8 @@ > >>> # unit will fail. But that's OK.) > >>> [Unit] > >>> Description=Kernel Module supporting RPCSEC_GSS > >>> -Before=gssproxy.service rpc-svcgssd.service > >>> +Before=gssproxy.service rpc-svcgssd.service rpc-gssd.service > >> By moving these into this unit,it destroys client/server > >> sync starts commit 12a95eda talks about... > > > > No it does not, this before is critical, the kernel module must be > > loaded before the gss daemons are started. > Understood.... but both the nfs-server.service and nfs-client.target > units have a Wants=auth-rpcgss-module.service, is not clear unit > will get started first... On one of my very fast booting machines > this race caused ordering cycles in systemd... I think... at least > when I ordered the server to start then the client the cycles > went a way... but who knows... Both nfs-server and nfs-client unit files have After: <gss unit files> so they are always after them (I fixed a missing gssproxy.service one in the last patch) And auth-rpcgss-module.service has Before: <gss unit files> So the ordering is fixed as per my last patch commit message. > > > >> Maybe we could put an After=nfs-server.service in nfs-client.target > > > > Why would you load the auth modules *after* nfs client and servers > > are started ? > > I think this could cause race conditions at mount on boot if someone > > wants to mount a filesystem with sec=krb5 > Again it has nothing to do the loading of the module... You are > correct the they have to be loaded before the gss daemons are started. > Its all about the ordering of the server and client units. So what is the ordering you are concerned about ? The way I understand it is 1. load module ---- 2. start rpc.gssd AND (rpc-svcgssd.service OR gssproxy.service) order between these seem not important so they can start in parallel ---- 3. nfs client AND/OR nfs server I do not know if there needs to be any ordering between the 2 above, I operated on the assumption they can start in parallel I left any ancillary daemon (statd/imapd/etc...) as it were, but if you can add the ordering here I can double check those are starting in the right order too. > > > >> to bring back that synchronization... because in the end > >> we really really want the server to start first especially > >> when gssproxy is involved and both units are enabled. > > > > uh ? > > no you really want to start the auth damoens first, if the server > > starts first then a mount request from a client could race with > > gssproxy starting up and poking the proc file to enable use of > > gssproxy resulting in the auth module to permanently initialize to > > use the old interface. > My bad on this one... I was thinking about when the nfs-client.target > was not starting gssproxy... there was race with the server which > caused both gssproxy and rpc.svcgssd to be started. Now that the > client is starting gssproxy, that race no longer exists... ok. please let me know if I wrongly understood the ordering requirements we have. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
