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 > > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel