LinuxLists.cc - [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Thu, Jan 30, 2014 at 12:56:49PM -0500, Weston Andros Adamson wrote:
> On Jan 30, 2014, at 10:04 AM, Weston Andros Adamson <[email protected]> wrote:
>
> > I think this is a great idea! The nfs-utils package seems like the right place for this.
> >
> > I don’t know enough about systemd to say that one set of scripts could definitely be shared across distributions, but it seems like any differences should be pretty minor. If there are differences, perhaps we could use cpp or something to do a pass over the source files to make distro specific files?
> >
> > -dros
>
> I think we’ll need a preprocessor pass (or something similar) to handle the “—prefix=” config option and such...

If it's just a different path here or there, it might be simplest for a
distro just to apply a one-line patch?

Anyway, thumbs up to the idea of agreeing on a common set of unit files,
I'll try to take a look....

--b.

>
> -dros
>
> >
> > On Jan 30, 2014, at 1:24 AM, NeilBrown <[email protected]> wrote:
> >
> >>
> >> Hi all,
> >>
> >> I would really like to see a common set of systemd unit files used for
> >> nfs-utils by every distribution (that actually uses systemd), and would like
> >> those unit files to be in the upstream nfs-utils package.
> >>
> >> To that end I have put together the following collection of unit files which
> >> seem right to me, and appear to work as I think I want them to work.
> >>
> >> I've looked at the unit files in Fedora and borrowed some ideas while
> >> discarding and changing others. I won't try to list and justify all the
> >> changes here, but I'm perfectly willing (possibly even eager) to justify
> >> anything specific that anyone cares to ask about.
> >>
> >> So:
> >> 1/ Do you agree that a collection of systemd unit files belongs in
> >> nfs-utils?
> >> 2/ Do you think it reasonable to expect most (systemd using) distros to
> >> use the one set? I will certainly try to ensure openSUSE does if
> >> upstream accepts them.
> >> 3/ Do you have any comments/question about those below?
> >>
> >>
> >> Thanks,
> >> NeilBrown
> >>
> >> diff --git a/systemd/README b/systemd/README
> >> new file mode 100644
> >> index 000000000000..f0fb68825499
> >> --- /dev/null
> >> +++ b/systemd/README
> >> @@ -0,0 +1,50 @@
> >> +
> >> +Notes about systemd unit files for nfs-utils.
> >> +
> >> +The unit files provided here should be sufficient for systemd
> >> +to manage all daemons and related services provides by nfs-utils.
> >> +
> >> +They do *not* include any unit files for separate services such as
> >> +rpc.rquotad (in the 'quota' package) or rpcbind.
> >> +
> >> +There are 4 units that can be 'enabled' or 'disabled' by systemctl, or
> >> +by a suitable 'preset' setting:
> >> +
> >> + nfs-server.target
> >> + If enabled, nfs service is started together with dependencies
> >> + such as mountd, statd, rpc.idmapd
> >> +
> >> + nfs-client.target
> >> + If enabled, daemons needs for an nfs client are enabled.
> >> + This does *not* include rpc.statd. the rpc-statd.service unit
> >> + is started by /usr/sbin/start-statd which mount.nfs will run
> >> + if statd is needed.
> >> +
> >> + nfs-secure.target
> >> + If enabled, then rpc.gssd will be run when either -client or
> >> + -server is started, and rpc.svcgssd will be run when -server
> >> + is started
> >> +
> >> + nfs-blkmap.target
> >> + If enabled, then blkmapd will be run when nfs-client.target is
> >> + started.
> >> +
> >> +
> >> +It is possible that we should have an nfs-statd.target which can
> >> +selectively enable statd being stared by -server and sm-notify
> >> +being started by -server or -client. That way it could be disabled
> >> +completely on V4-only configurations. Currently statd is always
> >> +started on the server and sm-notify is always run if server or
> >> +client is enabled.
> >> +
> >> +Stopping nfs-server will also stop rpc.mountd, and rpc.svcgssd.
> >> +It cannot stop rpc.statd or rpc.gssd as they may be in use by the
> >> +client and systemd cannot specify is two-pronged reverse dependency.
> >> +(i.e. stop this unit if none of these units are running)
> >> +
> >> +Distro specific commandline configuration can be provided by
> >> +installing a script /usr/lib/systemd/scripts/nfs-utils_env.sh
> >> +This should write /run/sysconfig/nfs-utils based on configuration
> >> +information such as in /etc/sysconfig/nfs or /etc/defaults/nfs.
> >> +It should write to a tmp file and rename to the target to
> >> +avoid parallel units seeing incomplete copies of the file.
> >> diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
> >> new file mode 100644
> >> index 000000000000..7319a88661cc
> >> --- /dev/null
> >> +++ b/systemd/nfs-blkmap.service
> >> @@ -0,0 +1,11 @@
> >> +[Unit]
> >> +Description=pNFS block layout mapping daemon
> >> +After=var-lib-nfs-rpc_pipefs.mount
> >> +Requires=var-lib-nfs-rpc_pipefs.mount
> >> +
> >> +Requisite=nfs-blkmap.target
> >> +After=nfs-blkmap.target
> >> +
> >> +[Service]
> >> +Type=forking
> >> +ExecStart=/usr/sbin/blkmapd
> >> diff --git a/systemd/nfs-blkmap.target b/systemd/nfs-blkmap.target
> >> new file mode 100644
> >> index 000000000000..fbcc111152ee
> >> --- /dev/null
> >> +++ b/systemd/nfs-blkmap.target
> >> @@ -0,0 +1,8 @@
> >> +[Unit]
> >> +Description= PNFS blkmaping enablement.
> >> +# If this target is enabled, then blkmapd will be started
> >> +# as required. If it is not enabled it won't.
> >> +
> >> +[Install]
> >> +WantedBy=remote-fs.target
> >> +WantedBy=multi-user.target
> >> \ No newline at end of file
> >> diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target
> >> new file mode 100644
> >> index 000000000000..fa591354abf3
> >> --- /dev/null
> >> +++ b/systemd/nfs-client.target
> >> @@ -0,0 +1,13 @@
> >> +[Unit]
> >> +Description=NFS client services
> >> +Before=remote-fs-pre.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 nfs-blkmap.service rpc-statd-notify.service
> >> +Before=rpc-gssd.service nfs-blkmap.service
> >> +
> >> +[Install]
> >> +WantedBy=multi-user.target
> >> +WantedBy=remote-fs.target
> >> diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
> >> new file mode 100644
> >> index 000000000000..6c2e1537f064
> >> --- /dev/null
> >> +++ b/systemd/nfs-idmapd.service
> >> @@ -0,0 +1,9 @@
> >> +[Unit]
> >> +Description=NFSv4 ID-name mapping service
> >> +
> >> +[Service]
> >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> >> +
> >> +Type=forking
> >> +ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS
> >> diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
> >> new file mode 100644
> >> index 000000000000..92e05ca309ee
> >> --- /dev/null
> >> +++ b/systemd/nfs-mountd.service
> >> @@ -0,0 +1,13 @@
> >> +[Unit]
> >> +Description=NFS Mount Daemon
> >> +Requires=proc-fs-nfsd.mount
> >> +After=proc-fs-nfsd.mount
> >> +After=network.target
> >> +PartOf=nfs-server.service
> >> +
> >> +[Service]
> >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> >> +
> >> +Type=forking
> >> +ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDARGS
> >> diff --git a/systemd/nfs-secure.target b/systemd/nfs-secure.target
> >> new file mode 100644
> >> index 000000000000..0127fdb07dbd
> >> --- /dev/null
> >> +++ b/systemd/nfs-secure.target
> >> @@ -0,0 +1,8 @@
> >> +[Unit]
> >> +Description=Secure NFS client/server services
> >> +# If this target is enabled, then rpc.gssd and rpc.svcgssd will be started
> >> +# as required. If it is not enabled they won't.
> >> +
> >> +[Install]
> >> +WantedBy=remote-fs.target
> >> +WantedBy=multi-user.target
> >> \ No newline at end of file
> >> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> >> new file mode 100644
> >> index 000000000000..9812866c66aa
> >> --- /dev/null
> >> +++ b/systemd/nfs-server.service
> >> @@ -0,0 +1,24 @@
> >> +[Unit]
> >> +Description=NFS server
> >> +DefaultDependencies=no
> >> +Requires= network.target proc-fs-nfsd.mount rpcbind.target
> >> +PartOf=nfs-server.target
> >> +
> >> +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
> >> +Before= rpc-statd-notify.service
> >> +
> >> +[Service]
> >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> >> +
> >> +Type=oneshot
> >> +RemainAfterExit=yes
> >> +ExecStartPre=/usr/sbin/exportfs -r
> >> +ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
> >> +ExecStop=/usr/sbin/rpc.nfsd 0
> >> +ExecStopPost=/usr/sbin/exportfs -au
> >> +ExecStopPost=/usr/sbin/exportfs -f
> >> +
> >> +ExecReload=/usr/sbin/exportfs -r
> >> diff --git a/systemd/nfs-server.target b/systemd/nfs-server.target
> >> new file mode 100644
> >> index 000000000000..a3e629f022a9
> >> --- /dev/null
> >> +++ b/systemd/nfs-server.target
> >> @@ -0,0 +1,8 @@
> >> +[Unit]
> >> +Description=NFS server services
> >> +Requires=nfs-server.service nfs-mountd.service
> >> +Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service rpc-svcgssd.service
> >> +Wants=rpc-statd-notify.service
> >> +
> >> +[Install]
> >> +WantedBy=multi-user.target
> >> diff --git a/systemd/proc-fs-nfsd.mount b/systemd/proc-fs-nfsd.mount
> >> new file mode 100644
> >> index 000000000000..f44d52f3d67b
> >> --- /dev/null
> >> +++ b/systemd/proc-fs-nfsd.mount
> >> @@ -0,0 +1,8 @@
> >> +[Unit]
> >> +Description=NFSD configuration filesystem
> >> +DefaultDependencies=no
> >> +
> >> +[Mount]
> >> +What=nfsd
> >> +Where=/proc/fs/nfsd
> >> +Type=nfsd
> >> diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
> >> new file mode 100644
> >> index 000000000000..f0fef007d480
> >> --- /dev/null
> >> +++ b/systemd/rpc-gssd.service
> >> @@ -0,0 +1,14 @@
> >> +[Unit]
> >> +Description=RPC security service for NFS client and server
> >> +Requires=var-lib-nfs-rpc_pipefs.mount
> >> +After=var-lib-nfs-rpc_pipefs.mount
> >> +
> >> +Requisite=nfs-secure.target
> >> +After=nfs-secure.target
> >> +
> >> +[Service]
> >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> >> +
> >> +Type=forking
> >> +ExecStart=/usr/sbin/rpc.gssd $GSSDARGS
> >> diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
> >> new file mode 100644
> >> index 000000000000..9d972fc7753a
> >> --- /dev/null
> >> +++ b/systemd/rpc-statd-notify.service
> >> @@ -0,0 +1,17 @@
> >> +[Unit]
> >> +Description=Notify NFS peers of a restart
> >> +DefaultDependencies=no
> >> +Requires=network-online.target
> >> +After=network-online.target nss-lookup.target
> >> +
> >> +# if we run an nfs server, it needs to be running before we
> >> +# tell clients that it has restarted.
> >> +After=nfs-server.service
> >> +
> >> +[Service]
> >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> >> +ExecStartPre=/usr/lib/systemd/scritps/nfs-utils_env.sh
> >> +
> >> +Type=oneshot
> >> +RemainAfterExit=yes
> >> +ExecStart=-/usr/sbin/sm-notify -d $SMNOTIFYARGS
> >> diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
> >> new file mode 100644
> >> index 000000000000..04962e542fbc
> >> --- /dev/null
> >> +++ b/systemd/rpc-statd.service
> >> @@ -0,0 +1,12 @@
> >> +[Unit]
> >> +Description=NFS status monitor for NFSv2/3 locking.
> >> +DefaultDependencies=no
> >> +Requires=nss-lookup.target rpcbind.target
> >> +After=network.target nss-lookup.target rpcbind.target
> >> +
> >> +[Service]
> >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> >> +
> >> +Type=forking
> >> +ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS
> >> diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service
> >> new file mode 100644
> >> index 000000000000..f024d40a8f41
> >> --- /dev/null
> >> +++ b/systemd/rpc-svcgssd.service
> >> @@ -0,0 +1,15 @@
> >> +[Unit]
> >> +Description=RPC security service for NFS server
> >> +Requires=var-lib-nfs-rpc_pipefs.mount
> >> +After=var-lib-nfs-rpc_pipefs.mount
> >> +PartOf=nfs-server.service
> >> +
> >> +Requisite=nfs-secure.target
> >> +After=nfs-secure.target
> >> +
> >> +[Service]
> >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> >> +
> >> +Type=forking
> >> +ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS
> >> diff --git a/systemd/var-lib-nfs-rpc_pipefs.mount b/systemd/var-lib-nfs-rpc_pipefs.mount
> >> new file mode 100644
> >> index 000000000000..cd614cf49f00
> >> --- /dev/null
> >> +++ b/systemd/var-lib-nfs-rpc_pipefs.mount
> >> @@ -0,0 +1,8 @@
> >> +[Unit]
> >> +Description=RPC Pipe File System
> >> +DefaultDependencies=no
> >> +
> >> +[Mount]
> >> +What=sunrpc
> >> +Where=/var/lib/nfs/rpc_pipefs
> >> +Type=rpc_pipefs
> >> diff --git a/utils/statd/start-statd b/utils/statd/start-statd
> >> index 1b345a547932..cde3583238e3 100644
> >> --- a/utils/statd/start-statd
> >> +++ b/utils/statd/start-statd
> >> @@ -5,5 +5,8 @@
> >> # It should run statd with whatever flags are apropriate for this
> >> # site.
> >> PATH=/sbin:/usr/sbin
> >> -exec rpc.statd --no-notify
> >> -
> >> +if systemctl start statd.service
> >> +then :
> >> +else
> >> + exec rpc.statd --no-notify
> >> +fi
> >
>
> --
> 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

2014-01-30 22:15:05

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Thu, 30 Jan 2014 15:06:34 -0500 Steve Dickson <[email protected]> wrote:

>
>
> On 01/30/2014 01:24 AM, NeilBrown wrote:
> >
> > Hi all,
> >
> > I would really like to see a common set of systemd unit files used for
> > nfs-utils by every distribution (that actually uses systemd), and would like
> > those unit files to be in the upstream nfs-utils package.
> >
> > To that end I have put together the following collection of unit files which
> > seem right to me, and appear to work as I think I want them to work.
> >
> > I've looked at the unit files in Fedora and borrowed some ideas while
> > discarding and changing others. I won't try to list and justify all the
> > changes here, but I'm perfectly willing (possibly even eager) to justify
> > anything specific that anyone cares to ask about.
> >
> > So:
> > 1/ Do you agree that a collection of systemd unit files belongs in
> > nfs-utils?
> I would think so...
> > 2/ Do you think it reasonable to expect most (systemd using) distros to
> > use the one set? I will certainly try to ensure openSUSE does if
> > upstream accepts them.
> > 3/ Do you have any comments/question about those below?
> >
> >
> > Thanks,
> > NeilBrown
> >
> > diff --git a/systemd/README b/systemd/README
> > new file mode 100644
> > index 000000000000..f0fb68825499
> > --- /dev/null
> > +++ b/systemd/README
> > @@ -0,0 +1,50 @@
> > +
> > +Notes about systemd unit files for nfs-utils.
> > +
> > +The unit files provided here should be sufficient for systemd
> > +to manage all daemons and related services provides by nfs-utils.
> > +
> > +They do *not* include any unit files for separate services such as
> > +rpc.rquotad (in the 'quota' package) or rpcbind.
> > +
> > +There are 4 units that can be 'enabled' or 'disabled' by systemctl, or
> > +by a suitable 'preset' setting:
> > +
> > + nfs-server.target
> > + If enabled, nfs service is started together with dependencies
> > + such as mountd, statd, rpc.idmapd
> > +
> > + nfs-client.target
> > + If enabled, daemons needs for an nfs client are enabled.
> > + This does *not* include rpc.statd. the rpc-statd.service unit
> > + is started by /usr/sbin/start-statd which mount.nfs will run
> > + if statd is needed.
> > +
> > + nfs-secure.target
> > + If enabled, then rpc.gssd will be run when either -client or
> > + -server is started, and rpc.svcgssd will be run when -server
> > + is started
> > +
> > + nfs-blkmap.target
> > + If enabled, then blkmapd will be run when nfs-client.target is
> > + started.
> Do we really need all of these targets? Could we cut it down to
> two. nfs.target and nfs-secure.target?
>

Excellent question.
My thought was to err on the side of providing too many rather than too few.
If a distro wants to remove a particular choice it can use the "presets"
feature off systemd to make sure that target is always enabled.

But I think you might be questioning specific targets rather than the general
number of targets - I respond to that below.

> > +
> > +
> > +It is possible that we should have an nfs-statd.target which can
> > +selectively enable statd being stared by -server and sm-notify
> > +being started by -server or -client. That way it could be disabled
> > +completely on V4-only configurations. Currently statd is always
> > +started on the server and sm-notify is always run if server or
> > +client is enabled.
> > +
> > +Stopping nfs-server will also stop rpc.mountd, and rpc.svcgssd.
> > +It cannot stop rpc.statd or rpc.gssd as they may be in use by the
> > +client and systemd cannot specify is two-pronged reverse dependency.
> > +(i.e. stop this unit if none of these units are running)
> > +
> > +Distro specific commandline configuration can be provided by
> > +installing a script /usr/lib/systemd/scripts/nfs-utils_env.sh
> > +This should write /run/sysconfig/nfs-utils based on configuration
> > +information such as in /etc/sysconfig/nfs or /etc/defaults/nfs.
> > +It should write to a tmp file and rename to the target to
> > +avoid parallel units seeing incomplete copies of the file.
>
> > diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
> > new file mode 100644
> > index 000000000000..7319a88661cc
> > --- /dev/null
> > +++ b/systemd/nfs-blkmap.service
> > @@ -0,0 +1,11 @@
> > +[Unit]
> > +Description=pNFS block layout mapping daemon
> > +After=var-lib-nfs-rpc_pipefs.mount
> > +Requires=var-lib-nfs-rpc_pipefs.mount
> > +
> > +Requisite=nfs-blkmap.target
> > +After=nfs-blkmap.target
> > +
> > +[Service]
> > +Type=forking
> > +ExecStart=/usr/sbin/blkmapd
> Is this even supported anymore? Maybe we can just drop it???

No idea. I found it as I was looking around and assumed it should be started.
If it is no longer supported, how does NFS now find the block devices for
direct pnfs access?

>
>
> > diff --git a/systemd/nfs-blkmap.target b/systemd/nfs-blkmap.target
> > new file mode 100644
> > index 000000000000..fbcc111152ee
> > --- /dev/null
> > +++ b/systemd/nfs-blkmap.target
> > @@ -0,0 +1,8 @@
> > +[Unit]
> > +Description= PNFS blkmaping enablement.
> > +# If this target is enabled, then blkmapd will be started
> > +# as required. If it is not enabled it won't.
> > +
> > +[Install]
> > +WantedBy=remote-fs.target
> > +WantedBy=multi-user.target
> > \ No newline at end of file
>
> Again, why is a client target needed? Now that idmappings are
> stored in the key ring what needs to be started on the client?

rpc.gssd?

Also sm-notify needs to be run on a machine this is used as an NFS client.
This should happen even if no NFS filesystems are mounted at boot.
An 'nfs-client' target seems the natural place to put that requirement.

>
> > diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target
> > new file mode 100644
> > index 000000000000..fa591354abf3
> > --- /dev/null
> > +++ b/systemd/nfs-client.target
> > @@ -0,0 +1,13 @@
> > +[Unit]
> > +Description=NFS client services
> > +Before=remote-fs-pre.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 nfs-blkmap.service rpc-statd-notify.service
> > +Before=rpc-gssd.service nfs-blkmap.service
> > +
> > +[Install]
> > +WantedBy=multi-user.target
> > +WantedBy=remote-fs.target
>
>
> > diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
> > new file mode 100644
> > index 000000000000..6c2e1537f064
> > --- /dev/null
> > +++ b/systemd/nfs-idmapd.service
> > @@ -0,0 +1,9 @@
> > +[Unit]
> > +Description=NFSv4 ID-name mapping service
> Fedora has in the [Unit]:
> BindTo=nfs-server.service
> After=nfs-server.service
> I guess I thought they were needed at the time..

Yes, I saw that. So I looked into it.
Apart from being a typo ("BindsTo" with an 's' is correct),
BindsTo has an extra effect if the target unit - nfs-server.service in this
case - disappears unexpectedly. e.g. if the process dies.
However nfs-server.service doesn't have a process which can die. Rather it
starts some kernel threads. I'm pretty sure systemd won't be able to link
those threads with nfs-server.service.
So nfs-server.service can never "die", so "BindsTo" add nothing useful.

"After" just seems wrong. The moment nfsd is started a request could come in
which could require an idmap lookup, so nfs-idmapd should already be there.

>
> > +
> > +[Service]
> > +EnvironmentFile=-/run/sysconfig/nfs-utils
> > +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> > +
> > +Type=forking
> > +ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS
>
>
> > diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
> > new file mode 100644
> > index 000000000000..92e05ca309ee
> > --- /dev/null
> > +++ b/systemd/nfs-mountd.service
> > @@ -0,0 +1,13 @@
> > +[Unit]
> > +Description=NFS Mount Daemon
> > +Requires=proc-fs-nfsd.mount
> > +After=proc-fs-nfsd.mount
> > +After=network.target
> > +PartOf=nfs-server.service
> > +
> > +[Service]
> > +EnvironmentFile=-/run/sysconfig/nfs-utils
> > +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> How does this script know who is calling it and what it
> has to do?

Its task is to read some config file like /etc/sysconfig/nfs and determine
what the command line arguments for each nfs program should be and write out
FOO_ARGS=
lines to /run/sysconfig/nfs-utils for each FOO which is an nfs program.
I have since thought this would work better as a separate unit which creates
the nfs-utils env file once, and have all the other units have Wants/After
dependencies.

>
> > +
> > +Type=forking
> > +ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDARGS
>
>
> > diff --git a/systemd/nfs-secure.target b/systemd/nfs-secure.target
> > new file mode 100644
> > index 000000000000..0127fdb07dbd
> > --- /dev/null
> > +++ b/systemd/nfs-secure.target
> > @@ -0,0 +1,8 @@
> > +[Unit]
> > +Description=Secure NFS client/server services
> > +# If this target is enabled, then rpc.gssd and rpc.svcgssd will be started
> > +# as required. If it is not enabled they won't.
> So the "Requisite=nfs-secure.target" in rpc-gssd.service cause the
> daemon to started?

This is a bit subtle.
The "Requisite=nfs-secure.target" in rpc-gssd.service means that service is
only allowed to start if this unit (nfs-secure.target) is already started.
So if nfs-secure.target is enabled, then rpc-gssd.service will start when
anything Wants it. If nfs-secure.target is not enabled, then
rpc-gssd.service will not start, even if something Wants it.

So enabling nfs-secure.target doesn't start anything, just allows a couple of
things to start if they are Wanted.

>
> > +
> > +[Install]
> > +WantedBy=remote-fs.target
> > +WantedBy=multi-user.target
> > \ No newline at end of file
>
>
> > diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> > new file mode 100644
> > index 000000000000..9812866c66aa
> > --- /dev/null
> > +++ b/systemd/nfs-server.service
> > @@ -0,0 +1,24 @@
> > +[Unit]
> > +Description=NFS server
> > +DefaultDependencies=no
> > +Requires= network.target proc-fs-nfsd.mount rpcbind.target
> > +PartOf=nfs-server.target
> > +
> > +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
> > +Before= rpc-statd-notify.service
> > +
> > +[Service]
> > +EnvironmentFile=-/run/sysconfig/nfs-utils
> > +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> > +
> > +Type=oneshot
> > +RemainAfterExit=yes
> > +ExecStartPre=/usr/sbin/exportfs -r
> > +ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
> Having ExecStartPre and ExecStartPost scripts gives
> us a place to do some pre and post server configuration.
>
> Granted it has not been needed in a while but I'm thinking
> it could come in handing...

systemd supports so-called "dropins". If a distro wants to add an
ExecStartPre for some distro-specific reason they can put it in

/etc/systemd/system/nfs-server.service.d/04-Fedora-hacks.conf

and it will be understood by systemd to be part of this service.
Of course if they were not distro-specific reasons we would include them in
the upstream package :-)

I note that the Fedora nfs-server.service has a preconfig
echo "$NFSD_V4_GRACE" > /proc/fs/nfsd/nfsv4gracetime

and a postconfig
/sbin/modprobe svcrdma
echo "rdma $RDMA_PORT" > /proc/fs/nfsd/portlist

These seem reasonably general, though I'm wondering why the RDMA port is set
in postconfig rather than preconfig.
Do you know why that is?

