The stock Ubuntu approach was inadequate. It would DHCP out every nic and take the fastest result, and no going back.
Now the CDC nic can frequently win that race.
First, rmmod cdc_ether, as a scenario that is completely right out.
But beyond that, let Ubuntu have one shot at multi-nic bringup. Beyond that, maintain a list of all link-up devices.
If the check should fail, then start doing one nic at a time, cycling through them.
Also, the openssl s_client timeout is painfully slow, use subshell and kill to speed up things.
Reduce obvious output about skipped devices.
Rule out any read-only device.
Amend minimum size to 2GB.
Among same priority devices, select the smallest target.
Have block devices checked for identity information
in a loop with network source search.
Block devices may be delayed for various reasons. The previous method
could be bypassed by fast block device cutting off slow device
enumeration. It also incurred a delay for the network install
case.
It turns out that when busybox invokes openssl for
IPv4, it does not pass a servername field.
In this case, start amending arguments after '-verify' instead, to catch
the verify_ip argument correctly.
The busybox wget invocation of openssl is broken.
Override by stubbing it out to let openssl pick the verify
hostname instead of wget specified one, which is incorrect.
It may happen that the first pass at nics misses
a viable network interface due to slow link up
or slow spanning tree forwarding.
Repeat the loop through the interfaces to have follow
up chances at success.
A variant of the M.2 RAID enablement kit does not manifest with nvme
driver. Address this by allowing 'nvm' subsystype. to allow blank driver.
Also, to be on the safe side, have self.driver always be a string,
so it can be 'falsey' but still work as a string.
If syncfiles fails, keep it retrying.
Also, slow down sync checking to avoid hammering the system.
Further, randomized delay to spread highly synchronized requestors.
Block attempts to do multiple concurrent syncfile runs.
Some versions start manifesting nvme devnames with 'c', which
are to be used to interact with multipath to have raw devices
backing a traditional nvme device.
It is likely that a client connects from fe80::, which
is explicitly omitted from ssh principals.
This time, have the client provide all currently set IP addresses
and the server will make a determination.
There remains the possibility it misconfigures a nic and tries to use that,
inducing failure. One strategy would be to filter the addresses and
only provide from the 'current' interface. Another is to just take
the hit as the node is likely going to suffer a lot from such a
misconfiguration anyway.
