Re: ANN: DNS resolver changes in yakkety
Quoting Stéphane Graber (stgra...@ubuntu.com): > On Mon, Jun 06, 2016 at 05:41:06PM +0100, Dimitri John Ledkov wrote: > > On 6 June 2016 at 17:27, Stéphane Graber wrote: > > > On Mon, Jun 06, 2016 at 03:17:51PM +0100, Robie Basak wrote: > > > > > > Unless the above can be fixed somehow, and I very much doubt resolved > > > will grow a DNS server any time soon, the switch to resolved mostly > > > feels like a regression over the existing resolvconf+dnsmasq setup we've > > > got right now and which in my experience at least, has been working > > > pretty well for us. > > > > > > > I have in the past tried to drop all config files from /etc. > > > > Dropping /etc/nsswitch.conf is trivial. Apart from libc and shadow > > very little else parses that, so that has minimal breakage so things > > that do call into libc end up doing the right thing. > > Droping /etc/resolv.conf is hard, and in essence a bunch of stuff > > parses and uses it, for right and wrong reasons (e.g. even when doing > > shared linking with glibc and having it available). > > In those cases, things do go wrong. If there is no split routing, > > everything is fine and the change is mostly harmless. With split > > routing things will break. > > Ideally I would like to still see 127.0.0.1 specified in resolf.conf, > > and I'll be fine with that being implemented on top systemd-resolvd > > api, I don't think that would be hard, however It seems to me like a > > re-implementation of resolvconf+dnsmasq solution. > > > > I have heard before that it was requested as desirable to have > > plaintext view of the dns config. can somebody point out how can I > > get dns info out of current stable resolvconf+dnsmasq? E.g. what are > > my current dns servers, default, per- interface, etc? I guess i'm a > > dnsmasq n00b. > > Sending SIGUSR1 will dump the list of servers in syslog. > > Jun 6 12:48:09 castiana dnsmasq[3429]: time 1465231689 > Jun 6 12:48:09 castiana dnsmasq[3429]: cache size 0, 0/0 cache insertions > re-used unexpired cache entries. > Jun 6 12:48:09 castiana dnsmasq[3429]: queries forwarded 188289, queries > answered locally 4888 > Jun 6 12:48:09 castiana dnsmasq[3429]: queries for authoritative zones 0 > Jun 6 12:48:09 castiana dnsmasq[3429]: server > 2607:f2c0:f00f:2720:216:3eff:fe19:6f91#53: queries sent 945, retried or > failed 0 > Jun 6 12:48:09 castiana dnsmasq[3429]: server > 2607:f2c0:f00f:2720:216:3eff:fec3:3e8d#53: queries sent 1183, retried or > failed 0 > > > This isn't exactly user friendly though. > > In the past, "nm-tool" would dump you a nice view of your network > configuration, including DNS servers and VPNs but that went away with NM 1.x. > > Looks like the nmcli way of doing it nowadays is: > > root@castiana:~# nmcli dev show | grep DNS > IP6.DNS[1]: 2607:f2c0:f00f:2720:216:3eff:fe19:6f91 > IP6.DNS[2]: 2607:f2c0:f00f:2720:216:3eff:fec3:3e8d > > > I'd definitely be in favor of a change to dnsmasq to write and maintain > its current DNS configuration as comments in its resolvconf file. That > way a good old "cat /etc/resolv.conf" would show that 127.0.1.1 is the > DNS server but the actual configuration of that server would be included > above it as nice user-readable comments. Gosh that would be nice. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ANN: DNS resolver changes in yakkety
On Monday, June 06, 2016 12:27:33 PM Stéphane Graber wrote: > On Mon, Jun 06, 2016 at 03:17:51PM +0100, Robie Basak wrote: > > There's a thread here on Ubuntu and systemd-resolved: > > https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html > > > > > > > > It looks like there is some credible criticism here that is worth > > considering. > > They do have some very very good points, my main concerns after reading > the e-mail above are: > > - Anything which doesn't use the C library resolving functions, which >would include any static binary bundling its own copy of those, will >fallback to /etc/resolv.conf and not get split DNS information or the >desired fallback mechanism. > >This is likely to affect a whole bunch of Go binaries and similar >statically built piece of software. It will also, probably more visible >affect web browsers who have recently all switches to doing their own >DNS resolving. The Python interpreters have socket.gethostbyname which is, I believe, a thin layer over the C function, but neither of the two major Python DNS implmentations (python-dns and dnspython source packages) do. They parse /etc/resolv.conf and generate their own queries, so if I understand it correctly the Python world would end up not even internally consistent. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ANN: DNS resolver changes in yakkety
On 7 June 2016 at 04:41, Dimitri John Ledkov wrote: > On 6 June 2016 at 17:27, Stéphane Graber wrote: >> On Mon, Jun 06, 2016 at 03:17:51PM +0100, Robie Basak wrote: >> >> Unless the above can be fixed somehow, and I very much doubt resolved >> will grow a DNS server any time soon, the switch to resolved mostly >> feels like a regression over the existing resolvconf+dnsmasq setup we've >> got right now and which in my experience at least, has been working >> pretty well for us. >> > > I have in the past tried to drop all config files from /etc. > > Dropping /etc/nsswitch.conf is trivial. Apart from libc and shadow > very little else parses that, so that has minimal breakage so things > that do call into libc end up doing the right thing. Go binaries parse nsswitch.conf. If they find something they don't recognize they use the cgo-based resolver (if that is built into the binary, which I think is the case for most binaries we care about), so this shouldn't break anything, just perform slightly worse. Cheers, mwh -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ANN: DNS resolver changes in yakkety
On Mon, Jun 06, 2016 at 05:41:06PM +0100, Dimitri John Ledkov wrote: > On 6 June 2016 at 17:27, Stéphane Graber wrote: > > On Mon, Jun 06, 2016 at 03:17:51PM +0100, Robie Basak wrote: > > > > Unless the above can be fixed somehow, and I very much doubt resolved > > will grow a DNS server any time soon, the switch to resolved mostly > > feels like a regression over the existing resolvconf+dnsmasq setup we've > > got right now and which in my experience at least, has been working > > pretty well for us. > > > > I have in the past tried to drop all config files from /etc. > > Dropping /etc/nsswitch.conf is trivial. Apart from libc and shadow > very little else parses that, so that has minimal breakage so things > that do call into libc end up doing the right thing. > Droping /etc/resolv.conf is hard, and in essence a bunch of stuff > parses and uses it, for right and wrong reasons (e.g. even when doing > shared linking with glibc and having it available). > In those cases, things do go wrong. If there is no split routing, > everything is fine and the change is mostly harmless. With split > routing things will break. > Ideally I would like to still see 127.0.0.1 specified in resolf.conf, > and I'll be fine with that being implemented on top systemd-resolvd > api, I don't think that would be hard, however It seems to me like a > re-implementation of resolvconf+dnsmasq solution. > > I have heard before that it was requested as desirable to have > plaintext view of the dns config. can somebody point out how can I > get dns info out of current stable resolvconf+dnsmasq? E.g. what are > my current dns servers, default, per- interface, etc? I guess i'm a > dnsmasq n00b. Sending SIGUSR1 will dump the list of servers in syslog. Jun 6 12:48:09 castiana dnsmasq[3429]: time 1465231689 Jun 6 12:48:09 castiana dnsmasq[3429]: cache size 0, 0/0 cache insertions re-used unexpired cache entries. Jun 6 12:48:09 castiana dnsmasq[3429]: queries forwarded 188289, queries answered locally 4888 Jun 6 12:48:09 castiana dnsmasq[3429]: queries for authoritative zones 0 Jun 6 12:48:09 castiana dnsmasq[3429]: server 2607:f2c0:f00f:2720:216:3eff:fe19:6f91#53: queries sent 945, retried or failed 0 Jun 6 12:48:09 castiana dnsmasq[3429]: server 2607:f2c0:f00f:2720:216:3eff:fec3:3e8d#53: queries sent 1183, retried or failed 0 This isn't exactly user friendly though. In the past, "nm-tool" would dump you a nice view of your network configuration, including DNS servers and VPNs but that went away with NM 1.x. Looks like the nmcli way of doing it nowadays is: root@castiana:~# nmcli dev show | grep DNS IP6.DNS[1]: 2607:f2c0:f00f:2720:216:3eff:fe19:6f91 IP6.DNS[2]: 2607:f2c0:f00f:2720:216:3eff:fec3:3e8d I'd definitely be in favor of a change to dnsmasq to write and maintain its current DNS configuration as comments in its resolvconf file. That way a good old "cat /etc/resolv.conf" would show that 127.0.1.1 is the DNS server but the actual configuration of that server would be included above it as nice user-readable comments. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com 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
Re: ANN: DNS resolver changes in yakkety
On 6 June 2016 at 17:27, Stéphane Graber wrote: > On Mon, Jun 06, 2016 at 03:17:51PM +0100, Robie Basak wrote: > > Unless the above can be fixed somehow, and I very much doubt resolved > will grow a DNS server any time soon, the switch to resolved mostly > feels like a regression over the existing resolvconf+dnsmasq setup we've > got right now and which in my experience at least, has been working > pretty well for us. > I have in the past tried to drop all config files from /etc. Dropping /etc/nsswitch.conf is trivial. Apart from libc and shadow very little else parses that, so that has minimal breakage so things that do call into libc end up doing the right thing. Droping /etc/resolv.conf is hard, and in essence a bunch of stuff parses and uses it, for right and wrong reasons (e.g. even when doing shared linking with glibc and having it available). In those cases, things do go wrong. If there is no split routing, everything is fine and the change is mostly harmless. With split routing things will break. Ideally I would like to still see 127.0.0.1 specified in resolf.conf, and I'll be fine with that being implemented on top systemd-resolvd api, I don't think that would be hard, however It seems to me like a re-implementation of resolvconf+dnsmasq solution. I have heard before that it was requested as desirable to have plaintext view of the dns config. can somebody point out how can I get dns info out of current stable resolvconf+dnsmasq? E.g. what are my current dns servers, default, per- interface, etc? I guess i'm a dnsmasq n00b. -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ANN: DNS resolver changes in yakkety
On Mon, Jun 06, 2016 at 03:17:51PM +0100, Robie Basak wrote: > There's a thread here on Ubuntu and systemd-resolved: > https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html > > It looks like there is some credible criticism here that is worth > considering. They do have some very very good points, my main concerns after reading the e-mail above are: - Anything which doesn't use the C library resolving functions, which would include any static binary bundling its own copy of those, will fallback to /etc/resolv.conf and not get split DNS information or the desired fallback mechanism. This is likely to affect a whole bunch of Go binaries and similar statically built piece of software. It will also, probably more visible affect web browsers who have recently all switches to doing their own DNS resolving. - This breaks downstream DNSSEC validation. Mail servers and some web browsers require the ability to read the DNSSEC validation result from the DNS reply. Those therefore don't use the libc resolving functions and instead do the DNS request themselves, they'd then fall into the above problem where they'd use /etc/resolv.conf and miss any split DNS or similar configuration done inside resolved. - Some concerns about it broadcasting queries to all DNS servers rather than just the one it's supposed to use for a given domain. Hopefully this was just mis-configuration and not how resolved actually works, as this would be a pretty big privacy issue. - Not having resolved offer a DNS service itself means we can't properly daisy-chain our other DNS/DHCP servers like the dnsmasq instances we use for LXC, LXD and libvirt. That means that the containers and virtual machines will not be getting the same DNS view as the host, being only restricted to hitting the servers in the host /etc/resolv.conf without any awareness of split view DNS. Unless the above can be fixed somehow, and I very much doubt resolved will grow a DNS server any time soon, the switch to resolved mostly feels like a regression over the existing resolvconf+dnsmasq setup we've got right now and which in my experience at least, has been working pretty well for us. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com 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
Re: ANN: DNS resolver changes in yakkety
There's a thread here on Ubuntu and systemd-resolved: https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html It looks like there is some credible criticism here that is worth considering. 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
Re:Re: OpenGL to OpenGL ES change on arm64?
Hi All， We have ARM64 devices used AMD Radeon Series graphics cards。So，same as x86 we really need a full OpenGL Qt support With ARM64 。 在2016年06月04 08时48分，"Steve Langasek"写道： On Sat, Jun 04, 2016 at 02:00:04AM +0200, Matthias Klose wrote: > > There are two ways to make a GLES-enabled Qt stack available on arm64; the > > armhf way (build Qt exclusively for GLES), or the x86 way (build alternative > > stacks for both GL and GLES). > > Which we should pursue depends on whether there is a use case for OpenGL Qt > > software anywhere on ARM64. > > For the phone / embedded GPU case, we have no known chips providing > > accelerated OpenGL drivers. > > For the server / add-on GPU case, we have no known uses for GUI toolkits - > > only CUDA and GPU-accelerated computation. > > So from what I know, we should be fine to ship GLES-only Qt on ARM64, and > > delete any ARM64 binaries from the archive that require GL-enabled Qt. > so why change something, if we know we won't use it? If we see the need > for both stacks, why not keeping the current default, and then go the x86 > way later? You seem to propose a third way to do it, defaulting to GLES, > and then adding support for GL if needed. This looks like extra work, and > unique to arm64. I think you're confused here. We *are* going to be using the Qt GLES stack, for 64-bit ARM phones / devices. We have an immediate need for GLES-enabled Qt because these chips have accelerated GLES drivers, not accelerated GL drivers. And this is exactly the same thing that we already have on armhf, not a "third way". -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re:Re: OpenGL to OpenGL ES change on arm64?
Hi All， We have ARM64 devices used AMD Radeon Series graphics cards。So，same as x86 we really need a full OpenGL Qt support With ARM64 。 At 2016-06-04 08:48:17, "Steve Langasek" wrote: >On Sat, Jun 04, 2016 at 02:00:04AM +0200, Matthias Klose wrote: >> > There are two ways to make a GLES-enabled Qt stack available on arm64; the >> > armhf way (build Qt exclusively for GLES), or the x86 way (build >> > alternative >> > stacks for both GL and GLES). > >> > Which we should pursue depends on whether there is a use case for OpenGL Qt >> > software anywhere on ARM64. > >> > For the phone / embedded GPU case, we have no known chips providing >> > accelerated OpenGL drivers. > >> > For the server / add-on GPU case, we have no known uses for GUI toolkits - >> > only CUDA and GPU-accelerated computation. > >> > So from what I know, we should be fine to ship GLES-only Qt on ARM64, and >> > delete any ARM64 binaries from the archive that require GL-enabled Qt. > >> so why change something, if we know we won't use it? If we see the need >> for both stacks, why not keeping the current default, and then go the x86 >> way later? You seem to propose a third way to do it, defaulting to GLES, >> and then adding support for GL if needed. This looks like extra work, and >> unique to arm64. > >I think you're confused here. We *are* going to be using the Qt GLES stack, >for 64-bit ARM phones / devices. We have an immediate need for GLES-enabled >Qt because these chips have accelerated GLES drivers, not accelerated GL >drivers. > >And this is exactly the same thing that we already have on armhf, not a >"third way". > >-- >Steve Langasek Give me a lever long enough and a Free OS >Debian Developer to set it on, and I can move the world. >Ubuntu Developerhttp://www.debian.org/ >slanga...@ubuntu.com vor...@debian.org -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
