[arch-projects] [netcfg] [PATCH 3/3] systemd: Replace netcfg.service with a generator in order to get proper dependencies

[Leonid Isaev]

On Mon, 29 Oct 2012 21:31:13 +0100
Jouke Witteveen <j.witteveen at gmail.com> wrote:

> On Thu, Oct 25, 2012 at 11:53 PM, Thomas Bächler <thomas at archlinux.org>
> wrote:
> > Until now, netcfg might fail to start because it is started too early
> > (this actually happened to me quite regularly). To fix this, we need to
> > make systemd aware of the dependencies of a profile.
> >
> > This commit adds a systemd generator that creates profiles with the names
> >    netcfg-profile-$PROFILE.service
> > on boot. The ugly part: You cannot permanently enable such a profile, as
> > it is generated during boot. To enable it, put it in NETWORKS=() - it will
> > always be loaded, unless netcfg-profiles.target is masked. The old
> > netcfg.service has been removed. This scheme does not support
> > NETWORKS=(last) anymore, since we cannot determine which units were
> > manually started or stopped before.
> >
> > If you add a new profile, you need to reload the systemd configuration so
> > the service file shows up. We should encourage people to use systemctl to
> > start and stop their profiles instead of netcfg.
> >
> > While this scheme is less intuitive than netcfg at profilename.service, it
> > is the only way to provide proper dependencies during boot.
> >
> > A note on backgrounding: All netcfg profiles are now started in parallel,
> > so backgrounding is unnecessary. However, due to the correct dependencies
> > in the units, everything should work fine.
> >
> > Due to a bug in systemd's dependency resolution with devices, this patch
> > requires systemd v195 to work.
> 
> This patch (and all the related ones) might be the end of netcfg.
> There are a few reasons for which I don't like to merge them.
> 
> This will make it very difficult to maintain dual initscripts and
> systemd compatibility. For instance, in the NETWORKS array, it is
> possible to specify simple dependency relations between profiles. The
> new approach introduces a new, systemd-specific DEPENDS array for
> this. At the same time, systemd is basically a topological sorting
> mechanism, ie a dependency resolver. We inherently duplicate stuff
> here.
> 
> The proposed setup is quite complex. I feel it is likely possible to
> do netcfg's job in a systemd empowered way and I also feel that the
> proposed way is not the proper way of doing that. Therefore I suggest
> to start a new project for profile based network management as we have
> done with netcfg, but tailored to systemd. Let's call it netctl.

Makes a lot of sense to me. So basically, what is shipped is a set of template
services to be put by administrator in /etc/systemd/* ?

> 
> My goal for netctl would be to learn from netcfg experiences. No more
> 'menu' or 'last' on places where profile names are supposed to be put,
> no more connection types without interfaces, no more incomprehensible
> execution trails (there can be a lot of recursion, especially in calls
> to the ethernet connection code). I would also like to use systemd's
> power as much as possible. This might mean to hope for Lennarts
> cooperation in at least two places:
> 1) write a proper ifplugd service (possibly ifplugd needs to be altered),
> 2) support variables from EnvironmentFile in the BindsTo/After part of
> a unit (so that we can put our interfaces there).
> There will be (at least) two types of service files: one for simple
> wired/wireless connections with a fixed interface, one for connections
> that generate an interface (for example: bond connections). The latter
> will be the difficult kind. In any case, I would like the profile
> files to be of the kind systemd accepts as environment files, but very
> similar (in some cases even compatible) to those of netcfg.

Two quick questions due to my ignorance regarding systemd. With bond/bridge
interfaces, does one have to ensure (through Requires/After) that possible
iface renaming (via udev) takes place before actual profile is execed (with
initscripts udev always comes 1st, so it works OK)? Also, if a wpa profile is
started, what has to be done to protect passwords from being _possibly_
exposed via systemctl show -- setting permission 600 root:root as is done now?

> 
> In short, netctl should be a purified netcfg, depending on systemd.[1]
> We might loose a few features of netcfg, but we would gain a lot of
> simplicity and ease of use (for those used to systemd).
> 
> As for the problem addressed by the presented patch: we could put
> After=udev-settle.service
> in the services. A user can then prevent the case that netcfg is
> started before there interfaces appear by enabling the udev-settle
> service.
> 
> Any comments on this wild plan?
> 
> - Jouke
> 
> [1] and coreutils, iproute2, openresolv (let's do it right, this
> time), and optionally also wpa_supplicant, wpa_actiond, ifplugd,
> ifenslave, bridge-utils, dialog...

Can one at all use dialog with systemd boot?

-- 
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20121029/13463526/attachment.asc>