Once upon a time, Tim <ignored_mailbox@xxxxxxxxxxxx> said: > But being serious, I did start looking through the man files for the > new networking schemes (man systemd-resolved). And supposedly, > /etc/resolv.conf is a link to /run/systemd/resolve/stub-resolv.conf > And when it is, it controls the file its linked to. Yeah, if you just edit /etc/resolv.conf without reading it (leaving it a symlink to /run), your edits will get lost. All you have to do is remove the symlink and replace it with a file, and systemd-resolved will stop touching it (again, as documented in the file). It's not some mystery, or difficult problem to solve, if you read the comments and referenced documentation. > It is all a bit of a maze, and I don't really see how this was an > improvement on the previous methodology. A single system-wide resolv.conf cannot handle more complicated setups, such as a VPN where lookups for certain domains should be sent to a server across the VPN. You have to run some form of local DNS server to handle that (which could be BIND, Unbound, dnsmasq, etc.). Each of those have their own configuration quirks that can make it more complicated to programmatically manage, so systemd-resolved was created. I'm not entirely satisfied with systemd-resolved, but it solves things for a majority of cases. > Likewise with network configuration. If the previous config files > actually did the job, why didn't they keep on using them, and just > update the tools that set them up? The previous ifcfg files had many quirks, starting from being created as shell variable lists to feed to bash scripts for network config. They were also specific to Red Hat Linux derived OSes (e.g. Fedora, RHEL, CentOS, etc.). NetworkManager was created to solve multiple things, one of which was standardizing network configuration across distributions. The NM plugin to support the RHL-style ifcfg files has been there as a backwards-compatibility wedge, but it was time to move on from using that by default (and deprecate the old network-scripts pile of shell code). -- Chris Adams <linux@xxxxxxxxxxx> _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