>
> > +ExecStop=/usr/sbin/rpc.nfsd 0
> > +ExecStopPost=/usr/sbin/exportfs -au
> > +ExecStopPost=/usr/sbin/exportfs -f
> > +
> > +ExecReload=/usr/sbin/exportfs -r
>
>
> > diff --git a/systemd/nfs-server.target b/systemd/nfs-server.target
> > new file mode 100644
> > index 000000000000..a3e629f022a9
> > --- /dev/null
> > +++ b/systemd/nfs-server.target
> > @@ -0,0 +1,8 @@
> > +[Unit]
> > +Description=NFS server services
> > +Requires=nfs-server.service nfs-mountd.service
> > +Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service rpc-svcgssd.service
> > +Wants=rpc-statd-notify.service
> > +
> > +[Install]
> > +WantedBy=multi-user.target
>
>
> > diff --git a/systemd/proc-fs-nfsd.mount b/systemd/proc-fs-nfsd.mount
> > new file mode 100644
> > index 000000000000..f44d52f3d67b
> > --- /dev/null
> > +++ b/systemd/proc-fs-nfsd.mount
> > @@ -0,0 +1,8 @@
> > +[Unit]
> > +Description=NFSD configuration filesystem
> > +DefaultDependencies=no
> > +
> > +[Mount]
> > +What=nfsd
> > +Where=/proc/fs/nfsd
> > +Type=nfsd
>
>
> > diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
> > new file mode 100644
> > index 000000000000..f0fef007d480
> > --- /dev/null
> > +++ b/systemd/rpc-gssd.service
> > @@ -0,0 +1,14 @@
> > +[Unit]
> > +Description=RPC security service for NFS client and server
> > +Requires=var-lib-nfs-rpc_pipefs.mount
> > +After=var-lib-nfs-rpc_pipefs.mount
> > +
> > +Requisite=nfs-secure.target
> > +After=nfs-secure.target
> > +
> > +[Service]
> > +EnvironmentFile=-/run/sysconfig/nfs-utils
> > +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> > +
> > +Type=forking
> > +ExecStart=/usr/sbin/rpc.gssd $GSSDARGS
>
>
> > diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
> > new file mode 100644
> > index 000000000000..9d972fc7753a
> > --- /dev/null
> > +++ b/systemd/rpc-statd-notify.service
> > @@ -0,0 +1,17 @@
> > +[Unit]
> > +Description=Notify NFS peers of a restart
> > +DefaultDependencies=no
> > +Requires=network-online.target
> > +After=network-online.target nss-lookup.target
> > +
> > +# if we run an nfs server, it needs to be running before we
> > +# tell clients that it has restarted.
> > +After=nfs-server.service
> > +
> > +[Service]
> > +EnvironmentFile=-/run/sysconfig/nfs-utils
> > +ExecStartPre=/usr/lib/systemd/scritps/nfs-utils_env.sh
> > +
> > +Type=oneshot
> > +RemainAfterExit=yes
> > +ExecStart=-/usr/sbin/sm-notify -d $SMNOTIFYARGS
>
>
> > diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
> > new file mode 100644
> > index 000000000000..04962e542fbc
> > --- /dev/null
> > +++ b/systemd/rpc-statd.service
> > @@ -0,0 +1,12 @@
> > +[Unit]
> > +Description=NFS status monitor for NFSv2/3 locking.
> > +DefaultDependencies=no
> > +Requires=nss-lookup.target rpcbind.target
> > +After=network.target nss-lookup.target rpcbind.target
> > +
> > +[Service]
> > +EnvironmentFile=-/run/sysconfig/nfs-utils
> > +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> > +
> > +Type=forking
> > +ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS
>
>
> > diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service
> > new file mode 100644
> > index 000000000000..f024d40a8f41
> > --- /dev/null
> > +++ b/systemd/rpc-svcgssd.service
> > @@ -0,0 +1,15 @@
> > +[Unit]
> > +Description=RPC security service for NFS server
> > +Requires=var-lib-nfs-rpc_pipefs.mount
> > +After=var-lib-nfs-rpc_pipefs.mount
> > +PartOf=nfs-server.service
> > +
> > +Requisite=nfs-secure.target
> > +After=nfs-secure.target
> > +
> > +[Service]
> > +EnvironmentFile=-/run/sysconfig/nfs-utils
> > +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> > +
> > +Type=forking
> > +ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS
>
>
> > diff --git a/systemd/var-lib-nfs-rpc_pipefs.mount b/systemd/var-lib-nfs-rpc_pipefs.mount
> > new file mode 100644
> > index 000000000000..cd614cf49f00
> > --- /dev/null
> > +++ b/systemd/var-lib-nfs-rpc_pipefs.mount
> > @@ -0,0 +1,8 @@
> > +[Unit]
> > +Description=RPC Pipe File System
> > +DefaultDependencies=no
> > +
> > +[Mount]
> > +What=sunrpc
> > +Where=/var/lib/nfs/rpc_pipefs
> > +Type=rpc_pipefs
>
>
> > diff --git a/utils/statd/start-statd b/utils/statd/start-statd
> > index 1b345a547932..cde3583238e3 100644
> > --- a/utils/statd/start-statd
> > +++ b/utils/statd/start-statd
> > @@ -5,5 +5,8 @@
> > # It should run statd with whatever flags are apropriate for this
> > # site.
> > PATH=/sbin:/usr/sbin
> > -exec rpc.statd --no-notify
> > -
> > +if systemctl start statd.service
> > +then :
> > +else
> > + exec rpc.statd --no-notify
> > +fi
> >
>
> How does lockd get started and configured?

Lockd is automatically started by the kernel (nfs and nfsd) when needed.
I noticed that Fedora had some scripts to optionally set the port numbers
that lockd would use. I left that out because I hoped we could find a better
way.

If lockd is compiled in to the kernel, then I think fs.nfs.nlm_XXXport should
be set via /etc/sysctl.conf.
If it is a module, then the module parameters should be configured via
an /etc/modprobe.d/lockd.conf file.
I wish this was unified somehow (should modprobe call sysctl??) but it isn't.

I appreciate that in neither case is it easy to get values out of a
'sysconfig' file in to the right place.

