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

Bug #1664818 reported by Mike Pontillo on 2017-02-15
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
netplan
Wishlist
Unassigned
systemd (Ubuntu)
High
Mathieu Trudel-Lapierre

Bug Description

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.

description: updated
Changed in netplan:
importance: Undecided → Wishlist
Steve Langasek (vorlon) wrote :

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.

Changed in netplan:
status: New → Incomplete
Mike Pontillo (mpontillo) wrote :

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.

Changed in netplan:
status: Incomplete → New
Steve Langasek (vorlon) wrote :

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

Changed in systemd (Ubuntu):
importance: Undecided → High
status: New → Triaged
milestone: none → ubuntu-17.05
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Dimitri John Ledkov (xnox) wrote :

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

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

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions