On Sat, Nov 26, 2016 at 10:15 PM, Bruce Dubbs <[email protected]> wrote:
> DJ Lucas wrote: > >> Correct, this was resolved in SVN a couple of weeks ago. Should only >> affect 231 and 232. >> > > For someone who does not use systemd (me), all this sounds terribly > complex. Why not pass --disable-resolved to systemd and just use the > resolver in glibc? > > Alternatively, there is unbound or bind in BLFS that can provide a caching > name server in a straightforward (one task, one application) way. > > -- Bruce > > > Bruce, are you top posting? (or did DJ top post?) ;-) Anyway, I think we have to give up networkd if we do that, which will require network connectivity to be handled by yet another layer, which seems way more complicated to me than just keeping networkd. We'd have to provide links to something like NetworkManager. > > > > On November 26, 2016 9:12:30 PM CST, Eric Stone <[email protected]> wrote: >> >>> There is an open bug in systemd [0] that creates a bad experience for >>> LFS >>> users that do not create a static /etc/resolv.conf . This bug >>> prevented me >>> from using “wget” to download many BLFS packages. Here is a proposed >>> workaround for inclusion in the next LFS version. >>> >>> When following LFS’ network configuration instructions [1], the user >>> leaves >>> a blank /etc/resolv.conf . systemd-resolved later makes this a symlink >>> to >>> a file containing a “nameserver 127.0.0.53” entry, and runs a “stub >>> resolver” service listening at this local address. Programs that >>> resolve >>> their own names (instead of using the getent or systemd-resolve >>> utilities) >>> like “wget” or “dig”, then send requests to this stub nameserver. >>> However >>> the stub server has a bug, where its resolutions do not follow CNAMEs >>> through to A records (oddly “systemd-resolve” does not share this bug). >>> >>> One workaround could be to instruct all LFS users to create a static >>> /etc/resolv.conf, which avoids use of the stub resolver . However then >>> the >>> nameserver list is not automatically updated by DHCP. My suggested >>> workaround for users that want to use DHCP, is a change to the systemd >>> setup instructions [2]. Instead of pointing /etc/resolv.conf at the >>> “../lib/systemd/resolv.conf” file, later after first-boot do: >>> >>> ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf >>> >>> There is more information on this in the “/ETC/RESOLV.CONF” section of >>> “man systemd-resolved.service”. There is one downside I see to this >>> approach from the manpage - “it does not know a concept of >>> per-interface >>> DNS servers and hence only contains system-wide DNS server definitions” >>> (including all those discovered through DHCP). However this seems >>> better >>> for many LFS users than having many of their DNS resolution requests >>> fail. >>> >>> Regards, >>> >>> -Eric S. Stone >>> >>> [0] https://github.com/systemd/systemd/issues/3826 >>> >>> [1] >>> http://linuxfromscratch.org/lfs/view/stable-systemd/chapter0 >>> 7/network.html >>> >>> [2] >>> http://linuxfromscratch.org/lfs/view/stable-systemd/chapter0 >>> 6/systemd.html >>> >> >> > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page >
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
