[systemd-devel] One-Command complex network reconfiguration, was: propagate reload from other events

[Johannes Ernst]

On Oct 10, 2015, at 23:16, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> 
> 11.10.2015 07:14, Johannes Ernst пишет:
>> I understand that if foo.service specifies:
>> 
>> PropagatesReloadTo=bar.service
>> 
>> and I execute “systemctl reload foo”, this will trigger a reload of bar as well. Typically I might do that if I have changed some config file, and I want the daemon(s) to pick it up.
>> 
>> Is there a similar mechanism that triggers a reload in bar when foo stops, or when foo starts, or events like that?
>> 
>> I found a thread from 3 years ago on an OnStop= rule, but I don’t think that made it into the mainline? [1]
>> 
>> My use case is that if I switch from foo.service to foo2.service (both require bar, and are mutually exclusive to each other), I’d like bar to reload.
> 
> Usually if service A requires service B, service B need not be aware about service A starting or stopping. In your case it actually sounds like "bar requires either foo or foo2", otherwise why bar would need restart?

I guess I need to explain what I’m trying to do:

I want a single command to reconfigure networking for different situations that a device running UBOS [2] might encounter. Example syntax:

> ubos-admin setnetconfig client
# sets up DHCP client on all network interfaces, advertises http and https sites on device via Avahi, runs firewall
> ubos-admin setnetconfig static
# allocates static IP addresses on all network interfaces, advertises http and https sites via Avahi, runs firewall
> ubos-admin setnetconfig gateway
# sets up DHCP client on first Ethernet interface (WAN), allocates static IP addresses to all other interfaces (LAN), advertises via Avahi but only on LAN, runs firewall and NAT
> ubos-admin setnetconfig cloud
# sets up DHCP client on all network interfaces, no Avahi, runs firewall, also runs cloud-init

The idea is to take drudgery and needed competence out of network configuration and make it “fool proof” by identifying the situation on a high level (“this is my home gateway”, “this is just some device on my network” etc) and let software make it so.

My implementation of ‘ubos-admin setnetconfig XXX’ basically goes like this:

1. Generate/update configuration files for the configuration XXX
2. systemctl start ubos-networking-XXX.service (where XXX=client, static, gateway, …), with all the ubos-networking-XXX.service files declaring a Conflict with all others, so systemd will only run one of them at a time.

To get back to the problem on the beginning of the thread, let’s take an example:

ubos-networking-client.service depends on systemd-networkd.service, with a config file like this:

[Match]
Name=*
[Network]
DHCP=ipv4

ubos-networking-gateway.service depends on systemd-networkd.service, with a config file like this:

[Match]
Name=enp0s3
[Network]
DHCP=ipv4
[Match]
Name=*
[Network]
Address=0.0.0.0/16

Now, if the current state is “client” and the user executes “ubos-admin setnetconfig gateway”, after updating the config files, the following things need to occur:
1. ubos-networking-client.service needs to be stopped
2. ubos-networking-gateway.service needs to be started
3. systemd-networkd.service needs to be reloaded, because its configuration has changed.

So I was wondering whether there is a mechanism to have systemd reload systemd-networkd, in response to an event such as ubos-networking-client.service being stopped, or ubos-networking-gateway.service being started.

Does this make sense?


[2] http://ubos.net/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20151011/3eba001c/attachment.html>