The gssproxy(8) daemon will now be used to manage the GSSAPI
credentials on the server.
The nfs-server systemd script will now start gssproxy and
the building/installing of rpc.svcgssd is now off by
default.
Steve Dickson (2):
nfs-server: Replace rpc.svcgssd with gssproxy in systemd script
rpc.svcgssd: the build of rpc.svcgssd is off by default
configure.ac | 23 +++++++++++++++++++----
systemd/nfs-server.service | 4 ++--
utils/gssd/Makefile.am | 11 +++++++++--
3 files changed, 30 insertions(+), 8 deletions(-)
--
1.9.3
On Fri, 19 Sep 2014 15:51:09 -0400 Steve Dickson <[email protected]> wrote:
> Neil,
>
> On 09/19/2014 01:10 PM, Steve Dickson wrote:
> > Have the nfs-server depend/start on the gssproxy daemon
> > instead of rpc.svcgssd to manage GSSAPI credentials
> >
> > Signed-off-by: Steve Dickson <[email protected]>
> > ---
> > systemd/nfs-server.service | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> > index 2fa7387..3b04f84 100644
> > --- a/systemd/nfs-server.service
> > +++ b/systemd/nfs-server.service
> > @@ -2,12 +2,12 @@
> > 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 rpc-gssd.service gssproxy.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
> Is there a better way to do this, to be more backwards compatible?
>
> Maybe figure out that gssproxy is installed so would start that daemon
> if not fall back to rpc.svcgssd?
>
> Unfortunately systemd is still somewhat of a mystery to me.... :-(
>
> steved.
> > Before= rpc-statd-notify.service
> >
> > Wants=nfs-config.service
> >
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.
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.
rpc-svcgssd.service already declares itself as being *after* gssproxy so if
both are available, gssproxy will be run first.
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.
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
- 'systemctl enable gssproxy' needs to have been run somehow. There are
various ways to get this to happen at install time.
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".
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*.
I assume it doesn't *just*work* at present. What is actually happening? Do
you have gssproxy.service 'enabled'??
Thanks,
NeilBrown
Neil,
On 09/19/2014 01:10 PM, Steve Dickson wrote:
> Have the nfs-server depend/start on the gssproxy daemon
> instead of rpc.svcgssd to manage GSSAPI credentials
>
> Signed-off-by: Steve Dickson <[email protected]>
> ---
> systemd/nfs-server.service | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> index 2fa7387..3b04f84 100644
> --- a/systemd/nfs-server.service
> +++ b/systemd/nfs-server.service
> @@ -2,12 +2,12 @@
> 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 rpc-gssd.service gssproxy.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
Is there a better way to do this, to be more backwards compatible?
Maybe figure out that gssproxy is installed so would start that daemon
if not fall back to rpc.svcgssd?
Unfortunately systemd is still somewhat of a mystery to me.... :-(
steved.
> Before= rpc-statd-notify.service
>
> Wants=nfs-config.service
>
Due to the fact the gssproxy is not managing the
GASSAPI credentials, on the server, there is
no need to build/install rpc.svcgssd.
To re-enable the build use the --enable-svcgss
configure flag
Signed-off-by: Steve Dickson <[email protected]>
---
configure.ac | 23 +++++++++++++++++++----
utils/gssd/Makefile.am | 11 +++++++++--
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index bc48373..6767190 100644
--- a/configure.ac
+++ b/configure.ac
@@ -90,21 +90,36 @@ AC_ARG_ENABLE(nfsv41,
AC_ARG_ENABLE(gss,
[AC_HELP_STRING([--enable-gss],
- [enable support for rpcsec_gss @<:@default=yes@:>@])],
+ [enable client support for rpcsec_gss @<:@default=yes@:>@])],
enable_gss=$enableval,
enable_gss=yes)
if test "$enable_gss" = yes; then
GSSD=gssd
- SVCGSSD=svcgssd
else
enable_gss=
GSSD=
- SVCGSSD=
fi
AC_SUBST(GSSD)
- AC_SUBST(SVCGSSD)
AC_SUBST(enable_gss)
AM_CONDITIONAL(CONFIG_GSS, [test "$enable_gss" = "yes"])
+
+AC_ARG_ENABLE(svcgss,
+ [AC_HELP_STRING([--enable-svcgss],
+ [enable server support for rpcsec_gss @<:@default=no@:>@])],
+ enable_svcgss=$enableval,
+ enable_svcgss=no)
+ if test "$enable_gss" = yes; then
+ if "enable_svcgss" = yes; then
+ SVCGSSD=svcgssd
+ fi
+ else
+ enable_svcgss=
+ SVCGSSD=
+ fi
+ AC_SUBST(SVCGSSD)
+ AC_SUBST(enable_svcgss)
+ AM_CONDITIONAL(CONFIG_SVCGSS, [test "$enable_svcgss" = "yes"])
+
AC_ARG_ENABLE(kprefix,
[AC_HELP_STRING([--enable-kprefix], [install progs as rpc.knfsd etc])],
test "$enableval" = "yes" && kprefix=k,
diff --git a/utils/gssd/Makefile.am b/utils/gssd/Makefile.am
index af59791..9835117 100644
--- a/utils/gssd/Makefile.am
+++ b/utils/gssd/Makefile.am
@@ -1,10 +1,17 @@
## Process this file with automake to produce Makefile.in
-man8_MANS = gssd.man svcgssd.man
+man8_MANS = gssd.man
+if CONFIG_SVCGSS
+man8_MANS += svcgssd.man
+endif
RPCPREFIX = rpc.
KPREFIX = @kprefix@
-sbin_PREFIXED = gssd svcgssd
+sbin_PREFIXED = gssd
+if CONFIG_SVCGSS
+sbin_PREFIXED += svcgssd
+endif
+
sbin_PROGRAMS = $(sbin_PREFIXED)
EXTRA_DIST = \
--
1.9.3
On Mon, Sep 22, 2014 at 03:20:08PM -0400, Steve Dickson wrote:
> Due to the fact the gssproxy is not managing the
> GASSAPI credentials, on the server, there is
> no need to build/install rpc.svcgssd.
>
> To re-enable the build use the --enable-svcgss
> configure flag
Since we're not running rpc.svcgssd in those cases where it's not
needed, we should keep --enable-svcgss as the default for now. It's an
easy way to keep old kernels working.
--b.
>
> Signed-off-by: Steve Dickson <[email protected]>
> ---
> configure.ac | 23 +++++++++++++++++++----
> utils/gssd/Makefile.am | 11 +++++++++--
> 2 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index bc48373..6767190 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -90,21 +90,36 @@ AC_ARG_ENABLE(nfsv41,
>
> AC_ARG_ENABLE(gss,
> [AC_HELP_STRING([--enable-gss],
> - [enable support for rpcsec_gss @<:@default=yes@:>@])],
> + [enable client support for rpcsec_gss @<:@default=yes@:>@])],
> enable_gss=$enableval,
> enable_gss=yes)
> if test "$enable_gss" = yes; then
> GSSD=gssd
> - SVCGSSD=svcgssd
> else
> enable_gss=
> GSSD=
> - SVCGSSD=
> fi
> AC_SUBST(GSSD)
> - AC_SUBST(SVCGSSD)
> AC_SUBST(enable_gss)
> AM_CONDITIONAL(CONFIG_GSS, [test "$enable_gss" = "yes"])
> +
> +AC_ARG_ENABLE(svcgss,
> + [AC_HELP_STRING([--enable-svcgss],
> + [enable server support for rpcsec_gss @<:@default=no@:>@])],
> + enable_svcgss=$enableval,
> + enable_svcgss=no)
> + if test "$enable_gss" = yes; then
> + if "enable_svcgss" = yes; then
> + SVCGSSD=svcgssd
> + fi
> + else
> + enable_svcgss=
> + SVCGSSD=
> + fi
> + AC_SUBST(SVCGSSD)
> + AC_SUBST(enable_svcgss)
> + AM_CONDITIONAL(CONFIG_SVCGSS, [test "$enable_svcgss" = "yes"])
> +
> AC_ARG_ENABLE(kprefix,
> [AC_HELP_STRING([--enable-kprefix], [install progs as rpc.knfsd etc])],
> test "$enableval" = "yes" && kprefix=k,
> diff --git a/utils/gssd/Makefile.am b/utils/gssd/Makefile.am
> index af59791..9835117 100644
> --- a/utils/gssd/Makefile.am
> +++ b/utils/gssd/Makefile.am
> @@ -1,10 +1,17 @@
> ## Process this file with automake to produce Makefile.in
>
> -man8_MANS = gssd.man svcgssd.man
> +man8_MANS = gssd.man
> +if CONFIG_SVCGSS
> +man8_MANS += svcgssd.man
> +endif
>
> RPCPREFIX = rpc.
> KPREFIX = @kprefix@
> -sbin_PREFIXED = gssd svcgssd
> +sbin_PREFIXED = gssd
> +if CONFIG_SVCGSS
> +sbin_PREFIXED += svcgssd
> +endif
> +
> sbin_PROGRAMS = $(sbin_PREFIXED)
>
> EXTRA_DIST = \
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/22/2014 03:43 PM, J. Bruce Fields wrote:
> On Mon, Sep 22, 2014 at 03:20:08PM -0400, Steve Dickson wrote:
>> Due to the fact the gssproxy is not managing the
>> GASSAPI credentials, on the server, there is
>> no need to build/install rpc.svcgssd.
>>
>> To re-enable the build use the --enable-svcgss
>> configure flag
>
> Since we're not running rpc.svcgssd in those cases where it's not
> needed, we should keep --enable-svcgss as the default for now. It's an
> easy way to keep old kernels working.
Either way is fine with me... As long as there is a switch but
I have to wonder out loud...
How often is it the case where the the latest nfs-utils is being
run on a a kernel that is over two years old... I guess I don't
see the point...
steved.
>
> --b.
>
>>
>> Signed-off-by: Steve Dickson <[email protected]>
>> ---
>> configure.ac | 23 +++++++++++++++++++----
>> utils/gssd/Makefile.am | 11 +++++++++--
>> 2 files changed, 28 insertions(+), 6 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index bc48373..6767190 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -90,21 +90,36 @@ AC_ARG_ENABLE(nfsv41,
>>
>> AC_ARG_ENABLE(gss,
>> [AC_HELP_STRING([--enable-gss],
>> - [enable support for rpcsec_gss @<:@default=yes@:>@])],
>> + [enable client support for rpcsec_gss @<:@default=yes@:>@])],
>> enable_gss=$enableval,
>> enable_gss=yes)
>> if test "$enable_gss" = yes; then
>> GSSD=gssd
>> - SVCGSSD=svcgssd
>> else
>> enable_gss=
>> GSSD=
>> - SVCGSSD=
>> fi
>> AC_SUBST(GSSD)
>> - AC_SUBST(SVCGSSD)
>> AC_SUBST(enable_gss)
>> AM_CONDITIONAL(CONFIG_GSS, [test "$enable_gss" = "yes"])
>> +
>> +AC_ARG_ENABLE(svcgss,
>> + [AC_HELP_STRING([--enable-svcgss],
>> + [enable server support for rpcsec_gss @<:@default=no@:>@])],
>> + enable_svcgss=$enableval,
>> + enable_svcgss=no)
>> + if test "$enable_gss" = yes; then
>> + if "enable_svcgss" = yes; then
>> + SVCGSSD=svcgssd
>> + fi
>> + else
>> + enable_svcgss=
>> + SVCGSSD=
>> + fi
>> + AC_SUBST(SVCGSSD)
>> + AC_SUBST(enable_svcgss)
>> + AM_CONDITIONAL(CONFIG_SVCGSS, [test "$enable_svcgss" = "yes"])
>> +
>> AC_ARG_ENABLE(kprefix,
>> [AC_HELP_STRING([--enable-kprefix], [install progs as rpc.knfsd etc])],
>> test "$enableval" = "yes" && kprefix=k,
>> diff --git a/utils/gssd/Makefile.am b/utils/gssd/Makefile.am
>> index af59791..9835117 100644
>> --- a/utils/gssd/Makefile.am
>> +++ b/utils/gssd/Makefile.am
>> @@ -1,10 +1,17 @@
>> ## Process this file with automake to produce Makefile.in
>>
>> -man8_MANS = gssd.man svcgssd.man
>> +man8_MANS = gssd.man
>> +if CONFIG_SVCGSS
>> +man8_MANS += svcgssd.man
>> +endif
>>
>> RPCPREFIX = rpc.
>> KPREFIX = @kprefix@
>> -sbin_PREFIXED = gssd svcgssd
>> +sbin_PREFIXED = gssd
>> +if CONFIG_SVCGSS
>> +sbin_PREFIXED += svcgssd
>> +endif
>> +
>> sbin_PROGRAMS = $(sbin_PREFIXED)
>>
>> EXTRA_DIST = \
>> --
>> 1.9.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
On 09/23/2014 10:55 AM, Steve Dickson wrote:
> 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...
As Simo just pointed out... nfs-utils does not need to require
gssproxy to be installed... When its not installed, rpc.svcgssd
will be started when it is, gssproxy will be started.
steved.
On Mon, Sep 22, 2014 at 03:50:13PM -0400, Steve Dickson wrote:
>
>
> On 09/22/2014 03:43 PM, J. Bruce Fields wrote:
> > On Mon, Sep 22, 2014 at 03:20:08PM -0400, Steve Dickson wrote:
> >> Due to the fact the gssproxy is not managing the
> >> GASSAPI credentials, on the server, there is
> >> no need to build/install rpc.svcgssd.
> >>
> >> To re-enable the build use the --enable-svcgss
> >> configure flag
> >
> > Since we're not running rpc.svcgssd in those cases where it's not
> > needed, we should keep --enable-svcgss as the default for now. It's an
> > easy way to keep old kernels working.
> Either way is fine with me... As long as there is a switch but
> I have to wonder out loud...
>
> How often is it the case where the the latest nfs-utils is being
> run on a a kernel that is over two years old...
Anyone trying to do a git-bisect to identify a kernel regression.
(You upgrade your NFS server from F19 to F20 and your network adapter
stops working. You suspect a driver bug, so you try installing the
kernel from F19.)
And it's closer to one year than two. When gss-proxy's a little older
I'll agree.
--b.
Have the nfs-server depend/start on the gssproxy daemon
instead of rpc.svcgssd to manage GSSAPI credentials
Signed-off-by: Steve Dickson <[email protected]>
---
systemd/nfs-server.service | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
index 2fa7387..3b04f84 100644
--- a/systemd/nfs-server.service
+++ b/systemd/nfs-server.service
@@ -2,12 +2,12 @@
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 rpc-gssd.service gssproxy.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
Before= rpc-statd-notify.service
Wants=nfs-config.service
--
1.9.3