[systemd-devel] Fedora NFS systemd units

Wed May 8 04:54:44 PDT 2013

'Twas brillig, and Steve Dickson at 08/05/13 11:58 did gyre and gimble:
> 
> 
> 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?

It's more generic. So if things other than bind provide name lookups
they should hold up nss-lookup.target to allow for such ordering.

It's not failsafe, but it's likely a better fit and named.service
directly IMO (others please feel free to correct me 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?
> 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.. 

Yeah, but the current units are quite different from the ones submitted
in that bug.

All of the ones from the bug have WantedBy=nfs.target. In your packages
git repo http://pkgs.fedoraproject.org/cgit/nfs-utils.git/tree/ most
units have WantedBy=multi-user.target instead, along with various other
modifications.

While some modifications are good, the confusion for me now lies in what
needs to be enabled when etc.

FYI, here are my tidyups (which should mostly apply to your files I think):
http://svnweb.mageia.org/packages?view=revision&revision=412429
http://svnweb.mageia.org/packages?view=revision&revision=412433

The main bit is removing the option from sysadmins for components they
shouldn't need to care about (i.e. removing several [Install] sections).
Systemd will start them automatically when required and the sysadmin
doesn't have to get the "magic recipe" to make things work).

I think this gets them in a better state, but some work is still needed
to make it first class and as automatic as our previous solution (more
below).

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

Ahh that might be a difference between you and us then I guess. I
believe we still require it (we certainly did in Mageia 2), but perhaps
not. Will have to investigate. My changes above assume it's needed, but
it would be trivial to leave it out (basically just remove
PartOf=nfs.target and add BindTo=nfs-server.service in nfs-idmap.service
and remove the Require=nfs-idmap.service from nfs.target and add
Require=nfs-idmap.service to nfs-server.service - all assuming the idmap
daemon is still required on the server of course)

Longer term, I would like to see more things happen magically/automatically.

For example in the "old days" we had a script (apparently from Debian)
to do a bit of parsing options in /etc/fstab and automatically started
rpc.gssd if it detected appropriate settings.

This means that the init script inherently knew about any secure mounts.
This means the systemd fstab parser really needs to be aware of this.

Here we have a few options to continue and get this nice automatic
behaviour.
 1. We modify systemd's fstab-generator to "know" more about nfs stuff.

 2. We modify systemd's fstab-generator to check for other generators
for specific filesystem types i.e. if systemd-fstab-generator-nfs
exists, the main generator will simply ignore those lines in fstab and
assume some other generator will take care of them. This wouldn't be
specific to nfs but rather to the file system type, so we could provide
a systemd-fstab-generator-sshfs etc too should the need arise.

 3. As our solution only really needs slight modification of the mount
units generated, we could write a totally independent generator which
simply uses the drop-ins system to augment the mount units created by
systemd-fstab-generator and add the appropriate requires and ordering
info to the units. This generator would have to run after the systemd
one, but I believe that can be arranged (is the order based on filename?)

To me, 3 seems like the cleanest solution. (1 is nasty generally from a
design perspective, and 2 requires both a second generator and several
stats() for all users where 3 only requires extra work when nfs-utils is
actually installed).

Without actually committing to doing any work, does this seem like a
sensible approach to get the desired behaviour? This will hopefully be
totally generic and can be pushed upstream and used by all distros
thereafter (the only exception might be the sysconfig parsing stuff
which upstream may want to exclude, but could be readded more easily at
a distro level if so desired - that said, I'd suggest a .d dropin in
/etc/systemd tree could act as a modifier for the unit rather than a
file in /etc/sysconfig if this is the approach currently favoured by
systemd upstream)

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/