I cannot really think of a better solution than an 'nfs-lock' service which
sets these values, so I'll probably add it.
>
> Overall it looks reasonable... But this is a change
> of ABI... so it will be painful... :-(

What exactly is changing that will be painful? I would certainly like to
arrange the unit files to minimise your pain as much as possible, as long as
it doesn't compromise effectiveness.

Thanks for your review!

NeilBrown

Attachments:

signature.asc (828.00 B)

2014-01-30 17:56:53

by Weston Andros Adamson

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Jan 30, 2014, at 10:04 AM, Weston Andros Adamson <[email protected]> wrote:

> I think this is a great idea! The nfs-utils package seems like the right place for this.
>
> I don?t know enough about systemd to say that one set of scripts could definitely be shared across distributions, but it seems like any differences should be pretty minor. If there are differences, perhaps we could use cpp or something to do a pass over the source files to make distro specific files?
>
> -dros

I think we?ll need a preprocessor pass (or something similar) to handle the ??prefix=? config option and such...

-dros

>
> On Jan 30, 2014, at 1:24 AM, NeilBrown <[email protected]> wrote:
>
>>
>> Hi all,
>>
>> I would really like to see a common set of systemd unit files used for
>> nfs-utils by every distribution (that actually uses systemd), and would like
>> those unit files to be in the upstream nfs-utils package.
>>
>> To that end I have put together the following collection of unit files which
>> seem right to me, and appear to work as I think I want them to work.
>>
>> I've looked at the unit files in Fedora and borrowed some ideas while
>> discarding and changing others. I won't try to list and justify all the
>> changes here, but I'm perfectly willing (possibly even eager) to justify
>> anything specific that anyone cares to ask about.
>>
>> So:
>> 1/ Do you agree that a collection of systemd unit files belongs in
>> nfs-utils?
>> 2/ Do you think it reasonable to expect most (systemd using) distros to
>> use the one set? I will certainly try to ensure openSUSE does if
>> upstream accepts them.
>> 3/ Do you have any comments/question about those below?
>>
>>
>> Thanks,
>> NeilBrown
>>
>> diff --git a/systemd/README b/systemd/README
>> new file mode 100644
>> index 000000000000..f0fb68825499
>> --- /dev/null
>> +++ b/systemd/README
>> @@ -0,0 +1,50 @@
>> +
>> +Notes about systemd unit files for nfs-utils.
>> +
>> +The unit files provided here should be sufficient for systemd
>> +to manage all daemons and related services provides by nfs-utils.
>> +
>> +They do *not* include any unit files for separate services such as
>> +rpc.rquotad (in the 'quota' package) or rpcbind.
>> +
>> +There are 4 units that can be 'enabled' or 'disabled' by systemctl, or
>> +by a suitable 'preset' setting:
>> +
>> + nfs-server.target
>> + If enabled, nfs service is started together with dependencies
>> + such as mountd, statd, rpc.idmapd
>> +
>> + nfs-client.target
>> + If enabled, daemons needs for an nfs client are enabled.
>> + This does *not* include rpc.statd. the rpc-statd.service unit
>> + is started by /usr/sbin/start-statd which mount.nfs will run
>> + if statd is needed.
>> +
>> + nfs-secure.target
>> + If enabled, then rpc.gssd will be run when either -client or
>> + -server is started, and rpc.svcgssd will be run when -server
>> + is started
>> +
>> + nfs-blkmap.target
>> + If enabled, then blkmapd will be run when nfs-client.target is
>> + started.
>> +
>> +
>> +It is possible that we should have an nfs-statd.target which can
>> +selectively enable statd being stared by -server and sm-notify
>> +being started by -server or -client. That way it could be disabled
>> +completely on V4-only configurations. Currently statd is always
>> +started on the server and sm-notify is always run if server or
>> +client is enabled.
>> +
>> +Stopping nfs-server will also stop rpc.mountd, and rpc.svcgssd.
>> +It cannot stop rpc.statd or rpc.gssd as they may be in use by the
>> +client and systemd cannot specify is two-pronged reverse dependency.
>> +(i.e. stop this unit if none of these units are running)
>> +
>> +Distro specific commandline configuration can be provided by
>> +installing a script /usr/lib/systemd/scripts/nfs-utils_env.sh
>> +This should write /run/sysconfig/nfs-utils based on configuration
>> +information such as in /etc/sysconfig/nfs or /etc/defaults/nfs.
>> +It should write to a tmp file and rename to the target to
>> +avoid parallel units seeing incomplete copies of the file.
>> diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
>> new file mode 100644
>> index 000000000000..7319a88661cc
>> --- /dev/null
>> +++ b/systemd/nfs-blkmap.service
>> @@ -0,0 +1,11 @@
>> +[Unit]
>> +Description=pNFS block layout mapping daemon
>> +After=var-lib-nfs-rpc_pipefs.mount
>> +Requires=var-lib-nfs-rpc_pipefs.mount
>> +
>> +Requisite=nfs-blkmap.target
>> +After=nfs-blkmap.target
>> +
>> +[Service]
>> +Type=forking
>> +ExecStart=/usr/sbin/blkmapd
>> diff --git a/systemd/nfs-blkmap.target b/systemd/nfs-blkmap.target
>> new file mode 100644
>> index 000000000000..fbcc111152ee
>> --- /dev/null
>> +++ b/systemd/nfs-blkmap.target
>> @@ -0,0 +1,8 @@
>> +[Unit]
>> +Description= PNFS blkmaping enablement.
>> +# If this target is enabled, then blkmapd will be started
>> +# as required. If it is not enabled it won't.
>> +
>> +[Install]
>> +WantedBy=remote-fs.target
>> +WantedBy=multi-user.target
>> \ No newline at end of file
>> diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target
>> new file mode 100644
>> index 000000000000..fa591354abf3
>> --- /dev/null
>> +++ b/systemd/nfs-client.target
>> @@ -0,0 +1,13 @@
>> +[Unit]
>> +Description=NFS client services
>> +Before=remote-fs-pre.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 nfs-blkmap.service rpc-statd-notify.service
>> +Before=rpc-gssd.service nfs-blkmap.service
>> +
>> +[Install]
>> +WantedBy=multi-user.target
>> +WantedBy=remote-fs.target
>> diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
>> new file mode 100644
>> index 000000000000..6c2e1537f064
>> --- /dev/null
>> +++ b/systemd/nfs-idmapd.service
>> @@ -0,0 +1,9 @@
>> +[Unit]
>> +Description=NFSv4 ID-name mapping service
>> +
>> +[Service]
>> +EnvironmentFile=-/run/sysconfig/nfs-utils
>> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
>> +
>> +Type=forking
>> +ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS
>> diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
>> new file mode 100644
>> index 000000000000..92e05ca309ee
>> --- /dev/null
>> +++ b/systemd/nfs-mountd.service
>> @@ -0,0 +1,13 @@
>> +[Unit]
>> +Description=NFS Mount Daemon
>> +Requires=proc-fs-nfsd.mount
>> +After=proc-fs-nfsd.mount
>> +After=network.target
>> +PartOf=nfs-server.service
>> +
>> +[Service]
>> +EnvironmentFile=-/run/sysconfig/nfs-utils
>> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
>> +
>> +Type=forking
>> +ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDARGS
>> diff --git a/systemd/nfs-secure.target b/systemd/nfs-secure.target
>> new file mode 100644
>> index 000000000000..0127fdb07dbd
>> --- /dev/null
>> +++ b/systemd/nfs-secure.target
>> @@ -0,0 +1,8 @@
>> +[Unit]
>> +Description=Secure NFS client/server services
>> +# If this target is enabled, then rpc.gssd and rpc.svcgssd will be started
>> +# as required. If it is not enabled they won't.
>> +
>> +[Install]
>> +WantedBy=remote-fs.target
>> +WantedBy=multi-user.target
>> \ No newline at end of file
>> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
>> new file mode 100644
>> index 000000000000..9812866c66aa
>> --- /dev/null
>> +++ b/systemd/nfs-server.service
>> @@ -0,0 +1,24 @@
>> +[Unit]
>> +Description=NFS server
>> +DefaultDependencies=no
>> +Requires= network.target proc-fs-nfsd.mount rpcbind.target
>> +PartOf=nfs-server.target
>> +
>> +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
>> +Before= rpc-statd-notify.service
>> +
>> +[Service]
>> +EnvironmentFile=-/run/sysconfig/nfs-utils
>> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
>> +
>> +Type=oneshot
>> +RemainAfterExit=yes
>> +ExecStartPre=/usr/sbin/exportfs -r
>> +ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
>> +ExecStop=/usr/sbin/rpc.nfsd 0
>> +ExecStopPost=/usr/sbin/exportfs -au
>> +ExecStopPost=/usr/sbin/exportfs -f
>> +
>> +ExecReload=/usr/sbin/exportfs -r
>> diff --git a/systemd/nfs-server.target b/systemd/nfs-server.target
>> new file mode 100644
>> index 000000000000..a3e629f022a9
>> --- /dev/null
>> +++ b/systemd/nfs-server.target
>> @@ -0,0 +1,8 @@
>> +[Unit]
>> +Description=NFS server services
>> +Requires=nfs-server.service nfs-mountd.service
>> +Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service rpc-svcgssd.service
>> +Wants=rpc-statd-notify.service
>> +
>> +[Install]
>> +WantedBy=multi-user.target
>> diff --git a/systemd/proc-fs-nfsd.mount b/systemd/proc-fs-nfsd.mount
>> new file mode 100644
>> index 000000000000..f44d52f3d67b
>> --- /dev/null
>> +++ b/systemd/proc-fs-nfsd.mount
>> @@ -0,0 +1,8 @@
>> +[Unit]
>> +Description=NFSD configuration filesystem
>> +DefaultDependencies=no
>> +
>> +[Mount]
>> +What=nfsd
>> +Where=/proc/fs/nfsd
>> +Type=nfsd
>> diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
>> new file mode 100644
>> index 000000000000..f0fef007d480
>> --- /dev/null
>> +++ b/systemd/rpc-gssd.service
>> @@ -0,0 +1,14 @@
>> +[Unit]
>> +Description=RPC security service for NFS client and server
>> +Requires=var-lib-nfs-rpc_pipefs.mount
>> +After=var-lib-nfs-rpc_pipefs.mount
>> +
>> +Requisite=nfs-secure.target
>> +After=nfs-secure.target
>> +
>> +[Service]
>> +EnvironmentFile=-/run/sysconfig/nfs-utils
>> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
>> +
>> +Type=forking
>> +ExecStart=/usr/sbin/rpc.gssd $GSSDARGS
>> diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
>> new file mode 100644
>> index 000000000000..9d972fc7753a
>> --- /dev/null
>> +++ b/systemd/rpc-statd-notify.service
>> @@ -0,0 +1,17 @@
>> +[Unit]
>> +Description=Notify NFS peers of a restart
>> +DefaultDependencies=no
>> +Requires=network-online.target
>> +After=network-online.target nss-lookup.target
>> +
>> +# if we run an nfs server, it needs to be running before we
>> +# tell clients that it has restarted.
>> +After=nfs-server.service
>> +
>> +[Service]
>> +EnvironmentFile=-/run/sysconfig/nfs-utils
>> +ExecStartPre=/usr/lib/systemd/scritps/nfs-utils_env.sh
>> +
>> +Type=oneshot
>> +RemainAfterExit=yes
>> +ExecStart=-/usr/sbin/sm-notify -d $SMNOTIFYARGS
>> diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
>> new file mode 100644
>> index 000000000000..04962e542fbc
>> --- /dev/null
>> +++ b/systemd/rpc-statd.service
>> @@ -0,0 +1,12 @@
>> +[Unit]
>> +Description=NFS status monitor for NFSv2/3 locking.
>> +DefaultDependencies=no
>> +Requires=nss-lookup.target rpcbind.target
>> +After=network.target nss-lookup.target rpcbind.target
>> +
>> +[Service]
>> +EnvironmentFile=-/run/sysconfig/nfs-utils
>> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
>> +
>> +Type=forking
>> +ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS
>> diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service
>> new file mode 100644
>> index 000000000000..f024d40a8f41
>> --- /dev/null
>> +++ b/systemd/rpc-svcgssd.service
>> @@ -0,0 +1,15 @@
>> +[Unit]
>> +Description=RPC security service for NFS server
>> +Requires=var-lib-nfs-rpc_pipefs.mount
>> +After=var-lib-nfs-rpc_pipefs.mount
>> +PartOf=nfs-server.service
>> +
>> +Requisite=nfs-secure.target
>> +After=nfs-secure.target
>> +
>> +[Service]
>> +EnvironmentFile=-/run/sysconfig/nfs-utils
>> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
>> +
>> +Type=forking
>> +ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS
>> diff --git a/systemd/var-lib-nfs-rpc_pipefs.mount b/systemd/var-lib-nfs-rpc_pipefs.mount
>> new file mode 100644
>> index 000000000000..cd614cf49f00
>> --- /dev/null
>> +++ b/systemd/var-lib-nfs-rpc_pipefs.mount
>> @@ -0,0 +1,8 @@
>> +[Unit]
>> +Description=RPC Pipe File System
>> +DefaultDependencies=no
>> +
>> +[Mount]
>> +What=sunrpc
>> +Where=/var/lib/nfs/rpc_pipefs
>> +Type=rpc_pipefs
>> diff --git a/utils/statd/start-statd b/utils/statd/start-statd
>> index 1b345a547932..cde3583238e3 100644
>> --- a/utils/statd/start-statd
>> +++ b/utils/statd/start-statd
>> @@ -5,5 +5,8 @@
>> # It should run statd with whatever flags are apropriate for this
>> # site.
>> PATH=/sbin:/usr/sbin
>> -exec rpc.statd --no-notify
>> -
>> +if systemctl start statd.service
>> +then :
>> +else
>> + exec rpc.statd --no-notify
>> +fi
>

2014-01-30 20:06:37

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On 01/30/2014 01:24 AM, NeilBrown wrote:
>
> Hi all,
>
> I would really like to see a common set of systemd unit files used for
> nfs-utils by every distribution (that actually uses systemd), and would like
> those unit files to be in the upstream nfs-utils package.
>
> To that end I have put together the following collection of unit files which
> seem right to me, and appear to work as I think I want them to work.
>
> I've looked at the unit files in Fedora and borrowed some ideas while
> discarding and changing others. I won't try to list and justify all the
> changes here, but I'm perfectly willing (possibly even eager) to justify
> anything specific that anyone cares to ask about.
>
> So:
> 1/ Do you agree that a collection of systemd unit files belongs in
> nfs-utils?
I would think so...
> 2/ Do you think it reasonable to expect most (systemd using) distros to
> use the one set? I will certainly try to ensure openSUSE does if
> upstream accepts them.
> 3/ Do you have any comments/question about those below?
>
>
> Thanks,
> NeilBrown
>
> diff --git a/systemd/README b/systemd/README
> new file mode 100644
> index 000000000000..f0fb68825499
> --- /dev/null
> +++ b/systemd/README
> @@ -0,0 +1,50 @@
> +
> +Notes about systemd unit files for nfs-utils.
> +
> +The unit files provided here should be sufficient for systemd
> +to manage all daemons and related services provides by nfs-utils.
> +
> +They do *not* include any unit files for separate services such as
> +rpc.rquotad (in the 'quota' package) or rpcbind.
> +
> +There are 4 units that can be 'enabled' or 'disabled' by systemctl, or
> +by a suitable 'preset' setting:
> +
> + nfs-server.target
> + If enabled, nfs service is started together with dependencies
> + such as mountd, statd, rpc.idmapd
> +
> + nfs-client.target
> + If enabled, daemons needs for an nfs client are enabled.
> + This does *not* include rpc.statd. the rpc-statd.service unit
> + is started by /usr/sbin/start-statd which mount.nfs will run
> + if statd is needed.
> +
> + nfs-secure.target
> + If enabled, then rpc.gssd will be run when either -client or
> + -server is started, and rpc.svcgssd will be run when -server
> + is started
> +
> + nfs-blkmap.target
> + If enabled, then blkmapd will be run when nfs-client.target is
> + started.
Do we really need all of these targets? Could we cut it down to
two. nfs.target and nfs-secure.target?

> +
> +
> +It is possible that we should have an nfs-statd.target which can
> +selectively enable statd being stared by -server and sm-notify
> +being started by -server or -client. That way it could be disabled
> +completely on V4-only configurations. Currently statd is always
> +started on the server and sm-notify is always run if server or
> +client is enabled.
> +
> +Stopping nfs-server will also stop rpc.mountd, and rpc.svcgssd.
> +It cannot stop rpc.statd or rpc.gssd as they may be in use by the
> +client and systemd cannot specify is two-pronged reverse dependency.
> +(i.e. stop this unit if none of these units are running)
> +
> +Distro specific commandline configuration can be provided by
> +installing a script /usr/lib/systemd/scripts/nfs-utils_env.sh
> +This should write /run/sysconfig/nfs-utils based on configuration
> +information such as in /etc/sysconfig/nfs or /etc/defaults/nfs.
> +It should write to a tmp file and rename to the target to
> +avoid parallel units seeing incomplete copies of the file.

> diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
> new file mode 100644
> index 000000000000..7319a88661cc
> --- /dev/null
> +++ b/systemd/nfs-blkmap.service
> @@ -0,0 +1,11 @@
> +[Unit]
> +Description=pNFS block layout mapping daemon
> +After=var-lib-nfs-rpc_pipefs.mount
> +Requires=var-lib-nfs-rpc_pipefs.mount
> +
> +Requisite=nfs-blkmap.target
> +After=nfs-blkmap.target
> +
> +[Service]
> +Type=forking
> +ExecStart=/usr/sbin/blkmapd
Is this even supported anymore? Maybe we can just drop it???

> diff --git a/systemd/nfs-blkmap.target b/systemd/nfs-blkmap.target
> new file mode 100644
> index 000000000000..fbcc111152ee
> --- /dev/null
> +++ b/systemd/nfs-blkmap.target
> @@ -0,0 +1,8 @@
> +[Unit]
> +Description= PNFS blkmaping enablement.
> +# If this target is enabled, then blkmapd will be started
> +# as required. If it is not enabled it won't.
> +
> +[Install]
> +WantedBy=remote-fs.target
> +WantedBy=multi-user.target
> \ No newline at end of file

Again, why is a client target needed? Now that idmappings are
stored in the key ring what needs to be started on the client?

> diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target
> new file mode 100644
> index 000000000000..fa591354abf3
> --- /dev/null
> +++ b/systemd/nfs-client.target
> @@ -0,0 +1,13 @@
> +[Unit]
> +Description=NFS client services
> +Before=remote-fs-pre.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 nfs-blkmap.service rpc-statd-notify.service
> +Before=rpc-gssd.service nfs-blkmap.service
> +
> +[Install]
> +WantedBy=multi-user.target
> +WantedBy=remote-fs.target

> diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
> new file mode 100644
> index 000000000000..6c2e1537f064
> --- /dev/null
> +++ b/systemd/nfs-idmapd.service
> @@ -0,0 +1,9 @@
> +[Unit]
> +Description=NFSv4 ID-name mapping service
Fedora has in the [Unit]:
BindTo=nfs-server.service
After=nfs-server.service
I guess I thought they were needed at the time..

> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=forking
> +ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS

> diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
> new file mode 100644
> index 000000000000..92e05ca309ee
> --- /dev/null
> +++ b/systemd/nfs-mountd.service
> @@ -0,0 +1,13 @@
> +[Unit]
> +Description=NFS Mount Daemon
> +Requires=proc-fs-nfsd.mount
> +After=proc-fs-nfsd.mount
> +After=network.target
> +PartOf=nfs-server.service
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
How does this script know who is calling it and what it
has to do?

> +
> +Type=forking
> +ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDARGS

> diff --git a/systemd/nfs-secure.target b/systemd/nfs-secure.target
> new file mode 100644
> index 000000000000..0127fdb07dbd
> --- /dev/null
> +++ b/systemd/nfs-secure.target
> @@ -0,0 +1,8 @@
> +[Unit]
> +Description=Secure NFS client/server services
> +# If this target is enabled, then rpc.gssd and rpc.svcgssd will be started
> +# as required. If it is not enabled they won't.
So the "Requisite=nfs-secure.target" in rpc-gssd.service cause the
daemon to started?

> +
> +[Install]
> +WantedBy=remote-fs.target
> +WantedBy=multi-user.target
> \ No newline at end of file

> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> new file mode 100644
> index 000000000000..9812866c66aa
> --- /dev/null
> +++ b/systemd/nfs-server.service
> @@ -0,0 +1,24 @@
> +[Unit]
> +Description=NFS server
> +DefaultDependencies=no
> +Requires= network.target proc-fs-nfsd.mount rpcbind.target
> +PartOf=nfs-server.target
> +
> +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
> +Before= rpc-statd-notify.service
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=oneshot
> +RemainAfterExit=yes
> +ExecStartPre=/usr/sbin/exportfs -r
> +ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
Having ExecStartPre and ExecStartPost scripts gives
us a place to do some pre and post server configuration.

Granted it has not been needed in a while but I'm thinking
it could come in handing...

> +ExecStop=/usr/sbin/rpc.nfsd 0
> +ExecStopPost=/usr/sbin/exportfs -au
> +ExecStopPost=/usr/sbin/exportfs -f
> +
> +ExecReload=/usr/sbin/exportfs -r

> diff --git a/systemd/nfs-server.target b/systemd/nfs-server.target
> new file mode 100644
> index 000000000000..a3e629f022a9
> --- /dev/null
> +++ b/systemd/nfs-server.target
> @@ -0,0 +1,8 @@
> +[Unit]
> +Description=NFS server services
> +Requires=nfs-server.service nfs-mountd.service
> +Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service rpc-svcgssd.service
> +Wants=rpc-statd-notify.service
> +
> +[Install]
> +WantedBy=multi-user.target

> diff --git a/systemd/proc-fs-nfsd.mount b/systemd/proc-fs-nfsd.mount
> new file mode 100644
> index 000000000000..f44d52f3d67b
> --- /dev/null
> +++ b/systemd/proc-fs-nfsd.mount
> @@ -0,0 +1,8 @@
> +[Unit]
> +Description=NFSD configuration filesystem
> +DefaultDependencies=no
> +
> +[Mount]
> +What=nfsd
> +Where=/proc/fs/nfsd
> +Type=nfsd

> diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
> new file mode 100644
> index 000000000000..f0fef007d480
> --- /dev/null
> +++ b/systemd/rpc-gssd.service
> @@ -0,0 +1,14 @@
> +[Unit]
> +Description=RPC security service for NFS client and server
> +Requires=var-lib-nfs-rpc_pipefs.mount
> +After=var-lib-nfs-rpc_pipefs.mount
> +
> +Requisite=nfs-secure.target
> +After=nfs-secure.target
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=forking
> +ExecStart=/usr/sbin/rpc.gssd $GSSDARGS

> diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
> new file mode 100644
> index 000000000000..9d972fc7753a
> --- /dev/null
> +++ b/systemd/rpc-statd-notify.service
> @@ -0,0 +1,17 @@
> +[Unit]
> +Description=Notify NFS peers of a restart
> +DefaultDependencies=no
> +Requires=network-online.target
> +After=network-online.target nss-lookup.target
> +
> +# if we run an nfs server, it needs to be running before we
> +# tell clients that it has restarted.
> +After=nfs-server.service
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=oneshot
> +RemainAfterExit=yes
> +ExecStart=-/usr/sbin/sm-notify -d $SMNOTIFYARGS

> diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
> new file mode 100644
> index 000000000000..04962e542fbc
> --- /dev/null
> +++ b/systemd/rpc-statd.service
> @@ -0,0 +1,12 @@
> +[Unit]
> +Description=NFS status monitor for NFSv2/3 locking.
> +DefaultDependencies=no
> +Requires=nss-lookup.target rpcbind.target
> +After=network.target nss-lookup.target rpcbind.target
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=forking
> +ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS

> diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service
> new file mode 100644
> index 000000000000..f024d40a8f41
> --- /dev/null
> +++ b/systemd/rpc-svcgssd.service
> @@ -0,0 +1,15 @@
> +[Unit]
> +Description=RPC security service for NFS server
> +Requires=var-lib-nfs-rpc_pipefs.mount
> +After=var-lib-nfs-rpc_pipefs.mount
> +PartOf=nfs-server.service
> +
> +Requisite=nfs-secure.target
> +After=nfs-secure.target
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=forking
> +ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS

> diff --git a/systemd/var-lib-nfs-rpc_pipefs.mount b/systemd/var-lib-nfs-rpc_pipefs.mount
> new file mode 100644
> index 000000000000..cd614cf49f00
> --- /dev/null
> +++ b/systemd/var-lib-nfs-rpc_pipefs.mount
> @@ -0,0 +1,8 @@
> +[Unit]
> +Description=RPC Pipe File System
> +DefaultDependencies=no
> +
> +[Mount]
> +What=sunrpc
> +Where=/var/lib/nfs/rpc_pipefs
> +Type=rpc_pipefs

> diff --git a/utils/statd/start-statd b/utils/statd/start-statd
> index 1b345a547932..cde3583238e3 100644
> --- a/utils/statd/start-statd
> +++ b/utils/statd/start-statd
> @@ -5,5 +5,8 @@
> # It should run statd with whatever flags are apropriate for this
> # site.
> PATH=/sbin:/usr/sbin
> -exec rpc.statd --no-notify
> -
> +if systemctl start statd.service
> +then :
> +else
> + exec rpc.statd --no-notify
> +fi
>

How does lockd get started and configured?

Overall it looks reasonable... But this is a change
of ABI... so it will be painful... :-(

steved.

2014-01-30 22:50:46

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Thu, 30 Jan 2014 13:52:06 -0500 "J. Bruce Fields" <[email protected]>
wrote:

> On Thu, Jan 30, 2014 at 12:56:49PM -0500, Weston Andros Adamson wrote:
> > On Jan 30, 2014, at 10:04 AM, Weston Andros Adamson <[email protected]> wrote:
> >
> > > I think this is a great idea! The nfs-utils package seems like the right place for this.
> > >
> > > I don’t know enough about systemd to say that one set of scripts could definitely be shared across distributions, but it seems like any differences should be pretty minor. If there are differences, perhaps we could use cpp or something to do a pass over the source files to make distro specific files?
> > >
> > > -dros
> >
> > I think we’ll need a preprocessor pass (or something similar) to handle the “—prefix=” config option and such...
>
> If it's just a different path here or there, it might be simplest for a
> distro just to apply a one-line patch?

I imagine the "make install" rules would do something like:
sed 's,/usr/sbin/,$(PREFIX)/,g' $file > $INSTALL_PREFIX/$SYSTEMD_DIR/$file

or something like that.

Though I do wonder if it would every be used. Would *anyone* build nfs-utils
with a non-standard prefix, and also get systemd to manage that version?

I guess the cost is small so we may as well.

>
> Anyway, thumbs up to the idea of agreeing on a common set of unit files,
> I'll try to take a look....

Thanks,
NeilBrown

>
> --b.
>
> >
> > -dros
> >
> > >
> > > On Jan 30, 2014, at 1:24 AM, NeilBrown <[email protected]> wrote:
> > >
> > >>
> > >> Hi all,
> > >>
> > >> I would really like to see a common set of systemd unit files used for
> > >> nfs-utils by every distribution (that actually uses systemd), and would like
> > >> those unit files to be in the upstream nfs-utils package.
> > >>
> > >> To that end I have put together the following collection of unit files which
> > >> seem right to me, and appear to work as I think I want them to work.
> > >>
> > >> I've looked at the unit files in Fedora and borrowed some ideas while
> > >> discarding and changing others. I won't try to list and justify all the
> > >> changes here, but I'm perfectly willing (possibly even eager) to justify
> > >> anything specific that anyone cares to ask about.
> > >>
> > >> So:
> > >> 1/ Do you agree that a collection of systemd unit files belongs in
> > >> nfs-utils?
> > >> 2/ Do you think it reasonable to expect most (systemd using) distros to
> > >> use the one set? I will certainly try to ensure openSUSE does if
> > >> upstream accepts them.
> > >> 3/ Do you have any comments/question about those below?
> > >>
> > >>
> > >> Thanks,
> > >> NeilBrown
> > >>
> > >> diff --git a/systemd/README b/systemd/README
> > >> new file mode 100644
> > >> index 000000000000..f0fb68825499
> > >> --- /dev/null
> > >> +++ b/systemd/README
> > >> @@ -0,0 +1,50 @@
> > >> +
> > >> +Notes about systemd unit files for nfs-utils.
> > >> +
> > >> +The unit files provided here should be sufficient for systemd
> > >> +to manage all daemons and related services provides by nfs-utils.
> > >> +
> > >> +They do *not* include any unit files for separate services such as
> > >> +rpc.rquotad (in the 'quota' package) or rpcbind.
> > >> +
> > >> +There are 4 units that can be 'enabled' or 'disabled' by systemctl, or
> > >> +by a suitable 'preset' setting:
> > >> +
> > >> + nfs-server.target
> > >> + If enabled, nfs service is started together with dependencies
> > >> + such as mountd, statd, rpc.idmapd
> > >> +
> > >> + nfs-client.target
> > >> + If enabled, daemons needs for an nfs client are enabled.
> > >> + This does *not* include rpc.statd. the rpc-statd.service unit
> > >> + is started by /usr/sbin/start-statd which mount.nfs will run
> > >> + if statd is needed.
> > >> +
> > >> + nfs-secure.target
> > >> + If enabled, then rpc.gssd will be run when either -client or
> > >> + -server is started, and rpc.svcgssd will be run when -server
> > >> + is started
> > >> +
> > >> + nfs-blkmap.target
> > >> + If enabled, then blkmapd will be run when nfs-client.target is
> > >> + started.
> > >> +
> > >> +
> > >> +It is possible that we should have an nfs-statd.target which can
> > >> +selectively enable statd being stared by -server and sm-notify
> > >> +being started by -server or -client. That way it could be disabled
> > >> +completely on V4-only configurations. Currently statd is always
> > >> +started on the server and sm-notify is always run if server or
> > >> +client is enabled.
> > >> +
> > >> +Stopping nfs-server will also stop rpc.mountd, and rpc.svcgssd.
> > >> +It cannot stop rpc.statd or rpc.gssd as they may be in use by the
> > >> +client and systemd cannot specify is two-pronged reverse dependency.
> > >> +(i.e. stop this unit if none of these units are running)
> > >> +
> > >> +Distro specific commandline configuration can be provided by
> > >> +installing a script /usr/lib/systemd/scripts/nfs-utils_env.sh
> > >> +This should write /run/sysconfig/nfs-utils based on configuration
> > >> +information such as in /etc/sysconfig/nfs or /etc/defaults/nfs.
> > >> +It should write to a tmp file and rename to the target to
> > >> +avoid parallel units seeing incomplete copies of the file.
> > >> diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
> > >> new file mode 100644
> > >> index 000000000000..7319a88661cc
> > >> --- /dev/null
> > >> +++ b/systemd/nfs-blkmap.service
> > >> @@ -0,0 +1,11 @@
> > >> +[Unit]
> > >> +Description=pNFS block layout mapping daemon
> > >> +After=var-lib-nfs-rpc_pipefs.mount
> > >> +Requires=var-lib-nfs-rpc_pipefs.mount
> > >> +
> > >> +Requisite=nfs-blkmap.target
> > >> +After=nfs-blkmap.target
> > >> +
> > >> +[Service]
> > >> +Type=forking
> > >> +ExecStart=/usr/sbin/blkmapd
> > >> diff --git a/systemd/nfs-blkmap.target b/systemd/nfs-blkmap.target
> > >> new file mode 100644
> > >> index 000000000000..fbcc111152ee
> > >> --- /dev/null
> > >> +++ b/systemd/nfs-blkmap.target
> > >> @@ -0,0 +1,8 @@
> > >> +[Unit]
> > >> +Description= PNFS blkmaping enablement.
> > >> +# If this target is enabled, then blkmapd will be started
> > >> +# as required. If it is not enabled it won't.
> > >> +
> > >> +[Install]
> > >> +WantedBy=remote-fs.target
> > >> +WantedBy=multi-user.target
> > >> \ No newline at end of file
> > >> diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target
> > >> new file mode 100644
> > >> index 000000000000..fa591354abf3
> > >> --- /dev/null
> > >> +++ b/systemd/nfs-client.target
> > >> @@ -0,0 +1,13 @@
> > >> +[Unit]
> > >> +Description=NFS client services
> > >> +Before=remote-fs-pre.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 nfs-blkmap.service rpc-statd-notify.service
> > >> +Before=rpc-gssd.service nfs-blkmap.service
> > >> +
> > >> +[Install]
> > >> +WantedBy=multi-user.target
> > >> +WantedBy=remote-fs.target
> > >> diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
> > >> new file mode 100644
> > >> index 000000000000..6c2e1537f064
> > >> --- /dev/null
> > >> +++ b/systemd/nfs-idmapd.service
> > >> @@ -0,0 +1,9 @@
> > >> +[Unit]
> > >> +Description=NFSv4 ID-name mapping service
> > >> +
> > >> +[Service]
> > >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> > >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> > >> +
> > >> +Type=forking
> > >> +ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS
> > >> diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
> > >> new file mode 100644
> > >> index 000000000000..92e05ca309ee
> > >> --- /dev/null
> > >> +++ b/systemd/nfs-mountd.service
> > >> @@ -0,0 +1,13 @@
> > >> +[Unit]
> > >> +Description=NFS Mount Daemon
> > >> +Requires=proc-fs-nfsd.mount
> > >> +After=proc-fs-nfsd.mount
> > >> +After=network.target
> > >> +PartOf=nfs-server.service
> > >> +
> > >> +[Service]
> > >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> > >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> > >> +
> > >> +Type=forking
> > >> +ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDARGS
> > >> diff --git a/systemd/nfs-secure.target b/systemd/nfs-secure.target
> > >> new file mode 100644
> > >> index 000000000000..0127fdb07dbd
> > >> --- /dev/null
> > >> +++ b/systemd/nfs-secure.target
> > >> @@ -0,0 +1,8 @@
> > >> +[Unit]
> > >> +Description=Secure NFS client/server services
> > >> +# If this target is enabled, then rpc.gssd and rpc.svcgssd will be started
> > >> +# as required. If it is not enabled they won't.
> > >> +
> > >> +[Install]
> > >> +WantedBy=remote-fs.target
> > >> +WantedBy=multi-user.target
> > >> \ No newline at end of file
> > >> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> > >> new file mode 100644
> > >> index 000000000000..9812866c66aa
> > >> --- /dev/null
> > >> +++ b/systemd/nfs-server.service
> > >> @@ -0,0 +1,24 @@
> > >> +[Unit]
> > >> +Description=NFS server
> > >> +DefaultDependencies=no
> > >> +Requires= network.target proc-fs-nfsd.mount rpcbind.target
> > >> +PartOf=nfs-server.target
> > >> +
> > >> +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
> > >> +Before= rpc-statd-notify.service
> > >> +
> > >> +[Service]
> > >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> > >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> > >> +
> > >> +Type=oneshot
> > >> +RemainAfterExit=yes
> > >> +ExecStartPre=/usr/sbin/exportfs -r
> > >> +ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
> > >> +ExecStop=/usr/sbin/rpc.nfsd 0
> > >> +ExecStopPost=/usr/sbin/exportfs -au
> > >> +ExecStopPost=/usr/sbin/exportfs -f
> > >> +
> > >> +ExecReload=/usr/sbin/exportfs -r
> > >> diff --git a/systemd/nfs-server.target b/systemd/nfs-server.target
> > >> new file mode 100644
> > >> index 000000000000..a3e629f022a9
> > >> --- /dev/null
> > >> +++ b/systemd/nfs-server.target
> > >> @@ -0,0 +1,8 @@
> > >> +[Unit]
> > >> +Description=NFS server services
> > >> +Requires=nfs-server.service nfs-mountd.service
> > >> +Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service rpc-svcgssd.service
> > >> +Wants=rpc-statd-notify.service
> > >> +
> > >> +[Install]
> > >> +WantedBy=multi-user.target
> > >> diff --git a/systemd/proc-fs-nfsd.mount b/systemd/proc-fs-nfsd.mount
> > >> new file mode 100644
> > >> index 000000000000..f44d52f3d67b
> > >> --- /dev/null
> > >> +++ b/systemd/proc-fs-nfsd.mount
> > >> @@ -0,0 +1,8 @@
> > >> +[Unit]
> > >> +Description=NFSD configuration filesystem
> > >> +DefaultDependencies=no
> > >> +
> > >> +[Mount]
> > >> +What=nfsd
> > >> +Where=/proc/fs/nfsd
> > >> +Type=nfsd
> > >> diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
> > >> new file mode 100644
> > >> index 000000000000..f0fef007d480
> > >> --- /dev/null
> > >> +++ b/systemd/rpc-gssd.service
> > >> @@ -0,0 +1,14 @@
> > >> +[Unit]
> > >> +Description=RPC security service for NFS client and server
> > >> +Requires=var-lib-nfs-rpc_pipefs.mount
> > >> +After=var-lib-nfs-rpc_pipefs.mount
> > >> +
> > >> +Requisite=nfs-secure.target
> > >> +After=nfs-secure.target
> > >> +
> > >> +[Service]
> > >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> > >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> > >> +
> > >> +Type=forking
> > >> +ExecStart=/usr/sbin/rpc.gssd $GSSDARGS
> > >> diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
> > >> new file mode 100644
> > >> index 000000000000..9d972fc7753a
> > >> --- /dev/null
> > >> +++ b/systemd/rpc-statd-notify.service
> > >> @@ -0,0 +1,17 @@
> > >> +[Unit]
> > >> +Description=Notify NFS peers of a restart
> > >> +DefaultDependencies=no
> > >> +Requires=network-online.target
> > >> +After=network-online.target nss-lookup.target
> > >> +
> > >> +# if we run an nfs server, it needs to be running before we
> > >> +# tell clients that it has restarted.
> > >> +After=nfs-server.service
> > >> +
> > >> +[Service]
> > >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> > >> +ExecStartPre=/usr/lib/systemd/scritps/nfs-utils_env.sh
> > >> +
> > >> +Type=oneshot
> > >> +RemainAfterExit=yes
> > >> +ExecStart=-/usr/sbin/sm-notify -d $SMNOTIFYARGS
> > >> diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
> > >> new file mode 100644
> > >> index 000000000000..04962e542fbc
> > >> --- /dev/null
> > >> +++ b/systemd/rpc-statd.service
> > >> @@ -0,0 +1,12 @@
> > >> +[Unit]
> > >> +Description=NFS status monitor for NFSv2/3 locking.
> > >> +DefaultDependencies=no
> > >> +Requires=nss-lookup.target rpcbind.target
> > >> +After=network.target nss-lookup.target rpcbind.target
> > >> +
> > >> +[Service]
> > >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> > >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> > >> +
> > >> +Type=forking
> > >> +ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS
> > >> diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service
> > >> new file mode 100644
> > >> index 000000000000..f024d40a8f41
> > >> --- /dev/null
> > >> +++ b/systemd/rpc-svcgssd.service
> > >> @@ -0,0 +1,15 @@
> > >> +[Unit]
> > >> +Description=RPC security service for NFS server
> > >> +Requires=var-lib-nfs-rpc_pipefs.mount
> > >> +After=var-lib-nfs-rpc_pipefs.mount
> > >> +PartOf=nfs-server.service
> > >> +
> > >> +Requisite=nfs-secure.target
> > >> +After=nfs-secure.target
> > >> +
> > >> +[Service]
> > >> +EnvironmentFile=-/run/sysconfig/nfs-utils
> > >> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> > >> +
> > >> +Type=forking
> > >> +ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS
> > >> diff --git a/systemd/var-lib-nfs-rpc_pipefs.mount b/systemd/var-lib-nfs-rpc_pipefs.mount
> > >> new file mode 100644
> > >> index 000000000000..cd614cf49f00
> > >> --- /dev/null
> > >> +++ b/systemd/var-lib-nfs-rpc_pipefs.mount
> > >> @@ -0,0 +1,8 @@
> > >> +[Unit]
> > >> +Description=RPC Pipe File System
> > >> +DefaultDependencies=no
> > >> +
> > >> +[Mount]
> > >> +What=sunrpc
> > >> +Where=/var/lib/nfs/rpc_pipefs
> > >> +Type=rpc_pipefs
> > >> diff --git a/utils/statd/start-statd b/utils/statd/start-statd
> > >> index 1b345a547932..cde3583238e3 100644
> > >> --- a/utils/statd/start-statd
> > >> +++ b/utils/statd/start-statd
> > >> @@ -5,5 +5,8 @@
> > >> # It should run statd with whatever flags are apropriate for this
> > >> # site.
> > >> PATH=/sbin:/usr/sbin
> > >> -exec rpc.statd --no-notify
> > >> -
> > >> +if systemctl start statd.service
> > >> +then :
> > >> +else
> > >> + exec rpc.statd --no-notify
> > >> +fi
> > >
> >
> > --
> > 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

Attachments:

signature.asc (828.00 B)

2014-01-30 15:04:57

by Weston Andros Adamson

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

I think this is a great idea! The nfs-utils package seems like the right place for this.

I don?t know enough about systemd to say that one set of scripts could definitely be shared across distributions, but it seems like any differences should be pretty minor. If there are differences, perhaps we could use cpp or something to do a pass over the source files to make distro specific files?

-dros

On Jan 30, 2014, at 1:24 AM, NeilBrown <[email protected]> wrote:

>
> Hi all,
>
> I would really like to see a common set of systemd unit files used for
> nfs-utils by every distribution (that actually uses systemd), and would like
> those unit files to be in the upstream nfs-utils package.
>
> To that end I have put together the following collection of unit files which
> seem right to me, and appear to work as I think I want them to work.
>
> I've looked at the unit files in Fedora and borrowed some ideas while
> discarding and changing others. I won't try to list and justify all the
> changes here, but I'm perfectly willing (possibly even eager) to justify
> anything specific that anyone cares to ask about.
>
> So:
> 1/ Do you agree that a collection of systemd unit files belongs in
> nfs-utils?
> 2/ Do you think it reasonable to expect most (systemd using) distros to
> use the one set? I will certainly try to ensure openSUSE does if
> upstream accepts them.
> 3/ Do you have any comments/question about those below?
>
>
> Thanks,
> NeilBrown
>
> diff --git a/systemd/README b/systemd/README
> new file mode 100644
> index 000000000000..f0fb68825499
> --- /dev/null
> +++ b/systemd/README
> @@ -0,0 +1,50 @@
> +
> +Notes about systemd unit files for nfs-utils.
> +
> +The unit files provided here should be sufficient for systemd
> +to manage all daemons and related services provides by nfs-utils.
> +
> +They do *not* include any unit files for separate services such as
> +rpc.rquotad (in the 'quota' package) or rpcbind.
> +
> +There are 4 units that can be 'enabled' or 'disabled' by systemctl, or
> +by a suitable 'preset' setting:
> +
> + nfs-server.target
> + If enabled, nfs service is started together with dependencies
> + such as mountd, statd, rpc.idmapd
> +
> + nfs-client.target
> + If enabled, daemons needs for an nfs client are enabled.
> + This does *not* include rpc.statd. the rpc-statd.service unit
> + is started by /usr/sbin/start-statd which mount.nfs will run
> + if statd is needed.
> +
> + nfs-secure.target
> + If enabled, then rpc.gssd will be run when either -client or
> + -server is started, and rpc.svcgssd will be run when -server
> + is started
> +
> + nfs-blkmap.target
> + If enabled, then blkmapd will be run when nfs-client.target is
> + started.
> +
> +
> +It is possible that we should have an nfs-statd.target which can
> +selectively enable statd being stared by -server and sm-notify
> +being started by -server or -client. That way it could be disabled
> +completely on V4-only configurations. Currently statd is always
> +started on the server and sm-notify is always run if server or
> +client is enabled.
> +
> +Stopping nfs-server will also stop rpc.mountd, and rpc.svcgssd.
> +It cannot stop rpc.statd or rpc.gssd as they may be in use by the
> +client and systemd cannot specify is two-pronged reverse dependency.
> +(i.e. stop this unit if none of these units are running)
> +
> +Distro specific commandline configuration can be provided by
> +installing a script /usr/lib/systemd/scripts/nfs-utils_env.sh
> +This should write /run/sysconfig/nfs-utils based on configuration
> +information such as in /etc/sysconfig/nfs or /etc/defaults/nfs.
> +It should write to a tmp file and rename to the target to
> +avoid parallel units seeing incomplete copies of the file.
> diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
> new file mode 100644
> index 000000000000..7319a88661cc
> --- /dev/null
> +++ b/systemd/nfs-blkmap.service
> @@ -0,0 +1,11 @@
> +[Unit]
> +Description=pNFS block layout mapping daemon
> +After=var-lib-nfs-rpc_pipefs.mount
> +Requires=var-lib-nfs-rpc_pipefs.mount
> +
> +Requisite=nfs-blkmap.target
> +After=nfs-blkmap.target
> +
> +[Service]
> +Type=forking
> +ExecStart=/usr/sbin/blkmapd
> diff --git a/systemd/nfs-blkmap.target b/systemd/nfs-blkmap.target
> new file mode 100644
> index 000000000000..fbcc111152ee
> --- /dev/null
> +++ b/systemd/nfs-blkmap.target
> @@ -0,0 +1,8 @@
> +[Unit]
> +Description= PNFS blkmaping enablement.
> +# If this target is enabled, then blkmapd will be started
> +# as required. If it is not enabled it won't.
> +
> +[Install]
> +WantedBy=remote-fs.target
> +WantedBy=multi-user.target
> \ No newline at end of file
> diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target
> new file mode 100644
> index 000000000000..fa591354abf3
> --- /dev/null
> +++ b/systemd/nfs-client.target
> @@ -0,0 +1,13 @@
> +[Unit]
> +Description=NFS client services
> +Before=remote-fs-pre.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 nfs-blkmap.service rpc-statd-notify.service
> +Before=rpc-gssd.service nfs-blkmap.service
> +
> +[Install]
> +WantedBy=multi-user.target
> +WantedBy=remote-fs.target
> diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
> new file mode 100644
> index 000000000000..6c2e1537f064
> --- /dev/null
> +++ b/systemd/nfs-idmapd.service
> @@ -0,0 +1,9 @@
> +[Unit]
> +Description=NFSv4 ID-name mapping service
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=forking
> +ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS
> diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
> new file mode 100644
> index 000000000000..92e05ca309ee
> --- /dev/null
> +++ b/systemd/nfs-mountd.service
> @@ -0,0 +1,13 @@
> +[Unit]
> +Description=NFS Mount Daemon
> +Requires=proc-fs-nfsd.mount
> +After=proc-fs-nfsd.mount
> +After=network.target
> +PartOf=nfs-server.service
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=forking
> +ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDARGS
> diff --git a/systemd/nfs-secure.target b/systemd/nfs-secure.target
> new file mode 100644
> index 000000000000..0127fdb07dbd
> --- /dev/null
> +++ b/systemd/nfs-secure.target
> @@ -0,0 +1,8 @@
> +[Unit]
> +Description=Secure NFS client/server services
> +# If this target is enabled, then rpc.gssd and rpc.svcgssd will be started
> +# as required. If it is not enabled they won't.
> +
> +[Install]
> +WantedBy=remote-fs.target
> +WantedBy=multi-user.target
> \ No newline at end of file
> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> new file mode 100644
> index 000000000000..9812866c66aa
> --- /dev/null
> +++ b/systemd/nfs-server.service
> @@ -0,0 +1,24 @@
> +[Unit]
> +Description=NFS server
> +DefaultDependencies=no
> +Requires= network.target proc-fs-nfsd.mount rpcbind.target
> +PartOf=nfs-server.target
> +
> +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
> +Before= rpc-statd-notify.service
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=oneshot
> +RemainAfterExit=yes
> +ExecStartPre=/usr/sbin/exportfs -r
> +ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
> +ExecStop=/usr/sbin/rpc.nfsd 0
> +ExecStopPost=/usr/sbin/exportfs -au
> +ExecStopPost=/usr/sbin/exportfs -f
> +
> +ExecReload=/usr/sbin/exportfs -r
> diff --git a/systemd/nfs-server.target b/systemd/nfs-server.target
> new file mode 100644
> index 000000000000..a3e629f022a9
> --- /dev/null
> +++ b/systemd/nfs-server.target
> @@ -0,0 +1,8 @@
> +[Unit]
> +Description=NFS server services
> +Requires=nfs-server.service nfs-mountd.service
> +Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service rpc-svcgssd.service
> +Wants=rpc-statd-notify.service
> +
> +[Install]
> +WantedBy=multi-user.target
> diff --git a/systemd/proc-fs-nfsd.mount b/systemd/proc-fs-nfsd.mount
> new file mode 100644
> index 000000000000..f44d52f3d67b
> --- /dev/null
> +++ b/systemd/proc-fs-nfsd.mount
> @@ -0,0 +1,8 @@
> +[Unit]
> +Description=NFSD configuration filesystem
> +DefaultDependencies=no
> +
> +[Mount]
> +What=nfsd
> +Where=/proc/fs/nfsd
> +Type=nfsd
> diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
> new file mode 100644
> index 000000000000..f0fef007d480
> --- /dev/null
> +++ b/systemd/rpc-gssd.service
> @@ -0,0 +1,14 @@
> +[Unit]
> +Description=RPC security service for NFS client and server
> +Requires=var-lib-nfs-rpc_pipefs.mount
> +After=var-lib-nfs-rpc_pipefs.mount
> +
> +Requisite=nfs-secure.target
> +After=nfs-secure.target
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=forking
> +ExecStart=/usr/sbin/rpc.gssd $GSSDARGS
> diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
> new file mode 100644
> index 000000000000..9d972fc7753a
> --- /dev/null
> +++ b/systemd/rpc-statd-notify.service
> @@ -0,0 +1,17 @@
> +[Unit]
> +Description=Notify NFS peers of a restart
> +DefaultDependencies=no
> +Requires=network-online.target
> +After=network-online.target nss-lookup.target
> +
> +# if we run an nfs server, it needs to be running before we
> +# tell clients that it has restarted.
> +After=nfs-server.service
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=oneshot
> +RemainAfterExit=yes
> +ExecStart=-/usr/sbin/sm-notify -d $SMNOTIFYARGS
> diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
> new file mode 100644
> index 000000000000..04962e542fbc
> --- /dev/null
> +++ b/systemd/rpc-statd.service
> @@ -0,0 +1,12 @@
> +[Unit]
> +Description=NFS status monitor for NFSv2/3 locking.
> +DefaultDependencies=no
> +Requires=nss-lookup.target rpcbind.target
> +After=network.target nss-lookup.target rpcbind.target
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=forking
> +ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS
> diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service
> new file mode 100644
> index 000000000000..f024d40a8f41
> --- /dev/null
> +++ b/systemd/rpc-svcgssd.service
> @@ -0,0 +1,15 @@
> +[Unit]
> +Description=RPC security service for NFS server
> +Requires=var-lib-nfs-rpc_pipefs.mount
> +After=var-lib-nfs-rpc_pipefs.mount
> +PartOf=nfs-server.service
> +
> +Requisite=nfs-secure.target
> +After=nfs-secure.target
> +
> +[Service]
> +EnvironmentFile=-/run/sysconfig/nfs-utils
> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> +
> +Type=forking
> +ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS
> diff --git a/systemd/var-lib-nfs-rpc_pipefs.mount b/systemd/var-lib-nfs-rpc_pipefs.mount
> new file mode 100644
> index 000000000000..cd614cf49f00
> --- /dev/null
> +++ b/systemd/var-lib-nfs-rpc_pipefs.mount
> @@ -0,0 +1,8 @@
> +[Unit]
> +Description=RPC Pipe File System
> +DefaultDependencies=no
> +
> +[Mount]
> +What=sunrpc
> +Where=/var/lib/nfs/rpc_pipefs
> +Type=rpc_pipefs
> diff --git a/utils/statd/start-statd b/utils/statd/start-statd
> index 1b345a547932..cde3583238e3 100644
> --- a/utils/statd/start-statd
> +++ b/utils/statd/start-statd
> @@ -5,5 +5,8 @@
> # It should run statd with whatever flags are apropriate for this
> # site.
> PATH=/sbin:/usr/sbin
> -exec rpc.statd --no-notify
> -
> +if systemctl start statd.service
> +then :
> +else
> + exec rpc.statd --no-notify
> +fi

2014-01-31 15:19:55

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On 01/30/2014 05:14 PM, NeilBrown wrote:

[snipped]

>> Do we really need all of these targets? Could we cut it down to
>> two. nfs.target and nfs-secure.target?
>>
>
> Excellent question.
> My thought was to err on the side of providing too many rather than too few.
> If a distro wants to remove a particular choice it can use the "presets"
> feature off systemd to make sure that target is always enabled.
>
> But I think you might be questioning specific targets rather than the general
> number of targets - I respond to that below.
On things that be came very apparent when we moved to
systemd was we needed to keep the "service" interface
intact (aka service [start|stop|...] nfs) because
it broke a ton of existing scripts (esp in our QE dept ;-) )
This was the reason for the nfs.target.

This might be a areas where distros need to do their own
tweaking to keep these legacy interfaces alive...

[snipped]

>>
>>> diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
>>> new file mode 100644
>>> index 000000000000..7319a88661cc
>>> --- /dev/null
>>> +++ b/systemd/nfs-blkmap.service
>>> @@ -0,0 +1,11 @@
>>> +[Unit]
>>> +Description=pNFS block layout mapping daemon
>>> +After=var-lib-nfs-rpc_pipefs.mount
>>> +Requires=var-lib-nfs-rpc_pipefs.mount
>>> +
>>> +Requisite=nfs-blkmap.target
>>> +After=nfs-blkmap.target
>>> +
>>> +[Service]
>>> +Type=forking
>>> +ExecStart=/usr/sbin/blkmapd
>> Is this even supported anymore? Maybe we can just drop it???
>
> No idea. I found it as I was looking around and assumed it should be started.
> If it is no longer supported, how does NFS now find the block devices for
> direct pnfs access?
Can someone point me to a pNFS server that supports block Layouts??
Will it be at next month's Connectathon?? If the answer is no, then I
say we drop it...

>
>
>>
>>
>>> diff --git a/systemd/nfs-blkmap.target b/systemd/nfs-blkmap.target
>>> new file mode 100644
>>> index 000000000000..fbcc111152ee
>>> --- /dev/null
>>> +++ b/systemd/nfs-blkmap.target
>>> @@ -0,0 +1,8 @@
>>> +[Unit]
>>> +Description= PNFS blkmaping enablement.
>>> +# If this target is enabled, then blkmapd will be started
>>> +# as required. If it is not enabled it won't.
>>> +
>>> +[Install]
>>> +WantedBy=remote-fs.target
>>> +WantedBy=multi-user.target
>>> \ No newline at end of file
>>
>> Again, why is a client target needed? Now that idmappings are
>> stored in the key ring what needs to be started on the client?
>
> rpc.gssd?
shouldn't this be taken care of in the nfs-secure.target?

>
> Also sm-notify needs to be run on a machine this is used as an NFS client.
> This should happen even if no NFS filesystems are mounted at boot.
> An 'nfs-client' target seems the natural place to put that requirement.
I believe this is all done in the nfs-lock.service today. But I guess
it could make sense to move it into a more generic target.

>
>>
>>> diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target
>>> new file mode 100644
>>> index 000000000000..fa591354abf3
>>> --- /dev/null
>>> +++ b/systemd/nfs-client.target
>>> @@ -0,0 +1,13 @@
>>> +[Unit]
>>> +Description=NFS client services
>>> +Before=remote-fs-pre.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 nfs-blkmap.service rpc-statd-notify.service
>>> +Before=rpc-gssd.service nfs-blkmap.service
Just to be clear. These two line will *not* start the rpc.gssd service
unless the nfs-secure.target was enabled?

>>> +
>>> +[Install]
>>> +WantedBy=multi-user.target
>>> +WantedBy=remote-fs.target
>>
>>
>>> diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
>>> new file mode 100644
>>> index 000000000000..6c2e1537f064
>>> --- /dev/null
>>> +++ b/systemd/nfs-idmapd.service
>>> @@ -0,0 +1,9 @@
>>> +[Unit]
>>> +Description=NFSv4 ID-name mapping service
>> Fedora has in the [Unit]:
>> BindTo=nfs-server.service
>> After=nfs-server.service
>> I guess I thought they were needed at the time..
>
> Yes, I saw that. So I looked into it.
> Apart from being a typo ("BindsTo" with an 's' is correct),
> BindsTo has an extra effect if the target unit - nfs-server.service in this
> case - disappears unexpectedly. e.g. if the process dies.
> However nfs-server.service doesn't have a process which can die. Rather it
> starts some kernel threads. I'm pretty sure systemd won't be able to link
> those threads with nfs-server.service.
> So nfs-server.service can never "die", so "BindsTo" add nothing useful.
Fair enough...

>
> "After" just seems wrong. The moment nfsd is started a request could come in
> which could require an idmap lookup, so nfs-idmapd should already be there.
In our testing we did find race conditions like this...

>
>>
>>> +
>>> +[Service]
>>> +EnvironmentFile=-/run/sysconfig/nfs-utils
>>> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
>>> +
>>> +Type=forking
>>> +ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS
>>
>>
>>> diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
>>> new file mode 100644
>>> index 000000000000..92e05ca309ee
>>> --- /dev/null
>>> +++ b/systemd/nfs-mountd.service
>>> @@ -0,0 +1,13 @@
>>> +[Unit]
>>> +Description=NFS Mount Daemon
>>> +Requires=proc-fs-nfsd.mount
>>> +After=proc-fs-nfsd.mount
>>> +After=network.target
>>> +PartOf=nfs-server.service
>>> +
>>> +[Service]
>>> +EnvironmentFile=-/run/sysconfig/nfs-utils
>>> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
>> How does this script know who is calling it and what it
>> has to do?
>
> Its task is to read some config file like /etc/sysconfig/nfs and determine
> what the command line arguments for each nfs program should be and write out
> FOO_ARGS=
> lines to /run/sysconfig/nfs-utils for each FOO which is an nfs program.
Well the the systemd people have argued that each FOO should read from
a config file instead the systemd scripts... Being as that it may....

> I have since thought this would work better as a separate unit which creates
> the nfs-utils env file once, and have all the other units have Wants/After
> dependencies.
The reason I broken them out was I could not figure out how the single
env script could tell which service it was being called from. Meaning what tells
the script it's being call from the nfs-mountd.service verses the
rpc-gssd.service? Does systemd set some type of environment variable?
Because you can't set one from the service file.

>
>
>>
>>> +
>>> +Type=forking
>>> +ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDARGS
>>
>>
>>> diff --git a/systemd/nfs-secure.target b/systemd/nfs-secure.target
>>> new file mode 100644
>>> index 000000000000..0127fdb07dbd
>>> --- /dev/null
>>> +++ b/systemd/nfs-secure.target
>>> @@ -0,0 +1,8 @@
>>> +[Unit]
>>> +Description=Secure NFS client/server services
>>> +# If this target is enabled, then rpc.gssd and rpc.svcgssd will be started
>>> +# as required. If it is not enabled they won't.
>> So the "Requisite=nfs-secure.target" in rpc-gssd.service cause the
>> daemon to started?
>
> This is a bit subtle.
> The "Requisite=nfs-secure.target" in rpc-gssd.service means that service is
> only allowed to start if this unit (nfs-secure.target) is already started.
> So if nfs-secure.target is enabled, then rpc-gssd.service will start when
> anything Wants it. If nfs-secure.target is not enabled, then
> rpc-gssd.service will not start, even if something Wants it.
>
> So enabling nfs-secure.target doesn't start anything, just allows a couple of
> things to start if they are Wanted.
Got it... and that should work...

>>> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
>>> new file mode 100644
>>> index 000000000000..9812866c66aa
>>> --- /dev/null
>>> +++ b/systemd/nfs-server.service
>>> @@ -0,0 +1,24 @@
>>> +[Unit]
>>> +Description=NFS server
>>> +DefaultDependencies=no
>>> +Requires= network.target proc-fs-nfsd.mount rpcbind.target
>>> +PartOf=nfs-server.target
>>> +
>>> +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
>>> +Before= rpc-statd-notify.service
>>> +
>>> +[Service]
>>> +EnvironmentFile=-/run/sysconfig/nfs-utils
>>> +ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
>>> +
>>> +Type=oneshot
>>> +RemainAfterExit=yes
>>> +ExecStartPre=/usr/sbin/exportfs -r
>>> +ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
>> Having ExecStartPre and ExecStartPost scripts gives
>> us a place to do some pre and post server configuration.
>>
>> Granted it has not been needed in a while but I'm thinking
>> it could come in handing...
>
> systemd supports so-called "dropins". If a distro wants to add an
> ExecStartPre for some distro-specific reason they can put it in
>
> /etc/systemd/system/nfs-server.service.d/04-Fedora-hacks.conf
>
> and it will be understood by systemd to be part of this service.
> Of course if they were not distro-specific reasons we would include them in
> the upstream package :-)
Right... Keeping things non-distro-specific would be the goal...

