James Coleman
b3dd8e8118
Setting DNS rewrote the connection profile and stopped there, so the running device kept resolving through whatever it had before. Nothing noticed while something else always activated the device afterwards: the profile was written first and NetworkManager picked the resolvers up when it got round to the interface on its own. Turning a DHCP client off now applies the profile when the device is not activated, which moved that activation ahead of the DNS write. A caller that sets an address, disables DHCP, and then sets resolvers -- the order a static configuration is naturally applied in -- ends with the device activated on a profile that had no DNS in it yet, and the write that follows never reaches the system. The profile carries the resolvers, resolv.conf carries none, and ipv4.ignore-auto-dns has by then ruled out the lease's resolvers as well: an interface holding an address, a route, and no way to resolve a name. Reapply the device after the change. Unlike turning a client off, this risks nothing for a caller connected over the interface -- reapply changes the device in place and does not tear the link down -- so it is not conditioned on the device being unactivated, which is exactly the case that needs it. |
||
|---|---|---|
| .. | ||
| cloudinit | ||
| configurator_linux | ||
| ifupdown | ||
| netplan | ||
| networkd | ||
| networkManager | ||
| networkScripts | ||