For net-auto-wired and -wireless, a new @-unit has to be instantiated with the interface name. Static profiles are enabled automatically when listed in /etc/conf.d/network NETWORKS= - the old netcfg.service has thus been removed.
This breaks the NETWORKS=(last) functionality, and I don't think we can handle it properly right now. NETWORKS=(menu) could never work with systemd anyway.
I'd really like to remove netcfg@.service, net-auto-wired.service and net-auto-wireless.service at some point, but that will break existing setups. I don't know if we should go ahead with this.
What we should definitely do is change netcfg, wifi-menu and netcfg-menu to use systemctl to start profiles when called manually. This would ensure systemd can track the profiles properly, knows how to shut them down and can track their processes.
--- systemd/net-auto-wired.service | 4 +++- systemd/net-auto-wireless.service | 3 +-- 2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/systemd/net-auto-wired.service b/systemd/net-auto-wired.service index 7bb885d..badaebf 100644 --- a/systemd/net-auto-wired.service +++ b/systemd/net-auto-wired.service @@ -1,5 +1,7 @@ [Unit] -Description=Provides automatic netcfg wired connection +Description=Automatic wired network connection +Before=network.target +Wants=network.target
[Service] EnvironmentFile=/etc/conf.d/netcfg diff --git a/systemd/net-auto-wireless.service b/systemd/net-auto-wireless.service index ab57ab9..e437a64 100644 --- a/systemd/net-auto-wireless.service +++ b/systemd/net-auto-wireless.service @@ -1,5 +1,5 @@ [Unit] -Description=Provides automatic netcfg wireless connection +Description=Automatic wireless network connection Before=network.target Wants=network.target
@@ -7,7 +7,6 @@ Wants=network.target EnvironmentFile=/etc/conf.d/netcfg ExecStart=/usr/bin/netcfg-wpa_actiond $WIRELESS_INTERFACE ExecStop=/usr/bin/netcfg-wpa_actiond stop $WIRELESS_INTERFACE -RemainAfterExit=yes Type=forking
[Install]
On Thu, Oct 25, 2012 at 11:20 PM, Thomas Bächler thomas@archlinux.org wrote:
systemd/net-auto-wired.service | 4 +++- systemd/net-auto-wireless.service | 3 +-- 2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/systemd/net-auto-wired.service b/systemd/net-auto-wired.service index 7bb885d..badaebf 100644 --- a/systemd/net-auto-wired.service +++ b/systemd/net-auto-wired.service @@ -1,5 +1,7 @@ [Unit] -Description=Provides automatic netcfg wired connection +Description=Automatic wired network connection +Before=network.target +Wants=network.target
No! FS#32161
[Service] EnvironmentFile=/etc/conf.d/netcfg diff --git a/systemd/net-auto-wireless.service b/systemd/net-auto-wireless.service index ab57ab9..e437a64 100644 --- a/systemd/net-auto-wireless.service +++ b/systemd/net-auto-wireless.service @@ -1,5 +1,5 @@ [Unit] -Description=Provides automatic netcfg wireless connection +Description=Automatic wireless network connection Before=network.target Wants=network.target
@@ -7,7 +7,6 @@ Wants=network.target EnvironmentFile=/etc/conf.d/netcfg ExecStart=/usr/bin/netcfg-wpa_actiond $WIRELESS_INTERFACE ExecStop=/usr/bin/netcfg-wpa_actiond stop $WIRELESS_INTERFACE -RemainAfterExit=yes Type=forking
[Install]
1.8.0
One gripe: wouldn't it be better to mention 'netcfg' in the descriptions, somehow?
Am 29.10.2012 16:46, schrieb Jouke Witteveen:>> [Unit]
-Description=Provides automatic netcfg wireless connection +Description=Automatic wireless network connection Before=network.target Wants=network.target
One gripe: wouldn't it be better to mention 'netcfg' in the descriptions, somehow?
Yes, we could do that. We just need to keep in mind that systemd prints "Starting $DESCRIPTION" and "Started $DESCRIPTION" in the logs, so the old descriptions were awful:
Would this work? Description=Automatic wire{d,less} network connection via netcfg
This has the advantage that we can (since systemd 195) have a proper dependency on the wireless device. These services deprecate the non-instantiated variants and should eventually replace them. --- systemd/net-auto-wired@.service | 13 +++++++++++++ systemd/net-auto-wireless@.service | 14 ++++++++++++++ 2 files changed, 27 insertions(+) create mode 100644 systemd/net-auto-wired@.service create mode 100644 systemd/net-auto-wireless@.service
diff --git a/systemd/net-auto-wired@.service b/systemd/net-auto-wired@.service new file mode 100644 index 0000000..9deede1 --- /dev/null +++ b/systemd/net-auto-wired@.service @@ -0,0 +1,13 @@ +[Unit] +Description=Automatic wired network connection on %i +Before=network.target +Wants=network.target +BindsTo=sys-subsystem-net-devices-%i.device +After=sys-subsystem-net-devices-%i.device + +[Service] +ExecStart=/usr/bin/ifplugd -i %i -r /etc/ifplugd/netcfg.action -fIns +ExecStop=/usr/bin/netcfg iface-down %i + +[Install] +WantedBy=multi-user.target diff --git a/systemd/net-auto-wireless@.service b/systemd/net-auto-wireless@.service new file mode 100644 index 0000000..231ffd1 --- /dev/null +++ b/systemd/net-auto-wireless@.service @@ -0,0 +1,14 @@ +[Unit] +Description=Automatic wireless network connection on %i +Before=network.target +Wants=network.target +BindsTo=sys-subsystem-net-devices-%i.device +After=sys-subsystem-net-devices-%i.device + +[Service] +ExecStart=/usr/bin/netcfg-wpa_actiond %i +ExecStop=/usr/bin/netcfg-wpa_actiond stop %i +Type=forking + +[Install] +WantedBy=multi-user.target
On Thu, Oct 25, 2012 at 11:20 PM, Thomas Bächler thomas@archlinux.org wrote:
This has the advantage that we can (since systemd 195) have a proper dependency on the wireless device. These services deprecate the non-instantiated variants and should eventually replace them.
systemd/net-auto-wired@.service | 13 +++++++++++++ systemd/net-auto-wireless@.service | 14 ++++++++++++++ 2 files changed, 27 insertions(+) create mode 100644 systemd/net-auto-wired@.service create mode 100644 systemd/net-auto-wireless@.service
diff --git a/systemd/net-auto-wired@.service b/systemd/net-auto-wired@.service new file mode 100644 index 0000000..9deede1 --- /dev/null +++ b/systemd/net-auto-wired@.service @@ -0,0 +1,13 @@ +[Unit] +Description=Automatic wired network connection on %i +Before=network.target +Wants=network.target +BindsTo=sys-subsystem-net-devices-%i.device +After=sys-subsystem-net-devices-%i.device
+[Service] +ExecStart=/usr/bin/ifplugd -i %i -r /etc/ifplugd/netcfg.action -fIns +ExecStop=/usr/bin/netcfg iface-down %i
+[Install] +WantedBy=multi-user.target diff --git a/systemd/net-auto-wireless@.service b/systemd/net-auto-wireless@.service new file mode 100644 index 0000000..231ffd1 --- /dev/null +++ b/systemd/net-auto-wireless@.service @@ -0,0 +1,14 @@ +[Unit] +Description=Automatic wireless network connection on %i +Before=network.target +Wants=network.target +BindsTo=sys-subsystem-net-devices-%i.device +After=sys-subsystem-net-devices-%i.device
+[Service] +ExecStart=/usr/bin/netcfg-wpa_actiond %i +ExecStop=/usr/bin/netcfg-wpa_actiond stop %i +Type=forking
+[Install]
+WantedBy=multi-user.target
1.8.0
This one looks fine. Even if they do not replace their counterparts, they have some value. I will merge this one.
- Jouke
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. --- Makefile | 4 +++ config/netcfg | 5 +--- systemd/netcfg-generator | 59 ++++++++++++++++++++++++++++++++++++++++++ systemd/netcfg-profiles.target | 2 ++ systemd/netcfg.service | 14 ---------- 5 files changed, 66 insertions(+), 18 deletions(-) create mode 100755 systemd/netcfg-generator create mode 100644 systemd/netcfg-profiles.target delete mode 100644 systemd/netcfg.service
diff --git a/Makefile b/Makefile index bbada3f..009bca5 100644 --- a/Makefile +++ b/Makefile @@ -35,9 +35,13 @@ install: install-docs rc.d/net-auto-wireless \ $(DESTDIR)/etc/rc.d/ install -d $(DESTDIR)/usr/lib/systemd/system + install -d $(DESTDIR)/usr/lib/systemd/system/multi-user.target.wants install -m644 \ systemd/*.service \ + systemd/*.target \ $(DESTDIR)/usr/lib/systemd/system/ + ln -sf /usr/lib/systemd/system/netcfg-profiles.target $(DESTDIR)/usr/lib/systemd/system/multi-user.target.wants/ + install -Dm755 systemd/netcfg-generator /usr/lib/systemd/system-generators/netcfg-generator
install-docs: docs install -d $(DESTDIR)/usr/share/man/{man5,man8} diff --git a/config/netcfg b/config/netcfg index 59ee57c..d68d06f 100644 --- a/config/netcfg +++ b/config/netcfg @@ -1,9 +1,6 @@ # Enable these netcfg profiles at boot time. -# - prefix an entry with a '@' to background its startup -# - set to 'last' to restore the profiles running at the last shutdown -# - set to 'menu' to present a menu (requires the dialog package) # Network profiles are found in /etc/network.d -NETWORKS=(last) +NETWORKS=()
# Specify the name of your wired interface for net-auto-wired WIRED_INTERFACE="eth0" diff --git a/systemd/netcfg-generator b/systemd/netcfg-generator new file mode 100755 index 0000000..2e37873 --- /dev/null +++ b/systemd/netcfg-generator @@ -0,0 +1,59 @@ +#!/bin/bash + +[[ -d $1 ]] || exit 1 + +. /usr/lib/network/network + +write_template() { + local profile=$1; shift + cat << EOF +[Unit] +Description=Netcfg networking service for profile ${profile} +SourcePath=${PROFILE_DIR}/${profile} +Before=network.target +Wants=network.target +Conflicts=netcfg@${profile}.service +EOF + (( $# )) && printf '%s\n' "$@" + cat << EOF + +[Service] +Type=oneshot +RemainAfterExit=yes +ExecStart=/usr/bin/netcfg check-iface ${profile} +ExecStop=-/usr/bin/netcfg down ${profile} +KillMode=none +EOF +} + +list_profiles | while read p; do + load_profile "${p}" || continue + systemd_devices=() + extra_deps=() + case ${CONNECTION} in + bond) + for iface in ${SLAVE_INTERFACES[*]}; do + systemd_devices+=(sys-subsystem-net-devices-${iface}.device) + done + ;; + bridge) + for iface in ${BRIDGE_INTERFACES[*]}; do + systemd_devices+=(sys-subsystem-net-devices-${iface}.device) + done + ;; + ethernet|pppoe|wireless) + systemd_devices+=(sys-subsystem-net-devices-${INTERFACE}.device) + ;; + vlan) + systemd_devices+=(sys-subsystem-net-devices-${VLAN_PHYS_DEV}.device) + ;; + esac + [[ ${#systemd_devices[@]} > 0 ]] && extra_deps+=("BindsTo=${systemd_devices[*]}" "After=${systemd_devices[*]}") + write_template "${p}" "${extra_deps[@]}" > "$1/netcfg-profile-${p}.service" +done + +. /etc/conf.d/netcfg +mkdir "$1/netcfg-profiles.target.wants" +for p in "${NETWORKS[@]}"; do + [[ -f "$1/netcfg-profile-${p}.service" ]] && ln -s "$1/netcfg-profile-${p}.service" "$1/netcfg-profiles.target.wants/netcfg-profile-${p}.service" +done diff --git a/systemd/netcfg-profiles.target b/systemd/netcfg-profiles.target new file mode 100644 index 0000000..54af553 --- /dev/null +++ b/systemd/netcfg-profiles.target @@ -0,0 +1,2 @@ +[Unit] +Description=Netcfg network profiles diff --git a/systemd/netcfg.service b/systemd/netcfg.service deleted file mode 100644 index f400be0..0000000 --- a/systemd/netcfg.service +++ /dev/null @@ -1,14 +0,0 @@ -[Unit] -Description=Netcfg multi-profile daemon -Before=network.target -Wants=network.target - -[Service] -Type=oneshot -RemainAfterExit=yes -ExecStart=/usr/bin/netcfg-daemon start -ExecStop=/usr/bin/netcfg-daemon stop -KillMode=none - -[Install] -WantedBy=multi-user.target
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. --- Makefile | 4 +++ config/netcfg | 5 +--- systemd/netcfg-generator | 59 ++++++++++++++++++++++++++++++++++++++++++ systemd/netcfg-profiles.target | 2 ++ systemd/netcfg.service | 14 ---------- 5 files changed, 66 insertions(+), 18 deletions(-) create mode 100755 systemd/netcfg-generator create mode 100644 systemd/netcfg-profiles.target delete mode 100644 systemd/netcfg.service
diff --git a/Makefile b/Makefile index bbada3f..009bca5 100644 --- a/Makefile +++ b/Makefile @@ -35,9 +35,13 @@ install: install-docs rc.d/net-auto-wireless \ $(DESTDIR)/etc/rc.d/ install -d $(DESTDIR)/usr/lib/systemd/system + install -d $(DESTDIR)/usr/lib/systemd/system/multi-user.target.wants install -m644 \ systemd/*.service \ + systemd/*.target \ $(DESTDIR)/usr/lib/systemd/system/ + ln -sf /usr/lib/systemd/system/netcfg-profiles.target $(DESTDIR)/usr/lib/systemd/system/multi-user.target.wants/ + install -Dm755 systemd/netcfg-generator /usr/lib/systemd/system-generators/netcfg-generator
install-docs: docs install -d $(DESTDIR)/usr/share/man/{man5,man8} diff --git a/config/netcfg b/config/netcfg index 59ee57c..d68d06f 100644 --- a/config/netcfg +++ b/config/netcfg @@ -1,9 +1,6 @@ # Enable these netcfg profiles at boot time. -# - prefix an entry with a '@' to background its startup -# - set to 'last' to restore the profiles running at the last shutdown -# - set to 'menu' to present a menu (requires the dialog package) # Network profiles are found in /etc/network.d -NETWORKS=(last) +NETWORKS=()
# Specify the name of your wired interface for net-auto-wired WIRED_INTERFACE="eth0" diff --git a/systemd/netcfg-generator b/systemd/netcfg-generator new file mode 100755 index 0000000..8b6f3af --- /dev/null +++ b/systemd/netcfg-generator @@ -0,0 +1,59 @@ +#!/bin/bash + +[[ -d $1 ]] || exit 1 + +. /usr/lib/network/network + +write_template() { + local profile=$1; shift + cat << EOF +[Unit] +Description=Netcfg networking service for profile ${profile} +SourcePath=${PROFILE_DIR}/${profile} +Before=network.target +Wants=network.target +Conflicts=netcfg@${profile}.service +EOF + (( $# )) && printf '%s\n' "$@" + cat << EOF + +[Service] +Type=oneshot +RemainAfterExit=yes +ExecStart=/usr/bin/netcfg check-iface ${profile} +ExecStop=-/usr/bin/netcfg down ${profile} +KillMode=none +EOF +} + +list_profiles | while read p; do + load_profile "${p}" || continue + systemd_devices=() + extra_deps=() + case "${CONNECTION}" in + bond) + for iface in "${SLAVE_INTERFACES[@]}"; do + systemd_devices+=("sys-subsystem-net-devices-${iface}.device") + done + ;; + bridge) + for iface in "${BRIDGE_INTERFACES[@]}"; do + systemd_devices+=("sys-subsystem-net-devices-${iface}.device") + done + ;; + ethernet|pppoe|wireless) + systemd_devices+=("sys-subsystem-net-devices-${INTERFACE}.device") + ;; + vlan) + systemd_devices+=("sys-subsystem-net-devices-${VLAN_PHYS_DEV}.device") + ;; + esac + [[ ${#systemd_devices[@]} > 0 ]] && extra_deps+=("BindsTo=${systemd_devices[*]}" "After=${systemd_devices[*]}") + write_template "${p}" "${extra_deps[@]}" > "$1/netcfg-profile-${p}.service" +done + +. /etc/conf.d/netcfg +mkdir "$1/netcfg-profiles.target.wants" +for p in "${NETWORKS[@]}"; do + [[ -f "$1/netcfg-profile-${p}.service" ]] && ln -s "$1/netcfg-profile-${p}.service" "$1/netcfg-profiles.target.wants/netcfg-profile-${p}.service" +done diff --git a/systemd/netcfg-profiles.target b/systemd/netcfg-profiles.target new file mode 100644 index 0000000..54af553 --- /dev/null +++ b/systemd/netcfg-profiles.target @@ -0,0 +1,2 @@ +[Unit] +Description=Netcfg network profiles diff --git a/systemd/netcfg.service b/systemd/netcfg.service deleted file mode 100644 index f400be0..0000000 --- a/systemd/netcfg.service +++ /dev/null @@ -1,14 +0,0 @@ -[Unit] -Description=Netcfg multi-profile daemon -Before=network.target -Wants=network.target - -[Service] -Type=oneshot -RemainAfterExit=yes -ExecStart=/usr/bin/netcfg-daemon start -ExecStop=/usr/bin/netcfg-daemon stop -KillMode=none - -[Install] -WantedBy=multi-user.target
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.
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.
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...
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:
- write a proper ifplugd service (possibly ifplugd needs to be altered),
- 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?
Am 29.10.2012 21:31, schrieb Jouke Witteveen:
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.
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.
Me too.
This might mean to hope for Lennarts cooperation in at least two places:
- write a proper ifplugd service (possibly ifplugd needs to be altered),
He won't work on ifplugd, he considers it obsolete.
- support variables from EnvironmentFile in the BindsTo/After part of
a unit (so that we can put our interfaces there).
Won't happen. Environment file is considered an ugly hack.
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.
Environment files are not the way to go. They are considered a hack and we won't get support for them anywhere but in Exec*=.
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).
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.
As for the problem addressed by the presented patch: we could put After=udev-settle.service in the services.
Never. udev-settle is the worst idea and I don't use any service that needs it - and I will not support adding it anywhere.
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?
As I said: Make a transition from old to new, in small steps and catch bugs on the way. Rewriting is not the answer.
On Mon, Oct 29, 2012 at 9:56 PM, Thomas Bächler thomas@archlinux.org wrote:
Am 29.10.2012 21:31, schrieb Jouke Witteveen:
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.
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.
Me too.
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).
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
--- systemd/netcfg-generator | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/systemd/netcfg-generator b/systemd/netcfg-generator index 8b6f3af..4bd6292 100755 --- a/systemd/netcfg-generator +++ b/systemd/netcfg-generator @@ -41,12 +41,20 @@ list_profiles | while read p; do systemd_devices+=("sys-subsystem-net-devices-${iface}.device") done ;; - ethernet|pppoe|wireless) + ethernet) + systemd_devices+=("sys-subsystem-net-devices-${INTERFACE}.device") + extra_deps+=("Conflicts=net-auto-wired@${INTERFACE}.service") + ;; + pppoe) systemd_devices+=("sys-subsystem-net-devices-${INTERFACE}.device") ;; vlan) systemd_devices+=("sys-subsystem-net-devices-${VLAN_PHYS_DEV}.device") ;; + wireless) + systemd_devices+=("sys-subsystem-net-devices-${INTERFACE}.device") + extra_deps+=("Conflicts=net-auto-wireless@${INTERFACE}.service") + ;; esac [[ ${#systemd_devices[@]} > 0 ]] && extra_deps+=("BindsTo=${systemd_devices[*]}" "After=${systemd_devices[*]}") write_template "${p}" "${extra_deps[@]}" > "$1/netcfg-profile-${p}.service"
--- systemd/netcfg-generator | 1 + 1 file changed, 1 insertion(+)
diff --git a/systemd/netcfg-generator b/systemd/netcfg-generator index 4bd6292..e6c4068 100755 --- a/systemd/netcfg-generator +++ b/systemd/netcfg-generator @@ -63,5 +63,6 @@ done . /etc/conf.d/netcfg mkdir "$1/netcfg-profiles.target.wants" for p in "${NETWORKS[@]}"; do + p=${p#@} [[ -f "$1/netcfg-profile-${p}.service" ]] && ln -s "$1/netcfg-profile-${p}.service" "$1/netcfg-profiles.target.wants/netcfg-profile-${p}.service" done
Profiles can safely omit options, but options from other profiles may leak this way, as netcfg does not take care of them for us. --- systemd/netcfg-generator | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/systemd/netcfg-generator b/systemd/netcfg-generator index e6c4068..6a625f4 100755 --- a/systemd/netcfg-generator +++ b/systemd/netcfg-generator @@ -27,6 +27,8 @@ EOF }
list_profiles | while read p; do + # Clean environment before loading the profile + unset CONNECTION INTERFACE SLAVE_INTERFACES BRIDGE_INTERFACES VLAN_PHYS_DEV load_profile "${p}" || continue systemd_devices=() extra_deps=()
There may be situations where a profile requires another. For example, we can create several tap interfaces and add them to a bridge. On boot, the device dependencies should take care of the correct ordering, if all required profiles are enabled. If they are not, or if a user runs systemctl start netcfg-profile-mybridge.service then the required profiles should be pulled in. In the systemd case, this patch introduces a new DEPENDS=() array to add those dependencies. --- systemd/netcfg-generator | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/systemd/netcfg-generator b/systemd/netcfg-generator index 6a625f4..989040d 100755 --- a/systemd/netcfg-generator +++ b/systemd/netcfg-generator @@ -28,7 +28,7 @@ EOF
list_profiles | while read p; do # Clean environment before loading the profile - unset CONNECTION INTERFACE SLAVE_INTERFACES BRIDGE_INTERFACES VLAN_PHYS_DEV + unset CONNECTION INTERFACE SLAVE_INTERFACES BRIDGE_INTERFACES VLAN_PHYS_DEV DEPENDS load_profile "${p}" || continue systemd_devices=() extra_deps=() @@ -59,6 +59,9 @@ list_profiles | while read p; do ;; esac [[ ${#systemd_devices[@]} > 0 ]] && extra_deps+=("BindsTo=${systemd_devices[*]}" "After=${systemd_devices[*]}") + for dep in "${DEPENDS[@]}"; do + extra_deps+=("Requires=netcfg-profile-${dep}.service" "After=netcfg-profile-${dep}.service") + done write_template "${p}" "${extra_deps[@]}" > "$1/netcfg-profile-${p}.service" done
--- systemd/netcfg-generator | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/systemd/netcfg-generator b/systemd/netcfg-generator index 989040d..76365c9 100755 --- a/systemd/netcfg-generator +++ b/systemd/netcfg-generator @@ -39,7 +39,7 @@ list_profiles | while read p; do done ;; bridge) - for iface in "${BRIDGE_INTERFACES[@]}"; do + for iface in ${BRIDGE_INTERFACES}; do systemd_devices+=("sys-subsystem-net-devices-${iface}.device") done ;;
arch-projects@lists.archlinux.org