| Message ID | 20140923192311.GI29932@fieldses.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 09/23/2014 03:23 PM, J. Bruce Fields wrote: > commit 3fab32b4bf96 > Author: J. Bruce Fields <bfields@redhat.com> > Date: Mon Sep 22 21:43:59 2014 -0400 > > systemd: manually insert auth_rpcgss module. > > We need to insert the auth_rpcgss module before starting rpc.svcgssd or > gss-proxy, for two reasons: > > - gss-proxy needs access to the /proc/net/rpc/use-gss-proxy file > to set up communication with knfsd. > - the unit files need to able to test for the existance of the > same path in order to decide whether the kernel supports > gss-proxy or not. > > Currently we're using dependencies on proc-fs-nfsd.mount for this, but > that works only because of the nfsd kernel module references some > symbols in auth_rpcgss, which is an odd implementation detail we're > likely to fix some day. > > Signed-off-by: J. Bruce Fields <bfields@redhat.com> > > diff --git a/systemd/auth-rpcgss-module.service b/systemd/auth-rpcgss-module.service > new file mode 100644 > index 000000000000..3fc2f4ac924f > --- /dev/null > +++ b/systemd/auth-rpcgss-module.service > @@ -0,0 +1,14 @@ > +# 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 support 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 > +ConditionPathExists=/etc/krb5.keytab > + > +[Service] > +Type=oneshot > +ExecStart=/sbin/modprobe -q auth_rpcgss > diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target > index f3c09e76a0f7..474f5e9ad74b 100644 > --- a/systemd/nfs-client.target > +++ b/systemd/nfs-client.target > @@ -5,7 +5,7 @@ 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 > +Wants=rpc-gssd.service rpc-svcgssd.service auth-rpcgss-module.service > Wants=nfs-blkmap.service rpc-statd-notify.service > Before=rpc-gssd.service rpc-svcgssd.service nfs-blkmap.service > > diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service > index 2fa7387e1cb9..fd213a3995de 100644 > --- a/systemd/nfs-server.service > +++ b/systemd/nfs-server.service > @@ -3,6 +3,7 @@ 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=auth-rpcgss-module.service > Wants=rpc-statd-notify.service > > After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service > I through this into my test world and one side effect of this patch is both rpc.gssd and rpc.svcgssd daemons are *always* started when a key tab exists (/etc/krb5.keytab) and *all* the services (nfs-client, nfs-server, rpc-gssd, and rpc-svcgssd) are disabled, which is not good... Those daemons don't need to be started when both sides are disabled... But the auth_rpcgss is loaded! ;-) 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, Sep 23, 2014 at 04:17:31PM -0400, Steve Dickson wrote: > On 09/23/2014 03:23 PM, J. Bruce Fields wrote: > > commit 3fab32b4bf96 > > Author: J. Bruce Fields <bfields@redhat.com> > > Date: Mon Sep 22 21:43:59 2014 -0400 > > > > systemd: manually insert auth_rpcgss module. > > > > We need to insert the auth_rpcgss module before starting rpc.svcgssd or > > gss-proxy, for two reasons: > > > > - gss-proxy needs access to the /proc/net/rpc/use-gss-proxy file > > to set up communication with knfsd. > > - the unit files need to able to test for the existance of the > > same path in order to decide whether the kernel supports > > gss-proxy or not. > > > > Currently we're using dependencies on proc-fs-nfsd.mount for this, but > > that works only because of the nfsd kernel module references some > > symbols in auth_rpcgss, which is an odd implementation detail we're > > likely to fix some day. > > > > Signed-off-by: J. Bruce Fields <bfields@redhat.com> > > > > diff --git a/systemd/auth-rpcgss-module.service b/systemd/auth-rpcgss-module.service > > new file mode 100644 > > index 000000000000..3fc2f4ac924f > > --- /dev/null > > +++ b/systemd/auth-rpcgss-module.service > > @@ -0,0 +1,14 @@ > > +# 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 support 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 > > +ConditionPathExists=/etc/krb5.keytab > > + > > +[Service] > > +Type=oneshot > > +ExecStart=/sbin/modprobe -q auth_rpcgss > > diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target > > index f3c09e76a0f7..474f5e9ad74b 100644 > > --- a/systemd/nfs-client.target > > +++ b/systemd/nfs-client.target > > @@ -5,7 +5,7 @@ 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 > > +Wants=rpc-gssd.service rpc-svcgssd.service auth-rpcgss-module.service > > Wants=nfs-blkmap.service rpc-statd-notify.service > > Before=rpc-gssd.service rpc-svcgssd.service nfs-blkmap.service > > > > diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service > > index 2fa7387e1cb9..fd213a3995de 100644 > > --- a/systemd/nfs-server.service > > +++ b/systemd/nfs-server.service > > @@ -3,6 +3,7 @@ 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=auth-rpcgss-module.service > > Wants=rpc-statd-notify.service > > > > After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service > > > I through this into my test world Thanks! > and one side effect of this patch > is both rpc.gssd and rpc.svcgssd daemons are *always* started when > a key tab exists (/etc/krb5.keytab) and *all* the services (nfs-client, > nfs-server, rpc-gssd, and rpc-svcgssd) are disabled, which is not > good... Those daemons don't need to be started when both sides > are disabled... But the auth_rpcgss is loaded! ;-) Weird. I can't see how this patch on its own would have any effect on that. --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 04:25 PM, J. Bruce Fields wrote: >> I through this into my test world > Thanks! > >> > and one side effect of this patch >> > is both rpc.gssd and rpc.svcgssd daemons are *always* started when >> > a key tab exists (/etc/krb5.keytab) and *all* the services (nfs-client, >> > nfs-server, rpc-gssd, and rpc-svcgssd) are disabled, which is not >> > good... Those daemons don't need to be started when both sides >> > are disabled... But the auth_rpcgss is loaded! ;-) > Weird. I can't see how this patch on its own would have any effect on > that. I agree... I was surprised myself... Unfortunately I'm sure how to debug what/how/when systemd starts things... But I moving the key tab out of the way stop the daemons from starting. Moving it back in place caused the daemons to start again, which didn't happen with the current f21 nfs-utils. Maybe its a bug in some other unit file... 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 09/23/2014 05:15 PM, Steve Dickson wrote: > > On 09/23/2014 04:25 PM, J. Bruce Fields wrote: >>> I through this into my test world >> Thanks! >> >>>> and one side effect of this patch >>>> is both rpc.gssd and rpc.svcgssd daemons are *always* started when >>>> a key tab exists (/etc/krb5.keytab) and *all* the services (nfs-client, >>>> nfs-server, rpc-gssd, and rpc-svcgssd) are disabled, which is not >>>> good... Those daemons don't need to be started when both sides >>>> are disabled... But the auth_rpcgss is loaded! ;-) >> Weird. I can't see how this patch on its own would have any effect on >> that. It turns out I must have had the nfs-client.target enabled... I just realize 'systemctl disable nfs-client' does not fail, but it does not do anything either. :-( I would think it should fail with some type of "unit not found", but it does not... 'systemctl disable nfs-client.target' was the command I wanted to disable the client, so your patch works... Question, Why is rpc.svcgssd/gssproxy when only the nfs-client is enabled?? 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 Wed, Sep 24, 2014 at 11:07:16AM -0400, Steve Dickson wrote: > On 09/23/2014 05:15 PM, Steve Dickson wrote: > > > > On 09/23/2014 04:25 PM, J. Bruce Fields wrote: > >>> I through this into my test world > >> Thanks! > >> > >>>> and one side effect of this patch > >>>> is both rpc.gssd and rpc.svcgssd daemons are *always* started when > >>>> a key tab exists (/etc/krb5.keytab) and *all* the services (nfs-client, > >>>> nfs-server, rpc-gssd, and rpc-svcgssd) are disabled, which is not > >>>> good... Those daemons don't need to be started when both sides > >>>> are disabled... But the auth_rpcgss is loaded! ;-) > >> Weird. I can't see how this patch on its own would have any effect on > >> that. > It turns out I must have had the nfs-client.target enabled... > > I just realize 'systemctl disable nfs-client' does not fail, > but it does not do anything either. :-( I would think > it should fail with some type of "unit not found", but it > does not... > > 'systemctl disable nfs-client.target' was the command I > wanted to disable the client, so your patch works... > > Question, Why is rpc.svcgssd/gssproxy when only the > nfs-client is enabled?? It handles NFSv4.0/krb5 callbacks. (It's not needed for NFSv4.1+, and even in the 4.0 case the only consequence is that you'll lose delegations on krb5 mounts. So maybe we'll be able to remove that dependency, one of these decades....) --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 Wed, Sep 24, 2014 at 11:07:16AM -0400, Steve Dickson wrote: > On 09/23/2014 05:15 PM, Steve Dickson wrote: > > > > On 09/23/2014 04:25 PM, J. Bruce Fields wrote: > >>> I through this into my test world > >> Thanks! > >> > >>>> and one side effect of this patch > >>>> is both rpc.gssd and rpc.svcgssd daemons are *always* started when > >>>> a key tab exists (/etc/krb5.keytab) and *all* the services (nfs-client, > >>>> nfs-server, rpc-gssd, and rpc-svcgssd) are disabled, which is not > >>>> good... Those daemons don't need to be started when both sides > >>>> are disabled... But the auth_rpcgss is loaded! ;-) > >> Weird. I can't see how this patch on its own would have any effect on > >> that. > It turns out I must have had the nfs-client.target enabled... > > I just realize 'systemctl disable nfs-client' does not fail, > but it does not do anything either. :-( I would think > it should fail with some type of "unit not found", but it > does not... Huh, yes, that seems kind of unhelpful. # systemctl disable dighdfdij # echo $? 0 --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/24/2014 11:23 AM, J. Bruce Fields wrote: > On Wed, Sep 24, 2014 at 11:07:16AM -0400, Steve Dickson wrote: >> On 09/23/2014 05:15 PM, Steve Dickson wrote: >>> >>> On 09/23/2014 04:25 PM, J. Bruce Fields wrote: >>>>> I through this into my test world >>>> Thanks! >>>> >>>>>> and one side effect of this patch >>>>>> is both rpc.gssd and rpc.svcgssd daemons are *always* started when >>>>>> a key tab exists (/etc/krb5.keytab) and *all* the services (nfs-client, >>>>>> nfs-server, rpc-gssd, and rpc-svcgssd) are disabled, which is not >>>>>> good... Those daemons don't need to be started when both sides >>>>>> are disabled... But the auth_rpcgss is loaded! ;-) >>>> Weird. I can't see how this patch on its own would have any effect on >>>> that. >> It turns out I must have had the nfs-client.target enabled... >> >> I just realize 'systemctl disable nfs-client' does not fail, >> but it does not do anything either. :-( I would think >> it should fail with some type of "unit not found", but it >> does not... > > Huh, yes, that seems kind of unhelpful. > > # systemctl disable dighdfdij > # echo $? > 0 yup... that's what bit me in the original testing... The wonderful world of systemd!!! :-P Your patch has been committed... 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
diff --git a/systemd/auth-rpcgss-module.service b/systemd/auth-rpcgss-module.service new file mode 100644 index 000000000000..3fc2f4ac924f --- /dev/null +++ b/systemd/auth-rpcgss-module.service @@ -0,0 +1,14 @@ +# 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 support 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 +ConditionPathExists=/etc/krb5.keytab + +[Service] +Type=oneshot +ExecStart=/sbin/modprobe -q auth_rpcgss diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target index f3c09e76a0f7..474f5e9ad74b 100644 --- a/systemd/nfs-client.target +++ b/systemd/nfs-client.target @@ -5,7 +5,7 @@ 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 +Wants=rpc-gssd.service rpc-svcgssd.service auth-rpcgss-module.service Wants=nfs-blkmap.service rpc-statd-notify.service Before=rpc-gssd.service rpc-svcgssd.service nfs-blkmap.service diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service index 2fa7387e1cb9..fd213a3995de 100644 --- a/systemd/nfs-server.service +++ b/systemd/nfs-server.service @@ -3,6 +3,7 @@ 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=auth-rpcgss-module.service Wants=rpc-statd-notify.service After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service