[systemd-devel] Fedora NFS systemd units

[Steve Dickson]

On 06/05/13 05:27, Colin Guthrie wrote:
> 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).
I didn't know a nss-lookup.target existed... would that be better than
After=named.service?

> 
>> 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?
It was request from https://bugzilla.redhat.com/show_bug.cgi?id=769879
Its not clear why a nfs.target is needed either but it does not break 
anything so I went with it.. 

> 
> 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.
No, As (I believe) f17 rpc.idmapd is no longer needed on the client.
The kernel now uses the nfsidmap(5) command to to do the idmapping.

steved.

> 
> 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
> 
>