On Mon, 29 Oct 2012 21:31:13 +0100 Jouke Witteveen <j.witteveen@gmail.com> wrote:
On Thu, Oct 25, 2012 at 11:53 PM, Thomas Bächler <thomas@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@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