wido opened a new pull request, #14060:
URL: https://github.com/apache/cloudstack/pull/14060
### Description
A CloudStack management server does not need an IPv4 default route. It can
be IPv6-first, or — as in the setup that triggered this — have IPv4
connectivity to the POD network and the KVM agents without any IPv4 default
gateway. Today such a management server does not boot:
```
ERROR [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:[]) (logid:) Error on
configuring bean RootCAProvider -
Cannot invoke "java.net.NetworkInterface.getInterfaceAddresses()" because
"nic" is null
java.lang.NullPointerException: Cannot invoke
"java.net.NetworkInterface.getInterfaceAddresses()" because "nic" is null
at
com.cloud.utils.net.NetUtils.getAllDefaultNicIps(NetUtils.java:298)
at
org.apache.cloudstack.ca.provider.RootCAProvider.loadManagementKeyStore(RootCAProvider.java:409)
at
org.apache.cloudstack.ca.provider.RootCAProvider.setupCA(RootCAProvider.java:521)
at
org.apache.cloudstack.ca.provider.RootCAProvider.configure(RootCAProvider.java:548)
...
ERROR [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:[]) (logid:) Failed
to load module [root-ca]
```
`RootCAProvider` calls `NetUtils.getAllDefaultNicIps()` to collect the IPs
that go into the management server certificate's SANs. That in turn calls
`NetUtils.getDefaultEthDevice()`, which ran:
```
ip route show default 0.0.0.0/0 | head -1 | awk '{print $5}'
```
Two problems with that:
1. **It only looks at IPv4, and it does not always return a device name.**
`Script` merges stderr into stdout
(`ProcessBuilder.redirectErrorStream(true)`), so anything the shell or `ip`
writes on stderr becomes the "device name". That non-null, non-device string is
handed to `NetworkInterface.getByName()`, which returns `null`, and the
unchecked dereference on the next line throws the NPE above — which aborts the
whole `root-ca` module and therefore the management server boot.
2. **Column 5 is not the device.** `$5` only happens to be the device for
routes shaped like `default via <gw> dev <name> ...`. For an on-link default
route it is wrong:
| route | old `$5` | new |
|---|---|---|
| `default via 10.0.0.1 dev eth0 proto static metric 100` | `eth0` |
`eth0` |
| `default dev eth0 scope link` | `link` ❌ | `eth0` |
| `default via fe80::1 dev eno1 proto ra metric 1024 expires 1798sec pref
medium` | `eno1` | `eno1` |
| `default dev eno1 proto kernel metric 256 pref medium` | `kernel` ❌ |
`eno1` |
| multipath (`default proto static` + `nexthop ... dev eth0 ...`) |
*(empty)* | `eth0` |
### Fix
Small change, all in `NetUtils`:
* The device name is taken from the token that follows `dev`, rather than
from a fixed column. Correct for every route layout above, including multipath.
* `ip -4 route show default` is queried first; if there is no IPv4 default
route, `ip -6 route show default` is used. An IPv6-first management server now
resolves its default NIC and gets its addresses (both families) into the
management server certificate, instead of getting nothing.
* The results of `NetworkInterface.getByName()` are null-checked in both
`getAllDefaultNicIps()` and `getDefaultHostIp()`, so an unresolvable device
name degrades to "no default NIC found" with a warning in the log instead of
killing the boot.
### Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
### How Has This Been Tested?
Four unit tests added to `NetUtilsTest`, covering the IPv4→IPv6 fallback,
the IPv4-preferred path, an unresolvable device name, and no default route at
all.
The `awk` expression was checked against the route outputs in the table
above.
> [!NOTE]
> `NetUtilsTest#testAllIpsOfDefaultNic` fails on JDK 26 with
`UnsupportedOperationException` from `Collections.reverse()` in
`getNetworkParams()`, because `NetworkInterface.getInterfaceAddresses()` now
returns an immutable list. That is pre-existing on `main` and unrelated to this
PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
