| Message ID | 1412014923-26587-2-git-send-email-simo@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@redhat.com> > --- > 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 > +Wants=gssproxy.service rpc-svcgssd.service rpc-gssd.service > ConditionPathExists=/etc/krb5.keytab > > [Service] > diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target > index 474f5e9ad74b70d265a7b2099556c2b9220bcdd0..f3d884a241543e41fdd91bcb0a055654b4b2c275 100644 > --- a/systemd/nfs-client.target > +++ b/systemd/nfs-client.target > @@ -5,9 +5,9 @@ Wants=remote-fs-pre.target > > # Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to > # start that on demand if needed. > -Wants=rpc-gssd.service rpc-svcgssd.service auth-rpcgss-module.service > +Wants=auth-rpcgss-module.service > Wants=nfs-blkmap.service rpc-statd-notify.service > -Before=rpc-gssd.service rpc-svcgssd.service nfs-blkmap.service > +Before=nfs-blkmap.service In the upstream version (commit 12a95edae) this is actually After=rpc-gssd.service rpc-svcgssd.service nfs-blkmap.service and I think we should leave it because sync things up nicely when both the server and client plus this patch is only about moving Wants around... not Afters... steved. > > [Install] > WantedBy=multi-user.target > diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service > index 1048c5cbbf68328a8ac8c88b67e477061cf487c7..a5039062ad95ca0c73c8a6c33d053a845d596185 100644 > --- a/systemd/nfs-server.service > +++ b/systemd/nfs-server.service > @@ -3,7 +3,6 @@ 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 auth-rpcgss-module.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 > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@redhat.com> > --- > 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... Maybe we could put an After=nfs-server.service in nfs-client.target 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. Also, this will cause gssproxy to be started on every boot regardless whether Kerberos is installed and configured (which not the case with rpc.svcgssd)... I can hear the complaints already... Why is NFS starting up this daemon that will never have anything to do, in the case when Kerberos is not installed/configure which could be the majority of the cases... I would really really, really like to avoid this. steved. > +Wants=gssproxy.service rpc-svcgssd.service rpc-gssd.service > ConditionPathExists=/etc/krb5.keytab > > [Service] > diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target > index 474f5e9ad74b70d265a7b2099556c2b9220bcdd0..f3d884a241543e41fdd91bcb0a055654b4b2c275 100644 > --- a/systemd/nfs-client.target > +++ b/systemd/nfs-client.target > @@ -5,9 +5,9 @@ Wants=remote-fs-pre.target > > # Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to > # start that on demand if needed. > -Wants=rpc-gssd.service rpc-svcgssd.service auth-rpcgss-module.service > +Wants=auth-rpcgss-module.service > Wants=nfs-blkmap.service rpc-statd-notify.service > -Before=rpc-gssd.service rpc-svcgssd.service nfs-blkmap.service > +Before=nfs-blkmap.service > > [Install] > WantedBy=multi-user.target > diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service > index 1048c5cbbf68328a8ac8c88b67e477061cf487c7..a5039062ad95ca0c73c8a6c33d053a845d596185 100644 > --- a/systemd/nfs-server.service > +++ b/systemd/nfs-server.service > @@ -3,7 +3,6 @@ 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 auth-rpcgss-module.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 > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 30 Sep 2014 10:45:31 -0400 Steve Dickson <SteveD@redhat.com> 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@redhat.com> > > --- > > 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 > > +Wants=gssproxy.service rpc-svcgssd.service rpc-gssd.service > > ConditionPathExists=/etc/krb5.keytab > > > > [Service] > > diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target > > index > > 474f5e9ad74b70d265a7b2099556c2b9220bcdd0..f3d884a241543e41fdd91bcb0a055654b4b2c275 > > 100644 --- a/systemd/nfs-client.target +++ > > b/systemd/nfs-client.target @@ -5,9 +5,9 @@ > > Wants=remote-fs-pre.target > > # Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will > > arrange to # start that on demand if needed. > > -Wants=rpc-gssd.service rpc-svcgssd.service > > auth-rpcgss-module.service +Wants= > > Wants=nfs-blkmap.service rpc-statd-notify.service > > -Before=rpc-gssd.service rpc-svcgssd.service nfs-blkmap.service > > +Before=nfs-blkmap.service > In the upstream version (commit 12a95edae) this is actually > After=rpc-gssd.service rpc-svcgssd.service nfs-blkmap.service > > and I think we should leave it because sync things up nicely > when both the server and client plus this patch is only > about moving Wants around... not Afters... I will send new patch with corrected After. Simo. > steved. > > > > > [Install] > > WantedBy=multi-user.target > > diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service > > index > > 1048c5cbbf68328a8ac8c88b67e477061cf487c7..a5039062ad95ca0c73c8a6c33d053a845d596185 > > 100644 --- a/systemd/nfs-server.service +++ > > b/systemd/nfs-server.service @@ -3,7 +3,6 @@ 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 > > auth-rpcgss-module.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 > >
On Tue, 30 Sep 2014 11:05:14 -0400 Steve Dickson <SteveD@redhat.com> 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@redhat.com> > > --- > > 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. > 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 > 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. > Also, this will cause gssproxy to be started on every boot > regardless whether Kerberos is installed and configured > (which not the case with rpc.svcgssd)... This is a separate issue, I am trying to get the ordering right here, then we can debug why gssproxy is started, I suspect Wants always kicks in regrardless of ConditionPathExists. > I can hear the complaints already... Why is NFS starting > up this daemon that will never have anything to do, in > the case when Kerberos is not installed/configure > which could be the majority of the cases... > > I would really really, really like to avoid this. We can handle it in the next patch. Let's get the order right first. Simo.
On 09/30/2014 11:31 AM, Simo Sorce wrote: > On Tue, 30 Sep 2014 11:05:14 -0400 > Steve Dickson <SteveD@redhat.com> 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@redhat.com> >>> --- >>> 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... > >> 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. > >> 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... > >> Also, this will cause gssproxy to be started on every boot >> regardless whether Kerberos is installed and configured >> (which not the case with rpc.svcgssd)... > > This is a separate issue, I am trying to get the ordering right here, > then we can debug why gssproxy is started, I suspect Wants always kicks > in regrardless of ConditionPathExists. > >> I can hear the complaints already... Why is NFS starting >> up this daemon that will never have anything to do, in >> the case when Kerberos is not installed/configure >> which could be the majority of the cases... >> >> I would really really, really like to avoid this. > > We can handle it in the next patch. Let's get the order right first. Fine... steved. > > Simo. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 30 Sep 2014 11:54:47 -0400 Steve Dickson <SteveD@redhat.com> wrote: > > > On 09/30/2014 11:31 AM, Simo Sorce wrote: > > On Tue, 30 Sep 2014 11:05:14 -0400 > > Steve Dickson <SteveD@redhat.com> 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@redhat.com> > >>> --- > >>> 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.
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 +Wants=gssproxy.service rpc-svcgssd.service rpc-gssd.service ConditionPathExists=/etc/krb5.keytab [Service] diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target index 474f5e9ad74b70d265a7b2099556c2b9220bcdd0..f3d884a241543e41fdd91bcb0a055654b4b2c275 100644 --- a/systemd/nfs-client.target +++ b/systemd/nfs-client.target @@ -5,9 +5,9 @@ Wants=remote-fs-pre.target # Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to # start that on demand if needed. -Wants=rpc-gssd.service rpc-svcgssd.service auth-rpcgss-module.service +Wants=auth-rpcgss-module.service Wants=nfs-blkmap.service rpc-statd-notify.service -Before=rpc-gssd.service rpc-svcgssd.service nfs-blkmap.service +Before=nfs-blkmap.service [Install] WantedBy=multi-user.target diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service index 1048c5cbbf68328a8ac8c88b67e477061cf487c7..a5039062ad95ca0c73c8a6c33d053a845d596185 100644 --- a/systemd/nfs-server.service +++ b/systemd/nfs-server.service @@ -3,7 +3,6 @@ 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 auth-rpcgss-module.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
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@redhat.com> --- systemd/auth-rpcgss-module.service | 3 ++- systemd/nfs-client.target | 4 ++-- systemd/nfs-server.service | 1 - 3 files changed, 4 insertions(+), 4 deletions(-)