Fair point. I feel that asking/requiring that everything that users want to do be supported in networkd is a high bar, and might not provide the level of flexibility that users expect from Ubuntu.
Here's an example of when I needed something like this in the ifupdown world:
In this example, I have a bridge called lan0, whose only physical interface is ens1.
The requirement here is, I need to know when ens1 goes up or down, so that I can make changes to the bridge interface. The `ifmonitor` script will monitor the link status of ens1, and then take appropriate actions, such as restarting a DHCP client, adding or removing routes that have been programmed via the lan0 bridge to egress on ens1, adding or removing IP addresses from the configuration, etc.
In the ifupdown world, the other horrible hack I've sometimes found necessary (although the reason why is eluding me at the moment) is when I want an interface to be 'manual', yet behave like a 'static' definition, in that it should configure itself automatically when it comes online. So I might have something like:
iface vlan105 inet manual
...
post-up (ip a a 192.168.105.1/24 broadcast 192.168.105.255 dev $IFACE) || true
I could go on. There are endless reasons why users want to use these ad-hoc hooks to get things working in their environment. Maybe I want to configure iptables rules when an interface comes up, etc.
Fair point. I feel that asking/requiring that everything that users want to do be supported in networkd is a high bar, and might not provide the level of flexibility that users expect from Ubuntu.
Here's an example of when I needed something like this in the ifupdown world:
iface ens1 inet manual ens1) 2> /dev/null || true
iface lan0 inet manual
metric 1
bridge_ports ens1
bridge_stp off
bridge_waitport 0
bridge_fd 0
dns-nameserver 172.16.42.1
post-up run-one /root/ifmonitor ens1 &
pre-down kill $(cat /run/ifmonitor.
In this example, I have a bridge called lan0, whose only physical interface is ens1.
The requirement here is, I need to know when ens1 goes up or down, so that I can make changes to the bridge interface. The `ifmonitor` script will monitor the link status of ens1, and then take appropriate actions, such as restarting a DHCP client, adding or removing routes that have been programmed via the lan0 bridge to egress on ens1, adding or removing IP addresses from the configuration, etc.
In the ifupdown world, the other horrible hack I've sometimes found necessary (although the reason why is eluding me at the moment) is when I want an interface to be 'manual', yet behave like a 'static' definition, in that it should configure itself automatically when it comes online. So I might have something like:
iface vlan105 inet manual
...
post-up (ip a a 192.168.105.1/24 broadcast 192.168.105.255 dev $IFACE) || true
I could go on. There are endless reasons why users want to use these ad-hoc hooks to get things working in their environment. Maybe I want to configure iptables rules when an interface comes up, etc.