[systemd-devel] Fedora NFS systemd units

[Colin Guthrie]

Hi,

Just trying to work out a few problems on our (Mageia's) NFS packages.

As with a lot of things we often take the units from Fedora (we will
soon have a nicer way to share units I hope - need to get release out
the way before I can help and put my bit of the work into this tho').

However I'm a bit confused by the latest units.

> nfs-server.service:[Unit]
> nfs-server.service:Description=NFS Server
> nfs-server.service:Requires=proc-fs-nfsd.mount var-lib-nfs-rpc_pipefs.mount rpcbind.service
> nfs-server.service:Requires=nfs-idmap.service nfs-mountd.service nfs-rquotad.service
> nfs-server.service:After=network.target named.service
> nfs-server.service:[Service]
> nfs-server.service:Type=oneshot
> nfs-server.service:RemainAfterExit=yes
> nfs-server.service:StandardError=syslog+console
> nfs-server.service:EnvironmentFile=-/etc/sysconfig/nfs
> nfs-server.service:ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig
> nfs-server.service:ExecStartPre=/usr/sbin/exportfs -r
> nfs-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT
> nfs-server.service:ExecStartPost=-/usr/lib/nfs-utils/scripts/nfs-server.postconfig
> nfs-server.service:ExecStop=/usr/sbin/rpc.nfsd 0
> nfs-server.service:ExecStopPost=/usr/sbin/exportfs -f
> nfs-server.service:[Install]
> nfs-server.service:WantedBy=multi-user.target

This is the main server unit. It requires the idmap, mountd and rquotad
services.

It has After=named.service. Should this not be After=nss-lookup.target
instead? Bind/named might not be the only thing that does name lookups
after all and nss-lookup.target is meant to encapsulate this does it
not? (e.g. ldap could factor in here).

> nfs-idmap.service:[Unit]
> nfs-idmap.service:Description=NFSv4 ID-name mapping daemon
> nfs-idmap.service:BindTo=nfs-server.service
> nfs-idmap.service:After=nfs-server.service
> nfs-idmap.service:[Service]
> nfs-idmap.service:Type=forking
> nfs-idmap.service:StandardError=syslog+console
> nfs-idmap.service:EnvironmentFile=-/etc/sysconfig/nfs
> nfs-idmap.service:ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS
> nfs-idmap.service:[Install]
> nfs-idmap.service:WantedBy=nfs.target

This unit is bound to nfs-server so it will follow it's start/stop
cycle. Yet it is also wanted by nfs.target. What purpose does nfs.target
actually serve here?

Ditto for the mountd and rquotad units which are similarly structured.

Also, It is my understanding (and feel free to correct me here) but
nfs-idmap is often needed on client systems also? I'm sure I had to
configure a client in the past to ensure idmap was running in order to
avoid permissions problems and users getting mapped to the 65k uid that
means "nobody.

I had to force this by setting NEEDS_IDMAP=yes in the old sysconfig file
/etc/sysconfig/nfs-common (I'm pretty sure we had the same sysvinit
setup as Fedora in the past).

This being the case should idmap be enablable as an independent unit for
client systems (same as nfs-lock.service). Again, feel free to correct
me here if I'm wrong.

If this is the case the BindTo would have to be dropped, but the Require
could still be kept. The install rule would have to be made independant
of nfs.target. To aid sysadmin clarity, it would make sense to have the
nfs-server.service's [Install] section to have an Also= directive so
that the relevant unit's enabled/disabled status's are shown more
clearly to sysadmins.

If mountd and rquotad make no sense to run separately then they should
just have their [Install] sections nuked (more comments about rquoatad
below tho').

> nfs.target:[Unit]
> nfs.target:Description=Network File System Server
> nfs.target:Requires=var-lib-nfs-rpc_pipefs.mount proc-fs-nfsd.mount rpcbind.service
> nfs.target:After=network.target named.service 
> nfs.target:[Install]
> nfs.target:WantedBy=multi-user.target

If nfs.target is "Network File Systemd Server", and the units are
already set to be BindTo AND Require, then I really don't grok what
nfs.target is for. It's not like it provides any additional level of
isolation or configurability. In fact, enabling/disabling idmap, mountd
and rquotad services will have no effect anyway due to them being
requires/bound to nfs-server.service. Should this target just be dropped?


> nfs-rquotad.service:[Unit]
> nfs-rquotad.service:Description=NFS Remote Quota Server
> nfs-rquotad.service:BindTo=nfs-server.service
> nfs-rquotad.service:After=nfs-server.service
> nfs-rquotad.service:[Service]
> nfs-rquotad.service:Type=forking
> nfs-rquotad.service:StandardError=syslog+console
> nfs-rquotad.service:EnvironmentFile=-/etc/sysconfig/nfs
> nfs-rquotad.service:ExecStart=-/usr/sbin/rpc.rquotad $RPCRQUOTADOPTS
> nfs-rquotad.service:[Install]
> nfs-rquotad.service:WantedBy=nfs.target

This package refers to a binary that is actually shipped in a different
package (rpc.rquotad comes from the "quota" package).

Shipping units in different packages to the binaries is pretty strange.
Shouldn't this unit be renamed to rpc-rquotad.service and shipped
instead in the quota package? Perhaps with no [Install] rule or one that
makes sense in isolation if it can be sensibly used separately from nfs.


> nfs-mountd.service:[Unit]
> nfs-mountd.service:Description=NFS Mount Daemon
> nfs-mountd.service:BindTo=nfs-server.service
> nfs-mountd.service:After=nfs-server.service
> nfs-mountd.service:[Service]
> nfs-mountd.service:Type=forking
> nfs-mountd.service:EnvironmentFile=-/etc/sysconfig/nfs
> nfs-mountd.service:ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDOPTS
> nfs-mountd.service:StandardError=syslog+console
> nfs-mountd.service:[Install]
> nfs-mountd.service:WantedBy=nfs.target

The variable name here ends in OPTS, but all the others end in ARGS.
Consistency aids understanding and this is already confusing for me, so
every little helps!!


> nfs-blkmap.service:[Unit]
> nfs-blkmap.service:Description=pNFS block layout mapping daemon
> nfs-blkmap.service:Wants=var-lib-nfs-rpc_pipefs.mount
> nfs-blkmap.service:Requires=var-lib-nfs-rpc_pipefs.mount
> nfs-blkmap.service:[Service]
> nfs-blkmap.service:Type=forking
> nfs-blkmap.service:StandardError=syslog+console
> nfs-blkmap.service:EnvironmentFile=-/etc/sysconfig/nfs
> nfs-blkmap.service:ExecStart=/usr/sbin/blkmapd $BLKMAPDARGS
> nfs-blkmap.service:[Install]
> nfs-blkmap.service:WantedBy=multi-user.target

No real comment here other than I am left still unsure if I need to
manually enable this or not and under what circumstances I should care etc.


> nfs-lock.service:[Unit]
> nfs-lock.service:Description=NFS file locking service.
> nfs-lock.service:Requires=rpcbind.service network.target
> nfs-lock.service:After=network.target named.service rpcbind.service
> nfs-lock.service:Before=remote-fs-pre.target
> nfs-lock.service:[Service]
> nfs-lock.service:Type=forking
> nfs-lock.service:StandardError=syslog+console
> nfs-lock.service:EnvironmentFile=-/etc/sysconfig/nfs
> nfs-lock.service:ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-lock.preconfig
> nfs-lock.service:ExecStart=/sbin/rpc.statd $STATDARG
> nfs-lock.service:# Make sure lockd's ports are reset
> nfs-lock.service:ExecStopPost=-/sbin/sysctl -w fs.nfs.nlm_tcpport=0 fs.nfs.nlm_udpport=0
> nfs-lock.service:[Install]
> nfs-lock.service:WantedBy=multi-user.target


No comment here really. The only thing I would say is that
rpcbind.target also exists... should this be used as a higher level
After= (rather than rpcbind.service) or should we be aiming to kill
rpcbind.target in the long term?


> nfs-secure-server.service:[Unit]
> nfs-secure-server.service:Description=Secure NFS Server
> nfs-secure-server.service:Requires=var-lib-nfs-rpc_pipefs.mount nfs-server.service
> nfs-secure-server.service:After=syslog.target var-lib-nfs-rpc_pipefs.mount nfs-server.service 
> nfs-secure-server.service:[Service]
> nfs-secure-server.service:Type=forking
> nfs-secure-server.service:StandardError=syslog+console
> nfs-secure-server.service:EnvironmentFile=-/etc/sysconfig/nfs
> nfs-secure-server.service:ExecStart=/usr/sbin/rpc.svcgssd $RPCSVCGSSDARGS
> nfs-secure-server.service:[Install]
> nfs-secure-server.service:WantedBy=multi-user.target
> 
> nfs-secure.service:[Unit]
> nfs-secure.service:Description=Secure NFS
> nfs-secure.service:Requires=var-lib-nfs-rpc_pipefs.mount
> nfs-secure.service:After=syslog.target var-lib-nfs-rpc_pipefs.mount
> nfs-secure.service:[Service]
> nfs-secure.service:Type=forking
> nfs-secure.service:StandardError=syslog+console
> nfs-secure.service:EnvironmentFile=-/etc/sysconfig/nfs
> nfs-secure.service:ExecStart=/usr/sbin/rpc.gssd $RPCGSSDARGS
> nfs-secure.service:[Install]
> nfs-secure.service:WantedBy=multi-user.target


Only comment here is that it is unclear from the unit names what these
actually do and how they interoperate. Do I need to enable both for
things to work? If so why are they not using Requires/BindTo like the
other units? If they work independently (perhaps one is server and one
client?), then the descriptions need to be adjusted I think.



All in all, I think there is scope to tidy these up and make them
better. Adding man pages and Documentation= directives would also help a
lot.

Happy to help out here if I can get some feedback on some of the points
above.

Many thanks.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/