Re: Tip: how to make your own resolv.conf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux