Hello Seth,
Seth Arnold [2016-06-03 21:30 -0700]:
> /etc/resolv.conf appears to be both a resolved configuration file ("global
> resolvers") as well as something it will publish for other programs to
> consume (the symlink to /run/systemd/resolve/resolv.conf ).To clarify, it's a configuration file of glibc's NSS system, it's not specific to resolved or resolvconf. And it's still managed by resolvconf, like for the last umpteen Ubuntu releases. > - Which programs would consume data from this file? (My guess is 'native' > lookup routines in languages like perl, python, ruby, erlang, java. Is > this close? Who else would read from this file? Should we let them?) Mostly libc's gethostbyname() family, via libnss-dns. But as it's an ancient standard config file, other programs surely read it as well, for example "dig" or "host" (which don't use glibc's API). > - Would we want to stop using resolvconf? It feels like resolvconf's uses > would be drastically less important with good systemd-networkd > configuration instead. Would any cases remain where we want to keep > resolvconf? I looked into that, as resolved can manage resolv.conf as well. But it's deeply entrenched into Debian/Ubuntu packages [1], so we'd need to adjust quite a number of packages to talk to resolved instead. Doable, but it's unrelated to the main goal of the spec, so I didn't propose this for now. That said, networkd will still send DNS information that cannot be represented in resolv.conf (such as domain-specific DNS servers) to resolved -- that is, *if* you use such features in networkd, you *have* to use libnss-resolve for it to actually work. [1] http://people.canonical.com/~pitti/tmp/resolvconf-hooks.txt > - Will we go with the symlink route (i.e., resolved is the publisher) or > will we go with the regular file route (i.e., resolved is the consumer)? No change planned, see above. > == /etc/nsswitch.conf == > > > [2] This is configured in /etc/nsswitch.conf ("hosts: files ... resolve > > dns") > > Do we even want to keep 'dns' on this line? If resolved fails to resolve > a request then falling back to DNS feels like it will simply push the > inevitable failure off by another six to eighteen seconds. libnss-resolve automatically falls back to "dns" (i. e. libnss-dns) if resolved isn't running or cannot be contacted. So indeed we don't need it for most cases. The issue is with multi-arch installations: Suppose you only have libnss-resolve:amd64 installed, and then install foo:i386. The latter wouldn't have libnss-resolve available. That's the only reason why we still need the "dns" line there. Alternatively we would need to figure out a way to install libnss-resolve:<arch> whenever we install the first package on <arch>. > == replace dnsmasq's combined dhcpd and "local" dns == > > - Will dhcp leases handed out by systemd's dhcp server be automatically > entered into the resolved database for lookups? Clarification: resolved is not a DHCP server, it's just a resolver. I'm trying to interpret what you mean by this: DNS servers picked up by networkd (via DHCP or config files) get sent to resolved, yes. networkd also has a small builtin DHCP (v4 only) server, which can be enabled with "DHCPServer=yes". This does not have many features though, it's main intention is to provide simple DHCP to containers on embedded systems which don't want to setup anything more complicated. But we don't use this, as in Ubuntu "container" == "LX[CD]", which sets up dnsmasq. > dnsmasq is used by many tools for these dual purposes and often times > chained together with resolveconf but the fact that it is _chained_ > together means that e.g. containers can't look up VM names, or VMs > can't look up container names, when both VMs and containers are hosted > on one system. systemd's approach for that is that container or VM managers such as nspawn or libvirt register themselves in machined [2], and then you can use libnss-mymachines to resolve their names. But again, our current LXC/D don't use this. However, this was discussed with Stéphane in a different part of this thread, I'm sure we can find a solution here. [2] https://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/ > Will we adapt lxd and libvirt and so on to use systemd-network so that > resolved and the systemd dhcp server stand a chance of replacing the other > tooling? I don't know about libvirt. Since RH is heavily involved in this, I figure it might get direct machined/resolved integration at some point for the above. I doubt it for lxc/lxd, though. > == LLDNS == > > Will we enable LLDNS? Do we want to? Responding too? Not sure what LLDNS is, do you mean LLMNR? Resolved does that indeed, but we still have Avahi's libnss-mdns4 installed by default. I haven't checked if that can go now. I added a work item to https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver to check this. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