>
> I note that the Fedora nfs-server.service has a preconfig
> echo "$NFSD_V4_GRACE" > /proc/fs/nfsd/nfsv4gracetime
>
> and a postconfig
> /sbin/modprobe svcrdma
> echo "rdma $RDMA_PORT" > /proc/fs/nfsd/portlist
>
> These seem reasonably general, though I'm wondering why the RDMA port is set
> in postconfig rather than preconfig.
> Do you know why that is?
Because the nfs server need be up and running before the listing
port is created. Just the way it was designed... I guess...

But at the end of the day, all the rdma stuff could go
into is own nfs-server-rdma service file too...

[snipped]

>>
>>
>>> diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service
>>> new file mode 100644
>>> index 000000000000..f024d40a8f41
>>> --- /dev/null
>>> +++ b/systemd/rpc-svcgssd.service
FYI... when gss-proxy is enabled this does not need to be started...

[snipped]

>>
>>
>>> diff --git a/utils/statd/start-statd b/utils/statd/start-statd
>>> index 1b345a547932..cde3583238e3 100644
>>> --- a/utils/statd/start-statd
>>> +++ b/utils/statd/start-statd
>>> @@ -5,5 +5,8 @@
>>> # It should run statd with whatever flags are apropriate for this
>>> # site.
>>> PATH=/sbin:/usr/sbin
>>> -exec rpc.statd --no-notify
>>> -
>>> +if systemctl start statd.service
>>> +then :
>>> +else
>>> + exec rpc.statd --no-notify
>>> +fi
>>>
>>
>> How does lockd get started and configured?
>
> Lockd is automatically started by the kernel (nfs and nfsd) when needed.
> I noticed that Fedora had some scripts to optionally set the port numbers
> that lockd would use. I left that out because I hoped we could find a better
> way.
>
> If lockd is compiled in to the kernel, then I think fs.nfs.nlm_XXXport should
> be set via /etc/sysctl.conf.
> If it is a module, then the module parameters should be configured via
> an /etc/modprobe.d/lockd.conf file.
> I wish this was unified somehow (should modprobe call sysctl??) but it isn't.
>
> I appreciate that in neither case is it easy to get values out of a
> 'sysconfig' file in to the right place.
Yes... it is messy...

>
> I cannot really think of a better solution than an 'nfs-lock' service which
> sets these values, so I'll probably add it.
Well it could be part the the nfs-client.target...

>>
>> Overall it looks reasonable... But this is a change
>> of ABI... so it will be painful... :-(
>
> What exactly is changing that will be painful? I would certainly like to
> arrange the unit files to minimise your pain as much as possible, as long as
> it doesn't compromise effectiveness.
As I've already alluded to, people have built scripts around the
old sysv scripts... when all that changes... all those scripts break.
Which is the reason why I think we should maintain the old service
interface... at least for a while...

Question: Do all the distro's install the systemd scripts in the
same place? /usr/lib/systemd/system??

Do even need to install them? Maybe just let the distro deal with them?

steved.

2014-01-31 16:15:37

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On 01/30/2014 05:14 PM, NeilBrown wrote:
> On Thu, 30 Jan 2014 15:06:34 -0500 Steve Dickson <[email protected]> wrote:
>>> diff --git a/systemd/README b/systemd/README
>>> new file mode 100644
>>> index 000000000000..f0fb68825499
>>> --- /dev/null
>>> +++ b/systemd/README
>>> @@ -0,0 +1,50 @@
>>> +
>>> +Notes about systemd unit files for nfs-utils.
>>> +
>>> +The unit files provided here should be sufficient for systemd
>>> +to manage all daemons and related services provides by nfs-utils.
>>> +
>>> +They do *not* include any unit files for separate services such as
>>> +rpc.rquotad (in the 'quota' package) or rpcbind.
>>> +
>>> +There are 4 units that can be 'enabled' or 'disabled' by systemctl, or
>>> +by a suitable 'preset' setting:
>>> +
>>> + nfs-server.target
>>> + If enabled, nfs service is started together with dependencies
>>> + such as mountd, statd, rpc.idmapd
>>> +
>>> + nfs-client.target
>>> + If enabled, daemons needs for an nfs client are enabled.
>>> + This does *not* include rpc.statd. the rpc-statd.service unit
>>> + is started by /usr/sbin/start-statd which mount.nfs will run
>>> + if statd is needed.
>>> +
>>> + nfs-secure.target
>>> + If enabled, then rpc.gssd will be run when either -client or
>>> + -server is started, and rpc.svcgssd will be run when -server
>>> + is started
>>> +
>>> + nfs-blkmap.target
>>> + If enabled, then blkmapd will be run when nfs-client.target is
>>> + started.
We should also somehow document the targets we come up with. That
was some of the frustration that was expressed when we move
to systemd... It was not so much the changes it was the fact there
was no documentation describing the changes...

Also note I've separated out each file into a separate commit.
I thought it would be easier to review that way...
Those commits are on the systemd branch in my git tree:

git://linux-nfs.org/~steved/nfs-utils systemd

Finally... Who well are these tested? :-)

steved.

2014-01-30 23:17:32

by Jim Rees

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

NeilBrown wrote:

Though I do wonder if it would every be used. Would *anyone* build nfs-utils
with a non-standard prefix, and also get systemd to manage that version?

Some of the other paths, like this one (note the typo too) might need to
change.

/usr/lib/systemd/scritps/nfs-utils_env.sh

2014-02-05 21:11:10

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Wed, Feb 05, 2014 at 04:43:51PM +1100, NeilBrown wrote:
> On Tue, 04 Feb 2014 13:26:42 -0500 Steve Dickson <[email protected]> wrote:
>
>
> > >
> > >>
> > >> How would these daemons be restart and shutdown? Since this is a
> > >> target, systemctl restart and system stop don't do anything.
> > >
> > > This is something I haven't completely figured out yet.
> > >
> > > Part of the solution might be the "PartOf" directive.
> > > If each service claims to be "PartOf" the main one, then stopping or
> > > restarting the main service will propagate to stopping and restarting the
> > > individual services.
> > > Unfortunately in nfs we have some shared services. rpc.statd and rpc.gssd
> > > are needed by both server and client. That isn't a big problem for 'restart',
> > > but if you 'systemctl stop nfs-client' and find that the server isn't
> > > properly working any more, that would be awkward
> > > If could possibly work around that by setting "StopWhenUnneeded" for those
> > > shared services. Then e.g. rpc.statd would stop when both client and server
> > > are stopped, but not if either one of them is stopped.
> > > However I don't know how that interacts with restart. I suspect that the
> > > StopWhenUnneeded services are *not* stopped and restarted when the main
> > > service is stopped. So it would be hard to restart all nfs services on an
> > > upgrade.
> > >
> > > Further research seems needed here.
> > Fine... I'll try to digest what you are saying here, but
> > would it make it easier if everything was in a service file?
>
> So I did a bit more research and thinking, and I present the two patches
> below for consideration. If you agree and would prefer them in separate
> emails I can certainly do that.
>
> The first ensures that we can easily restart all daemons during software
> update. It creates a new 'nfs-utils.service' which exists only to allow that
> restart.
>
> The second ensures startup and shutdown work properly (though I haven't
> tested much).
> Do we need to shutdown nfs-server or nfs-client easily at any time other than
> system shutdown?

I think it's hard to as I don't think there's a way for the NSM protocol
to treat the nfs client and server as different things that could go up
and down independently. But I could be wrong, I rarely think about
statd! In a v4-only setup that wouldn't be a problem any more.

On the server side there are a few parameters (v4 lease time?) that can
only be changed with a restart but maybe that's not terribly important.

HA people may restart the server on failover to get a new grace period.
They probably use their own scripts for that but it would be better to
get them using standard systemd configuration to the extent possible.

Anyway those are existing problems that it's not necessarily up to you
to fix.

--b.

