| Message ID | 20140923015549.GB32712@fieldses.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, 22 Sep 2014 21:55:49 -0400 "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Mon, Sep 22, 2014 at 08:26:55PM -0400, Simo Sorce wrote: > > On Mon, 22 Sep 2014 19:58:05 -0400 > > Steve Dickson <SteveD@redhat.com> wrote: > > > > > > > > > > > On 09/22/2014 06:34 PM, J. Bruce Fields wrote: > > > > On Mon, Sep 22, 2014 at 05:14:05PM -0400, Steve Dickson wrote: > > > >> > > > >> > > > >> On 09/22/2014 04:44 PM, J. Bruce Fields wrote: > > > >>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote: > > > >>>> > > > >>>> > > > >>>> On 09/22/2014 03:26 PM, Simo Sorce wrote: > > > >>>>> On Mon, 22 Sep 2014 15:20:07 -0400 > > > >>>>> Steve Dickson <steved@redhat.com> wrote: > > > >>>>> > > > >>>>>> Added the gssproxy.service to both the Wants= and > > > >>>>>> Atfers= lines, before the rpc-svcgssd.service. There > > > >>>>>> are ConditionPathExists= lines in the rpc-svcgssd.service > > > >>>>>> unit which will stop the rpc.svcgssd daemon from > > > >>>>>> starting when the gssproxy daemon is already running. > > > >>>>>> > > > >>>>>> Signed-off-by: Steve Dickson <steved@redhat.com> > > > >>>>>> --- > > > >>>>>> systemd/nfs-server.service | 5 +++-- > > > >>>>>> 1 file changed, 3 insertions(+), 2 deletions(-) > > > >>>>>> > > > >>>>>> diff --git a/systemd/nfs-server.service > > > >>>>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 100644 > > > >>>>>> --- a/systemd/nfs-server.service > > > >>>>>> +++ b/systemd/nfs-server.service > > > >>>>>> @@ -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 > > > >>>>>> 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 > > > >>>>> > > > >>>>> I think you really need to insure that the modules are loaded > > > >>>>> before any of the server services are started, perhaps adding a > > > >>>>> unit file that exec's modprobe and has "Before: > > > >>>>> gssproxy.service rpc-svcgssd.service" in it ? > > > >>>> I really don't think its needed... From my testing it appears > > > >>>> gssproxy is always being started and rpc.svcgssd is not... > > > >>> > > > >>> Huh. Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount > > > >>> as both "Requires=" and "After=", so rpc-svcgssd.service will > > > >>> never run without first running var-lib-nfs-rpc_pipefs.mount, > > > >>> which will load sunrpc. But I don't see where auth_rpcgss is > > > >>> getting loaded. And I don't see what ensures anything happening > > > >>> before gssproxy runs. > > > >> It happens during the mount on the client and when the server > > > >> is started. > > > >> > > > >>> > > > >>> We want to make sure your testing's not just getting lucky on the > > > >>> startup order. > > > >> The reason it working is because rpc.gssd is being started on the > > > >> server these days for callbacks and the After= line in > > > >> rpc-svcgssd.service is being executed before the > > > >> ConditionPathExists which cause rpc.svcgssd not to start. > > > > > > > > nfs-utils$ grep After systemd/rpc-svcgssd.service > > > > After=var-lib-nfs-rpc_pipefs.mount > > > > After=gssproxy.service > > > > After=nfs-config.service > > > > > > > > There doesn't seem to be an After= line referring to rpc.gssd. > > > No, why should there be? There is After= line referring to rpc.gssd > > > in nfs-server.service > > > > > > grep After systemd/nfs-server.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=nfs-config.service > > > > > > So when the server starts,rpc.gssd will start and rpc.svcgssd will > > > start if gssproxy is not enable and there is a key tab. > > > > They can start in parallel, there is nothing in that line that makes > > one start before the other. > > > > If you are relying on this you are relying on luck. > > > > > >> So when gssproxy.service does it's "Before=nfs-secure.service > > > >> nfs-secure-server.service" line everything is loaded before > > > >> gssproxy start... > > > > > > > > That line only makes gss-proxy start before those other things. > > > Right, which will load the sunrpc modules. > > > > No, starting before those service in itself achieves nothing.\ > > I think what may cause the module to load maybe the fact > > gssproxy.service includes: > > Requires=proc-fs-nfsd.mount > > I'd expect that to only load the nfsd module. > > Hm, I think nfsd actually has a dependency on auth_rpcgss. I wonder if > that's correct. Maybe that's what's doing it. > > > But to be honest this was a hack to deal with broken nfs service files, > > gss-proxy should not require nfsd, the dependency should be the other > > way around, as gss-proxy can run on machines where there is no nfs > > service whatsoever, as it stand this is a bug in gssproxy.service and > > I'd like to fix it. > > So, something like this? (Untested, no idea if I'm doing this right.) > > --b. > > diff --git a/systemd/auth-rpcgss-module.service b/systemd/auth-rpcgss-module.service > new file mode 100644 > index 000000000000..252545b458fd > --- /dev/null > +++ b/systemd/auth-rpcgss-module.service > @@ -0,0 +1,15 @@ > +# We want to start gss-proxy on kernels that support it and rpc.svcgssd > +# on those that don't. Those services check for support by checking > +# for existence of the path /proc/net/rpc/use-gss-proxy. Before they > +# can perform that check, they need this module loaded. (Unless > +# rpcsec_gss is built directly into the kernel, in which case this unit > +# will fail. But that's OK.) > +[Unit] > +Description=Kernel Module supporting RPCSEC_GSS > +Before=gssproxy.service rpc-svcgssd.service > + > +[Service] > +ExecStart=/sbin/modprobe -q auth_rpcgss I think you need Type=oneshot else systemd won't wait for the modprobe to complete before running the other services. > + > +[Install] > +WantedBy=gssproxy.service rpc-svcgssd.service I don't think you want an install section. That means the service has to be explicitly enabled, which is a pain. I think nfs-server.service should Want= this. I also think ConditionPathExists=/etc/krb5.keytab would be appropriate. Thanks, NeilBrown
On Tue, Sep 23, 2014 at 12:08:04PM +1000, NeilBrown wrote: > On Mon, 22 Sep 2014 21:55:49 -0400 "J. Bruce Fields" <bfields@fieldses.org> > wrote: > > So, something like this? (Untested, no idea if I'm doing this right.) > > > > --b. > > > > diff --git a/systemd/auth-rpcgss-module.service b/systemd/auth-rpcgss-module.service > > new file mode 100644 > > index 000000000000..252545b458fd > > --- /dev/null > > +++ b/systemd/auth-rpcgss-module.service > > @@ -0,0 +1,15 @@ > > +# We want to start gss-proxy on kernels that support it and rpc.svcgssd > > +# on those that don't. Those services check for support by checking > > +# for existence of the path /proc/net/rpc/use-gss-proxy. Before they > > +# can perform that check, they need this module loaded. (Unless > > +# rpcsec_gss is built directly into the kernel, in which case this unit > > +# will fail. But that's OK.) > > +[Unit] > > +Description=Kernel Module supporting RPCSEC_GSS > > +Before=gssproxy.service rpc-svcgssd.service > > + > > +[Service] > > +ExecStart=/sbin/modprobe -q auth_rpcgss > > I think you need > Type=oneshot > > else systemd won't wait for the modprobe to complete before running the other > services. Whoops, yes, thought I'd done that but I guess not. > > + > > +[Install] > > +WantedBy=gssproxy.service rpc-svcgssd.service > > I don't think you want an install section. That means the service has to be > explicitly enabled, which is a pain. > I think nfs-server.service should Want= this. > I also think > > ConditionPathExists=/etc/krb5.keytab > > would be appropriate. OK. --b. -- 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 Mon, 22 Sep 2014 21:55:49 -0400 "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Mon, Sep 22, 2014 at 08:26:55PM -0400, Simo Sorce wrote: > > On Mon, 22 Sep 2014 19:58:05 -0400 > > Steve Dickson <SteveD@redhat.com> wrote: > > > > > > > > > > > On 09/22/2014 06:34 PM, J. Bruce Fields wrote: > > > > On Mon, Sep 22, 2014 at 05:14:05PM -0400, Steve Dickson wrote: > > > >> > > > >> > > > >> On 09/22/2014 04:44 PM, J. Bruce Fields wrote: > > > >>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote: > > > >>>> > > > >>>> > > > >>>> On 09/22/2014 03:26 PM, Simo Sorce wrote: > > > >>>>> On Mon, 22 Sep 2014 15:20:07 -0400 > > > >>>>> Steve Dickson <steved@redhat.com> wrote: > > > >>>>> > > > >>>>>> Added the gssproxy.service to both the Wants= and > > > >>>>>> Atfers= lines, before the rpc-svcgssd.service. There > > > >>>>>> are ConditionPathExists= lines in the rpc-svcgssd.service > > > >>>>>> unit which will stop the rpc.svcgssd daemon from > > > >>>>>> starting when the gssproxy daemon is already running. > > > >>>>>> > > > >>>>>> Signed-off-by: Steve Dickson <steved@redhat.com> > > > >>>>>> --- > > > >>>>>> systemd/nfs-server.service | 5 +++-- > > > >>>>>> 1 file changed, 3 insertions(+), 2 deletions(-) > > > >>>>>> > > > >>>>>> diff --git a/systemd/nfs-server.service > > > >>>>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 100644 > > > >>>>>> --- a/systemd/nfs-server.service > > > >>>>>> +++ b/systemd/nfs-server.service > > > >>>>>> @@ -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 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 > > > >>>>> > > > >>>>> I think you really need to insure that the modules are > > > >>>>> loaded before any of the server services are started, > > > >>>>> perhaps adding a unit file that exec's modprobe and has > > > >>>>> "Before: gssproxy.service rpc-svcgssd.service" in it ? > > > >>>> I really don't think its needed... From my testing it > > > >>>> appears gssproxy is always being started and rpc.svcgssd is > > > >>>> not... > > > >>> > > > >>> Huh. Well rpc-svcgssd.service has > > > >>> var-lib-nfs-rpc_pipefs.mount as both "Requires=" and > > > >>> "After=", so rpc-svcgssd.service will never run without first > > > >>> running var-lib-nfs-rpc_pipefs.mount, which will load > > > >>> sunrpc. But I don't see where auth_rpcgss is getting > > > >>> loaded. And I don't see what ensures anything happening > > > >>> before gssproxy runs. > > > >> It happens during the mount on the client and when the server > > > >> is started. > > > >> > > > >>> > > > >>> We want to make sure your testing's not just getting lucky on > > > >>> the startup order. > > > >> The reason it working is because rpc.gssd is being started on > > > >> the server these days for callbacks and the After= line in > > > >> rpc-svcgssd.service is being executed before the > > > >> ConditionPathExists which cause rpc.svcgssd not to start. > > > > > > > > nfs-utils$ grep After systemd/rpc-svcgssd.service > > > > After=var-lib-nfs-rpc_pipefs.mount > > > > After=gssproxy.service > > > > After=nfs-config.service > > > > > > > > There doesn't seem to be an After= line referring to rpc.gssd. > > > No, why should there be? There is After= line referring to > > > rpc.gssd in nfs-server.service > > > > > > grep After systemd/nfs-server.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=nfs-config.service > > > > > > So when the server starts,rpc.gssd will start and rpc.svcgssd will > > > start if gssproxy is not enable and there is a key tab. > > > > They can start in parallel, there is nothing in that line that makes > > one start before the other. > > > > If you are relying on this you are relying on luck. > > > > > >> So when gssproxy.service does it's "Before=nfs-secure.service > > > >> nfs-secure-server.service" line everything is loaded before > > > >> gssproxy start... > > > > > > > > That line only makes gss-proxy start before those other things. > > > Right, which will load the sunrpc modules. > > > > No, starting before those service in itself achieves nothing.\ > > I think what may cause the module to load maybe the fact > > gssproxy.service includes: > > Requires=proc-fs-nfsd.mount > > I'd expect that to only load the nfsd module. > > Hm, I think nfsd actually has a dependency on auth_rpcgss. I wonder > if that's correct. Maybe that's what's doing it. > > > But to be honest this was a hack to deal with broken nfs service > > files, gss-proxy should not require nfsd, the dependency should be > > the other way around, as gss-proxy can run on machines where there > > is no nfs service whatsoever, as it stand this is a bug in > > gssproxy.service and I'd like to fix it. > > So, something like this? (Untested, no idea if I'm doing this right.) > > --b. > > diff --git a/systemd/auth-rpcgss-module.service > b/systemd/auth-rpcgss-module.service new file mode 100644 > index 000000000000..252545b458fd > --- /dev/null > +++ b/systemd/auth-rpcgss-module.service > @@ -0,0 +1,15 @@ > +# We want to start gss-proxy on kernels that support it and > rpc.svcgssd +# on those that don't. Those services check for support > by checking +# for existence of the > path /proc/net/rpc/use-gss-proxy. Before they +# can perform that > check, they need this module loaded. (Unless +# rpcsec_gss is built > directly into the kernel, in which case this unit +# will fail. But > that's OK.) +[Unit] > +Description=Kernel Module supporting RPCSEC_GSS > +Before=gssproxy.service rpc-svcgssd.service > + > +[Service] > +ExecStart=/sbin/modprobe -q auth_rpcgss > + > +[Install] > +WantedBy=gssproxy.service rpc-svcgssd.service Not sure about the last WantedBy, but this looks like what I had in mind. Simo.
On Tue, 23 Sep 2014 12:08:04 +1000 NeilBrown <neilb@suse.de> wrote: > On Mon, 22 Sep 2014 21:55:49 -0400 "J. Bruce Fields" > <bfields@fieldses.org> wrote: > > > On Mon, Sep 22, 2014 at 08:26:55PM -0400, Simo Sorce wrote: > > > On Mon, 22 Sep 2014 19:58:05 -0400 > > > Steve Dickson <SteveD@redhat.com> wrote: > > > > > > > > > > > > > > > On 09/22/2014 06:34 PM, J. Bruce Fields wrote: > > > > > On Mon, Sep 22, 2014 at 05:14:05PM -0400, Steve Dickson wrote: > > > > >> > > > > >> > > > > >> On 09/22/2014 04:44 PM, J. Bruce Fields wrote: > > > > >>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson > > > > >>> wrote: > > > > >>>> > > > > >>>> > > > > >>>> On 09/22/2014 03:26 PM, Simo Sorce wrote: > > > > >>>>> On Mon, 22 Sep 2014 15:20:07 -0400 > > > > >>>>> Steve Dickson <steved@redhat.com> wrote: > > > > >>>>> > > > > >>>>>> Added the gssproxy.service to both the Wants= and > > > > >>>>>> Atfers= lines, before the rpc-svcgssd.service. There > > > > >>>>>> are ConditionPathExists= lines in the > > > > >>>>>> rpc-svcgssd.service unit which will stop the rpc.svcgssd > > > > >>>>>> daemon from starting when the gssproxy daemon is already > > > > >>>>>> running. > > > > >>>>>> > > > > >>>>>> Signed-off-by: Steve Dickson <steved@redhat.com> > > > > >>>>>> --- > > > > >>>>>> systemd/nfs-server.service | 5 +++-- > > > > >>>>>> 1 file changed, 3 insertions(+), 2 deletions(-) > > > > >>>>>> > > > > >>>>>> diff --git a/systemd/nfs-server.service > > > > >>>>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 > > > > >>>>>> 100644 --- a/systemd/nfs-server.service > > > > >>>>>> +++ b/systemd/nfs-server.service > > > > >>>>>> @@ -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 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 > > > > >>>>> > > > > >>>>> I think you really need to insure that the modules are > > > > >>>>> loaded before any of the server services are started, > > > > >>>>> perhaps adding a unit file that exec's modprobe and has > > > > >>>>> "Before: gssproxy.service rpc-svcgssd.service" in it ? > > > > >>>> I really don't think its needed... From my testing it > > > > >>>> appears gssproxy is always being started and rpc.svcgssd > > > > >>>> is not... > > > > >>> > > > > >>> Huh. Well rpc-svcgssd.service has > > > > >>> var-lib-nfs-rpc_pipefs.mount as both "Requires=" and > > > > >>> "After=", so rpc-svcgssd.service will never run without > > > > >>> first running var-lib-nfs-rpc_pipefs.mount, which will load > > > > >>> sunrpc. But I don't see where auth_rpcgss is getting > > > > >>> loaded. And I don't see what ensures anything happening > > > > >>> before gssproxy runs. > > > > >> It happens during the mount on the client and when the server > > > > >> is started. > > > > >> > > > > >>> > > > > >>> We want to make sure your testing's not just getting lucky > > > > >>> on the startup order. > > > > >> The reason it working is because rpc.gssd is being started > > > > >> on the server these days for callbacks and the After= line in > > > > >> rpc-svcgssd.service is being executed before the > > > > >> ConditionPathExists which cause rpc.svcgssd not to start. > > > > > > > > > > nfs-utils$ grep After systemd/rpc-svcgssd.service > > > > > After=var-lib-nfs-rpc_pipefs.mount > > > > > After=gssproxy.service > > > > > After=nfs-config.service > > > > > > > > > > There doesn't seem to be an After= line referring to rpc.gssd. > > > > No, why should there be? There is After= line referring to > > > > rpc.gssd in nfs-server.service > > > > > > > > grep After systemd/nfs-server.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=nfs-config.service > > > > > > > > So when the server starts,rpc.gssd will start and rpc.svcgssd > > > > will start if gssproxy is not enable and there is a key tab. > > > > > > They can start in parallel, there is nothing in that line that > > > makes one start before the other. > > > > > > If you are relying on this you are relying on luck. > > > > > > > >> So when gssproxy.service does it's "Before=nfs-secure.service > > > > >> nfs-secure-server.service" line everything is loaded before > > > > >> gssproxy start... > > > > > > > > > > That line only makes gss-proxy start before those other > > > > > things. > > > > Right, which will load the sunrpc modules. > > > > > > No, starting before those service in itself achieves nothing.\ > > > I think what may cause the module to load maybe the fact > > > gssproxy.service includes: > > > Requires=proc-fs-nfsd.mount > > > > I'd expect that to only load the nfsd module. > > > > Hm, I think nfsd actually has a dependency on auth_rpcgss. I > > wonder if that's correct. Maybe that's what's doing it. > > > > > But to be honest this was a hack to deal with broken nfs service > > > files, gss-proxy should not require nfsd, the dependency should > > > be the other way around, as gss-proxy can run on machines where > > > there is no nfs service whatsoever, as it stand this is a bug in > > > gssproxy.service and I'd like to fix it. > > > > So, something like this? (Untested, no idea if I'm doing this > > right.) > > > > --b. > > > > diff --git a/systemd/auth-rpcgss-module.service > > b/systemd/auth-rpcgss-module.service new file mode 100644 > > index 000000000000..252545b458fd > > --- /dev/null > > +++ b/systemd/auth-rpcgss-module.service > > @@ -0,0 +1,15 @@ > > +# We want to start gss-proxy on kernels that support it and > > rpc.svcgssd +# on those that don't. Those services check for > > support by checking +# for existence of the > > path /proc/net/rpc/use-gss-proxy. Before they +# can perform that > > check, they need this module loaded. (Unless +# rpcsec_gss is > > built directly into the kernel, in which case this unit +# will > > fail. But that's OK.) +[Unit] > > +Description=Kernel Module supporting RPCSEC_GSS > > +Before=gssproxy.service rpc-svcgssd.service > > + > > +[Service] > > +ExecStart=/sbin/modprobe -q auth_rpcgss > > I think you need > Type=oneshot > > else systemd won't wait for the modprobe to complete before running > the other services. > > > + > > +[Install] > > +WantedBy=gssproxy.service rpc-svcgssd.service > > I don't think you want an install section. That means the service > has to be explicitly enabled, which is a pain. > I think nfs-server.service should Want= this. > I also think > > ConditionPathExists=/etc/krb5.keytab > > would be appropriate. If GSS-Proxy is in use the administrator may choose to use a keytab in a different location, so I am not entirely sure we should depend on /etc/krb5.keytab, however it is also ok to decide that if the admin wants to use a different place that they create a custom unit file. Up to you. Simo.
On 09/22/2014 09:55 PM, J. Bruce Fields wrote: > On Mon, Sep 22, 2014 at 08:26:55PM -0400, Simo Sorce wrote: >> On Mon, 22 Sep 2014 19:58:05 -0400 >> Steve Dickson <SteveD@redhat.com> wrote: >> >>> >>> >>> On 09/22/2014 06:34 PM, J. Bruce Fields wrote: >>>> On Mon, Sep 22, 2014 at 05:14:05PM -0400, Steve Dickson wrote: >>>>> >>>>> >>>>> On 09/22/2014 04:44 PM, J. Bruce Fields wrote: >>>>>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote: >>>>>>> >>>>>>> >>>>>>> On 09/22/2014 03:26 PM, Simo Sorce wrote: >>>>>>>> On Mon, 22 Sep 2014 15:20:07 -0400 >>>>>>>> Steve Dickson <steved@redhat.com> wrote: >>>>>>>> >>>>>>>>> Added the gssproxy.service to both the Wants= and >>>>>>>>> Atfers= lines, before the rpc-svcgssd.service. There >>>>>>>>> are ConditionPathExists= lines in the rpc-svcgssd.service >>>>>>>>> unit which will stop the rpc.svcgssd daemon from >>>>>>>>> starting when the gssproxy daemon is already running. >>>>>>>>> >>>>>>>>> Signed-off-by: Steve Dickson <steved@redhat.com> >>>>>>>>> --- >>>>>>>>> systemd/nfs-server.service | 5 +++-- >>>>>>>>> 1 file changed, 3 insertions(+), 2 deletions(-) >>>>>>>>> >>>>>>>>> diff --git a/systemd/nfs-server.service >>>>>>>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 100644 >>>>>>>>> --- a/systemd/nfs-server.service >>>>>>>>> +++ b/systemd/nfs-server.service >>>>>>>>> @@ -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 >>>>>>>>> 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 >>>>>>>> >>>>>>>> I think you really need to insure that the modules are loaded >>>>>>>> before any of the server services are started, perhaps adding a >>>>>>>> unit file that exec's modprobe and has "Before: >>>>>>>> gssproxy.service rpc-svcgssd.service" in it ? >>>>>>> I really don't think its needed... From my testing it appears >>>>>>> gssproxy is always being started and rpc.svcgssd is not... >>>>>> >>>>>> Huh. Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount >>>>>> as both "Requires=" and "After=", so rpc-svcgssd.service will >>>>>> never run without first running var-lib-nfs-rpc_pipefs.mount, >>>>>> which will load sunrpc. But I don't see where auth_rpcgss is >>>>>> getting loaded. And I don't see what ensures anything happening >>>>>> before gssproxy runs. >>>>> It happens during the mount on the client and when the server >>>>> is started. >>>>> >>>>>> >>>>>> We want to make sure your testing's not just getting lucky on the >>>>>> startup order. >>>>> The reason it working is because rpc.gssd is being started on the >>>>> server these days for callbacks and the After= line in >>>>> rpc-svcgssd.service is being executed before the >>>>> ConditionPathExists which cause rpc.svcgssd not to start. >>>> >>>> nfs-utils$ grep After systemd/rpc-svcgssd.service >>>> After=var-lib-nfs-rpc_pipefs.mount >>>> After=gssproxy.service >>>> After=nfs-config.service >>>> >>>> There doesn't seem to be an After= line referring to rpc.gssd. >>> No, why should there be? There is After= line referring to rpc.gssd >>> in nfs-server.service >>> >>> grep After systemd/nfs-server.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=nfs-config.service >>> >>> So when the server starts,rpc.gssd will start and rpc.svcgssd will >>> start if gssproxy is not enable and there is a key tab. >> >> They can start in parallel, there is nothing in that line that makes >> one start before the other. >> >> If you are relying on this you are relying on luck. >> >>>>> So when gssproxy.service does it's "Before=nfs-secure.service >>>>> nfs-secure-server.service" line everything is loaded before >>>>> gssproxy start... >>>> >>>> That line only makes gss-proxy start before those other things. >>> Right, which will load the sunrpc modules. >> >> No, starting before those service in itself achieves nothing.\ >> I think what may cause the module to load maybe the fact >> gssproxy.service includes: >> Requires=proc-fs-nfsd.mount > > I'd expect that to only load the nfsd module. > > Hm, I think nfsd actually has a dependency on auth_rpcgss. I wonder if > that's correct. Maybe that's what's doing it. It is... In another thread I clearly showed that.... So I really don't think another unit file is necessary... steved. > >> But to be honest this was a hack to deal with broken nfs service files, >> gss-proxy should not require nfsd, the dependency should be the other >> way around, as gss-proxy can run on machines where there is no nfs >> service whatsoever, as it stand this is a bug in gssproxy.service and >> I'd like to fix it. > > So, something like this? (Untested, no idea if I'm doing this right.) > > --b. > > diff --git a/systemd/auth-rpcgss-module.service b/systemd/auth-rpcgss-module.service > new file mode 100644 > index 000000000000..252545b458fd > --- /dev/null > +++ b/systemd/auth-rpcgss-module.service > @@ -0,0 +1,15 @@ > +# We want to start gss-proxy on kernels that support it and rpc.svcgssd > +# on those that don't. Those services check for support by checking > +# for existence of the path /proc/net/rpc/use-gss-proxy. Before they > +# can perform that check, they need this module loaded. (Unless > +# rpcsec_gss is built directly into the kernel, in which case this unit > +# will fail. But that's OK.) > +[Unit] > +Description=Kernel Module supporting RPCSEC_GSS > +Before=gssproxy.service rpc-svcgssd.service > + > +[Service] > +ExecStart=/sbin/modprobe -q auth_rpcgss > + > +[Install] > +WantedBy=gssproxy.service rpc-svcgssd.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, Sep 23, 2014 at 11:06:45AM -0400, Steve Dickson wrote: > > > On 09/22/2014 09:55 PM, J. Bruce Fields wrote: > > On Mon, Sep 22, 2014 at 08:26:55PM -0400, Simo Sorce wrote: > >> No, starting before those service in itself achieves nothing.\ > >> I think what may cause the module to load maybe the fact > >> gssproxy.service includes: > >> Requires=proc-fs-nfsd.mount > > > > I'd expect that to only load the nfsd module. > > > > Hm, I think nfsd actually has a dependency on auth_rpcgss. I wonder if > > that's correct. Maybe that's what's doing it. > It is... In another thread I clearly showed that.... The dependency of nfsd on auth_rpcgss looks to me like an implementation detail. The client module doesn't have the same dependency. We definitely shouldn't depend on it, as the dependency could get removed some day. > So I really don't think another unit file is necessary... I haven't seen an alternative yet. --b. > > steved. > > > > >> But to be honest this was a hack to deal with broken nfs service files, > >> gss-proxy should not require nfsd, the dependency should be the other > >> way around, as gss-proxy can run on machines where there is no nfs > >> service whatsoever, as it stand this is a bug in gssproxy.service and > >> I'd like to fix it. > > > > So, something like this? (Untested, no idea if I'm doing this right.) > > > > --b. > > > > diff --git a/systemd/auth-rpcgss-module.service b/systemd/auth-rpcgss-module.service > > new file mode 100644 > > index 000000000000..252545b458fd > > --- /dev/null > > +++ b/systemd/auth-rpcgss-module.service > > @@ -0,0 +1,15 @@ > > +# We want to start gss-proxy on kernels that support it and rpc.svcgssd > > +# on those that don't. Those services check for support by checking > > +# for existence of the path /proc/net/rpc/use-gss-proxy. Before they > > +# can perform that check, they need this module loaded. (Unless > > +# rpcsec_gss is built directly into the kernel, in which case this unit > > +# will fail. But that's OK.) > > +[Unit] > > +Description=Kernel Module supporting RPCSEC_GSS > > +Before=gssproxy.service rpc-svcgssd.service > > + > > +[Service] > > +ExecStart=/sbin/modprobe -q auth_rpcgss > > + > > +[Install] > > +WantedBy=gssproxy.service rpc-svcgssd.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, Sep 23, 2014 at 08:48:54AM -0400, Simo Sorce wrote: > On Tue, 23 Sep 2014 12:08:04 +1000 > NeilBrown <neilb@suse.de> wrote: > > I don't think you want an install section. That means the service > > has to be explicitly enabled, which is a pain. > > I think nfs-server.service should Want= this. > > I also think > > > > ConditionPathExists=/etc/krb5.keytab > > > > would be appropriate. > > If GSS-Proxy is in use the administrator may choose to use a keytab in > a different location, so I am not entirely sure we should depend > on /etc/krb5.keytab, however it is also ok to decide that if the admin > wants to use a different place that they create a custom unit file. > Up to you. Note we're already using the same line in rpc-gssd.service and rpc-svcgssd.service. Can you suggest a better "does this host have krb5 configured?" test? I think false positives are OK, but not false negatives. (So, if we run those daemons unnecessarily it may annoy some people, but if we fail to run them when they're needed then things really don't work.) --b. -- 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/23/2014 11:16 AM, J. Bruce Fields wrote: > On Tue, Sep 23, 2014 at 11:06:45AM -0400, Steve Dickson wrote: >> > >> > >> > On 09/22/2014 09:55 PM, J. Bruce Fields wrote: >>> > > On Mon, Sep 22, 2014 at 08:26:55PM -0400, Simo Sorce wrote: >>>> > >> No, starting before those service in itself achieves nothing.\ >>>> > >> I think what may cause the module to load maybe the fact >>>> > >> gssproxy.service includes: >>>> > >> Requires=proc-fs-nfsd.mount >>> > > >>> > > I'd expect that to only load the nfsd module. >>> > > >>> > > Hm, I think nfsd actually has a dependency on auth_rpcgss. I wonder if >>> > > that's correct. Maybe that's what's doing it. >> > It is... In another thread I clearly showed that.... > The dependency of nfsd on auth_rpcgss looks to me like an implementation > detail. The client module doesn't have the same dependency. It does... auth_rpcgss and friends are loaded during the mount > We definitely shouldn't depend on it, as the dependency could get removed > some day. Well if that dependency gets removed (which I can't see why it ever would) we'll deal with the then... Remember the scope of this patch set is to enable the server to use the gssproxy, seamlessly... As thing stand today, I think we can easily do that by modifying the server service file to "call" gssproxy when its installed... Plus since both gssproxy and the server have the 'Requires=proc-fs-nfsd.mount' in their service files and Today we know that loads the needed modules I thinking we are good go to... If things change down the road, lets deal with it then... > >> > So I really don't think another unit file is necessary... > I haven't seen an alternative yet. I'm thinking adding yet another unit file to do something that is already being done is just adding more complexity to an already confusing situation... So I guess my alternative is to do nothing. ;-) steved. -- 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, 23 Sep 2014 11:20:00 -0400 "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Tue, Sep 23, 2014 at 08:48:54AM -0400, Simo Sorce wrote: > > On Tue, 23 Sep 2014 12:08:04 +1000 > > NeilBrown <neilb@suse.de> wrote: > > > I don't think you want an install section. That means the service > > > has to be explicitly enabled, which is a pain. > > > I think nfs-server.service should Want= this. > > > I also think > > > > > > ConditionPathExists=/etc/krb5.keytab > > > > > > would be appropriate. > > > > If GSS-Proxy is in use the administrator may choose to use a keytab > > in a different location, so I am not entirely sure we should depend > > on /etc/krb5.keytab, however it is also ok to decide that if the > > admin wants to use a different place that they create a custom unit > > file. Up to you. > > Note we're already using the same line in rpc-gssd.service and > rpc-svcgssd.service. > > Can you suggest a better "does this host have krb5 configured?" test? > > I think false positives are OK, but not false negatives. > > (So, if we run those daemons unnecessarily it may annoy some people, > but if we fail to run them when they're needed then things really > don't work.) I would simply not test for presence of a keytab if it were my call. If the admin decided to start nfs-secure I assume he already got the proper key material, ie I am not so sure that double-checking the admin in the unit files is right for gssproxy, because gssproxy has directives that allow the admin to put the keytab elsewhere. Simo.
On Tue, Sep 23, 2014 at 11:52:12AM -0400, Steve Dickson wrote: > On 09/23/2014 11:16 AM, J. Bruce Fields wrote: > > On Tue, Sep 23, 2014 at 11:06:45AM -0400, Steve Dickson wrote: > >> > > >> > > >> > On 09/22/2014 09:55 PM, J. Bruce Fields wrote: > >>> > > On Mon, Sep 22, 2014 at 08:26:55PM -0400, Simo Sorce wrote: > >>>> > >> No, starting before those service in itself achieves nothing.\ > >>>> > >> I think what may cause the module to load maybe the fact > >>>> > >> gssproxy.service includes: > >>>> > >> Requires=proc-fs-nfsd.mount > >>> > > > >>> > > I'd expect that to only load the nfsd module. > >>> > > > >>> > > Hm, I think nfsd actually has a dependency on auth_rpcgss. I wonder if > >>> > > that's correct. Maybe that's what's doing it. > >> > It is... In another thread I clearly showed that.... > > The dependency of nfsd on auth_rpcgss looks to me like an implementation > > detail. The client module doesn't have the same dependency. > It does... auth_rpcgss and friends are loaded during the mount They get loaded for other reasons. The nfs module does not have any static dependency on the auth_rpcgss module that I can see. > > We definitely shouldn't depend on it, as the dependency could get removed > > some day. > Well if that dependency gets removed (which I can't see why it ever would) > we'll deal with the then... No, please don't depend on this implementation detail. --b. -- 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, Sep 23, 2014 at 12:00:54PM -0400, Simo Sorce wrote: > On Tue, 23 Sep 2014 11:20:00 -0400 > "J. Bruce Fields" <bfields@fieldses.org> wrote: > > > On Tue, Sep 23, 2014 at 08:48:54AM -0400, Simo Sorce wrote: > > > On Tue, 23 Sep 2014 12:08:04 +1000 > > > NeilBrown <neilb@suse.de> wrote: > > > > I don't think you want an install section. That means the service > > > > has to be explicitly enabled, which is a pain. > > > > I think nfs-server.service should Want= this. > > > > I also think > > > > > > > > ConditionPathExists=/etc/krb5.keytab > > > > > > > > would be appropriate. > > > > > > If GSS-Proxy is in use the administrator may choose to use a keytab > > > in a different location, so I am not entirely sure we should depend > > > on /etc/krb5.keytab, however it is also ok to decide that if the > > > admin wants to use a different place that they create a custom unit > > > file. Up to you. > > > > Note we're already using the same line in rpc-gssd.service and > > rpc-svcgssd.service. > > > > Can you suggest a better "does this host have krb5 configured?" test? > > > > I think false positives are OK, but not false negatives. > > > > (So, if we run those daemons unnecessarily it may annoy some people, > > but if we fail to run them when they're needed then things really > > don't work.) > > I would simply not test for presence of a keytab if it were my call. > > If the admin decided to start nfs-secure I assume he already got the > proper key material, ie I am not so sure that double-checking the admin > in the unit files is right for gssproxy, because gssproxy has > directives that allow the admin to put the keytab elsewhere. I believe nfs-secure is being removed (there's none under nfs-utils/systemd). We'd rather not require unnecessary configuration steps. Configuring NFS and krb5 should be enough. So the point is to start the daemons automatically. --b. -- 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, 23 Sep 2014 12:12:14 -0400 "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Tue, Sep 23, 2014 at 12:00:54PM -0400, Simo Sorce wrote: > > On Tue, 23 Sep 2014 11:20:00 -0400 > > "J. Bruce Fields" <bfields@fieldses.org> wrote: > > > > > On Tue, Sep 23, 2014 at 08:48:54AM -0400, Simo Sorce wrote: > > > > On Tue, 23 Sep 2014 12:08:04 +1000 > > > > NeilBrown <neilb@suse.de> wrote: > > > > > I don't think you want an install section. That means the > > > > > service has to be explicitly enabled, which is a pain. > > > > > I think nfs-server.service should Want= this. > > > > > I also think > > > > > > > > > > ConditionPathExists=/etc/krb5.keytab > > > > > > > > > > would be appropriate. > > > > > > > > If GSS-Proxy is in use the administrator may choose to use a > > > > keytab in a different location, so I am not entirely sure we > > > > should depend on /etc/krb5.keytab, however it is also ok to > > > > decide that if the admin wants to use a different place that > > > > they create a custom unit file. Up to you. > > > > > > Note we're already using the same line in rpc-gssd.service and > > > rpc-svcgssd.service. > > > > > > Can you suggest a better "does this host have krb5 configured?" > > > test? > > > > > > I think false positives are OK, but not false negatives. > > > > > > (So, if we run those daemons unnecessarily it may annoy some > > > people, but if we fail to run them when they're needed then > > > things really don't work.) > > > > I would simply not test for presence of a keytab if it were my call. > > > > If the admin decided to start nfs-secure I assume he already got the > > proper key material, ie I am not so sure that double-checking the > > admin in the unit files is right for gssproxy, because gssproxy has > > directives that allow the admin to put the keytab elsewhere. > > I believe nfs-secure is being removed (there's none under > nfs-utils/systemd). > > We'd rather not require unnecessary configuration steps. Configuring > NFS and krb5 should be enough. > > So the point is to start the daemons automatically. I see, I can live with that for now. Simo.
diff --git a/systemd/auth-rpcgss-module.service b/systemd/auth-rpcgss-module.service new file mode 100644 index 000000000000..252545b458fd --- /dev/null +++ b/systemd/auth-rpcgss-module.service @@ -0,0 +1,15 @@ +# We want to start gss-proxy on kernels that support it and rpc.svcgssd +# on those that don't. Those services check for support by checking +# for existence of the path /proc/net/rpc/use-gss-proxy. Before they +# can perform that check, they need this module loaded. (Unless +# rpcsec_gss is built directly into the kernel, in which case this unit +# will fail. But that's OK.) +[Unit] +Description=Kernel Module supporting RPCSEC_GSS +Before=gssproxy.service rpc-svcgssd.service + +[Service] +ExecStart=/sbin/modprobe -q auth_rpcgss + +[Install] +WantedBy=gssproxy.service rpc-svcgssd.service