23dfaebb

By: Tom Sydney Kerckhove <syd@cs-syd.eu>

Test the deployment tool against a router, over ssh

The one path nothing here touched. A vm that imports over its own console
never sees ssh, and every bug in this deployment was on that side of the
line.

So the harness can now forward a port to the router's ssh and hold the
router still instead of importing anything, and there is a second test
suite, driven from Haskell like the first, that drives the tool at it: an
import onto a running router, and then the whole two-stage shape, reset
into one half, wait, import the other.

Both bugs are caught by the second of those. With the old import back in
place it fails and says the second stage did; with the exit status read
instead, it passes. Worth knowing why it only ever bit a real deployment:
/import over ssh prints "executed successfully" on a router in its default
state and prints nothing at all on one that has just come back from a
reset, which is exactly and only the router stage two talks to.

examples/deployable holds the configuration that half needs, since a
deployment has to still be able to reach what it deployed to. It is not one
of the valid examples: a router that already has a dhcp client on ether1
refuses to add a second, and the vm that imports over its console has one.

--port on the tool, because a vm on a user-mode network is reachable no
other way.