>
> Thanks,
>
> NeilBrown
>
> From 0d880d8faf4db7189c11fc13854da82074c260ac Mon Sep 17 00:00:00 2001
> From: Neil Brown <[email protected]>
> Date: Wed, 5 Feb 2014 16:28:47 +1100
> Subject: [PATCH] systemd: add nfs-utils.service which can be used to restart
> everything.
>
> With this patch,
> systemctl restart nfs-utils
> will restart any nfs-utils daemons that are currently running, whether
> there were started via nfs-server.service, nfs-client.target, or
> directly by systemctl.
>
> Signed-off-by: NeilBrown <[email protected]>
>
> diff --git a/systemd/README b/systemd/README
> index d697cefbe229..8359530098f4 100644
> --- a/systemd/README
> +++ b/systemd/README
> @@ -28,6 +28,17 @@ by a suitable 'preset' setting:
> If enabled, then blkmapd will be run when nfs-client.target is
> started.
>
> +Another special unit is "nfs-utils.service". This doesn't really do
> +anything, but exists so that other units may declare themselves as
> +"PartOf" nfs-utils.service.
> +The effect of this is that
> + systemctl restart nfs-utils
> +will restart all nfs-utils daemons as maybe be required during
> +software update. It isn't possible to make
> + systemctl try-restart nfs-server nfs-client.target
> +do this as some daemon are included in both, and rpc.statd would
> +not be restarted if nfs-server were not active (as nfs-client doesn't
> +Want it - it is started by mount.nfs running start-statd).
>
> It is possible that we should have an nfs-statd.target which can
> selectively enable statd being stared by -server and sm-notify
> diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
> index 7319a88661cc..80033f2fbcf4 100644
> --- a/systemd/nfs-blkmap.service
> +++ b/systemd/nfs-blkmap.service
> @@ -6,6 +6,8 @@ Requires=var-lib-nfs-rpc_pipefs.mount
> Requisite=nfs-blkmap.target
> After=nfs-blkmap.target
>
> +PartOf=nfs-utils.service
> +
> [Service]
> Type=forking
> ExecStart=/usr/sbin/blkmapd
> diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
> index 6c2e1537f064..7d0dd84d8a44 100644
> --- a/systemd/nfs-idmapd.service
> +++ b/systemd/nfs-idmapd.service
> @@ -1,6 +1,8 @@
> [Unit]
> Description=NFSv4 ID-name mapping service
>
> +PartOf=nfs-utils.service
> +
> [Service]
> EnvironmentFile=-/run/sysconfig/nfs-utils
> ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
> index 92e05ca309ee..90746a854b40 100644
> --- a/systemd/nfs-mountd.service
> +++ b/systemd/nfs-mountd.service
> @@ -4,6 +4,7 @@ Requires=proc-fs-nfsd.mount
> After=proc-fs-nfsd.mount
> After=network.target
> PartOf=nfs-server.service
> +PartOf=nfs-utils.service
>
> [Service]
> EnvironmentFile=-/run/sysconfig/nfs-utils
> diff --git a/systemd/nfs-utils.service b/systemd/nfs-utils.service
> new file mode 100644
> index 000000000000..54b6314d8d52
> --- /dev/null
> +++ b/systemd/nfs-utils.service
> @@ -0,0 +1,17 @@
> +[Unit]
> +Description=NFS server and client services
> +# This service should never be stopped, only restarted.
> +# When it is re-started, all other services which declare
> +# themselves to be "PartOf" this service will also be
> +# restarted. Thus
> +# systemctl restart nfs-utils
> +# will restart all daemons which are part of nfs-utils
> +# and which are running. This is useful after a software
> +# update.
> +
> +# This is a "service" rather than "target" so that we
> +# don't need to say "systemctl restart nfs-utils.target".
> +[Service]
> +Type=oneshot
> +RemainAfterExit=yes
> +ExecStart=/bin/true
> diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
> index 8778c3ef651b..3982985762ea 100644
> --- a/systemd/rpc-gssd.service
> +++ b/systemd/rpc-gssd.service
> @@ -5,6 +5,8 @@ After=var-lib-nfs-rpc_pipefs.mount
>
> ConditionPathExists=/etc/krb5.keytab
>
> +PartOf=nfs-utils.service
> +
> [Service]
> EnvironmentFile=-/run/sysconfig/nfs-utils
> ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
> index 9d972fc7753a..532354d64fa0 100644
> --- a/systemd/rpc-statd-notify.service
> +++ b/systemd/rpc-statd-notify.service
> @@ -8,6 +8,8 @@ After=network-online.target nss-lookup.target
> # tell clients that it has restarted.
> After=nfs-server.service
>
> +PartOf=nfs-utils.service
> +
> [Service]
> EnvironmentFile=-/run/sysconfig/nfs-utils
> ExecStartPre=/usr/lib/systemd/scritps/nfs-utils_env.sh
> diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
> index 04962e542fbc..88d2527cae9d 100644
> --- a/systemd/rpc-statd.service
> +++ b/systemd/rpc-statd.service
> @@ -4,6 +4,8 @@ DefaultDependencies=no
> Requires=nss-lookup.target rpcbind.target
> After=network.target nss-lookup.target rpcbind.target
>
> +PartOf=nfs-utils.service
> +
> [Service]
> EnvironmentFile=-/run/sysconfig/nfs-utils
> ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service
> index 036ec579bfc1..6bd45884d991 100644
> --- a/systemd/rpc-svcgssd.service
> +++ b/systemd/rpc-svcgssd.service
> @@ -3,6 +3,7 @@ Description=RPC security service for NFS server
> Requires=var-lib-nfs-rpc_pipefs.mount
> After=var-lib-nfs-rpc_pipefs.mount
> PartOf=nfs-server.service
> +PartOf=nfs-utils.service
>
> After=gssproxy.service
> ConditionPathExists=|!@localstatedir@/run/gssproxy.pid
>
>
>
>
>
>
>
> From 30b27a718632e9d24c479921b116d2c3958a3fc2 Mon Sep 17 00:00:00 2001
> From: Neil Brown <[email protected]>
> Date: Wed, 5 Feb 2014 16:36:21 +1100
> Subject: [PATCH] systemd: tidy up DefaultDependencies
>
> DefaultDependencies should be "yes" (the default) for things
> needed only be the NFS server, as that is a service that doesn't
> need to start early.
>
> DefaultDependencies should be "no" for things needed to mount an
> NFS filesystem, and filesystems are mounted before basic.target.
> To ensure these services are shut down in a timely fashion, they
> must Conflict with systemd.umount so they are shutdown when everything
> is unmounted.
>
> Signed-off-by: NeilBrown <[email protected]>
>
> diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
> index 80033f2fbcf4..4b74e9f61454 100644
> --- a/systemd/nfs-blkmap.service
> +++ b/systemd/nfs-blkmap.service
> @@ -1,5 +1,7 @@
> [Unit]
> Description=pNFS block layout mapping daemon
> +DefaultDependencies=no
> +Conflicts=umount.target
> After=var-lib-nfs-rpc_pipefs.mount
> Requires=var-lib-nfs-rpc_pipefs.mount
>
> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> index 6ba2fc0f346e..5779fd39ed34 100644
> --- a/systemd/nfs-server.service
> +++ b/systemd/nfs-server.service
> @@ -1,6 +1,5 @@
> [Unit]
> Description=NFS server and services
> -DefaultDependencies=no
> 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
> diff --git a/systemd/proc-fs-nfsd.mount b/systemd/proc-fs-nfsd.mount
> index f44d52f3d67b..931a5ceeb055 100644
> --- a/systemd/proc-fs-nfsd.mount
> +++ b/systemd/proc-fs-nfsd.mount
> @@ -1,6 +1,5 @@
> [Unit]
> Description=NFSD configuration filesystem
> -DefaultDependencies=no
>
> [Mount]
> What=nfsd
> diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
> index 3982985762ea..375792804247 100644
> --- a/systemd/rpc-gssd.service
> +++ b/systemd/rpc-gssd.service
> @@ -1,5 +1,7 @@
> [Unit]
> Description=RPC security service for NFS client and server
> +DefaultDependencies=no
> +Conflicts=umount.target
> Requires=var-lib-nfs-rpc_pipefs.mount
> After=var-lib-nfs-rpc_pipefs.mount
>
> diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
> index 532354d64fa0..7742ac8c5d9a 100644
> --- a/systemd/rpc-statd-notify.service
> +++ b/systemd/rpc-statd-notify.service
> @@ -1,6 +1,5 @@
> [Unit]
> Description=Notify NFS peers of a restart
> -DefaultDependencies=no
> Requires=network-online.target
> After=network-online.target nss-lookup.target
>
> diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
> index 88d2527cae9d..3f6cda16accd 100644
> --- a/systemd/rpc-statd.service
> +++ b/systemd/rpc-statd.service
> @@ -1,6 +1,7 @@
> [Unit]
> Description=NFS status monitor for NFSv2/3 locking.
> DefaultDependencies=no
> +Conflicts=umount.target
> Requires=nss-lookup.target rpcbind.target
> After=network.target nss-lookup.target rpcbind.target
>
> diff --git a/systemd/var-lib-nfs-rpc_pipefs.mount b/systemd/var-lib-nfs-rpc_pipefs.mount
> index cd614cf49f00..33c5db65aa38 100644
> --- a/systemd/var-lib-nfs-rpc_pipefs.mount
> +++ b/systemd/var-lib-nfs-rpc_pipefs.mount
> @@ -1,6 +1,7 @@
> [Unit]
> Description=RPC Pipe File System
> DefaultDependencies=no
> +Conflicts=umount.target
>
> [Mount]
> What=sunrpc

2014-02-11 16:48:05

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On 02/11/2014 11:37 AM, J. Bruce Fields wrote:
> On Tue, Feb 11, 2014 at 03:50:52PM +1100, NeilBrown wrote:
>> On Mon, 10 Feb 2014 15:50:41 -0500 Steve Dickson <[email protected]> wrote:
>>
>>> On 02/06/2014 11:19 AM, J. Bruce Fields wrote:
>>>> On Thu, Feb 06, 2014 at 11:09:58AM -0500, Chuck Lever wrote:
>>>>>
>>>>> On Feb 5, 2014, at 8:27 PM, NeilBrown <[email protected]> wrote:
>>>>>> I certainly agree with making things simple. If we can make a configuration
>>>>>> irrelevant, e.g. by gets nfsd to auto-tune the number of threads so the
>>>>>> setting becomes pointless, then I've very happy to remove that sort of
>>>>>> configuration. But if a configuration option actually means something I
>>>>>> certainly don't want to remove it.
>>>>>>
>>>>>> So I'm leaning towards having "systemctl {un,}mask rpc-gssd" be the
>>>>>> configuration tool for rpc.gssd.
>>>>>
>>>>> I like that better than the “off-until-requested” behavior we have currently. IMO folks who want to disable rpc.gssd will be in the increasing minority and the rest of the world will take scant notice of the extra daemon, as long as we ensure it speaks only when necessary.
>>>>
>>>> I'd also prefer running the gssd's by default: one less (confusing) step
>>>> to set up kerberos, and I'm not seeing a realistic security risk.
>>> I'm not for starting daemon that are not needed or necessary. I
>>> just think that is a bad design.
>>>
>>>>
>>>> If we can easily provide a way to turn it off for people that want a
>>>> really stripped-down system for whatever reason, fine, let's provide
>>>> that.
>>> I'm thinking just the opposite... Have a way to easily (or even
>>> automatically) way to enabled NFS security.... when needed...
>>>
>>> Would it make it easier if we combined the gssd daemon? That goes
>>> both ways (server and client)... That way we could just enable
>>> nfs security and the daemon would started regardless on what side
>>> its on...
>>>
>>> steved.
>>
>> By "combine" do you mean "rewrite the code so there is only one process" or
>> "have a systemd unit which starts both"? The former seems like a lot of
>> pointless work and the later contradicts your stated preference for not
>> starting daemons that are not needed.
>
> Note the client needs svcgssd or gss-proxy too, if you want it to be
> able to get delegations over NFSv4.0. (It doesn't matter for versions
> 2, 3, or >=4.1).
Even when kerberos is not configured?

>
> I still pretty vague on exactly what problems we solve by turning off
> these daemons by default.
To keep things simple.... I just see the point of starting a daemon
if its known its not going to be needed...

steved.
>
> --b.
>
>>
>> What do you think of the suggestion to start rpc.gssd when Wanted
>> if /etc/krb5.conf exists, and document that it can be disabled with
>>
>> systemctl mask rpc-gssd
>>
>> (I like your idea of clearly documenting the important systemd units).
>> That way it is running when needed, probably not when not, and if you happen
>> to have kerberos installed but don't want rpc.gssd, it is easy to achieve
>> that.
>>
>> NeilBrown
>
>

2014-02-11 20:12:39

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On 02/11/2014 11:56 AM, J. Bruce Fields wrote:
> On Tue, Feb 11, 2014 at 11:47:56AM -0500, Steve Dickson wrote:
>>
>>
>> On 02/11/2014 11:37 AM, J. Bruce Fields wrote:
>>> On Tue, Feb 11, 2014 at 03:50:52PM +1100, NeilBrown wrote:
>>>> On Mon, 10 Feb 2014 15:50:41 -0500 Steve Dickson <[email protected]> wrote:
>>>>
>>>>> On 02/06/2014 11:19 AM, J. Bruce Fields wrote:
>>>>>> On Thu, Feb 06, 2014 at 11:09:58AM -0500, Chuck Lever wrote:
>>>>>>>
>>>>>>> On Feb 5, 2014, at 8:27 PM, NeilBrown <[email protected]> wrote:
>>>>>>>> I certainly agree with making things simple. If we can make a configuration
>>>>>>>> irrelevant, e.g. by gets nfsd to auto-tune the number of threads so the
>>>>>>>> setting becomes pointless, then I've very happy to remove that sort of
>>>>>>>> configuration. But if a configuration option actually means something I
>>>>>>>> certainly don't want to remove it.
>>>>>>>>
>>>>>>>> So I'm leaning towards having "systemctl {un,}mask rpc-gssd" be the
>>>>>>>> configuration tool for rpc.gssd.
>>>>>>>
>>>>>>> I like that better than the “off-until-requested” behavior we have currently. IMO folks who want to disable rpc.gssd will be in the increasing minority and the rest of the world will take scant notice of the extra daemon, as long as we ensure it speaks only when necessary.
>>>>>>
>>>>>> I'd also prefer running the gssd's by default: one less (confusing) step
>>>>>> to set up kerberos, and I'm not seeing a realistic security risk.
>>>>> I'm not for starting daemon that are not needed or necessary. I
>>>>> just think that is a bad design.
>>>>>
>>>>>>
>>>>>> If we can easily provide a way to turn it off for people that want a
>>>>>> really stripped-down system for whatever reason, fine, let's provide
>>>>>> that.
>>>>> I'm thinking just the opposite... Have a way to easily (or even
>>>>> automatically) way to enabled NFS security.... when needed...
>>>>>
>>>>> Would it make it easier if we combined the gssd daemon? That goes
>>>>> both ways (server and client)... That way we could just enable
>>>>> nfs security and the daemon would started regardless on what side
>>>>> its on...
>>>>>
>>>>> steved.
>>>>
>>>> By "combine" do you mean "rewrite the code so there is only one process" or
>>>> "have a systemd unit which starts both"? The former seems like a lot of
>>>> pointless work and the later contradicts your stated preference for not
>>>> starting daemons that are not needed.
>>>
>>> Note the client needs svcgssd or gss-proxy too, if you want it to be
>>> able to get delegations over NFSv4.0. (It doesn't matter for versions
>>> 2, 3, or >=4.1).
>> Even when kerberos is not configured?
>
> No. So an attempt to summarize:
> - not using kerberos? You don't need any daemons.
> - using kerberos, NFS version 2, 3, or >=4.1? You need rpc.gssd
> on the client, and rpc.svcgssd (or gss-proxy) on the server.
> - using kerberos, NFS version 4.0, care about delegations
> working? You need both rpc.gssd and rpc.svcgssd (or
> gss-proxy) on both server and client.
Thanks for the summary...

>
>>> I still pretty vague on exactly what problems we solve by turning off
>>> these daemons by default.
>> To keep things simple....
>
> "Always start" is simpler logic than, say, "start if /etc/krb5.conf is
> available".
Point... but I still think we can do better than that...

steved.

>
> --b.
>

2014-02-05 03:09:19

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields" <[email protected]>
wrote:

> On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote:
> > On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <[email protected]> wrote:
> > > Also how does gss-proxy come to play in all this? Maybe we
> > > just use gss-proxy by default and retire rpc.svcgssd.
> >
> > I haven't really be following and so am only dimly aware of gss-proxy.
> > It's a replacement for rpc.svcgssd - right?
> > So we should get it to start in the same circumstances as rpc.svcgssd?
> >
> > Is there some easy test - eg something existing in the filesystem - that we
> > could use to see if the kernel supports gss-proxy ?
>
> There's a /proc/net/rpc/use-gss-proxy file.
>
> (But doesn't gss-proxy have users other than nfsd?)

So presumably gss-proxy would come with its own unit file (looks ... oh yes,
it does. awesome), and we only want to start rpc.svcgssd if:
- gss-proxy is not active
- /etc/krpb5.keytab is present.

The second is easy to test in a unit file, an 'and' is generally trivial, but
testing if another unit is *not* present is not.
There is "Requisite" to test if it is, but you cannot do
"Requisite=!gssproxy.service"
or
"ConditionUnitStarted=!gssproxy.service"
or anything similar that I can find.

"Conflicts=gss-proxy.service" is closest, but that might cause
gss-proxy.service to stop.

Maybe we have to manage testing the .pid file thus:

After=gssproxy.service
ConditionPathExists=|!@localstatedir@/run/gssproxy.pid
ConditionPathExists=|!/proc/net/rpc/use-gss-proxy
ConditionPathExists=/etc/krb5.keytab

so we wait until the gssproxy.service has started if it will be starting at
all, then look for the pid file and if it is missing, or if use-gss-proxy is
missing, we run rpc.svcgssd, providing /etc/krb5.keytab is present.

>
> > Also, I've been wondering if we could avoid the need to explicitly enable
> > the gss stuff by gating it on the existence of /etc/krb5.keytab.
> > Do you think that would be reasonable?
>
> That would be great. I hate that people have to care about these
> support daemons, they should just be started automatically when they're
> needed.
>
> Is /etc/krb5.keytab the best indicator?

I was hoping you would tell me. :-)

It occurred to me as a good test when I tried running rpc.svcgssd in a fresh
VM and it wouldn't start. I eventually found the error message complaining
that it couldn't find that file.

It isn't perfect as an empty /etc/krb5.keytab will still result in failure
and exit. However if a sysadmin has created a keytab and is using NFS, it
seems reasonable to be ready to provide gss services.

rpc.gssd doesn't fail in the same way, but it does complain if the file
doesn't exist, so I suspect it is at least a good indicator.

The only thing that bothers me is that gssd is theoretically more general
than krb5. However as the reality seems to be that it is exactly krb5, I
don't let that bother me too much.

>
> Simplest might be to start unconditionally and just not care if it
> fails. Or is there a problem cluttering up logs with unimportant
> failures?

More a problem with starting things that aren't necessary, and possibly
leaving them running.
Every process you start adds a little to the boot time. We only get the best
experience if everyone contributes a little bit, no matter how little.
Also, every running process theoretically adds the to the attack service.
So some people will definitely not want these processes to be started. If we
make it really easy for them, I think that is a good thing.
i.e. I agree with SteveD:
> I think we want to stay away (and move away) from unconditionally
> starting anything...

Thanks,
NeilBrown

Attachments:

signature.asc (828.00 B)

2014-02-11 04:51:04

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Mon, 10 Feb 2014 15:50:41 -0500 Steve Dickson <[email protected]> wrote:

> On 02/06/2014 11:19 AM, J. Bruce Fields wrote:
> > On Thu, Feb 06, 2014 at 11:09:58AM -0500, Chuck Lever wrote:
> >>
> >> On Feb 5, 2014, at 8:27 PM, NeilBrown <[email protected]> wrote:
> >>> I certainly agree with making things simple. If we can make a configuration
> >>> irrelevant, e.g. by gets nfsd to auto-tune the number of threads so the
> >>> setting becomes pointless, then I've very happy to remove that sort of
> >>> configuration. But if a configuration option actually means something I
> >>> certainly don't want to remove it.
> >>>
> >>> So I'm leaning towards having "systemctl {un,}mask rpc-gssd" be the
> >>> configuration tool for rpc.gssd.
> >>
> >> I like that better than the “off-until-requested” behavior we have currently. IMO folks who want to disable rpc.gssd will be in the increasing minority and the rest of the world will take scant notice of the extra daemon, as long as we ensure it speaks only when necessary.
> >
> > I'd also prefer running the gssd's by default: one less (confusing) step
> > to set up kerberos, and I'm not seeing a realistic security risk.
> I'm not for starting daemon that are not needed or necessary. I
> just think that is a bad design.
>
> >
> > If we can easily provide a way to turn it off for people that want a
> > really stripped-down system for whatever reason, fine, let's provide
> > that.
> I'm thinking just the opposite... Have a way to easily (or even
> automatically) way to enabled NFS security.... when needed...
>
> Would it make it easier if we combined the gssd daemon? That goes
> both ways (server and client)... That way we could just enable
> nfs security and the daemon would started regardless on what side
> its on...
>
> steved.

By "combine" do you mean "rewrite the code so there is only one process" or
"have a systemd unit which starts both"? The former seems like a lot of
pointless work and the later contradicts your stated preference for not
starting daemons that are not needed.

What do you think of the suggestion to start rpc.gssd when Wanted
if /etc/krb5.conf exists, and document that it can be disabled with

systemctl mask rpc-gssd

(I like your idea of clearly documenting the important systemd units).
That way it is running when needed, probably not when not, and if you happen
to have kerberos installed but don't want rpc.gssd, it is easy to achieve
that.

NeilBrown

Attachments:

signature.asc (828.00 B)

2014-02-06 12:32:26

by Simo Sorce

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

----- Original Message -----
> On 02/04/2014 11:20 AM, J. Bruce Fields wrote:
> > On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote:
> >> On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <[email protected]>
> >> wrote:
> >>> Also how does gss-proxy come to play in all this? Maybe we
> >>> just use gss-proxy by default and retire rpc.svcgssd.
> >>
> >> I haven't really be following and so am only dimly aware of gss-proxy.
> >> It's a replacement for rpc.svcgssd - right?
> >> So we should get it to start in the same circumstances as rpc.svcgssd?
> >>
> >> Is there some easy test - eg something existing in the filesystem - that
> >> we
> >> could use to see if the kernel supports gss-proxy ?
> >
> > There's a /proc/net/rpc/use-gss-proxy file.
> hmm... I forget... who set this... gssproxy daemon?

If gss-proxy is configured to provide the kernel nfsd socket (it does by default)
then it writes to it at startup.

--
Simo Sorce * Red Hat, Inc. * New York

2014-02-11 12:56:35

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

Sorry for the delayed response... I got suck into another world... ;-(

On 02/04/2014 10:55 PM, NeilBrown wrote:
> On Tue, 04 Feb 2014 13:26:42 -0500 Steve Dickson <[email protected]> wrote:
>>>>
>>>> How is rpc.svcgssd enabled? Since the .service file does
>>>> not have a [Install] section the systemctl enable rpc.svcgssd
>>>> fails.
>>>
>>> The "README" touches on this. If you
>>> systemctl enable nfs-secure.target
>>> then rpc.svcgssd will be run whenever nfs-server.target is started.
>> I was thinking nfs-server would only start rpc.svcgssd when its
>> enabled... not every time...
>
> I don't follow what you are saying ... not that it really matters as we both
> seem to be agreed to take a different approach with the gss daemons.
>
> In my original plan:
> if nfs-secure is enabled, then whenever nfs-server is started, it makes sure
> that rpc.svcgssd is running.
> if nfs-secure is not enabled, then rpc.svcgssd will refuse to start.
Understood... and that's good...

>
>
>>
>>> Also rpc.gssd will be run whenever nfs-server.target or nfs-client.target is
>>> started.
>> Why is rpc.gssd started when the nfs server is started? Possibly for secure
>> loopback mounts??
>
> Call-backs from NFSv4.0 server, as has been mentioned elsewhere.
But kerberos has to be configure... but I think we are talking
about that in a another thread...

>
>>
>>>
>>>>
>>>> How would these daemons be restart and shutdown? Since this is a
>>>> target, systemctl restart and system stop don't do anything.
>>>
>>> This is something I haven't completely figured out yet.
>>>
>>> Part of the solution might be the "PartOf" directive.
>>> If each service claims to be "PartOf" the main one, then stopping or
>>> restarting the main service will propagate to stopping and restarting the
>>> individual services.
>>> Unfortunately in nfs we have some shared services. rpc.statd and rpc.gssd
>>> are needed by both server and client. That isn't a big problem for 'restart',
>>> but if you 'systemctl stop nfs-client' and find that the server isn't
>>> properly working any more, that would be awkward
>>> If could possibly work around that by setting "StopWhenUnneeded" for those
>>> shared services. Then e.g. rpc.statd would stop when both client and server
>>> are stopped, but not if either one of them is stopped.
>>> However I don't know how that interacts with restart. I suspect that the
>>> StopWhenUnneeded services are *not* stopped and restarted when the main
>>> service is stopped. So it would be hard to restart all nfs services on an
>>> upgrade.
>>>
>>> Further research seems needed here.
>> Fine... I'll try to digest what you are saying here, but
>> would it make it easier if everything was in a service file?
>
> No, the only way the .target files are more awkward is that you have to type
> ".target".
>
> In fact a .target can be turned into an .service by adding:
>
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/true
>
> at the end. You might even get away with less than that.
> Given this and that ".target" is extra typing, there seems little reason to
> use .target unit files.
So are you saying are not going use .target units? They will all be .service units?

>
>>
>>>
>>>
>>>>
>>>>> +
>>>>> + nfs-secure.target
>>>>> + If enabled, then rpc.gssd will be run when either -client or
>>>>> + -server is started, and rpc.svcgssd will be run when -server
>>>>> + is started
>>>> I like that fact that rpc.gssd is started by nfs-client but
>>>> I don't like that API change. systemctl restart nfs-secure breaks
>>>
>>> Why would you want to "restart nfs-secure". I can understanding wanting to
>>> restart individual processed, or the whole collection, but why that subset?
>> Well in Fedora nfs-secure is one process ;-)
>
> Oh yes, "nfs-secure" means "run rpc.gssd".
> If you wanted to preserve that I think you could create a drop-in file
> for rpc-gssd.service containing
> [Install]
> Alias=nfs-secure.service
> though that would require "systemctl enable rpc-gssd" so maybe it isn't the
> best approach.
If I'm understanding this and above... systemctl enable nfs-secure would
be controlling the starting up of both rpc.gssd and rpc.svcgssd/gss-proxy?

steved.

2014-02-05 05:44:04

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Tue, 04 Feb 2014 13:26:42 -0500 Steve Dickson <[email protected]> wrote:

> >
> >>
> >> How would these daemons be restart and shutdown? Since this is a
> >> target, systemctl restart and system stop don't do anything.
> >
> > This is something I haven't completely figured out yet.
> >
> > Part of the solution might be the "PartOf" directive.
> > If each service claims to be "PartOf" the main one, then stopping or
> > restarting the main service will propagate to stopping and restarting the
> > individual services.
> > Unfortunately in nfs we have some shared services. rpc.statd and rpc.gssd
> > are needed by both server and client. That isn't a big problem for 'restart',
> > but if you 'systemctl stop nfs-client' and find that the server isn't
> > properly working any more, that would be awkward
> > If could possibly work around that by setting "StopWhenUnneeded" for those
> > shared services. Then e.g. rpc.statd would stop when both client and server
> > are stopped, but not if either one of them is stopped.
> > However I don't know how that interacts with restart. I suspect that the
> > StopWhenUnneeded services are *not* stopped and restarted when the main
> > service is stopped. So it would be hard to restart all nfs services on an
> > upgrade.
> >
> > Further research seems needed here.
> Fine... I'll try to digest what you are saying here, but
> would it make it easier if everything was in a service file?

So I did a bit more research and thinking, and I present the two patches
below for consideration. If you agree and would prefer them in separate
emails I can certainly do that.

The first ensures that we can easily restart all daemons during software
update. It creates a new 'nfs-utils.service' which exists only to allow that
restart.

The second ensures startup and shutdown work properly (though I haven't
tested much).
Do we need to shutdown nfs-server or nfs-client easily at any time other than
system shutdown?

Thanks,

NeilBrown

From 0d880d8faf4db7189c11fc13854da82074c260ac Mon Sep 17 00:00:00 2001
From: Neil Brown <[email protected]>
Date: Wed, 5 Feb 2014 16:28:47 +1100
Subject: [PATCH] systemd: add nfs-utils.service which can be used to restart
everything.

With this patch,
systemctl restart nfs-utils
will restart any nfs-utils daemons that are currently running, whether
there were started via nfs-server.service, nfs-client.target, or
directly by systemctl.

Signed-off-by: NeilBrown <[email protected]>

diff --git a/systemd/README b/systemd/README
index d697cefbe229..8359530098f4 100644
--- a/systemd/README
+++ b/systemd/README
@@ -28,6 +28,17 @@ by a suitable 'preset' setting:
If enabled, then blkmapd will be run when nfs-client.target is
started.

+Another special unit is "nfs-utils.service". This doesn't really do
+anything, but exists so that other units may declare themselves as
+"PartOf" nfs-utils.service.
+The effect of this is that
+ systemctl restart nfs-utils
+will restart all nfs-utils daemons as maybe be required during
+software update. It isn't possible to make
+ systemctl try-restart nfs-server nfs-client.target
+do this as some daemon are included in both, and rpc.statd would
+not be restarted if nfs-server were not active (as nfs-client doesn't
+Want it - it is started by mount.nfs running start-statd).

It is possible that we should have an nfs-statd.target which can
selectively enable statd being stared by -server and sm-notify
diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
index 7319a88661cc..80033f2fbcf4 100644
--- a/systemd/nfs-blkmap.service
+++ b/systemd/nfs-blkmap.service
@@ -6,6 +6,8 @@ Requires=var-lib-nfs-rpc_pipefs.mount
Requisite=nfs-blkmap.target
After=nfs-blkmap.target

