iiab-network was failing at "Restart the networking service if appropriate" due to duplicate routes

[holta]

@georgejhunt on an RPi 3 machine running Raspbian Lite ("192.168.0.131") ./iiab-network was failing each time it was run — even after reboot:

TASK [network : Restart the networking service if appropriate] *****************
fatal: [127.0.0.1]: FAILED! => {"changed": false, "msg": "Unable to start service networking: Job for networking.service failed because the control process exited with error code.\nSee "systemctl status networking.service" and "journalctl -xe" for details.\n"}

@jvonau asked me to try out testing using rpi.j2 instead of iiab.j2 within the Copy the bridge script for RPi stanza here:
https://github.com/iiab/iiab/blob/master/roles/network/tasks/rpi_debian.yml#L42

i.e. trying this one...
https://github.com/iiab/iiab/blob/master/roles/network/templates/network/iiab.j2

instead of this one...
https://github.com/iiab/iiab/blob/master/roles/network/templates/network/rpi.j2

Quick testing on this particular RPi 3 (192.168.0.131) shows this fixes the problem — after I made the above change, and then ran ./iiab-network — dnsmasq now stays running even after reboot, yay!

Can we consider a PR doing exactly this? (Whether this happens in IIAB 6.7 or more likely afterwards!)

[georgejhunt]

Observations:

1. The proposed change only applies to rpi hardware. (https://github.com/iiab/iiab/blob/master/roles/network/tasks/main.yml#l129
2. The multiple routes failure occurs in "Gateway" mode (an assumption. --but need to verify that)
3. In Gateway mode the failing line in iiab.j2 is line 22.
4. There is always wifi, so the flag {{ discovered_lan_iface }} must not be none -- which is an error. (because in gateway on a rpi the ethernet is used for upstream).
5. If there is a route conflict, it is probably on the wired interface, which means the conflict is set up by line 31 "discovered_wan_iface" -- (setting it to manual just lets dhcpcd actually do it)
6. It seems strange to me that this failure surfaced now when the iiab.j2 has not changed for a year.
7. So it might be possible to let "discovered_wan_iface" blast "discovered_lan_iface" back to "none
8. The testing of this PR will become more difficult, once wifi upstream as well as downstream, becomes part of our code base.
9. At the minimum, I think this PR should be tested in appliance mode -- since rpi.j2 does nothing in "Appliance".

[tim-moody]

are the routes duplicate or are there simply more than one? what is for 0.0.0.0?
I would like to see separate networking plays for each platform (<OS>-networking.yml) to stop the proliferation of logic to handle an increasing number of cases.

[tim-moody]

to get fancier still, each <OS>.yml could have a networking_profile var that determines what play to run, to avoid multiple files that are identical.

[holta]

While similar in some ways, is this unrelated to #1469 in the end?