| Message ID | 20140130172451.7a354ce4@notabene.brown (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <neilb@suse.de> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jan 30, 2014, at 10:04 AM, Weston Andros Adamson <dros@monkey.org> 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 <neilb@suse.de> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <dros@monkey.org> 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 <neilb@suse.de> 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 30 Jan 2014 15:06:34 -0500 Steve Dickson <SteveD@redhat.com> 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
On Thu, 30 Jan 2014 13:52:06 -0500 "J. Bruce Fields" <bfields@fieldses.org> 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 <dros@monkey.org> 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 <neilb@suse.de> 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 majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/30/2014 05:14 PM, NeilBrown wrote: > On Thu, 30 Jan 2014 15:06:34 -0500 Steve Dickson <SteveD@redhat.com> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <SteveD@redhat.com> 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
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
On Tue, 04 Feb 2014 06:42:12 -0600 Anthony Messina <amessina@messinet.com> 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.
On Tuesday, February 04, 2014 08:24:26 AM Jeff Layton wrote: > On Tue, 04 Feb 2014 06:42:12 -0600 > > Anthony Messina <amessina@messinet.com> 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
On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote: > On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <SteveD@redhat.com> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Feb 4, 2014, at 11:20 AM, J. Bruce Fields <bfields@fieldses.org> wrote: > On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote: >> On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <SteveD@redhat.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/03/2014 05:34 PM, NeilBrown wrote: > On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <SteveD@redhat.com> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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
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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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 <SteveD@redhat.com> 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote: > > On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <SteveD@redhat.com> 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
On Tue, 04 Feb 2014 13:26:42 -0500 Steve Dickson <SteveD@redhat.com> wrote: > > > On 02/03/2014 05:34 PM, NeilBrown wrote: > > On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <SteveD@redhat.com> 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
Hi Neil! On Feb 4, 2014, at 10:09 PM, NeilBrown <neilb@suse.de> wrote: > On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields" <bfields@fieldses.org> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 5 Feb 2014 10:56:39 -0500 Chuck Lever <chuck.lever@oracle.com> wrote: > Hi Neil! > > > On Feb 4, 2014, at 10:09 PM, NeilBrown <neilb@suse.de> wrote: > > > On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields" <bfields@fieldses.org> > > 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
----- Original Message ----- > On Wed, 5 Feb 2014 10:56:39 -0500 Chuck Lever <chuck.lever@oracle.com> wrote: > > > Hi Neil! > > > > > > On Feb 4, 2014, at 10:09 PM, NeilBrown <neilb@suse.de> wrote: > > > > > On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields" > > > <bfields@fieldses.org> > > > 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.
----- 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 <SteveD@redhat.com> > >> 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.
On Feb 5, 2014, at 8:27 PM, NeilBrown <neilb@suse.de> wrote: > On Wed, 5 Feb 2014 10:56:39 -0500 Chuck Lever <chuck.lever@oracle.com> wrote: > >> Hi Neil! >> >> >> On Feb 4, 2014, at 10:09 PM, NeilBrown <neilb@suse.de> wrote: >> >>> On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields" <bfields@fieldses.org> >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 06, 2014 at 11:09:58AM -0500, Chuck Lever wrote: > > On Feb 5, 2014, at 8:27 PM, NeilBrown <neilb@suse.de> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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 <neilb@suse.de> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 10 Feb 2014 15:50:41 -0500 Steve Dickson <SteveD@redhat.com> 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 <neilb@suse.de> 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
On 02/10/2014 11:50 PM, NeilBrown wrote: > On Mon, 10 Feb 2014 15:50:41 -0500 Steve Dickson <SteveD@redhat.com> 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 <neilb@suse.de> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <SteveD@redhat.com> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 11, 2014 at 03:50:52PM +1100, NeilBrown wrote: > On Mon, 10 Feb 2014 15:50:41 -0500 Steve Dickson <SteveD@redhat.com> 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 <neilb@suse.de> 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). I still pretty vague on exactly what problems we solve by turning off these daemons by default. --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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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 <SteveD@redhat.com> 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 <neilb@suse.de> 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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 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 <SteveD@redhat.com> 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 <neilb@suse.de> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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 <SteveD@redhat.com> 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 <neilb@suse.de> 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/systemd/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
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