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.
When a node installs, it may not have it's node mapped address up,
or may not have one at all. Try to use the ip if it would be in the
same set that produced it's ssh certificate.
There remains a gap if a system has no static addressing *and* doesn't
map nodename to IP, but we have an impasse as the situation is too fuzzy
to grant a prinicpal in an SSH cert, and without that we can't securely
attempt rsync. For now, this scenario would still fail and I will
just hope that doesn't come up.
Some profiles may have all disk support suppressed through blacklist until %pre comes
along to fix it. This avoids /dev/disk ever existing.
Wait up until 10 seconds before giving up. This gives disk subsystem a fair chance to
speed up and avoid a wait, with a fallback worst case of 10 seconds
The change to allow CIDR syntax
broke for configurations that use name for
bmc 'address'.
Fix by letting getaddrinfo have a chance to process the ip before
trying to pton it.
When remote ip is detected,
communicate by returning False
instead of None.
Use this indication to let ssdp
skip a transmit and growing
pending list in such a case.
First, for a given contiguous set of snoop activity, start ignoring a given peer during that contiguous chenk after it has been considered once.
Further, make get_hwaddr cheaper for attempts against
remote IPs.
To facilitate the above, create an efficient 'ip_is_local' to be
a relatively cheap function, with
potential to cache result in future
if it needs to be even cheaper.
