Not possible to render pre-up, pre-down, post-up, or post-down snippets

[Mike Pontillo]

Many configurations require scripts to run before or after an interface comes up or down.

Example: I had a situation where I needed to render a post-up script to monitor an interface with ifupdown (and with the interface set to manual mode, because if the link was down I didn't want to require DHCP to run before the system continued booting). This is similar to what NetworkManager does in order to launch (or kill) a DHCP client.

Other use cases involve setting up custom routes (such as when complex logic involving metrics or source routing is required) or anything else the designers of the netplan rendering engine didn't think of, such as invoking workarounds or special settings required for a particular NIC or environment, iptables rules that should be added or removed, etc.

A follow-on issue is, it should be possible to ask that custom scripts run if the *link* is detected to come up or down. But I'll be happy if netplan first can simply replicate the custom-script-invoking behavior of ifupdown.

[Steve Langasek (vorlon)]

I'm trying to understand the example you've given here. Are you saying that you want a post-up script on one interface that monitors *another* interface to watch for the link to be up? Or that you're wanting to use it to monitor the *present* interface for it to be up?

Both this and the custom routes case sound like workarounds for bugs/limitations in ifupdown. We should not design netplan for working around bugs in netplan/networkd when we are committed to supporting and bugfixing netplan/networkd.

I believe that neither of the examples given are needed in the netplan world.

Also, networkd as the underlying renderer has no support for script hooks per upstream design, so this isn't fixable in netplan.

[Mike Pontillo (mpontillo)]

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
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.ens1) 2> /dev/null || true

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.

[Steve Langasek (vorlon)]

> 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.

Knowing the status of the physical link so that you can take appropriate action on the bridge/bond makes sense. But it seems to me that should be handled intrinsically by networkd, not something you could or should configure with scripts. Opening a task on systemd for us to verify the behavior here. When all the physical links in a bridge/bond drop, does networkd treat that as a down / subsequent up event?

When you say "egress on ens1", what do you mean? Your network config doesn't show any such routes. Why would these routes be managed externally to networkd?

> 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:

In ifupdown, I would expect to handle this as a static network without 'auto'.

For netplan / networkd, this looks like it needs some further work to support, already captured in bug #1664844.

[Dimitri John Ledkov (xnox)]

I'm kind of concerned about any non-declarative functionality here. For example, DHCP client and receiving/updating routes are all handled by netwokrd already.

You can bind a systemd unit to e.g. sys-subsystem-net-devices-eth0.device and then any number of systemd units should be started and stopped in concert.

One can also block and wait until the relevant interface is up with /lib/systemd/systemd-networkd-wait-online --help

However, I'd rather avoid running arbitrary code as all the examples provided at the moment can be achieve as specifications to the networkd units. (either as generated by netplan, or as drop-in snippets in /etc or /run).

[James Gibbins (jfgibbins)]

You mention that all the examples can already be done by netplan, yet one, he mentioned was modifying iptables, something I use myself, and have yet to find that anywhere in netplan.

[John Sweeney (john-sweeney)]

I need to add routing information to one interface to allow ssh that enters via the non-default gateway. Before metalanguage this was easy. Now it's so difficult! The closest advice was networkd-dispatcher but the advised directory doesn't exist. I can't see why "legacy" functionality is jettisoned in such a cavalier fashion

[Edo (etirta-a)]

I too have special action rely on these commands, mainly inserting/removing iptables rule and/or creating virtual sub-interfaces. While this most likely able to be achieved by systemd, but learning systemd itself requires time. It will be wise for netplan to incorporate these functionality generate the appropriate drop-in snippets, otherwise I will have to fallback to ifupdown instead.

[Dan Streetman (ddstreet)]

marking this as invalid for systemd as arbitrary code can be run using networkd-dispatcher and/or suggestions from comment 4.

[Steve Langasek (vorlon)]

To my knowledge, networkd-dispatcher has no way to do 'pre' hooks on systemd-networkd events, so this is still a valid feature request.

[Lukas Märdian (slyon)]

There is some documentation around how to implement this with netplan here: https://netplan.io/faq/#use-pre-up%2C-post-up%2C-etc.-hook-scripts

But its basically using the underlying renderer's (NM or networkd-dispatcher) hooks, as netplan itself is not a networking daemon and cannot easily listen to netlink changes.

[Lukas Märdian (slyon)]

Netplan does not support any pre/post-up/down hooks on its own, but is referring to a mapping table from ifupdown to its two backend renderers “NetworkManager-dispatcher” and “networkd-dispatcher”, which we are currently updating to better explain the details, pitfalls and differences: https://github.com/canonical/netplan.io/pull/245

It’s not a 1:1 mapping, as the three hook dispatchers behave slightly differently, especially wrt. Networkd-dispatcher being a pure listener, running hook scripts asynchronous, whereas ENI and NM handle the hook scripts natively and allow them to interject the interface configuration process.

Also, systemd-networkd does not keep an internal state (in contrast to ENI & NM) but relies on the kernel’s netlink state, thus uses different stages and cannot implement a “pre-down” hook at all.

Unfortunately, this is the best we can do for now, without requiring upstream changes to systemd, inroducing a possibility to block network configuration, controlled by external hooks, which the systemd devs want to avoid, due to performance concerns.

[Nick Rosbrook (enr0n)]

It does not sound like there is anything for us to do on systemd. If someone is still interested in a related feature request, please open an RFE with upstream: https://github.com/systemd/systemd/labels/RFE%20%F0%9F%8E%81.