-
David Johnson authored
Turned out that I could not guarantee that emulab-networkd@.service would write the .network files in /run/systemd/network in time for systemd-networkd to notice them; so I tweaked the strategy to a slightly more complex path: udev rules run a simple shell script that writes the per-device .network files that specify dhcp on all interfaces, in addition to telling systemd to want emulab-networkd@<dev>.service units. These units wait for the control net to come up on one of the devices; then the winner removes the extraneous .network files and downs the unused interfaces and restarts systemd-networkd so it only "manages" our control net. I also improved it so that if the user writes static systemd-networkd configuration into /etc/systemd/network/<foo>.network, our udev rules still write /run/systemd/network/<foo>.network if foo is a physical device -- but the waiter unit and cleanup scripts do *not* down <foo>; they just ignore it, because they notice that systemd-networkd did *not* pick our /run/systemd/network/<foo>.network to manage <foo>. So we should be good for integration and not squashing static user configs. Finally, I "completed" it in the sense that the winning emulab-networkd@.service unit also writes out all the /var/emulab/boot metadata, sets the hostname -- does what the dhclient exit hooks used to do. The only thing it does not yet handle is elabinelab dhcp "selection". I need a quick semantics tutorial for that.
4144c37f