Petr,
thanks for looking into this.
On Mon, 2021-02-22 at 18:30 +0100, Petr Menšík wrote:
After a quick glance at cloud-init code, it seems to me it does not
check /etc/resolv.conf for symlinks.
It just reads /etc/resolv.conf if it is a file, then writes its own
nameservers into target. I have seen no rm of original
/etc/resolv.conf,
so I guess it rewritten target of symlink on Fedora 33:
/run/systemd/resolve/stub-resolv.conf
Indeed, cloud-init just "blindly" amends the /etc/resolv.conf file
which is a symlink to /run/systemd/resolve/stub-resolv.conf and hence
gets overwritten by systemd-resolved.
Here are the relevant snippets from a DigitalOcean instance's
/var/log/cloud-init.log:
... trimmed ...
digitalocean.py[DEBUG]: added dns servers: ['67.207.67.2',
'67.207.67.3']
... trimmed ...
__init__.py[DEBUG]: Selected renderer 'sysconfig' from priority list:
None
util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth1 -
wb: [644] 212 bytes
util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
scripts/ifcfg-eth1 (recursive=False)
util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
scripts/ifcfg-eth1 (recursive=False)
util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth0 -
wb: [644] 287 bytes
util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
scripts/ifcfg-eth0 (recursive=False)
util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
scripts/ifcfg-eth0 (recursive=False)
util.py[DEBUG]: Reading from /etc/resolv.conf (quiet=False)
util.py[DEBUG]: Read 729 bytes from /etc/resolv.conf
util.py[DEBUG]: Writing to /etc/resolv.conf - wb: [644] 846 bytes
util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub-
resolv.conf (recursive=False)
util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub-
resolv.conf (recursive=False)
util.py[DEBUG]: Writing to /etc/NetworkManager/conf.d/99-cloud-
init.conf - wb: [644] 89 bytes
util.py[DEBUG]: Restoring selinux mode for
/etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False)
util.py[DEBUG]: Restoring selinux mode for
/etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False)
util.py[DEBUG]: Writing to /etc/udev/rules.d/70-persistent-net.rules -
wb: [644] 192 bytes
util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70-
persistent-net.rules (recursive=False)
util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70-
persistent-net.rules (recursive=False)
... trimmed ...
I think there are two possible fixes:
* cloud-init would check the symlink and target of etc/resolv.conf.
If
it points to /run/systemd/resolve/*, write DNS=x y into
/etc/systemd/resolved.conf.d/*cloud-init.conf
I think this option would be preferred.
* clound-init would always delete etc/resolv.conf before it writes
into
it, if it was symlink.
I guess this is a simple solution that would work, but from what I
understand it would also disable the use of systemd-resolved?
* systemd-resolved would check contents of link target of
/etc/resolv.conf on startup. If it leads to systemd, try parsing its
contents. If it does not look like managed contents of systemd,
assume
it might be misdirected resolv.conf configuration. Store it and wait
for
DHCP configuration. If no better configuration arrives, use
nameservers
from misdirected file. Would have to restore original resolv.conf on
shutdown to keep working after restarts. Should move it to
fallback.conf
and use it instead of built-in fallbacks?
This seems too complex and error prone.
Regards,
Tadej