*** BLURB HERE ***
Concentrate dependencies for rpcsec GSS stuff in one place.
Simo Sorce (1):
Move the wants only to the auth unit.
systemd/auth-rpcgss-module.service | 3 ++-
systemd/nfs-client.target | 4 ++--
systemd/nfs-server.service | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
--
2.1.0
On Tue, 30 Sep 2014 10:45:31 -0400
Steve Dickson <[email protected]> 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 <[email protected]>
> > ---
> > 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
> >
--
Simo Sorce * Red Hat, Inc * New York
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 <[email protected]>
> ---
> 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
>
On Tue, 30 Sep 2014 11:05:14 -0400
Steve Dickson <[email protected]> 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 <[email protected]>
> > ---
> > 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.
--
Simo Sorce * Red Hat, Inc * New York
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 <[email protected]>
> ---
> 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
>
On Tue, 30 Sep 2014 11:54:47 -0400
Steve Dickson <[email protected]> wrote:
>
>
> On 09/30/2014 11:31 AM, Simo Sorce wrote:
> > On Tue, 30 Sep 2014 11:05:14 -0400
> > Steve Dickson <[email protected]> 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 <[email protected]>
> >>> ---
> >>> 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
On 09/30/2014 11:31 AM, Simo Sorce wrote:
> On Tue, 30 Sep 2014 11:05:14 -0400
> Steve Dickson <[email protected]> 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 <[email protected]>
>>> ---
>>> 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.
>
>
>
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 <[email protected]>
---
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
[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
--
2.1.0