On Mon, Oct 29, 2012 at 9:56 PM, Thomas Bächler email@example.com wrote:
Am 29.10.2012 21:31, schrieb Jouke Witteveen:
On Thu, Oct 25, 2012 at 11:53 PM, Thomas Bächler firstname.lastname@example.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 email@example.com, 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.
I strongly disagree! In fact, they will keep netcfg alive.
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.
They're not "simple depencies", they're orderings of profiles. I agree that the systemd-only DEPENDS option confusing considering initscripts don't have it, but it is the right direction to go.
At the same time, systemd is basically a topological sorting mechanism, ie a dependency resolver. We inherently duplicate stuff here.
We don't duplicate anything. We use systemd to do the work for us. We allow systemd to properly resolve conflicts and dependencies.
The proposed setup is quite complex.
It is not! When you look at it, it only translates the information from our profiles to systemd units.
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.
First of all, starting a new project is a bad idea. We can have proper support NOW and improve that over time. Rewriting is a bad idea, transitioning is the right way. If you start something new, it'll take months before it is in a working state and more months until it matches netcfg's functionality. We can't live without a working networking solution for that long.
In the end, whatever you do, you'll end up using a generator like I did, because systemd cannot hold the networking information we need.
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).
These are all things we can change in netcfg now, instead of starting a new project.
I would also like to use systemd's power as much as possible.
In short, netctl should be a purified netcfg, depending on systemd. 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).
I agree we should improve and restructure netcfg's code - but the only way this will happen is by having a generator like the one I started.
I made a bold move and wrote netctl anyway. Without generators. This changes this discussion. We can now compare the feasibility of continuing one way or the other. I would appreciate it very (very) much if this new project got your and falconindy's (Dave Reisner) blessing. In the past year, you two have been by far the most valuable contributors, it would be a real shame to lose your input.
Thanks a ton, - Jouke