Hi Tadej, thanks for confirmation. On 2/23/21 10:37 AM, Tadej Janež wrote: > 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? Well, partially. It wouldn't disable systemd-resolved service, but would not direct DNS messages to resolved. It would still cache requests done via nss, typically via getaddrinfo() or gethostbyname() function. That was intention of cloud-init anyway. Personally I would prefer cache on the host instead of in each container. > >> * 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 It could just always move file without its own header to /run/systemd/resolved/fallback.conf (or maybe some permanent). When no better configuration was set, use this file as nameservers source, instead of built-in defaults. It would omit saving that files. Sure, this part is more complex. But only this part can fix this problem from inside the container IMO. Ie. we could fix it faster for any involved parties. I don't really run any container on any cloud service so this is just my guess. Who uses cloud-init to prepare the container? If it is used by cloud provider, I would expect slow updates and conservative behavior. Even if we fix it immediately, how fast would appear on the service? I think the fix from within can be much sooner be used by users. Who uses cloud-init to prepare containers? Is it end user on his system? -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