+PartOf=nfs-utils.service
+
[Service]
Type=forking
ExecStart=/usr/sbin/blkmapd
diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
index 6c2e1537f064..7d0dd84d8a44 100644
--- a/systemd/nfs-idmapd.service
+++ b/systemd/nfs-idmapd.service
@@ -1,6 +1,8 @@
[Unit]
Description=NFSv4 ID-name mapping service

+PartOf=nfs-utils.service
+
[Service]
EnvironmentFile=-/run/sysconfig/nfs-utils
ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
index 92e05ca309ee..90746a854b40 100644
--- a/systemd/nfs-mountd.service
+++ b/systemd/nfs-mountd.service
@@ -4,6 +4,7 @@ Requires=proc-fs-nfsd.mount
After=proc-fs-nfsd.mount
After=network.target
PartOf=nfs-server.service
+PartOf=nfs-utils.service

[Service]
EnvironmentFile=-/run/sysconfig/nfs-utils
diff --git a/systemd/nfs-utils.service b/systemd/nfs-utils.service
new file mode 100644
index 000000000000..54b6314d8d52
--- /dev/null
+++ b/systemd/nfs-utils.service
@@ -0,0 +1,17 @@
+[Unit]
+Description=NFS server and client services
+# This service should never be stopped, only restarted.
+# When it is re-started, all other services which declare
+# themselves to be "PartOf" this service will also be
+# restarted. Thus
+# systemctl restart nfs-utils
+# will restart all daemons which are part of nfs-utils
+# and which are running. This is useful after a software
+# update.
+
+# This is a "service" rather than "target" so that we
+# don't need to say "systemctl restart nfs-utils.target".
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStart=/bin/true
diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
index 8778c3ef651b..3982985762ea 100644
--- a/systemd/rpc-gssd.service
+++ b/systemd/rpc-gssd.service
@@ -5,6 +5,8 @@ After=var-lib-nfs-rpc_pipefs.mount

ConditionPathExists=/etc/krb5.keytab

+PartOf=nfs-utils.service
+
[Service]
EnvironmentFile=-/run/sysconfig/nfs-utils
ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
index 9d972fc7753a..532354d64fa0 100644
--- a/systemd/rpc-statd-notify.service
+++ b/systemd/rpc-statd-notify.service
@@ -8,6 +8,8 @@ After=network-online.target nss-lookup.target
# tell clients that it has restarted.
After=nfs-server.service

+PartOf=nfs-utils.service
+
[Service]
EnvironmentFile=-/run/sysconfig/nfs-utils
ExecStartPre=/usr/lib/systemd/scritps/nfs-utils_env.sh
diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
index 04962e542fbc..88d2527cae9d 100644
--- a/systemd/rpc-statd.service
+++ b/systemd/rpc-statd.service
@@ -4,6 +4,8 @@ DefaultDependencies=no
Requires=nss-lookup.target rpcbind.target
After=network.target nss-lookup.target rpcbind.target

+PartOf=nfs-utils.service
+
[Service]
EnvironmentFile=-/run/sysconfig/nfs-utils
ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service
index 036ec579bfc1..6bd45884d991 100644
--- a/systemd/rpc-svcgssd.service
+++ b/systemd/rpc-svcgssd.service
@@ -3,6 +3,7 @@ Description=RPC security service for NFS server
Requires=var-lib-nfs-rpc_pipefs.mount
After=var-lib-nfs-rpc_pipefs.mount
PartOf=nfs-server.service
+PartOf=nfs-utils.service

After=gssproxy.service
ConditionPathExists=|!@localstatedir@/run/gssproxy.pid

From 30b27a718632e9d24c479921b116d2c3958a3fc2 Mon Sep 17 00:00:00 2001
From: Neil Brown <[email protected]>
Date: Wed, 5 Feb 2014 16:36:21 +1100
Subject: [PATCH] systemd: tidy up DefaultDependencies

DefaultDependencies should be "yes" (the default) for things
needed only be the NFS server, as that is a service that doesn't
need to start early.

DefaultDependencies should be "no" for things needed to mount an
NFS filesystem, and filesystems are mounted before basic.target.
To ensure these services are shut down in a timely fashion, they
must Conflict with systemd.umount so they are shutdown when everything
is unmounted.

Signed-off-by: NeilBrown <[email protected]>

diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
index 80033f2fbcf4..4b74e9f61454 100644
--- a/systemd/nfs-blkmap.service
+++ b/systemd/nfs-blkmap.service
@@ -1,5 +1,7 @@
[Unit]
Description=pNFS block layout mapping daemon
+DefaultDependencies=no
+Conflicts=umount.target
After=var-lib-nfs-rpc_pipefs.mount
Requires=var-lib-nfs-rpc_pipefs.mount

diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
index 6ba2fc0f346e..5779fd39ed34 100644
--- a/systemd/nfs-server.service
+++ b/systemd/nfs-server.service
@@ -1,6 +1,5 @@
[Unit]
Description=NFS server and services
-DefaultDependencies=no
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
diff --git a/systemd/proc-fs-nfsd.mount b/systemd/proc-fs-nfsd.mount
index f44d52f3d67b..931a5ceeb055 100644
--- a/systemd/proc-fs-nfsd.mount
+++ b/systemd/proc-fs-nfsd.mount
@@ -1,6 +1,5 @@
[Unit]
Description=NFSD configuration filesystem
-DefaultDependencies=no

[Mount]
What=nfsd
diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
index 3982985762ea..375792804247 100644
--- a/systemd/rpc-gssd.service
+++ b/systemd/rpc-gssd.service
@@ -1,5 +1,7 @@
[Unit]
Description=RPC security service for NFS client and server
+DefaultDependencies=no
+Conflicts=umount.target
Requires=var-lib-nfs-rpc_pipefs.mount
After=var-lib-nfs-rpc_pipefs.mount

diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
index 532354d64fa0..7742ac8c5d9a 100644
--- a/systemd/rpc-statd-notify.service
+++ b/systemd/rpc-statd-notify.service
@@ -1,6 +1,5 @@
[Unit]
Description=Notify NFS peers of a restart
-DefaultDependencies=no
Requires=network-online.target
After=network-online.target nss-lookup.target

diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
index 88d2527cae9d..3f6cda16accd 100644
--- a/systemd/rpc-statd.service
+++ b/systemd/rpc-statd.service
@@ -1,6 +1,7 @@
[Unit]
Description=NFS status monitor for NFSv2/3 locking.
DefaultDependencies=no
+Conflicts=umount.target
Requires=nss-lookup.target rpcbind.target
After=network.target nss-lookup.target rpcbind.target

diff --git a/systemd/var-lib-nfs-rpc_pipefs.mount b/systemd/var-lib-nfs-rpc_pipefs.mount
index cd614cf49f00..33c5db65aa38 100644
--- a/systemd/var-lib-nfs-rpc_pipefs.mount
+++ b/systemd/var-lib-nfs-rpc_pipefs.mount
@@ -1,6 +1,7 @@
[Unit]
Description=RPC Pipe File System
DefaultDependencies=no
+Conflicts=umount.target

[Mount]
What=sunrpc

Attachments:

signature.asc (828.00 B)

2014-02-04 13:24:30

by Jeff Layton

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Tue, 04 Feb 2014 06:42:12 -0600
Anthony Messina <[email protected]> wrote:

> On Monday, February 03, 2014 04:01:21 PM Steve Dickson wrote:
> > This changes the current API... Today to enable/start this service
> > today one does:
> >
> > systemctl enable nfs-server
> > systemctl start nfs-server
> >
> > which would change to:
> >
> > systemctl enable nfs-server.target
> > systemctl start nfs-server
> >
> > with the same daemons being started.
> > This changed will cause existing scripts to fail...
> > I guess I don't see the point of having a .target file.
> >
> > How is rpc.svcgssd enabled? Since the .service file does
> > not have a [Install] section the systemctl enable rpc.svcgssd
> > fails.
> >
> > Also how does gss-proxy come to play in all this? Maybe we
> > just use gss-proxy by default and retire rpc.svcgssd.
>
> Usually just a quite listener (end-user & small-time sysadmin) on this ML...
>
> +1 for gss-proxy by default (for Fedora anyway). I've been using it
> throughout F19 extensively in the KRB5/NFSv4.1 environment with great success.
> I have nfs-secure-server.service "masked" via systemd to prevent it from being
> started.
>
> There seems to be only one strange issue I've come across with gss-proxy vs.
> rpc.svcgssd: https://fedorahosted.org/gss-proxy/ticket/98. This is with
> regard to how access for the "nfsnobody" user is handled. The ticket attempts
> to show that with rpc.svcgssd, a host with host credentials and a user without
> credentials can still access NFS shares with 0755 directories and 0644 files
> (via the host credentials and mapped to the nfsnobody user). With gss-proxy,
> I had to create user credentials for kojibuilder@REALM because the access
> wasn't allowed via the nfsnobody path. I'm not sure if this is resolved, or
> by design, etc. But it is the only issue I've seen with gss-proxy vs.
> rpc.svcgssd.
>
> Thanks. -A
>

Please do open a bug at bugzilla.redhat.com for that and cc me on it.
We really do want to ensure that these sorts of corner-cases get
addressed.

--
Jeff Layton <[email protected]>

2014-02-04 16:30:29

by Chuck Lever III

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Feb 4, 2014, at 11:20 AM, J. Bruce Fields <[email protected]> wrote:

> On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote:
>> On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <[email protected]> wrote:
>>> Also how does gss-proxy come to play in all this? Maybe we
>>> just use gss-proxy by default and retire rpc.svcgssd.
>>
>> I haven't really be following and so am only dimly aware of gss-proxy.
>> It's a replacement for rpc.svcgssd - right?
>> So we should get it to start in the same circumstances as rpc.svcgssd?
>>
>> Is there some easy test - eg something existing in the filesystem - that we
>> could use to see if the kernel supports gss-proxy ?
>
> There's a /proc/net/rpc/use-gss-proxy file.
>
> (But doesn't gss-proxy have users other than nfsd?)
>
>> Also, I've been wondering if we could avoid the need to explicitly enable
>> the gss stuff by gating it on the existence of /etc/krb5.keytab.
>> Do you think that would be reasonable?
>
> That would be great. I hate that people have to care about these
> support daemons, they should just be started automatically when they're
> needed.

I agree 100%.

> Is /etc/krb5.keytab the best indicator?
>
> Simplest might be to start unconditionally and just not care if it
> fails. Or is there a problem cluttering up logs with unimportant
> failures?

IMO gssd should be started unconditionally, and we should make it quieter if needed.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

2014-02-13 19:40:00

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On 02/05/2014 12:43 AM, NeilBrown wrote:
> On Tue, 04 Feb 2014 13:26:42 -0500 Steve Dickson <[email protected]> wrote:
>
>
>>>
>>>>
>>>> How would these daemons be restart and shutdown? Since this is a
>>>> target, systemctl restart and system stop don't do anything.
>>>
>>> This is something I haven't completely figured out yet.
>>>
>>> Part of the solution might be the "PartOf" directive.
>>> If each service claims to be "PartOf" the main one, then stopping or
>>> restarting the main service will propagate to stopping and restarting the
>>> individual services.
>>> Unfortunately in nfs we have some shared services. rpc.statd and rpc.gssd
>>> are needed by both server and client. That isn't a big problem for 'restart',
>>> but if you 'systemctl stop nfs-client' and find that the server isn't
>>> properly working any more, that would be awkward
>>> If could possibly work around that by setting "StopWhenUnneeded" for those
>>> shared services. Then e.g. rpc.statd would stop when both client and server
>>> are stopped, but not if either one of them is stopped.
>>> However I don't know how that interacts with restart. I suspect that the
>>> StopWhenUnneeded services are *not* stopped and restarted when the main
>>> service is stopped. So it would be hard to restart all nfs services on an
>>> upgrade.
>>>
>>> Further research seems needed here.
>> Fine... I'll try to digest what you are saying here, but
>> would it make it easier if everything was in a service file?
>
> So I did a bit more research and thinking, and I present the two patches
> below for consideration. If you agree and would prefer them in separate
> emails I can certainly do that.
>
> The first ensures that we can easily restart all daemons during software
> update. It creates a new 'nfs-utils.service' which exists only to allow that
> restart.
>
> The second ensures startup and shutdown work properly (though I haven't
> tested much).
> Do we need to shutdown nfs-server or nfs-client easily at any time other than
> system shutdown?
>
> Thanks,
>
> NeilBrown
Committed both these patches to the systemd branch of my git tree....

steved.

>
> From 0d880d8faf4db7189c11fc13854da82074c260ac Mon Sep 17 00:00:00 2001
> From: Neil Brown <[email protected]>
> Date: Wed, 5 Feb 2014 16:28:47 +1100
> Subject: [PATCH] systemd: add nfs-utils.service which can be used to restart
> everything.
>
> With this patch,
> systemctl restart nfs-utils
> will restart any nfs-utils daemons that are currently running, whether
> there were started via nfs-server.service, nfs-client.target, or
> directly by systemctl.
>
> Signed-off-by: NeilBrown <[email protected]>
>
> diff --git a/systemd/README b/systemd/README
> index d697cefbe229..8359530098f4 100644
> --- a/systemd/README
> +++ b/systemd/README
> @@ -28,6 +28,17 @@ by a suitable 'preset' setting:
> If enabled, then blkmapd will be run when nfs-client.target is
> started.
>
> +Another special unit is "nfs-utils.service". This doesn't really do
> +anything, but exists so that other units may declare themselves as
> +"PartOf" nfs-utils.service.
> +The effect of this is that
> + systemctl restart nfs-utils
> +will restart all nfs-utils daemons as maybe be required during
> +software update. It isn't possible to make
> + systemctl try-restart nfs-server nfs-client.target
> +do this as some daemon are included in both, and rpc.statd would
> +not be restarted if nfs-server were not active (as nfs-client doesn't
> +Want it - it is started by mount.nfs running start-statd).
>
> It is possible that we should have an nfs-statd.target which can
> selectively enable statd being stared by -server and sm-notify
> diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
> index 7319a88661cc..80033f2fbcf4 100644
> --- a/systemd/nfs-blkmap.service
> +++ b/systemd/nfs-blkmap.service
> @@ -6,6 +6,8 @@ Requires=var-lib-nfs-rpc_pipefs.mount
> Requisite=nfs-blkmap.target
> After=nfs-blkmap.target
>
> +PartOf=nfs-utils.service
> +
> [Service]
> Type=forking
> ExecStart=/usr/sbin/blkmapd
> diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
> index 6c2e1537f064..7d0dd84d8a44 100644
> --- a/systemd/nfs-idmapd.service
> +++ b/systemd/nfs-idmapd.service
> @@ -1,6 +1,8 @@
> [Unit]
> Description=NFSv4 ID-name mapping service
>
> +PartOf=nfs-utils.service
> +
> [Service]
> EnvironmentFile=-/run/sysconfig/nfs-utils
> ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
> index 92e05ca309ee..90746a854b40 100644
> --- a/systemd/nfs-mountd.service
> +++ b/systemd/nfs-mountd.service
> @@ -4,6 +4,7 @@ Requires=proc-fs-nfsd.mount
> After=proc-fs-nfsd.mount
> After=network.target
> PartOf=nfs-server.service
> +PartOf=nfs-utils.service
>
> [Service]
> EnvironmentFile=-/run/sysconfig/nfs-utils
> diff --git a/systemd/nfs-utils.service b/systemd/nfs-utils.service
> new file mode 100644
> index 000000000000..54b6314d8d52
> --- /dev/null
> +++ b/systemd/nfs-utils.service
> @@ -0,0 +1,17 @@
> +[Unit]
> +Description=NFS server and client services
> +# This service should never be stopped, only restarted.
> +# When it is re-started, all other services which declare
> +# themselves to be "PartOf" this service will also be
> +# restarted. Thus
> +# systemctl restart nfs-utils
> +# will restart all daemons which are part of nfs-utils
> +# and which are running. This is useful after a software
> +# update.
> +
> +# This is a "service" rather than "target" so that we
> +# don't need to say "systemctl restart nfs-utils.target".
> +[Service]
> +Type=oneshot
> +RemainAfterExit=yes
> +ExecStart=/bin/true
> diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
> index 8778c3ef651b..3982985762ea 100644
> --- a/systemd/rpc-gssd.service
> +++ b/systemd/rpc-gssd.service
> @@ -5,6 +5,8 @@ After=var-lib-nfs-rpc_pipefs.mount
>
> ConditionPathExists=/etc/krb5.keytab
>
> +PartOf=nfs-utils.service
> +
> [Service]
> EnvironmentFile=-/run/sysconfig/nfs-utils
> ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
> index 9d972fc7753a..532354d64fa0 100644
> --- a/systemd/rpc-statd-notify.service
> +++ b/systemd/rpc-statd-notify.service
> @@ -8,6 +8,8 @@ After=network-online.target nss-lookup.target
> # tell clients that it has restarted.
> After=nfs-server.service
>
> +PartOf=nfs-utils.service
> +
> [Service]
> EnvironmentFile=-/run/sysconfig/nfs-utils
> ExecStartPre=/usr/lib/systemd/scritps/nfs-utils_env.sh
> diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
> index 04962e542fbc..88d2527cae9d 100644
> --- a/systemd/rpc-statd.service
> +++ b/systemd/rpc-statd.service
> @@ -4,6 +4,8 @@ DefaultDependencies=no
> Requires=nss-lookup.target rpcbind.target
> After=network.target nss-lookup.target rpcbind.target
>
> +PartOf=nfs-utils.service
> +
> [Service]
> EnvironmentFile=-/run/sysconfig/nfs-utils
> ExecStartPre=-/usr/lib/systemd/scritps/nfs-utils_env.sh
> diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service
> index 036ec579bfc1..6bd45884d991 100644
> --- a/systemd/rpc-svcgssd.service
> +++ b/systemd/rpc-svcgssd.service
> @@ -3,6 +3,7 @@ Description=RPC security service for NFS server
> Requires=var-lib-nfs-rpc_pipefs.mount
> After=var-lib-nfs-rpc_pipefs.mount
> PartOf=nfs-server.service
> +PartOf=nfs-utils.service
>
> After=gssproxy.service
> ConditionPathExists=|!@localstatedir@/run/gssproxy.pid
>
>
>
>
>
>
>
> From 30b27a718632e9d24c479921b116d2c3958a3fc2 Mon Sep 17 00:00:00 2001
> From: Neil Brown <[email protected]>
> Date: Wed, 5 Feb 2014 16:36:21 +1100
> Subject: [PATCH] systemd: tidy up DefaultDependencies
>
> DefaultDependencies should be "yes" (the default) for things
> needed only be the NFS server, as that is a service that doesn't
> need to start early.
>
> DefaultDependencies should be "no" for things needed to mount an
> NFS filesystem, and filesystems are mounted before basic.target.
> To ensure these services are shut down in a timely fashion, they
> must Conflict with systemd.umount so they are shutdown when everything
> is unmounted.
>
> Signed-off-by: NeilBrown <[email protected]>
>
> diff --git a/systemd/nfs-blkmap.service b/systemd/nfs-blkmap.service
> index 80033f2fbcf4..4b74e9f61454 100644
> --- a/systemd/nfs-blkmap.service
> +++ b/systemd/nfs-blkmap.service
> @@ -1,5 +1,7 @@
> [Unit]
> Description=pNFS block layout mapping daemon
> +DefaultDependencies=no
> +Conflicts=umount.target
> After=var-lib-nfs-rpc_pipefs.mount
> Requires=var-lib-nfs-rpc_pipefs.mount
>
> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> index 6ba2fc0f346e..5779fd39ed34 100644
> --- a/systemd/nfs-server.service
> +++ b/systemd/nfs-server.service
> @@ -1,6 +1,5 @@
> [Unit]
> Description=NFS server and services
> -DefaultDependencies=no
> 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
> diff --git a/systemd/proc-fs-nfsd.mount b/systemd/proc-fs-nfsd.mount
> index f44d52f3d67b..931a5ceeb055 100644
> --- a/systemd/proc-fs-nfsd.mount
> +++ b/systemd/proc-fs-nfsd.mount
> @@ -1,6 +1,5 @@
> [Unit]
> Description=NFSD configuration filesystem
> -DefaultDependencies=no
>
> [Mount]
> What=nfsd
> diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service
> index 3982985762ea..375792804247 100644
> --- a/systemd/rpc-gssd.service
> +++ b/systemd/rpc-gssd.service
> @@ -1,5 +1,7 @@
> [Unit]
> Description=RPC security service for NFS client and server
> +DefaultDependencies=no
> +Conflicts=umount.target
> Requires=var-lib-nfs-rpc_pipefs.mount
> After=var-lib-nfs-rpc_pipefs.mount
>
> diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service
> index 532354d64fa0..7742ac8c5d9a 100644
> --- a/systemd/rpc-statd-notify.service
> +++ b/systemd/rpc-statd-notify.service
> @@ -1,6 +1,5 @@
> [Unit]
> Description=Notify NFS peers of a restart
> -DefaultDependencies=no
> Requires=network-online.target
> After=network-online.target nss-lookup.target
>
> diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
> index 88d2527cae9d..3f6cda16accd 100644
> --- a/systemd/rpc-statd.service
> +++ b/systemd/rpc-statd.service
> @@ -1,6 +1,7 @@
> [Unit]
> Description=NFS status monitor for NFSv2/3 locking.
> DefaultDependencies=no
> +Conflicts=umount.target
> Requires=nss-lookup.target rpcbind.target
> After=network.target nss-lookup.target rpcbind.target
>
> diff --git a/systemd/var-lib-nfs-rpc_pipefs.mount b/systemd/var-lib-nfs-rpc_pipefs.mount
> index cd614cf49f00..33c5db65aa38 100644
> --- a/systemd/var-lib-nfs-rpc_pipefs.mount
> +++ b/systemd/var-lib-nfs-rpc_pipefs.mount
> @@ -1,6 +1,7 @@
> [Unit]
> Description=RPC Pipe File System
> DefaultDependencies=no
> +Conflicts=umount.target
>
> [Mount]
> What=sunrpc
>

2014-02-06 16:19:19

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Thu, Feb 06, 2014 at 11:09:58AM -0500, Chuck Lever wrote:
>
> On Feb 5, 2014, at 8:27 PM, NeilBrown <[email protected]> wrote:
> > I certainly agree with making things simple. If we can make a configuration
> > irrelevant, e.g. by gets nfsd to auto-tune the number of threads so the
> > setting becomes pointless, then I've very happy to remove that sort of
> > configuration. But if a configuration option actually means something I
> > certainly don't want to remove it.
> >
> > So I'm leaning towards having "systemctl {un,}mask rpc-gssd" be the
> > configuration tool for rpc.gssd.
>
> I like that better than the “off-until-requested” behavior we have currently. IMO folks who want to disable rpc.gssd will be in the increasing minority and the rest of the world will take scant notice of the extra daemon, as long as we ensure it speaks only when necessary.

I'd also prefer running the gssd's by default: one less (confusing) step
to set up kerberos, and I'm not seeing a realistic security risk.

If we can easily provide a way to turn it off for people that want a
really stripped-down system for whatever reason, fine, let's provide
that.

--b.

2014-02-04 14:18:12

by Anthony Joseph Messina

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Tuesday, February 04, 2014 08:24:26 AM Jeff Layton wrote:
> On Tue, 04 Feb 2014 06:42:12 -0600
>
> Anthony Messina <[email protected]> wrote:
> > On Monday, February 03, 2014 04:01:21 PM Steve Dickson wrote:
> > > This changes the current API... Today to enable/start this service
> > >
> > > today one does:
> > >
> > > systemctl enable nfs-server
> > > systemctl start nfs-server
> > >
> > >
> > > which would change to:
> > >
> > > systemctl enable nfs-server.target
> > > systemctl start nfs-server
> > >
> > >
> > > with the same daemons being started.
> > > This changed will cause existing scripts to fail...
> > > I guess I don't see the point of having a .target file.
> > >
> > >
> > >
> > > How is rpc.svcgssd enabled? Since the .service file does
> > > not have a [Install] section the systemctl enable rpc.svcgssd
> > > fails.
> > >
> > >
> > >
> > > Also how does gss-proxy come to play in all this? Maybe we
> > > just use gss-proxy by default and retire rpc.svcgssd.
> >
> >
> >
> > Usually just a quite listener (end-user & small-time sysadmin) on this
> > ML...>
> >
> >
> > +1 for gss-proxy by default (for Fedora anyway). I've been using it
> > throughout F19 extensively in the KRB5/NFSv4.1 environment with great
> > success. I have nfs-secure-server.service "masked" via systemd to
> > prevent it from being started.
> >
> >
> >
> > There seems to be only one strange issue I've come across with gss-proxy
> > vs. rpc.svcgssd: https://fedorahosted.org/gss-proxy/ticket/98. This is
> > with regard to how access for the "nfsnobody" user is handled. The
> > ticket attempts to show that with rpc.svcgssd, a host with host
> > credentials and a user without credentials can still access NFS shares
> > with 0755 directories and 0644 files (via the host credentials and mapped
> > to the nfsnobody user). With gss-proxy, I had to create user credentials
> > for kojibuilder@REALM because the access wasn't allowed via the nfsnobody
> > path. I'm not sure if this is resolved, or by design, etc. But it is
> > the only issue I've seen with gss-proxy vs. rpc.svcgssd.
> >
> >
> >
> > Thanks. -A
> >
> >
>
> Please do open a bug at bugzilla.redhat.com for that and cc me on it.
> We really do want to ensure that these sorts of corner-cases get
> addressed.

https://bugzilla.redhat.com/show_bug.cgi?id=1061180

--
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

Attachments:

signature.asc (198.00 B)
This is a digitally signed message part.

2014-02-03 22:35:04

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <[email protected]> wrote:

>
>
> On 01/30/2014 01:24 AM, NeilBrown wrote:
> >
> > So:
> > 1/ Do you agree that a collection of systemd unit files belongs in
> > nfs-utils?
> I think having a single way to start NFS across all distors would be
> a very good thing...
>
> > 2/ Do you think it reasonable to expect most (systemd using) distros to
> > use the one set? I will certainly try to ensure openSUSE does if
> > upstream accepts them.
> I think I'll already agreed to this as well...
>
> > 3/ Do you have any comments/question about those below?
> I took a little closer look at these and actual tried to
> get them to work in a Fedora environment. Here is what I found..
>
>
> > diff --git a/systemd/README b/systemd/README
> > new file mode 100644
> > index 000000000000..f0fb68825499
> > --- /dev/null
> > +++ b/systemd/README
> > @@ -0,0 +1,50 @@
> > +
> > +Notes about systemd unit files for nfs-utils.
> > +
> > +The unit files provided here should be sufficient for systemd
> > +to manage all daemons and related services provides by nfs-utils.
> > +
> > +They do *not* include any unit files for separate services such as
> > +rpc.rquotad (in the 'quota' package) or rpcbind.
> > +
> > +There are 4 units that can be 'enabled' or 'disabled' by systemctl, or
> > +by a suitable 'preset' setting:
> > +
> > + nfs-server.target
> > + If enabled, nfs service is started together with dependencies
> > + such as mountd, statd, rpc.idmapd
> This changes the current API... Today to enable/start this service
> today one does:
>
> systemctl enable nfs-server
> systemctl start nfs-server
>
> which would change to:
>
> systemctl enable nfs-server.target
> systemctl start nfs-server

I think this would need to be "systemctl start nfs-server.target".

>
> with the same daemons being started.
> This changed will cause existing scripts to fail...
> I guess I don't see the point of having a .target file.

It's frustrating that "foo" is treated as "foo.service" rather than
"foo.target" but I guess we have to live with it.

According to the documentation a .service file "encodes
information about a process controlled and supervised by systemd."

nfs-server isn't "a process", it is a collection of processes.

A .target is "used for grouping units" so it makes sense to me to group all
the nfs-server units in an "nfs-server.target".

So the structure makes sense based on the documentation and apparent design
of systemd. Unfortunately it leads to this clumsy API of having to give the
".target" suffix.

I guess it makes sense to merge nfs-server.service and nfs-server.target as,
after all, nfs-server.service doesn't describe a process controlled by
systemd anyway - it is a 'oneshot'....
I'll send a patch to do that.

>
> How is rpc.svcgssd enabled? Since the .service file does
> not have a [Install] section the systemctl enable rpc.svcgssd
> fails.

The "README" touches on this. If you
systemctl enable nfs-secure.target
then rpc.svcgssd will be run whenever nfs-server.target is started.
Also rpc.gssd will be run whenever nfs-server.target or nfs-client.target is
started.

>
> Also how does gss-proxy come to play in all this? Maybe we
> just use gss-proxy by default and retire rpc.svcgssd.

I haven't really be following and so am only dimly aware of gss-proxy.
It's a replacement for rpc.svcgssd - right?
So we should get it to start in the same circumstances as rpc.svcgssd?

Is there some easy test - eg something existing in the filesystem - that we
could use to see if the kernel supports gss-proxy ?

Also, I've been wondering if we could avoid the need to explicitly enable
the gss stuff by gating it on the existence of /etc/krb5.keytab.
Do you think that would be reasonable?

>
> > +
> > + nfs-client.target
> > + If enabled, daemons needs for an nfs client are enabled.
> > + This does *not* include rpc.statd. the rpc-statd.service unit
> > + is started by /usr/sbin/start-statd which mount.nfs will run
> > + if statd is needed.
> I am coming around to liking this one... but I think it should start
> statd and configure lockd. Why not just roll the current nfs-lock
> service under this umbrella? A simple systemctl restart nfs-client
> would configure and start all of the needed daemons.

I just feels like the wrong place to be setting sysctl values... But maybe.
And why start statd if it isn't needed.

>
> How would these daemons be restart and shutdown? Since this is a
> target, systemctl restart and system stop don't do anything.

This is something I haven't completely figured out yet.

Part of the solution might be the "PartOf" directive.
If each service claims to be "PartOf" the main one, then stopping or
restarting the main service will propagate to stopping and restarting the
individual services.
Unfortunately in nfs we have some shared services. rpc.statd and rpc.gssd
are needed by both server and client. That isn't a big problem for 'restart',
but if you 'systemctl stop nfs-client' and find that the server isn't
properly working any more, that would be awkward
If could possibly work around that by setting "StopWhenUnneeded" for those
shared services. Then e.g. rpc.statd would stop when both client and server
are stopped, but not if either one of them is stopped.
However I don't know how that interacts with restart. I suspect that the
StopWhenUnneeded services are *not* stopped and restarted when the main
service is stopped. So it would be hard to restart all nfs services on an
upgrade.

Further research seems needed here.

>
> > +
> > + nfs-secure.target
> > + If enabled, then rpc.gssd will be run when either -client or
> > + -server is started, and rpc.svcgssd will be run when -server
> > + is started
> I like that fact that rpc.gssd is started by nfs-client but
> I don't like that API change. systemctl restart nfs-secure breaks

Why would you want to "restart nfs-secure". I can understanding wanting to
restart individual processed, or the whole collection, but why that subset?

I'm fairly sure we can keep that API working if you really need it, but
maybe as a fedora-specific hack?
>
> > +
> > + nfs-blkmap.target
> > + If enabled, then blkmapd will be run when nfs-client.target is
> > + started.
> Unless someone steps up and says why this is needed or if it will
> ever be needed... I'm seriously thinking about dropping it from Fedora.
>
> I think overall its workable but I just don't see the advantage
> of using .targets over .service files...
>
> steved.

Thanks for your very thorough review.

NeilBrown

Attachments:

signature.asc (828.00 B)

2014-02-11 16:57:01

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Tue, Feb 11, 2014 at 11:47:56AM -0500, Steve Dickson wrote:
>
>
> On 02/11/2014 11:37 AM, J. Bruce Fields wrote:
> > On Tue, Feb 11, 2014 at 03:50:52PM +1100, NeilBrown wrote:
> >> On Mon, 10 Feb 2014 15:50:41 -0500 Steve Dickson <[email protected]> wrote:
> >>
> >>> On 02/06/2014 11:19 AM, J. Bruce Fields wrote:
> >>>> On Thu, Feb 06, 2014 at 11:09:58AM -0500, Chuck Lever wrote:
> >>>>>
> >>>>> On Feb 5, 2014, at 8:27 PM, NeilBrown <[email protected]> wrote:
> >>>>>> I certainly agree with making things simple. If we can make a configuration
> >>>>>> irrelevant, e.g. by gets nfsd to auto-tune the number of threads so the
> >>>>>> setting becomes pointless, then I've very happy to remove that sort of
> >>>>>> configuration. But if a configuration option actually means something I
> >>>>>> certainly don't want to remove it.
> >>>>>>
> >>>>>> So I'm leaning towards having "systemctl {un,}mask rpc-gssd" be the
> >>>>>> configuration tool for rpc.gssd.
> >>>>>
> >>>>> I like that better than the “off-until-requested” behavior we have currently. IMO folks who want to disable rpc.gssd will be in the increasing minority and the rest of the world will take scant notice of the extra daemon, as long as we ensure it speaks only when necessary.
> >>>>
> >>>> I'd also prefer running the gssd's by default: one less (confusing) step
> >>>> to set up kerberos, and I'm not seeing a realistic security risk.
> >>> I'm not for starting daemon that are not needed or necessary. I
> >>> just think that is a bad design.
> >>>
> >>>>
> >>>> If we can easily provide a way to turn it off for people that want a
> >>>> really stripped-down system for whatever reason, fine, let's provide
> >>>> that.
> >>> I'm thinking just the opposite... Have a way to easily (or even
> >>> automatically) way to enabled NFS security.... when needed...
> >>>
> >>> Would it make it easier if we combined the gssd daemon? That goes
> >>> both ways (server and client)... That way we could just enable
> >>> nfs security and the daemon would started regardless on what side
> >>> its on...
> >>>
> >>> steved.
> >>
> >> By "combine" do you mean "rewrite the code so there is only one process" or
> >> "have a systemd unit which starts both"? The former seems like a lot of
> >> pointless work and the later contradicts your stated preference for not
> >> starting daemons that are not needed.
> >
> > Note the client needs svcgssd or gss-proxy too, if you want it to be
> > able to get delegations over NFSv4.0. (It doesn't matter for versions
> > 2, 3, or >=4.1).
> Even when kerberos is not configured?

