On 9/30/20 7:11 PM, Michael Catanzaro wrote: > On Wed, Sep 30, 2020 at 9:54 am, PGNet Dev <pgnet.dev@xxxxxxxxx> wrote: >> So the upgrade WILL ignore current F32 state -- systemd-resolved >> DISABLED + 'my' /etc/resolv.conf -- and enable + overwrite >> (respectively) each, regardless of whether we're _using_ >> NetworkManager (afaict it's impossible to completely remove all NM* >> cruft)? > > It only touches your /etc/resolv.conf if you are using NetworkManager, > but I think it enables systemd-resolved regardless. You'll have to > disable it if you don't want it. Shouldn't it change resolv.conf only in case NM is active AND resolv.conf is generated by Network Manager? resolv.conf with dnssec-trigger is generated anyway, there is little need to backup it. It looks like: # Generated by dnssec-trigger-script nameserver 127.0.0.1 I haven't tested upgrade to f33 yet. dnssec-trigger also tries protect resolv.conf for overwriting by chattr +i /etc/resolv.conf. I think it would break upgrade if change was attempted by systemd. Also, it would battle for port 53 for anyone having already local resolver. It would just fail to start, if user enabled listening on any address. Which is now unfortunately default for dnsmasq. It might be a little random, which one would win on machine start. I guess systemd-resolved would win, because unlike named(bind) or unbound, it has before nss-lookup.target and network.target. Normal dns services start After=network.target. Fortunately, it would not conflict with resolvers listening on localhost only, because it listens on different IP address. But it is before dns in nsswitch.conf, so every query would be done before "proper" dns resolvers. I don't this that is correct, when resolved has serious limitations in security. I expect it would break any local resolver configured, unless it can detect existing resolver and avoid activation of systemd-resolved. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
signature.asc
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
