Re: [systemd-devel] Fedora NFS systemd units
On 05/08/2013 10:58 AM, Steve Dickson wrote: It was request fromhttps://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.. Unit and administrative simplification JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora NFS systemd units
'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
Re: [systemd-devel] Fedora NFS systemd units
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-serv
Re: [systemd-devel] Fedora NFS systemd units
On 06/05/13 15:36, Guillaume Rousse wrote: > Le 06/05/2013 11:27, Colin Guthrie a écrit : >> 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). > We didn't :) > > I stole the nfs-common sysvinit script from Debian, to hide the complexity of > the gazillion different daemons needed. AFAIK, Fedora always used > single-executable-services. > > > And indeed idmapd is needed both sides for NFSv4. This is no longer the case on the client. The kernel now calls the nfsidmap(5) command to do the idmapping, which is the reason rpc.idmapd is only started on the server side. steved. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora NFS systemd units
On 06/05/13 06:29, "Jóhann B. Guðmundsson" wrote: > On 05/06/2013 09:27 AM, 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. > > Steve did not pull in all the units a while back [1] ( which I had broken > into special nfs target ) so I honestly expect nfs implemenation to be > utterly broken ( as it used to be ) in Fedora + the units need to be > rewritten and necessary changes done to dracut for root on nfs4 to work ( > which I did not test or have in mind when creating them ). > > JBG > > 1. https://bugzilla.redhat.com/show_bug.cgi?id=769879 I just did... https://bugzilla.redhat.com/show_bug.cgi?id=769879#c11 Please verify that everything that is needed is there... steved. > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora NFS systemd units
Le 06/05/2013 11:27, Colin Guthrie a écrit : 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). We didn't :) I stole the nfs-common sysvinit script from Debian, to hide the complexity of the gazillion different daemons needed. AFAIK, Fedora always used single-executable-services. And indeed idmapd is needed both sides for NFSv4. -- Guillaume ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora NFS systemd units
On 05/06/2013 09:27 AM, 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. Steve did not pull in all the units a while back [1] ( which I had broken into special nfs target ) so I honestly expect nfs implemenation to be utterly broken ( as it used to be ) in Fedora + the units need to be rewritten and necessary changes done to dracut for root on nfs4 to work ( which I did not test or have in mind when creating them ). JBG 1. https://bugzilla.redhat.com/show_bug.cgi?id=769879 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