No. So an attempt to summarize:
- not using kerberos? You don't need any daemons.
- using kerberos, NFS version 2, 3, or >=4.1? You need rpc.gssd
on the client, and rpc.svcgssd (or gss-proxy) on the server.
- using kerberos, NFS version 4.0, care about delegations
working? You need both rpc.gssd and rpc.svcgssd (or
gss-proxy) on both server and client.

> > I still pretty vague on exactly what problems we solve by turning off
> > these daemons by default.
> To keep things simple....

"Always start" is simpler logic than, say, "start if /etc/krb5.conf is
available".

--b.

2014-02-10 20:50:57

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On 02/06/2014 11:19 AM, J. Bruce Fields wrote:
> On Thu, Feb 06, 2014 at 11:09:58AM -0500, Chuck Lever wrote:
>>
>> On Feb 5, 2014, at 8:27 PM, NeilBrown <[email protected]> wrote:
>>> I certainly agree with making things simple. If we can make a configuration
>>> irrelevant, e.g. by gets nfsd to auto-tune the number of threads so the
>>> setting becomes pointless, then I've very happy to remove that sort of
>>> configuration. But if a configuration option actually means something I
>>> certainly don't want to remove it.
>>>
>>> So I'm leaning towards having "systemctl {un,}mask rpc-gssd" be the
>>> configuration tool for rpc.gssd.
>>
>> I like that better than the “off-until-requested” behavior we have currently. IMO folks who want to disable rpc.gssd will be in the increasing minority and the rest of the world will take scant notice of the extra daemon, as long as we ensure it speaks only when necessary.
>
> I'd also prefer running the gssd's by default: one less (confusing) step
> to set up kerberos, and I'm not seeing a realistic security risk.
I'm not for starting daemon that are not needed or necessary. I
just think that is a bad design.

>
> If we can easily provide a way to turn it off for people that want a
> really stripped-down system for whatever reason, fine, let's provide
> that.
I'm thinking just the opposite... Have a way to easily (or even
automatically) way to enabled NFS security.... when needed...

Would it make it easier if we combined the gssd daemon? That goes
both ways (server and client)... That way we could just enable
nfs security and the daemon would started regardless on what side
its on...

steved.

2014-02-06 01:28:03

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Wed, 5 Feb 2014 10:56:39 -0500 Chuck Lever <[email protected]> wrote:

> Hi Neil!
>
>
> On Feb 4, 2014, at 10:09 PM, NeilBrown <[email protected]> wrote:
>
> > On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields" <[email protected]>
> > wrote:
> >
> >> On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote:
> >>> Also, I've been wondering if we could avoid the need to explicitly enable
> >>> the gss stuff by gating it on the existence of /etc/krb5.keytab.
> >>> Do you think that would be reasonable?
> >>
> >> That would be great. I hate that people have to care about these
> >> support daemons, they should just be started automatically when they're
> >> needed.
> >>
> >> Is /etc/krb5.keytab the best indicator?
> >
> > I was hoping you would tell me. :-)
>
> rpc.gssd has to run in cases where there is no /etc/krb5.keytab. Remember the discussion we had last year about using root’s user credential as the client’s machine credential? We want the kernel to be able to find out whether there is a machine credential available, and one can be available even if there is no keytab.

Hi Chuck,
thanks for reminding me about that! Yes we clearly cannot key
off /etc/krb5.keytab for rpc.gssd.

Maybe /etc/krb5.conf? Seems a bit lame.
How about /etc/gssapi_mech.conf ?? rpc.gssd seems to exit if that doesn't
exist. What if systemd is told not to run rpc.gssd if that file is
missing?

I guess that otherwise we can make it on-by-default, but document that people
can turn it off with
systemctl mask rpc-gssd

which is probably easier that requiring "systemctl enable nfs-secure".

>
> > It occurred to me as a good test when I tried running rpc.svcgssd in a fresh
> > VM and it wouldn't start. I eventually found the error message complaining
> > that it couldn't find that file.
> >
> > It isn't perfect as an empty /etc/krb5.keytab will still result in failure
> > and exit. However if a sysadmin has created a keytab and is using NFS, it
> > seems reasonable to be ready to provide gss services.
> >
> > rpc.gssd doesn't fail in the same way, but it does complain if the file
> > doesn't exist, so I suspect it is at least a good indicator.
> >
> > The only thing that bothers me is that gssd is theoretically more general
> > than krb5. However as the reality seems to be that it is exactly krb5, I
> > don't let that bother me too much.
> >
> >>
> >> Simplest might be to start unconditionally and just not care if it
> >> fails. Or is there a problem cluttering up logs with unimportant
> >> failures?
> >
> > More a problem with starting things that aren't necessary, and possibly
> > leaving them running.
> > Every process you start adds a little to the boot time. We only get the best
> > experience if everyone contributes a little bit, no matter how little.
> > Also, every running process theoretically adds the to the attack service.
>
> rpc.gssd doesn’t expose a network listener. What attack vector is exposed by running rpc.gssd?

Not all attacks are external. Also not all decisions relating to security
are completely rational. And the 'attack surface' argument may apply better
to other services but might cause a spill-over to people not wanting to run
anything they don't have to.

>
> Why would we insist on using a potentially insecure mechanism to provide strong security?
>
> > So some people will definitely not want these processes to be started.
>
> How many such people are there? The trend I expect is that more and more people will want to use security features, and fewer will want “sec=sys,” especially if we work hard to make security features as painless as possible (as we should be doing).

I honestly don't know. I may be seeing spectres that aren't there. But I've
certainly heard a strong preference to not run unnecessary daemons more than
once in the past.

When NFS is only used over a tightly coupled local network (infiniband?) you
really do want sec=sys.

>
> It seems to me that provisionally starting rpc.gssd optimizes for a fairly uncommon case that will become less and less common going forward. I believe we should start designing as if security is the default use case. I would feel more comfortable if we knew more precisely what proportion of our users want to disable gssd and why.
>
> > i.e. I agree with SteveD:
> >> I think we want to stay away (and move away) from unconditionally
> >> starting anything…
>
> I believe we should make things simple both for us and for our customers. Thus I agree philosophically with the Gnome strategy of removing less frequently used configuration options to reduce complexity, make things easier to configure, more reliable, and easier to troubleshoot.

I certainly agree with making things simple. If we can make a configuration
irrelevant, e.g. by gets nfsd to auto-tune the number of threads so the
setting becomes pointless, then I've very happy to remove that sort of
configuration. But if a configuration option actually means something I
certainly don't want to remove it.

So I'm leaning towards having "systemctl {un,}mask rpc-gssd" be the
configuration tool for rpc.gssd.

Thanks,
NeilBrown

Attachments:

signature.asc (828.00 B)

2014-02-05 03:55:25

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Tue, 04 Feb 2014 13:26:42 -0500 Steve Dickson <[email protected]> wrote:

>
>
> On 02/03/2014 05:34 PM, NeilBrown wrote:
> > On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <[email protected]> wrote:

> >
> > So the structure makes sense based on the documentation and apparent design
> > of systemd. Unfortunately it leads to this clumsy API of having to give the
> > ".target" suffix.
> In the beginning the .service suffix was not appended either. I actually
> opened a bug asking for the .service to be appended, which got
> soundly closed as NOTABUG! But I guess enough people bitched about
> so one day that "feature" just appeared. ;-)

Oh dear. That is a sad story. Good to know though.

> >
> >
> >>
> >> How is rpc.svcgssd enabled? Since the .service file does
> >> not have a [Install] section the systemctl enable rpc.svcgssd
> >> fails.
> >
> > The "README" touches on this. If you
> > systemctl enable nfs-secure.target
> > then rpc.svcgssd will be run whenever nfs-server.target is started.
> I was thinking nfs-server would only start rpc.svcgssd when its
> enabled... not every time...

I don't follow what you are saying ... not that it really matters as we both
seem to be agreed to take a different approach with the gss daemons.

In my original plan:
if nfs-secure is enabled, then whenever nfs-server is started, it makes sure
that rpc.svcgssd is running.
if nfs-secure is not enabled, then rpc.svcgssd will refuse to start.

>
> > Also rpc.gssd will be run whenever nfs-server.target or nfs-client.target is
> > started.
> Why is rpc.gssd started when the nfs server is started? Possibly for secure
> loopback mounts??

Call-backs from NFSv4.0 server, as has been mentioned elsewhere.

>
> >
> >>
> >> How would these daemons be restart and shutdown? Since this is a
> >> target, systemctl restart and system stop don't do anything.
> >
> > This is something I haven't completely figured out yet.
> >
> > Part of the solution might be the "PartOf" directive.
> > If each service claims to be "PartOf" the main one, then stopping or
> > restarting the main service will propagate to stopping and restarting the
> > individual services.
> > Unfortunately in nfs we have some shared services. rpc.statd and rpc.gssd
> > are needed by both server and client. That isn't a big problem for 'restart',
> > but if you 'systemctl stop nfs-client' and find that the server isn't
> > properly working any more, that would be awkward
> > If could possibly work around that by setting "StopWhenUnneeded" for those
> > shared services. Then e.g. rpc.statd would stop when both client and server
> > are stopped, but not if either one of them is stopped.
> > However I don't know how that interacts with restart. I suspect that the
> > StopWhenUnneeded services are *not* stopped and restarted when the main
> > service is stopped. So it would be hard to restart all nfs services on an
> > upgrade.
> >
> > Further research seems needed here.
> Fine... I'll try to digest what you are saying here, but
> would it make it easier if everything was in a service file?

No, the only way the .target files are more awkward is that you have to type
".target".

In fact a .target can be turned into an .service by adding:

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true

at the end. You might even get away with less than that.
Given this and that ".target" is extra typing, there seems little reason to
use .target unit files.

>
> >
> >
> >>
> >>> +
> >>> + nfs-secure.target
> >>> + If enabled, then rpc.gssd will be run when either -client or
> >>> + -server is started, and rpc.svcgssd will be run when -server
> >>> + is started
> >> I like that fact that rpc.gssd is started by nfs-client but
> >> I don't like that API change. systemctl restart nfs-secure breaks
> >
> > Why would you want to "restart nfs-secure". I can understanding wanting to
> > restart individual processed, or the whole collection, but why that subset?
> Well in Fedora nfs-secure is one process ;-)

Oh yes, "nfs-secure" means "run rpc.gssd".
If you wanted to preserve that I think you could create a drop-in file
for rpc-gssd.service containing
[Install]
Alias=nfs-secure.service
though that would require "systemctl enable rpc-gssd" so maybe it isn't the
best approach.

>
> >
> > I'm fairly sure we can keep that API working if you really need it, but
> > maybe as a fedora-specific hack?
> Yup! At the time I didn't know how to handle the security daemons
> that why there is a nfs-secure service and an nfs-server-secure
> service.
>
> The path we are head is much better...

Glad you think so :-)

NeilBrown

Attachments:

signature.asc (828.00 B)

2014-02-05 15:56:56

by Chuck Lever III

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

Hi Neil!

On Feb 4, 2014, at 10:09 PM, NeilBrown <[email protected]> wrote:

> On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields" <[email protected]>
> wrote:
>
>> On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote:
>>> Also, I've been wondering if we could avoid the need to explicitly enable
>>> the gss stuff by gating it on the existence of /etc/krb5.keytab.
>>> Do you think that would be reasonable?
>>
>> That would be great. I hate that people have to care about these
>> support daemons, they should just be started automatically when they're
>> needed.
>>
>> Is /etc/krb5.keytab the best indicator?
>
> I was hoping you would tell me. :-)

rpc.gssd has to run in cases where there is no /etc/krb5.keytab. Remember the discussion we had last year about using root?s user credential as the client?s machine credential? We want the kernel to be able to find out whether there is a machine credential available, and one can be available even if there is no keytab.

> It occurred to me as a good test when I tried running rpc.svcgssd in a fresh
> VM and it wouldn't start. I eventually found the error message complaining
> that it couldn't find that file.
>
> It isn't perfect as an empty /etc/krb5.keytab will still result in failure
> and exit. However if a sysadmin has created a keytab and is using NFS, it
> seems reasonable to be ready to provide gss services.
>
> rpc.gssd doesn't fail in the same way, but it does complain if the file
> doesn't exist, so I suspect it is at least a good indicator.
>
> The only thing that bothers me is that gssd is theoretically more general
> than krb5. However as the reality seems to be that it is exactly krb5, I
> don't let that bother me too much.
>
>>
>> Simplest might be to start unconditionally and just not care if it
>> fails. Or is there a problem cluttering up logs with unimportant
>> failures?
>
> More a problem with starting things that aren't necessary, and possibly
> leaving them running.
> Every process you start adds a little to the boot time. We only get the best
> experience if everyone contributes a little bit, no matter how little.
> Also, every running process theoretically adds the to the attack service.

rpc.gssd doesn?t expose a network listener. What attack vector is exposed by running rpc.gssd?

Why would we insist on using a potentially insecure mechanism to provide strong security?

> So some people will definitely not want these processes to be started.

How many such people are there? The trend I expect is that more and more people will want to use security features, and fewer will want ?sec=sys,? especially if we work hard to make security features as painless as possible (as we should be doing).

It seems to me that provisionally starting rpc.gssd optimizes for a fairly uncommon case that will become less and less common going forward. I believe we should start designing as if security is the default use case. I would feel more comfortable if we knew more precisely what proportion of our users want to disable gssd and why.

> i.e. I agree with SteveD:
>> I think we want to stay away (and move away) from unconditionally
>> starting anything?

I believe we should make things simple both for us and for our customers. Thus I agree philosophically with the Gnome strategy of removing less frequently used configuration options to reduce complexity, make things easier to configure, more reliable, and easier to troubleshoot.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

2014-02-04 18:54:53

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Tue, Feb 04, 2014 at 12:48:47PM -0600, Anthony Messina wrote:
> On Tuesday, February 04, 2014 01:26:42 PM Steve Dickson wrote:
> > > Also rpc.gssd will be run whenever nfs-server.target or nfs-client.target
> > > is started.
> >
> > Why is rpc.gssd started when the nfs server is started? Possibly for secure
> > loopback mounts??
>
> Isn't this needed for KRB5/NFSv4.1 callbacks? I seem to remember needing this
> on the server as well as the client, lest I get the frequent "gss upcall
> timeout" issue. At least on Fedora that's how it's been for me.

It's only for KRB5/NFSv4.0 callbacks, actually. Since minor version >=1
callbacks use the client-established credentials (and the
client-established tcp connection).

--b.

2014-02-04 19:00:42

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On 02/04/2014 11:20 AM, J. Bruce Fields wrote:
> On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote:
>> On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <[email protected]> wrote:
>>> Also how does gss-proxy come to play in all this? Maybe we
>>> just use gss-proxy by default and retire rpc.svcgssd.
>>
>> I haven't really be following and so am only dimly aware of gss-proxy.
>> It's a replacement for rpc.svcgssd - right?
>> So we should get it to start in the same circumstances as rpc.svcgssd?
>>
>> Is there some easy test - eg something existing in the filesystem - that we
>> could use to see if the kernel supports gss-proxy ?
>
> There's a /proc/net/rpc/use-gss-proxy file.
hmm... I forget... who set this... gssproxy daemon?

>
> (But doesn't gss-proxy have users other than nfsd?)
>
>> Also, I've been wondering if we could avoid the need to explicitly enable
>> the gss stuff by gating it on the existence of /etc/krb5.keytab.
>> Do you think that would be reasonable?
>
> That would be great. I hate that people have to care about these
> support daemons, they should just be started automatically when they're
> needed.
>
> Is /etc/krb5.keytab the best indicator?
>
> Simplest might be to start unconditionally and just not care if it
> fails. Or is there a problem cluttering up logs with unimportant
> failures?
I think we want to stay away (and move away) from unconditionally
starting anything... Having "triggers" of when services should
or should not be started is a better direction... Like what
Neil is doing with rpc.statd.

steved.

>
> --b.
>

2014-02-04 18:26:45

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On 02/03/2014 05:34 PM, NeilBrown wrote:
> On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <[email protected]> wrote:
>
>>
>>
>> On 01/30/2014 01:24 AM, NeilBrown wrote:
>>>
>>> So:
>>> 1/ Do you agree that a collection of systemd unit files belongs in
>>> nfs-utils?
>> I think having a single way to start NFS across all distors would be
>> a very good thing...
>>
>>> 2/ Do you think it reasonable to expect most (systemd using) distros to
>>> use the one set? I will certainly try to ensure openSUSE does if
>>> upstream accepts them.
>> I think I'll already agreed to this as well...
>>
>>> 3/ Do you have any comments/question about those below?
>> I took a little closer look at these and actual tried to
>> get them to work in a Fedora environment. Here is what I found..
>>
>>
>>> diff --git a/systemd/README b/systemd/README
>>> new file mode 100644
>>> index 000000000000..f0fb68825499
>>> --- /dev/null
>>> +++ b/systemd/README
>>> @@ -0,0 +1,50 @@
>>> +
>>> +Notes about systemd unit files for nfs-utils.
>>> +
>>> +The unit files provided here should be sufficient for systemd
>>> +to manage all daemons and related services provides by nfs-utils.
>>> +
>>> +They do *not* include any unit files for separate services such as
>>> +rpc.rquotad (in the 'quota' package) or rpcbind.
>>> +
>>> +There are 4 units that can be 'enabled' or 'disabled' by systemctl, or
>>> +by a suitable 'preset' setting:
>>> +
>>> + nfs-server.target
>>> + If enabled, nfs service is started together with dependencies
>>> + such as mountd, statd, rpc.idmapd
>> This changes the current API... Today to enable/start this service
>> today one does:
>>
>> systemctl enable nfs-server
>> systemctl start nfs-server
>>
>> which would change to:
>>
>> systemctl enable nfs-server.target
>> systemctl start nfs-server
>
> I think this would need to be "systemctl start nfs-server.target".
>
>>
>> with the same daemons being started.
>> This changed will cause existing scripts to fail...
>> I guess I don't see the point of having a .target file.
>
> It's frustrating that "foo" is treated as "foo.service" rather than
> "foo.target" but I guess we have to live with it.
>
> According to the documentation a .service file "encodes
> information about a process controlled and supervised by systemd."
>
> nfs-server isn't "a process", it is a collection of processes.
>
> A .target is "used for grouping units" so it makes sense to me to group all
> the nfs-server units in an "nfs-server.target".
I see this logic.

>
> So the structure makes sense based on the documentation and apparent design
> of systemd. Unfortunately it leads to this clumsy API of having to give the
> ".target" suffix.
In the beginning the .service suffix was not appended either. I actually
opened a bug asking for the .service to be appended, which got
soundly closed as NOTABUG! But I guess enough people bitched about
so one day that "feature" just appeared. ;-)

>
> I guess it makes sense to merge nfs-server.service and nfs-server.target as,
> after all, nfs-server.service doesn't describe a process controlled by
> systemd anyway - it is a 'oneshot'....
> I'll send a patch to do that.
Thanks! That will make our transition much easier....

>
>
>>
>> How is rpc.svcgssd enabled? Since the .service file does
>> not have a [Install] section the systemctl enable rpc.svcgssd
>> fails.
>
> The "README" touches on this. If you
> systemctl enable nfs-secure.target
> then rpc.svcgssd will be run whenever nfs-server.target is started.
I was thinking nfs-server would only start rpc.svcgssd when its
enabled... not every time...

> Also rpc.gssd will be run whenever nfs-server.target or nfs-client.target is
> started.
Why is rpc.gssd started when the nfs server is started? Possibly for secure
loopback mounts??

>
>>
>> Also how does gss-proxy come to play in all this? Maybe we
>> just use gss-proxy by default and retire rpc.svcgssd.
>
> I haven't really be following and so am only dimly aware of gss-proxy.
> It's a replacement for rpc.svcgssd - right?
> So we should get it to start in the same circumstances as rpc.svcgssd?
>
> Is there some easy test - eg something existing in the filesystem - that we
> could use to see if the kernel supports gss-proxy ?
In Fedora, you set the GSS_USE_PROXY="yes" in /etc/sysconfig/nfs.
I've done a little testing with it but not enough...

>
> Also, I've been wondering if we could avoid the need to explicitly enable
> the gss stuff by gating it on the existence of /etc/krb5.keytab.
> Do you think that would be reasonable?
Personally I think the gssd daemons should just check for the
existence of /etc/krb5.keytab. If it does not exist it either
immediately errors out the upcall or dies...

>
>>
>>> +
>>> + nfs-client.target
>>> + If enabled, daemons needs for an nfs client are enabled.
>>> + This does *not* include rpc.statd. the rpc-statd.service unit
>>> + is started by /usr/sbin/start-statd which mount.nfs will run
>>> + if statd is needed.
>> I am coming around to liking this one... but I think it should start
>> statd and configure lockd. Why not just roll the current nfs-lock
>> service under this umbrella? A simple systemctl restart nfs-client
>> would configure and start all of the needed daemons.
>
> I just feels like the wrong place to be setting sysctl values... But maybe.
> And why start statd if it isn't needed.
I can live with this... :-)

>
>>
>> How would these daemons be restart and shutdown? Since this is a
>> target, systemctl restart and system stop don't do anything.
>
> This is something I haven't completely figured out yet.
>
> Part of the solution might be the "PartOf" directive.
> If each service claims to be "PartOf" the main one, then stopping or
> restarting the main service will propagate to stopping and restarting the
> individual services.
> Unfortunately in nfs we have some shared services. rpc.statd and rpc.gssd
> are needed by both server and client. That isn't a big problem for 'restart',
> but if you 'systemctl stop nfs-client' and find that the server isn't
> properly working any more, that would be awkward
> If could possibly work around that by setting "StopWhenUnneeded" for those
> shared services. Then e.g. rpc.statd would stop when both client and server
> are stopped, but not if either one of them is stopped.
> However I don't know how that interacts with restart. I suspect that the
> StopWhenUnneeded services are *not* stopped and restarted when the main
> service is stopped. So it would be hard to restart all nfs services on an
> upgrade.
>
> Further research seems needed here.
Fine... I'll try to digest what you are saying here, but
would it make it easier if everything was in a service file?

>
>
>>
>>> +
>>> + nfs-secure.target
>>> + If enabled, then rpc.gssd will be run when either -client or
>>> + -server is started, and rpc.svcgssd will be run when -server
>>> + is started
>> I like that fact that rpc.gssd is started by nfs-client but
>> I don't like that API change. systemctl restart nfs-secure breaks
>
> Why would you want to "restart nfs-secure". I can understanding wanting to
> restart individual processed, or the whole collection, but why that subset?
Well in Fedora nfs-secure is one process ;-)

>
> I'm fairly sure we can keep that API working if you really need it, but
> maybe as a fedora-specific hack?
Yup! At the time I didn't know how to handle the security daemons
that why there is a nfs-secure service and an nfs-server-secure
service.

The path we are head is much better...

steved.

>>
>>> +
>>> + nfs-blkmap.target
>>> + If enabled, then blkmapd will be run when nfs-client.target is
>>> + started.
>> Unless someone steps up and says why this is needed or if it will
>> ever be needed... I'm seriously thinking about dropping it from Fedora.
>>
>> I think overall its workable but I just don't see the advantage
>> of using .targets over .service files...
>>
>> steved.
>
> Thanks for your very thorough review.
>
> NeilBrown
>

2014-02-11 12:38:34

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On 02/10/2014 11:50 PM, NeilBrown wrote:
> On Mon, 10 Feb 2014 15:50:41 -0500 Steve Dickson <[email protected]> wrote:
>
>> On 02/06/2014 11:19 AM, J. Bruce Fields wrote:
>>> On Thu, Feb 06, 2014 at 11:09:58AM -0500, Chuck Lever wrote:
>>>>
>>>> On Feb 5, 2014, at 8:27 PM, NeilBrown <[email protected]> wrote:
>>>>> I certainly agree with making things simple. If we can make a configuration
>>>>> irrelevant, e.g. by gets nfsd to auto-tune the number of threads so the
>>>>> setting becomes pointless, then I've very happy to remove that sort of
>>>>> configuration. But if a configuration option actually means something I
>>>>> certainly don't want to remove it.
>>>>>
>>>>> So I'm leaning towards having "systemctl {un,}mask rpc-gssd" be the
>>>>> configuration tool for rpc.gssd.
>>>>
>>>> I like that better than the “off-until-requested” behavior we have currently. IMO folks who want to disable rpc.gssd will be in the increasing minority and the rest of the world will take scant notice of the extra daemon, as long as we ensure it speaks only when necessary.
>>>
>>> I'd also prefer running the gssd's by default: one less (confusing) step
>>> to set up kerberos, and I'm not seeing a realistic security risk.
>> I'm not for starting daemon that are not needed or necessary. I
>> just think that is a bad design.
>>
>>>
>>> If we can easily provide a way to turn it off for people that want a
>>> really stripped-down system for whatever reason, fine, let's provide
>>> that.
>> I'm thinking just the opposite... Have a way to easily (or even
>> automatically) way to enabled NFS security.... when needed...
>>
>> Would it make it easier if we combined the gssd daemon? That goes
>> both ways (server and client)... That way we could just enable
>> nfs security and the daemon would started regardless on what side
>> its on...
>>
>> steved.
>
> By "combine" do you mean "rewrite the code so there is only one process" or
> "have a systemd unit which starts both"? The former seems like a lot of
> pointless work and the later contradicts your stated preference for not
> starting daemons that are not needed.
I was talking about the former, since there was some talk way back when
about doing that... What I'm really trying to do is get rid of rpc.svcgssd
in favor of gss-proxy... but... I don't know if that is a good idea
and not sure how to get there.

>
> What do you think of the suggestion to start rpc.gssd when Wanted
> if /etc/krb5.conf exists, and document that it can be disabled with
>
> systemctl mask rpc-gssd
Yes I do like this idea of having a some type of trigger...

So systemctl mask is used to turn off the service, who would
the service be turn back on?

Would we still need to something like systemctl enable nfs-secure.target?

>
> (I like your idea of clearly documenting the important systemd units).
Once this is all said and done, I'll try to find some resources in
my world to help us out with this... the keyword being... _try_ ;-)

> That way it is running when needed, probably not when not, and if you happen
> to have kerberos installed but don't want rpc.gssd, it is easy to achieve
> that.
Good...

steved.
>
> NeilBrown
>

2014-02-06 00:58:28

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Wed, 5 Feb 2014 16:11:07 -0500 "J. Bruce Fields" <[email protected]>
wrote:

> On Wed, Feb 05, 2014 at 04:43:51PM +1100, NeilBrown wrote:
> > On Tue, 04 Feb 2014 13:26:42 -0500 Steve Dickson <[email protected]> wrote:
> >
> >
> > > >
> > > >>
> > > >> How would these daemons be restart and shutdown? Since this is a
> > > >> target, systemctl restart and system stop don't do anything.
> > > >
> > > > This is something I haven't completely figured out yet.
> > > >
> > > > Part of the solution might be the "PartOf" directive.
> > > > If each service claims to be "PartOf" the main one, then stopping or
> > > > restarting the main service will propagate to stopping and restarting the
> > > > individual services.
> > > > Unfortunately in nfs we have some shared services. rpc.statd and rpc.gssd
> > > > are needed by both server and client. That isn't a big problem for 'restart',
> > > > but if you 'systemctl stop nfs-client' and find that the server isn't
> > > > properly working any more, that would be awkward
> > > > If could possibly work around that by setting "StopWhenUnneeded" for those
> > > > shared services. Then e.g. rpc.statd would stop when both client and server
> > > > are stopped, but not if either one of them is stopped.
> > > > However I don't know how that interacts with restart. I suspect that the
> > > > StopWhenUnneeded services are *not* stopped and restarted when the main
> > > > service is stopped. So it would be hard to restart all nfs services on an
> > > > upgrade.
> > > >
> > > > Further research seems needed here.
> > > Fine... I'll try to digest what you are saying here, but
> > > would it make it easier if everything was in a service file?
> >
> > So I did a bit more research and thinking, and I present the two patches
> > below for consideration. If you agree and would prefer them in separate
> > emails I can certainly do that.
> >
> > The first ensures that we can easily restart all daemons during software
> > update. It creates a new 'nfs-utils.service' which exists only to allow that
> > restart.
> >
> > The second ensures startup and shutdown work properly (though I haven't
> > tested much).
> > Do we need to shutdown nfs-server or nfs-client easily at any time other than
> > system shutdown?
>
> I think it's hard to as I don't think there's a way for the NSM protocol
> to treat the nfs client and server as different things that could go up
> and down independently. But I could be wrong, I rarely think about
> statd! In a v4-only setup that wouldn't be a problem any more.

So if we don't make it particular easy to restart statd, then that might be a
good thing? I can live with that :-)

>
> On the server side there are a few parameters (v4 lease time?) that can
> only be changed with a restart but maybe that's not terribly important.

Maybe this should be treated as 'reload'. If we provide ExecReload for
nfs-server.service which:
- stops the nfsd threads
- updates all these parameters
- optionally triggers a new grace period?? (or is that automatic)
- start the nfsd threads

we could document that "systemctl reload nfs-server" does the right thing

>
> HA people may restart the server on failover to get a new grace period.
> They probably use their own scripts for that but it would be better to
> get them using standard systemd configuration to the extent possible.

Probably best not to second-guess such configurations if we don't thoroughly
understand them - but if we hear of a need that our unit files don't meant we
can use that as a trigger for improvement.

>
> Anyway those are existing problems that it's not necessarily up to you
> to fix.

True, but good to consider nonetheless.
Thanks,
NeilBrown

Attachments:

signature.asc (828.00 B)

2014-02-04 16:20:53

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote:
> On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <[email protected]> wrote:
> > Also how does gss-proxy come to play in all this? Maybe we
> > just use gss-proxy by default and retire rpc.svcgssd.
>
> I haven't really be following and so am only dimly aware of gss-proxy.
> It's a replacement for rpc.svcgssd - right?
> So we should get it to start in the same circumstances as rpc.svcgssd?
>
> Is there some easy test - eg something existing in the filesystem - that we
> could use to see if the kernel supports gss-proxy ?

There's a /proc/net/rpc/use-gss-proxy file.

(But doesn't gss-proxy have users other than nfsd?)

> Also, I've been wondering if we could avoid the need to explicitly enable
> the gss stuff by gating it on the existence of /etc/krb5.keytab.
> Do you think that would be reasonable?

That would be great. I hate that people have to care about these
support daemons, they should just be started automatically when they're
needed.

Is /etc/krb5.keytab the best indicator?

Simplest might be to start unconditionally and just not care if it
fails. Or is there a problem cluttering up logs with unimportant
failures?

--b.

2014-02-06 16:10:23

by Chuck Lever III

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Feb 5, 2014, at 8:27 PM, NeilBrown <[email protected]> wrote:

> On Wed, 5 Feb 2014 10:56:39 -0500 Chuck Lever <[email protected]> wrote:
>
>> Hi Neil!
>>
>>
>> On Feb 4, 2014, at 10:09 PM, NeilBrown <[email protected]> wrote:
>>
>>> On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields" <[email protected]>
>>> wrote:
>>>
>>>> On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote:
>>>>> Also, I've been wondering if we could avoid the need to explicitly enable
>>>>> the gss stuff by gating it on the existence of /etc/krb5.keytab.
>>>>> Do you think that would be reasonable?
>>>>
>>>> That would be great. I hate that people have to care about these
>>>> support daemons, they should just be started automatically when they're
>>>> needed.
>>>>
>>>> Is /etc/krb5.keytab the best indicator?
>>>
>>> I was hoping you would tell me. :-)
>>
>> rpc.gssd has to run in cases where there is no /etc/krb5.keytab. Remember the discussion we had last year about using root?s user credential as the client?s machine credential? We want the kernel to be able to find out whether there is a machine credential available, and one can be available even if there is no keytab.
>
> Hi Chuck,
> thanks for reminding me about that! Yes we clearly cannot key
> off /etc/krb5.keytab for rpc.gssd.
>
> Maybe /etc/krb5.conf? Seems a bit lame.
> How about /etc/gssapi_mech.conf ?? rpc.gssd seems to exit if that doesn't
> exist. What if systemd is told not to run rpc.gssd if that file is
> missing?
>
> I guess that otherwise we can make it on-by-default, but document that people
> can turn it off with
> systemctl mask rpc-gssd
>
> which is probably easier that requiring "systemctl enable nfs-secure?.

Having rpc.gssd default on when NFS is enabled is much better than the current default. I think this would be an improvement. The administrative burden should be on the minority of people who care enough to want it disabled.

>
>>
>>> It occurred to me as a good test when I tried running rpc.svcgssd in a fresh
>>> VM and it wouldn't start. I eventually found the error message complaining
>>> that it couldn't find that file.
>>>
>>> It isn't perfect as an empty /etc/krb5.keytab will still result in failure
>>> and exit. However if a sysadmin has created a keytab and is using NFS, it
>>> seems reasonable to be ready to provide gss services.
>>>
>>> rpc.gssd doesn't fail in the same way, but it does complain if the file
>>> doesn't exist, so I suspect it is at least a good indicator.
>>>
>>> The only thing that bothers me is that gssd is theoretically more general
>>> than krb5. However as the reality seems to be that it is exactly krb5, I
>>> don't let that bother me too much.
>>>
>>>>
>>>> Simplest might be to start unconditionally and just not care if it
>>>> fails. Or is there a problem cluttering up logs with unimportant
>>>> failures?
>>>
>>> More a problem with starting things that aren't necessary, and possibly
>>> leaving them running.
>>> Every process you start adds a little to the boot time. We only get the best
>>> experience if everyone contributes a little bit, no matter how little.
>>> Also, every running process theoretically adds the to the attack service.
>>
>> rpc.gssd doesn?t expose a network listener. What attack vector is exposed by running rpc.gssd?
>
> Not all attacks are external. Also not all decisions relating to security
> are completely rational. And the 'attack surface' argument may apply better
> to other services but might cause a spill-over to people not wanting to run
> anything they don't have to.

If there is any local attack vector, folks who do run rpc.gssd would be concerned about that too. Any exposure should be addressed.

It might stand up for, say, rpcbind or rpc.statd, but I think the ?attack surface? argument doesn?t stand up for any security daemon worth its salt.

>
>>
>> Why would we insist on using a potentially insecure mechanism to provide strong security?
>>
>>> So some people will definitely not want these processes to be started.
>>
>> How many such people are there? The trend I expect is that more and more people will want to use security features, and fewer will want ?sec=sys,? especially if we work hard to make security features as painless as possible (as we should be doing).
>
> I honestly don't know. I may be seeing spectres that aren't there. But I've
> certainly heard a strong preference to not run unnecessary daemons more than
> once in the past.

Sure, I have too. But I can?t think of a reason to cater to that impulse in this case.

> When NFS is only used over a tightly coupled local network (infiniband?) you
> really do want sec=sys.

True, you might not want to use integrity or privacy in such environments due to their performance impact, but Kerberos authentication can provide value to make ACLs strong or to enable secure auditing.

Besides, there is zero performance impact to running rpc.gssd with sec=sys on a big client, even if there is no KDC within miles.

>
>
>>
>> It seems to me that provisionally starting rpc.gssd optimizes for a fairly uncommon case that will become less and less common going forward. I believe we should start designing as if security is the default use case. I would feel more comfortable if we knew more precisely what proportion of our users want to disable gssd and why.
>>
>>> i.e. I agree with SteveD:
>>>> I think we want to stay away (and move away) from unconditionally
>>>> starting anything?
>>
>> I believe we should make things simple both for us and for our customers. Thus I agree philosophically with the Gnome strategy of removing less frequently used configuration options to reduce complexity, make things easier to configure, more reliable, and easier to troubleshoot.
>
> I certainly agree with making things simple. If we can make a configuration
> irrelevant, e.g. by gets nfsd to auto-tune the number of threads so the
> setting becomes pointless, then I've very happy to remove that sort of
> configuration. But if a configuration option actually means something I
> certainly don't want to remove it.
>
> So I'm leaning towards having "systemctl {un,}mask rpc-gssd" be the
> configuration tool for rpc.gssd.

I like that better than the ?off-until-requested? behavior we have currently. IMO folks who want to disable rpc.gssd will be in the increasing minority and the rest of the world will take scant notice of the extra daemon, as long as we ensure it speaks only when necessary.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

2014-02-04 12:48:48

by Anthony Joseph Messina

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Monday, February 03, 2014 04:01:21 PM Steve Dickson wrote:
> This changes the current API... Today to enable/start this service
> today one does:
>
> systemctl enable nfs-server
> systemctl start nfs-server
>
> which would change to:
>
> systemctl enable nfs-server.target
> systemctl start nfs-server
>
> with the same daemons being started.
> This changed will cause existing scripts to fail...
> I guess I don't see the point of having a .target file.
>
> How is rpc.svcgssd enabled? Since the .service file does
> not have a [Install] section the systemctl enable rpc.svcgssd
> fails.
>
> Also how does gss-proxy come to play in all this? Maybe we
> just use gss-proxy by default and retire rpc.svcgssd.

Usually just a quite listener (end-user & small-time sysadmin) on this ML...

+1 for gss-proxy by default (for Fedora anyway). I've been using it
throughout F19 extensively in the KRB5/NFSv4.1 environment with great success.
I have nfs-secure-server.service "masked" via systemd to prevent it from being
started.

There seems to be only one strange issue I've come across with gss-proxy vs.
rpc.svcgssd: https://fedorahosted.org/gss-proxy/ticket/98. This is with
regard to how access for the "nfsnobody" user is handled. The ticket attempts
to show that with rpc.svcgssd, a host with host credentials and a user without
credentials can still access NFS shares with 0755 directories and 0644 files
(via the host credentials and mapped to the nfsnobody user). With gss-proxy,
I had to create user credentials for kojibuilder@REALM because the access
wasn't allowed via the nfsnobody path. I'm not sure if this is resolved, or
by design, etc. But it is the only issue I've seen with gss-proxy vs.
rpc.svcgssd.

Thanks. -A

--
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

Attachments:

signature.asc (198.00 B)
This is a digitally signed message part.

2014-02-03 21:01:29

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On 01/30/2014 01:24 AM, NeilBrown wrote:
>
> So:
> 1/ Do you agree that a collection of systemd unit files belongs in
> nfs-utils?
I think having a single way to start NFS across all distors would be
a very good thing...

> 2/ Do you think it reasonable to expect most (systemd using) distros to
> use the one set? I will certainly try to ensure openSUSE does if
> upstream accepts them.
I think I'll already agreed to this as well...

> 3/ Do you have any comments/question about those below?
I took a little closer look at these and actual tried to
get them to work in a Fedora environment. Here is what I found..

> diff --git a/systemd/README b/systemd/README
> new file mode 100644
> index 000000000000..f0fb68825499
> --- /dev/null
> +++ b/systemd/README
> @@ -0,0 +1,50 @@
> +
> +Notes about systemd unit files for nfs-utils.
> +
> +The unit files provided here should be sufficient for systemd
> +to manage all daemons and related services provides by nfs-utils.
> +
> +They do *not* include any unit files for separate services such as
> +rpc.rquotad (in the 'quota' package) or rpcbind.
> +
> +There are 4 units that can be 'enabled' or 'disabled' by systemctl, or
> +by a suitable 'preset' setting:
> +
> + nfs-server.target
> + If enabled, nfs service is started together with dependencies
> + such as mountd, statd, rpc.idmapd
This changes the current API... Today to enable/start this service
today one does:

systemctl enable nfs-server
systemctl start nfs-server

which would change to:

systemctl enable nfs-server.target
systemctl start nfs-server

with the same daemons being started.
This changed will cause existing scripts to fail...
I guess I don't see the point of having a .target file.

How is rpc.svcgssd enabled? Since the .service file does
not have a [Install] section the systemctl enable rpc.svcgssd
fails.

Also how does gss-proxy come to play in all this? Maybe we
just use gss-proxy by default and retire rpc.svcgssd.

> +
> + nfs-client.target
> + If enabled, daemons needs for an nfs client are enabled.
> + This does *not* include rpc.statd. the rpc-statd.service unit
> + is started by /usr/sbin/start-statd which mount.nfs will run
> + if statd is needed.
I am coming around to liking this one... but I think it should start
statd and configure lockd. Why not just roll the current nfs-lock
service under this umbrella? A simple systemctl restart nfs-client
would configure and start all of the needed daemons.

How would these daemons be restart and shutdown? Since this is a
target, systemctl restart and system stop don't do anything.

> +
> + nfs-secure.target
> + If enabled, then rpc.gssd will be run when either -client or
> + -server is started, and rpc.svcgssd will be run when -server
> + is started
I like that fact that rpc.gssd is started by nfs-client but
I don't like that API change. systemctl restart nfs-secure breaks

> +
> + nfs-blkmap.target
> + If enabled, then blkmapd will be run when nfs-client.target is
> + started.
Unless someone steps up and says why this is needed or if it will
ever be needed... I'm seriously thinking about dropping it from Fedora.

I think overall its workable but I just don't see the advantage
of using .targets over .service files...

steved.

2014-02-06 12:15:15

by Simo Sorce

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

----- Original Message -----
> On Wed, 5 Feb 2014 10:56:39 -0500 Chuck Lever <[email protected]> wrote:
>
> > Hi Neil!
> >
> >
> > On Feb 4, 2014, at 10:09 PM, NeilBrown <[email protected]> wrote:
> >
> > > On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields"
> > > <[email protected]>
> > > wrote:
> > >
> > >> On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote:
> > >>> Also, I've been wondering if we could avoid the need to explicitly
> > >>> enable
> > >>> the gss stuff by gating it on the existence of /etc/krb5.keytab.
> > >>> Do you think that would be reasonable?
> > >>
> > >> That would be great. I hate that people have to care about these
> > >> support daemons, they should just be started automatically when they're
> > >> needed.
> > >>
> > >> Is /etc/krb5.keytab the best indicator?
> > >
> > > I was hoping you would tell me. :-)
> >
> > rpc.gssd has to run in cases where there is no /etc/krb5.keytab. Remember
> > the discussion we had last year about using root’s user credential as the
> > client’s machine credential? We want the kernel to be able to find out
> > whether there is a machine credential available, and one can be available
> > even if there is no keytab.
>
> Hi Chuck,
> thanks for reminding me about that! Yes we clearly cannot key
> off /etc/krb5.keytab for rpc.gssd.
>
> Maybe /etc/krb5.conf? Seems a bit lame.
> How about /etc/gssapi_mech.conf ?? rpc.gssd seems to exit if that doesn't
> exist. What if systemd is told not to run rpc.gssd if that file is
> missing?

-1

> I guess that otherwise we can make it on-by-default, but document that
> people
> can turn it off with
> systemctl mask rpc-gssd

big +1

> which is probably easier that requiring "systemctl enable nfs-secure".

I would really like to see nfs-secure go away, it is a "configuration option" not some entity you start anyway so it never made sense to me.

Simo.

--
Simo Sorce * Red Hat, Inc. * New York

2014-02-04 18:48:54

by Anthony Joseph Messina

[permalink] [raw]

Subject: Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

On Tuesday, February 04, 2014 01:26:42 PM Steve Dickson wrote:
> > Also rpc.gssd will be run whenever nfs-server.target or nfs-client.target
> > is started.
>
> Why is rpc.gssd started when the nfs server is started? Possibly for secure
> loopback mounts??

Isn't this needed for KRB5/NFSv4.1 callbacks? I seem to remember needing this
on the server as well as the client, lest I get the frequent "gss upcall
timeout" issue. At least on Fedora that's how it's been for me.

-A

--
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

Attachments:

signature.asc (198.00 B)
This is a digitally signed message part.

2014-02-11 16:37:14