[PATCH 1/1] Move the wants only to the auth unit.

Post by Simo Sorce
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.
---
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.

Post by Simo Sorce
[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-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Simo Sorce

2014-09-30 15:21:39 UTC

On Tue, 30 Sep 2014 10:45:31 -0400

Post by Simo Sorce
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.
---
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 +++
# 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 +++
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.

Post by Steve Dickson
steved.

Post by Simo Sorce
[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 +++
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
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Steve Dickson

2014-09-30 15:05:14 UTC

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.

Post by Simo Sorce
+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-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Simo Sorce

2014-09-30 15:31:15 UTC

On Tue, 30 Sep 2014 11:05:14 -0400

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.

Post by Steve Dickson
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

Post by Steve Dickson
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.

Post by Steve Dickson
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.

Post by Steve Dickson
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.

Steve Dickson

2014-09-30 15:54:47 UTC

Post by Simo Sorce
On Tue, 30 Sep 2014 11:05:14 -0400

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...

Post by Steve Dickson
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.

Post by Steve Dickson
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.

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...

Post by Steve Dickson
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.

We can handle it in the next patch. Let's get the order right first.

Fine...

steved.

Post by Simo Sorce
Simo.

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Simo Sorce

2014-09-30 16:11:07 UTC

On Tue, 30 Sep 2014 11:54:47 -0400

Post by Simo Sorce
On Tue, 30 Sep 2014 11:05:14 -0400

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.

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.

Post by Steve Dickson
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.