[Touch-packages] [Bug 1680811] Re: Request to add wireguard interface to interface-order
Tanks. I'll make this change upstream in Debian too. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1680811 Title: Request to add wireguard interface to interface-order Status in resolvconf package in Ubuntu: Confirmed Bug description: This started from https://github.com/jlund/streisand/issues/557. Basically wg* namespace is not in interface-order and acts last in * scope, and this makes resolv.conf to stay in the same state. I suggest the following change: :/etc/resolvconf/interface-order # interface-order(5) lo.inet6 lo.inet lo.@(dnsmasq|pdnsd) lo.!(pdns|pdns-recursor) lo +wg* tun* tap* hso* em+([0-9])?(_+([0-9]))* p+([0-9])p+([0-9])?(_+([0-9]))* @(br|eth)*([^.]).inet6 @(br|eth)*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc) @(br|eth)*([^.]).inet @(br|eth)*([^.]).@(dhclient|dhcpcd|pump|udhcpc) @(br|eth)* @(ath|wifi|wlan)*([^.]).inet6 @(ath|wifi|wlan)*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc) @(ath|wifi|wlan)*([^.]).inet @(ath|wifi|wlan)*([^.]).@(dhclient|dhcpcd|pump|udhcpc) @(ath|wifi|wlan)* ppp* * To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1680811/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1663345] Re: 10-15 seconds delay until host is resolved
** Changed in: resolvconf (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1663345 Title: 10-15 seconds delay until host is resolved Status in resolvconf package in Ubuntu: Invalid Bug description: I have the problem that every new DNS query takes about 10 - 15 seconds. This is the first time I used "ubuntu-bug resolvconf". Hopefully all information of my system are attached to this report. Thanks for help or hints:) ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: resolvconf 1.79ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-37.39-generic 4.8.16 Uname: Linux 4.8.0-37-generic x86_64 ApportVersion: 2.20.3-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Thu Feb 9 19:36:34 2017 EcryptfsInUse: Yes InstallationDate: Installed on 2017-01-22 (18 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.resolvconf.resolv.conf.d.head: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 mtime.conffile..etc.resolvconf.resolv.conf.d.head: 2017-02-09T18:49:48.934789 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1663345/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1663345] Re: 10-15 seconds delay until host is resolved
Wait a sec, I just noticed that you have the line "nameserver 127.0.0.1" in your /etc/resolvconf/resolv.conf.d/head file. Remove that line, it shouldn't be there. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1663345 Title: 10-15 seconds delay until host is resolved Status in resolvconf package in Ubuntu: Incomplete Bug description: I have the problem that every new DNS query takes about 10 - 15 seconds. This is the first time I used "ubuntu-bug resolvconf". Hopefully all information of my system are attached to this report. Thanks for help or hints:) ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: resolvconf 1.79ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-37.39-generic 4.8.16 Uname: Linux 4.8.0-37-generic x86_64 ApportVersion: 2.20.3-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Thu Feb 9 19:36:34 2017 EcryptfsInUse: Yes InstallationDate: Installed on 2017-01-22 (18 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.resolvconf.resolv.conf.d.head: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 mtime.conffile..etc.resolvconf.resolv.conf.d.head: 2017-02-09T18:49:48.934789 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1663345/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1663345] Re: 10-15 seconds delay until host is resolved
Please post the output of /usr/share/resolvconf/dump-debug-info run from a terminal. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1663345 Title: 10-15 seconds delay until host is resolved Status in resolvconf package in Ubuntu: Incomplete Bug description: I have the problem that every new DNS query takes about 10 - 15 seconds. This is the first time I used "ubuntu-bug resolvconf". Hopefully all information of my system are attached to this report. Thanks for help or hints:) ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: resolvconf 1.79ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-37.39-generic 4.8.16 Uname: Linux 4.8.0-37-generic x86_64 ApportVersion: 2.20.3-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Thu Feb 9 19:36:34 2017 EcryptfsInUse: Yes InstallationDate: Installed on 2017-01-22 (18 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.resolvconf.resolv.conf.d.head: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 mtime.conffile..etc.resolvconf.resolv.conf.d.head: 2017-02-09T18:49:48.934789 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1663345/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1663345] Re: 10-15 seconds delay until host is resolved
Make sure "RESOLVCONF=no" in /etc/default/bind9. If not, set RESOLVCONF=no in /etc/default/bind9 and restart. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1663345 Title: 10-15 seconds delay until host is resolved Status in resolvconf package in Ubuntu: Incomplete Bug description: I have the problem that every new DNS query takes about 10 - 15 seconds. This is the first time I used "ubuntu-bug resolvconf". Hopefully all information of my system are attached to this report. Thanks for help or hints:) ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: resolvconf 1.79ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-37.39-generic 4.8.16 Uname: Linux 4.8.0-37-generic x86_64 ApportVersion: 2.20.3-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Thu Feb 9 19:36:34 2017 EcryptfsInUse: Yes InstallationDate: Installed on 2017-01-22 (18 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.resolvconf.resolv.conf.d.head: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 mtime.conffile..etc.resolvconf.resolv.conf.d.head: 2017-02-09T18:49:48.934789 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1663345/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1663345] Re: 10-15 seconds delay until host is resolved
** Changed in: resolvconf (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1663345 Title: 10-15 seconds delay until host is resolved Status in resolvconf package in Ubuntu: Incomplete Bug description: I have the problem that every new DNS query takes about 10 - 15 seconds. This is the first time I used "ubuntu-bug resolvconf". Hopefully all information of my system are attached to this report. Thanks for help or hints:) ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: resolvconf 1.79ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-37.39-generic 4.8.16 Uname: Linux 4.8.0-37-generic x86_64 ApportVersion: 2.20.3-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Thu Feb 9 19:36:34 2017 EcryptfsInUse: Yes InstallationDate: Installed on 2017-01-22 (18 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.resolvconf.resolv.conf.d.head: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 mtime.conffile..etc.resolvconf.resolv.conf.d.head: 2017-02-09T18:49:48.934789 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1663345/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1663345] Re: 10-15 seconds delay until host is resolved
Have you unintentionally installed either the dnsmasq or the bind9 package? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1663345 Title: 10-15 seconds delay until host is resolved Status in resolvconf package in Ubuntu: New Bug description: I have the problem that every new DNS query takes about 10 - 15 seconds. This is the first time I used "ubuntu-bug resolvconf". Hopefully all information of my system are attached to this report. Thanks for help or hints:) ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: resolvconf 1.79ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-37.39-generic 4.8.16 Uname: Linux 4.8.0-37-generic x86_64 ApportVersion: 2.20.3-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Thu Feb 9 19:36:34 2017 EcryptfsInUse: Yes InstallationDate: Installed on 2017-01-22 (18 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.resolvconf.resolv.conf.d.head: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 mtime.conffile..etc.resolvconf.resolv.conf.d.head: 2017-02-09T18:49:48.934789 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1663345/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1610479] Re: interface-order needs definitions for systemd predictable names
I revised the patch slightly (to put the wl* names with the wifi* names) and have applied it to the Debian package which I plan to release soon. ** Attachment added: "interface-order-patch_20170213-th1" https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1610479/+attachment/4818472/+files/interface-order-patch_20170213-th1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1610479 Title: interface-order needs definitions for systemd predictable names Status in resolvconf package in Ubuntu: Confirmed Bug description: Another release, another round of interface name changes. This time systemd has gotten into the fray to make things even more interesting. https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ As such, IPv4 resolvers are now being preferred over IPv6 again on these new interface names. kjotte@flounder:~$ grep '' /run/resolvconf/interface/ens3.* /run/resolvconf/interface/ens3.dhclient:search nivex.lan. /run/resolvconf/interface/ens3.dhclient:nameserver 172.31.3.30 /run/resolvconf/interface/ens3.ip6.dhclient:search home.nivex.net. /run/resolvconf/interface/ens3.ip6.dhclient:nameserver fd60:e0:a0f4:121::10 /run/resolvconf/interface/ens3.ip6.dhclient:nameserver fd60:e0:a0f4:321::4 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: resolvconf 1.78ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13 Uname: Linux 4.4.0-31-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Fri Aug 5 19:53:25 2016 InstallationDate: Installed on 2016-08-04 (1 days ago) InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) PackageArchitecture: all ProcEnviron: TERM=vt220 PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1610479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1652755] Re: Resolvconf multiple nameservers and search domains only first is used - quote bug
Hi, I understand why you might suggest this but on balance I don't think that resolvconf should be so verbose in normal operation. ** Changed in: resolvconf (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1652755 Title: Resolvconf multiple nameservers and search domains only first is used - quote bug Status in resolvconf package in Ubuntu: Invalid Bug description: Having more than one 'nameserver' or 'search' entry in any of the source files results in only the first one being used. The cause is a quote bug in /etc/resolvconf/update.d/libc. Patch attached. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1652755/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1652755] Re: Resolvconf multiple nameservers and search domains only first is used - quote bug
I am not convinced that this patch is correct. (I will look more carefully when I return from a trip.) Are you aware that resolvconf by default (unless TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no) truncates the list of nameservers after a loopback address? ** Changed in: resolvconf (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1652755 Title: Resolvconf multiple nameservers and search domains only first is used - quote bug Status in resolvconf package in Ubuntu: Incomplete Bug description: Having more than one 'nameserver' or 'search' entry in any of the source files results in only the first one being used. The cause is a quote bug in /etc/resolvconf/update.d/libc. Patch attached. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1652755/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1638836] Re: resolv.conf for resolved stub server should have a comment how to see the actual servers
Right, I think the file should only document the Ubuntu-specific things such as the facts that by default resolvconf and the systemd resolver are used, NetworkManager is used by default on Desktop and ifup on Server, and so on. There have been hundreds of questions about these basic things on AskUbuntu and the forums over the years. I have often referred people to Stephane Graber's blog post (https://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/) for background info but this is as of 16.11 no longer adequate. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1638836 Title: resolv.conf for resolved stub server should have a comment how to see the actual servers Status in resolvconf package in Ubuntu: In Progress Bug description: resolv.conf currently just has nameserver 127.0.0.53 with resolved (its local stub resolver). We should have an extra comment on top of that that says # systemd-resolved stub resolver; run "systemd-resolve --status" to see the actual name servers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1638836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1638836] Re: resolv.conf for resolved stub server should have a comment how to see the actual servers
If such a comment were to be added then in order not to mislead it would have to take into account the configurability of various components. So you'd have to say something like: «If the line "nameserver 127.0.0.53" is present then it probably refers to the systemd resolver listening on the loopback address. By default the systemd resolver is also configured to handle name queries via the Name Service Switch whose configuration file is nsswitch.conf. The name servers to which the systemd resolver forwards queries can be discovered by running "systemd-resolve --status".» What would be far better, though, is to include a text file or manpage explaining how name service currently works in Ubuntu. (Actually we should have done this long ago.) The file could include the previous paragraph but would also talk about resolvconf and NetworkManager and its plugins. The name of this file could then be mentioned in the header that resolvconf writes into resolv.conf. /etc/resolvconf/resolv.conf.d/head would then be: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # For more info see /usr/share/doc/resolvconf/name-service-in-Ubuntu.txt # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1638836 Title: resolv.conf for resolved stub server should have a comment how to see the actual servers Status in resolvconf package in Ubuntu: In Progress Bug description: resolv.conf currently just has nameserver 127.0.0.53 with resolved (its local stub resolver). We should have an extra comment on top of that that says # systemd-resolved stub resolver; run "systemd-resolve --status" to see the actual name servers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1638836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1637700] Re: Caching dnsmasq stops resolving after some time
Compare bug #1631241. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1637700 Title: Caching dnsmasq stops resolving after some time Status in Ubuntu: New Status in network-manager package in Ubuntu: New Bug description: Since upgrading to yakkety my network sometimes stops working - it might be related to suspending the laptop. The NetworkManager-managed caching dnsmasq just stops resolving at some point: dig google.com @127.0.1.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @127.0.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 22521 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com.IN A ;; Query time: 0 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Oct 29 09:12:33 CEST 2016 ;; MSG SIZE rcvd: 28 Networking and upstream DNS are fine: dig google.com @8.8.8.8 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63345 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 299 IN A 46.134.208.30 [...] ;; Query time: 43 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Oct 29 09:12:31 CEST 2016 ;; MSG SIZE rcvd: 295 Killing it resolves the issue, dnsmasq gets restarted and works again: ps aux | grep dnsmasq nobody4262 0.0 0.0 54308 2740 ?S01:30 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.1.1 --cache-size=0 --conf-file=/dev/null --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d sudo kill 4262 dig google.com @127.0.1.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @127.0.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58324 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 299 IN A 46.134.208.59 [...] ;; Query time: 41 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Oct 29 09:12:54 CEST 2016 ;; MSG SIZE rcvd: 295 ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: dnsmasq (not installed) ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0 Uname: Linux 4.8.0-26-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Sat Oct 29 09:13:04 2016 InstallationDate: Installed on 2016-05-06 (175 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) --- ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity DistroRelease: Ubuntu 16.10 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2016-05-06 (175 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=false WWANEnabled=true NonfreeKernelModules: zfs zunicode zcommon znvpair zavl Package: network-manager 1.2.4-0ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0 Tags: yakkety third-party-packages Uname: Linux 4.8.0-26-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dialout dip libvirt libvirtd lpadmin lxd plugdev sambashare sbuild sudo vboxusers _MarkForUpload: True modified.conffile..etc.polkit-1.localauthority.50-local.d.org.freedesktop.NetworkManager.pkla: [deleted] nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.4connected started full enabled enabled disabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1637700/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1637700] Re: Caching dnsmasq stops resolving after some time
Edit /etc/NetworkManager/NetworkManager.conf and comment out the line "dns=dnsmasq" with a leading '#'. Then reboot. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1637700 Title: Caching dnsmasq stops resolving after some time Status in Ubuntu: New Status in network-manager package in Ubuntu: New Bug description: Since upgrading to yakkety my network sometimes stops working - it might be related to suspending the laptop. The NetworkManager-managed caching dnsmasq just stops resolving at some point: dig google.com @127.0.1.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @127.0.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 22521 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com.IN A ;; Query time: 0 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Oct 29 09:12:33 CEST 2016 ;; MSG SIZE rcvd: 28 Networking and upstream DNS are fine: dig google.com @8.8.8.8 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63345 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 299 IN A 46.134.208.30 [...] ;; Query time: 43 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Oct 29 09:12:31 CEST 2016 ;; MSG SIZE rcvd: 295 Killing it resolves the issue, dnsmasq gets restarted and works again: ps aux | grep dnsmasq nobody4262 0.0 0.0 54308 2740 ?S01:30 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.1.1 --cache-size=0 --conf-file=/dev/null --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d sudo kill 4262 dig google.com @127.0.1.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @127.0.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58324 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 299 IN A 46.134.208.59 [...] ;; Query time: 41 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Oct 29 09:12:54 CEST 2016 ;; MSG SIZE rcvd: 295 ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: dnsmasq (not installed) ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0 Uname: Linux 4.8.0-26-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Sat Oct 29 09:13:04 2016 InstallationDate: Installed on 2016-05-06 (175 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) --- ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity DistroRelease: Ubuntu 16.10 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2016-05-06 (175 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=false WWANEnabled=true NonfreeKernelModules: zfs zunicode zcommon znvpair zavl Package: network-manager 1.2.4-0ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0 Tags: yakkety third-party-packages Uname: Linux 4.8.0-26-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dialout dip libvirt libvirtd lpadmin lxd plugdev sambashare sbuild sudo vboxusers _MarkForUpload: True modified.conffile..etc.polkit-1.localauthority.50-local.d.org.freedesktop.NetworkManager.pkla: [deleted] nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.4connected started full enabled enabled disabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1637700/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help
[Touch-packages] [Bug 1637700] Re: Caching dnsmasq stops resolving after some time
NetworkManager is starting a dnsmasq instance whereas it shouldn't do that any more. ** Package changed: dnsmasq (Ubuntu) => ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1637700 Title: Caching dnsmasq stops resolving after some time Status in Ubuntu: New Status in network-manager package in Ubuntu: New Bug description: Since upgrading to yakkety my network sometimes stops working - it might be related to suspending the laptop. The NetworkManager-managed caching dnsmasq just stops resolving at some point: dig google.com @127.0.1.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @127.0.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 22521 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com.IN A ;; Query time: 0 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Oct 29 09:12:33 CEST 2016 ;; MSG SIZE rcvd: 28 Networking and upstream DNS are fine: dig google.com @8.8.8.8 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63345 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 299 IN A 46.134.208.30 [...] ;; Query time: 43 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Oct 29 09:12:31 CEST 2016 ;; MSG SIZE rcvd: 295 Killing it resolves the issue, dnsmasq gets restarted and works again: ps aux | grep dnsmasq nobody4262 0.0 0.0 54308 2740 ?S01:30 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.1.1 --cache-size=0 --conf-file=/dev/null --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d sudo kill 4262 dig google.com @127.0.1.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @127.0.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58324 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 299 IN A 46.134.208.59 [...] ;; Query time: 41 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Oct 29 09:12:54 CEST 2016 ;; MSG SIZE rcvd: 295 ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: dnsmasq (not installed) ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0 Uname: Linux 4.8.0-26-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Sat Oct 29 09:13:04 2016 InstallationDate: Installed on 2016-05-06 (175 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) --- ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity DistroRelease: Ubuntu 16.10 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2016-05-06 (175 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=false WWANEnabled=true NonfreeKernelModules: zfs zunicode zcommon znvpair zavl Package: network-manager 1.2.4-0ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0 Tags: yakkety third-party-packages Uname: Linux 4.8.0-26-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dialout dip libvirt libvirtd lpadmin lxd plugdev sambashare sbuild sudo vboxusers _MarkForUpload: True modified.conffile..etc.polkit-1.localauthority.50-local.d.org.freedesktop.NetworkManager.pkla: [deleted] nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.4connected started full enabled enabled disabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1637700/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe :
[Touch-packages] [Bug 1637700] Re: Caching dnsmasq stops resolving after some time
In yakkety there is no longer supposed to be a local forwarding nameserver (instance of dnsmasq) listening at 127.0.1.1. Instead an instande of resolved is started. Name resolution requests are fed to it via the name service switch (configured with nsswitch.conf) rather than via the libc resolver (configured with resolv.conf). Announcement: https://lists.ubuntu.com/archives/ubuntu- devel/2016-May/039350.html Please post the output of the /usr/share/resolvconf/dump-debug-info utility. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1637700 Title: Caching dnsmasq stops resolving after some time Status in dnsmasq package in Ubuntu: New Status in network-manager package in Ubuntu: New Bug description: Since upgrading to yakkety my network sometimes stops working - it might be related to suspending the laptop. The NetworkManager-managed caching dnsmasq just stops resolving at some point: dig google.com @127.0.1.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @127.0.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 22521 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com.IN A ;; Query time: 0 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Oct 29 09:12:33 CEST 2016 ;; MSG SIZE rcvd: 28 Networking and upstream DNS are fine: dig google.com @8.8.8.8 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63345 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 299 IN A 46.134.208.30 [...] ;; Query time: 43 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Oct 29 09:12:31 CEST 2016 ;; MSG SIZE rcvd: 295 Killing it resolves the issue, dnsmasq gets restarted and works again: ps aux | grep dnsmasq nobody4262 0.0 0.0 54308 2740 ?S01:30 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.1.1 --cache-size=0 --conf-file=/dev/null --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d sudo kill 4262 dig google.com @127.0.1.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @127.0.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58324 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 299 IN A 46.134.208.59 [...] ;; Query time: 41 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Oct 29 09:12:54 CEST 2016 ;; MSG SIZE rcvd: 295 ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: dnsmasq (not installed) ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0 Uname: Linux 4.8.0-26-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Sat Oct 29 09:13:04 2016 InstallationDate: Installed on 2016-05-06 (175 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) --- ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity DistroRelease: Ubuntu 16.10 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2016-05-06 (175 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=false WWANEnabled=true NonfreeKernelModules: zfs zunicode zcommon znvpair zavl Package: network-manager 1.2.4-0ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0 Tags: yakkety third-party-packages Uname: Linux 4.8.0-26-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dialout dip libvirt libvirtd lpadmin lxd plugdev sambashare sbuild sudo vboxusers _MarkForUpload: True modified.conffile..etc.polkit-1.localauthority.50-local.d.org.freedesktop.NetworkManager.pkla: [deleted] nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN
[Touch-packages] [Bug 1628552] Re: on startup gateway & dns- options in /etc/network/interfaces are not always set
** Changed in: resolvconf (Ubuntu) Status: New => Incomplete ** Changed in: ifupdown (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1628552 Title: on startup gateway & dns- options in /etc/network/interfaces are not always set Status in ifupdown package in Ubuntu: Incomplete Status in resolvconf package in Ubuntu: Incomplete Bug description: recently i have upgraded 4 VM-based systems to 16.04.1 LTS (Xenial Xerus). on startup, settings within /etc/network/interfaces do not appear to be taking effect reliably. specifically, the gateway and dns- settings have been problematic for me. on subsequent restarts, all or some of the settings take effect other times the gateway is set and the dns- options are not set. very problematic when the default gateway is not added to the routing table. the dns- settings were a bit easier to illustrate the issue. i added a comment to /etc/resolvconf/resolv.conf.d/base (# base) & etc/resolvconf/resolv.conf.d/tail (# tail). $ cat /etc/resolvconf/resolv.conf.d/* # base # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # tail on startup on 1 of the systems showed this: $ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # tail you can see the "# base" comment wasn't added. let me know if i can add anymore details or if this should be posted somewhere else. $ lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 $ apt-cache policy ifupdown ifupdown: Installed: 0.8.10ubuntu1.1 Candidate: 0.8.10ubuntu1.1 Version table: *** 0.8.10ubuntu1.1 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 0.8.10ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages $ apt-cache policy resolvconf resolvconf: Installed: 1.78ubuntu2 Candidate: 1.78ubuntu2 Version table: *** 1.78ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1628552/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1628552] Re: on startup gateway & dns- options in /etc/network/interfaces are not always set
Are there cases where the interface is configured properly but resolv.conf is not updated to include material from the dns-* lines? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1628552 Title: on startup gateway & dns- options in /etc/network/interfaces are not always set Status in ifupdown package in Ubuntu: New Status in resolvconf package in Ubuntu: New Bug description: recently i have upgraded 4 VM-based systems to 16.04.1 LTS (Xenial Xerus). on startup, settings within /etc/network/interfaces do not appear to be taking effect reliably. specifically, the gateway and dns- settings have been problematic for me. on subsequent restarts, all or some of the settings take effect other times the gateway is set and the dns- options are not set. very problematic when the default gateway is not added to the routing table. the dns- settings were a bit easier to illustrate the issue. i added a comment to /etc/resolvconf/resolv.conf.d/base (# base) & etc/resolvconf/resolv.conf.d/tail (# tail). $ cat /etc/resolvconf/resolv.conf.d/* # base # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # tail on startup on 1 of the systems showed this: $ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # tail you can see the "# base" comment wasn't added. let me know if i can add anymore details or if this should be posted somewhere else. $ lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 $ apt-cache policy ifupdown ifupdown: Installed: 0.8.10ubuntu1.1 Candidate: 0.8.10ubuntu1.1 Version table: *** 0.8.10ubuntu1.1 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 0.8.10ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages $ apt-cache policy resolvconf resolvconf: Installed: 1.78ubuntu2 Candidate: 1.78ubuntu2 Version table: *** 1.78ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1628552/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1628552] Re: on startup gateway & dns- options in /etc/network/interfaces are not always set
Obviously the presence of material in the "base" file should have no effect on the processing of material from /etc/network/interfaces. Are you still sure that material from /e/n/i is sometimes incorrectly omitted from the /etc/resolv.conf file? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1628552 Title: on startup gateway & dns- options in /etc/network/interfaces are not always set Status in ifupdown package in Ubuntu: New Status in resolvconf package in Ubuntu: New Bug description: recently i have upgraded 4 VM-based systems to 16.04.1 LTS (Xenial Xerus). on startup, settings within /etc/network/interfaces do not appear to be taking effect reliably. specifically, the gateway and dns- settings have been problematic for me. on subsequent restarts, all or some of the settings take effect other times the gateway is set and the dns- options are not set. very problematic when the default gateway is not added to the routing table. the dns- settings were a bit easier to illustrate the issue. i added a comment to /etc/resolvconf/resolv.conf.d/base (# base) & etc/resolvconf/resolv.conf.d/tail (# tail). $ cat /etc/resolvconf/resolv.conf.d/* # base # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # tail on startup on 1 of the systems showed this: $ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # tail you can see the "# base" comment wasn't added. let me know if i can add anymore details or if this should be posted somewhere else. $ lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 $ apt-cache policy ifupdown ifupdown: Installed: 0.8.10ubuntu1.1 Candidate: 0.8.10ubuntu1.1 Version table: *** 0.8.10ubuntu1.1 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 0.8.10ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages $ apt-cache policy resolvconf resolvconf: Installed: 1.78ubuntu2 Candidate: 1.78ubuntu2 Version table: *** 1.78ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1628552/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1628552] Re: on startup gateway & dns- options in /etc/network/interfaces are not always set
Comment lines from the "base" file are always omitted from resolv.conf. Try adding a line "search bogus.com“ and see if "bogus.com" shows up on the "search" line in resolv.conf. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1628552 Title: on startup gateway & dns- options in /etc/network/interfaces are not always set Status in ifupdown package in Ubuntu: New Status in resolvconf package in Ubuntu: New Bug description: recently i have upgraded 4 VM-based systems to 16.04.1 LTS (Xenial Xerus). on startup, settings within /etc/network/interfaces do not appear to be taking effect reliably. specifically, the gateway and dns- settings have been problematic for me. on subsequent restarts, all or some of the settings take effect other times the gateway is set and the dns- options are not set. very problematic when the default gateway is not added to the routing table. the dns- settings were a bit easier to illustrate the issue. i added a comment to /etc/resolvconf/resolv.conf.d/base (# base) & etc/resolvconf/resolv.conf.d/tail (# tail). $ cat /etc/resolvconf/resolv.conf.d/* # base # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # tail on startup on 1 of the systems showed this: $ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # tail you can see the "# base" comment wasn't added. let me know if i can add anymore details or if this should be posted somewhere else. $ lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 $ apt-cache policy ifupdown ifupdown: Installed: 0.8.10ubuntu1.1 Candidate: 0.8.10ubuntu1.1 Version table: *** 0.8.10ubuntu1.1 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 0.8.10ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages $ apt-cache policy resolvconf resolvconf: Installed: 1.78ubuntu2 Candidate: 1.78ubuntu2 Version table: *** 1.78ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1628552/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1610479] Re: interface-order needs definitions for systemd predictable names
Hi and thanks for the report. How 'bout a patch? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1610479 Title: interface-order needs definitions for systemd predictable names Status in resolvconf package in Ubuntu: New Bug description: Another release, another round of interface name changes. This time systemd has gotten into the fray to make things even more interesting. https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ As such, IPv4 resolvers are now being preferred over IPv6 again on these new interface names. kjotte@flounder:~$ grep '' /run/resolvconf/interface/ens3.* /run/resolvconf/interface/ens3.dhclient:search nivex.lan. /run/resolvconf/interface/ens3.dhclient:nameserver 172.31.3.30 /run/resolvconf/interface/ens3.ip6.dhclient:search home.nivex.net. /run/resolvconf/interface/ens3.ip6.dhclient:nameserver fd60:e0:a0f4:121::10 /run/resolvconf/interface/ens3.ip6.dhclient:nameserver fd60:e0:a0f4:321::4 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: resolvconf 1.78ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13 Uname: Linux 4.4.0-31-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Fri Aug 5 19:53:25 2016 InstallationDate: Installed on 2016-08-04 (1 days ago) InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) PackageArchitecture: all ProcEnviron: TERM=vt220 PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1610479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1593489] Re: resolvconf postrm is broken, purge breaks DNS
Thanks for the bug report. Yes, this is a bug. Here's a patch I have applied to the Debian version which will appear shortly in Debian resolvconf version 1.80. This should fix the bug in the Ubuntu version of the package when it's merged. ** Attachment added: "resolvconf_bug_1593489_patch" https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1593489/+attachment/4685486/+files/resolvconf_bug_1593489_patch ** Changed in: resolvconf (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1593489 Title: resolvconf postrm is broken, purge breaks DNS Status in resolvconf package in Ubuntu: Confirmed Bug description: apt-get remove resolvconf incorrectly leaves a symlink from /etc/resolv.conf to ../run/resolvconf/resolv.conf. apt-get purge resolvconf leaves that symlink with no target, so DNS is broken. The problem is in postrm: it's examining /etc/resolv.conf to see if it's a link to /run/resolvconf/resolv.conf, but it's a relative link to ../run/resolvconf/resolv.conf, so the comparison fails, resulting in the failures above. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: resolvconf 1.78ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-24.43-generic 4.4.10 Uname: Linux 4.4.0-24-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Thu Jun 16 23:52:41 2016 PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1593489/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1522057] Re: DNS resolution stops working after some time
This possibly arises from bug #1003842. What is possibly happening: the second or third nameserver on the list of available nameservers supplied to dnsmasq replies quickly to dnsmasq's query with a negative answer and dnsmasq immediately passes that negative answer back to the resolver. When dnsmasq is not used, the resolver tries the first nameserver on the list first, only trying the second nameserver after a timeout period. If this is the problem then the "correct" solution is to fix the malfunctioning nameserver or to remove it from the list. ** Changed in: dnsmasq (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1522057 Title: DNS resolution stops working after some time Status in dnsmasq package in Ubuntu: Incomplete Status in network-manager package in Ubuntu: Confirmed Bug description: DNS resolution stops working after sometime (usually 10-20 minutes) in Lubuntu 15.10 The problem can be temporarily corrected after restarting network- manager using systemctl, but it starts again after 10-20 minutes. Looks like network-manager is not configuring dnsmasq properly. Output from 'nslookup google.com': ~ Server: 127.0.1.1 Address: 127.0.1.1#53 ** server can't find google.com: REFUSED ~ Output from 'tcpdump -i lo port 53' while running above command: ~ 20:16:59.235879 IP localhost.38045 > comp0.arhome.info.domain: 28529+ A? google.com. (28) 20:16:59.286851 IP comp0.arhome.info.domain > localhost.38045: 28529 Refused 0/0/0 (28) ~ ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: network-manager 1.0.4-0ubuntu5.1 ProcVersionSignature: Ubuntu 4.2.0-18.22-generic 4.2.3 Uname: Linux 4.2.0-18-generic x86_64 ApportVersion: 2.19.1-0ubuntu5 Architecture: amd64 CRDA: country IN: DFS-JP (2402 - 2482 @ 40), (N/A, 20), (N/A) (5170 - 5250 @ 80), (N/A, 20), (N/A) (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 20), (N/A) CurrentDesktop: LXDE Date: Wed Dec 2 20:14:32 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2015-09-25 (68 days ago) InstallationMedia: Lubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) IpRoute: default via 172.16.84.1 dev wlan0 proto static metric 600 172.16.84.0/22 dev wlan0 proto kernel scope link src 172.16.84.50 metric 600 200.1.1.2 via 172.16.84.1 dev wlan0 proto dhcp metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: Upgraded to wily on 2015-11-06 (25 days ago) nmcli-dev: DEVICETYPE STATEDBUS-PATH CONNECTION CON-UUID CON-PATH wlan0 wifi connected/org/freedesktop/NetworkManager/Devices/1 nn0.arhome.info bab29dc2-8a79-4170-8253-277286712124 /org/freedesktop/NetworkManager/ActiveConnection/0 eth0 ethernet unavailable /org/freedesktop/NetworkManager/Devices/2 -- ---- vboxnet0 ethernet unmanaged/org/freedesktop/NetworkManager/Devices/3 -- ---- loloopback unmanaged/org/freedesktop/NetworkManager/Devices/0 -- ---- nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1522057/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1522057] Re: DNS resolution stops working after some time
** Summary changed: - DNS resolution stops working after sometime + DNS resolution stops working after some time -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1522057 Title: DNS resolution stops working after some time Status in dnsmasq package in Ubuntu: New Status in network-manager package in Ubuntu: Confirmed Bug description: DNS resolution stops working after sometime (usually 10-20 minutes) in Lubuntu 15.10 The problem can be temporarily corrected after restarting network- manager using systemctl, but it starts again after 10-20 minutes. Looks like network-manager is not configuring dnsmasq properly. Output from 'nslookup google.com': ~ Server: 127.0.1.1 Address: 127.0.1.1#53 ** server can't find google.com: REFUSED ~ Output from 'tcpdump -i lo port 53' while running above command: ~ 20:16:59.235879 IP localhost.38045 > comp0.arhome.info.domain: 28529+ A? google.com. (28) 20:16:59.286851 IP comp0.arhome.info.domain > localhost.38045: 28529 Refused 0/0/0 (28) ~ ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: network-manager 1.0.4-0ubuntu5.1 ProcVersionSignature: Ubuntu 4.2.0-18.22-generic 4.2.3 Uname: Linux 4.2.0-18-generic x86_64 ApportVersion: 2.19.1-0ubuntu5 Architecture: amd64 CRDA: country IN: DFS-JP (2402 - 2482 @ 40), (N/A, 20), (N/A) (5170 - 5250 @ 80), (N/A, 20), (N/A) (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 20), (N/A) CurrentDesktop: LXDE Date: Wed Dec 2 20:14:32 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2015-09-25 (68 days ago) InstallationMedia: Lubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) IpRoute: default via 172.16.84.1 dev wlan0 proto static metric 600 172.16.84.0/22 dev wlan0 proto kernel scope link src 172.16.84.50 metric 600 200.1.1.2 via 172.16.84.1 dev wlan0 proto dhcp metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: Upgraded to wily on 2015-11-06 (25 days ago) nmcli-dev: DEVICETYPE STATEDBUS-PATH CONNECTION CON-UUID CON-PATH wlan0 wifi connected/org/freedesktop/NetworkManager/Devices/1 nn0.arhome.info bab29dc2-8a79-4170-8253-277286712124 /org/freedesktop/NetworkManager/ActiveConnection/0 eth0 ethernet unavailable /org/freedesktop/NetworkManager/Devices/2 -- ---- vboxnet0 ethernet unmanaged/org/freedesktop/NetworkManager/Devices/3 -- ---- loloopback unmanaged/org/freedesktop/NetworkManager/Devices/0 -- ---- nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1522057/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1577720] Re: dnsmasq resolves xyzzy.xyzzy.xyzzy. to unknown IP
** Changed in: dnsmasq (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1577720 Title: dnsmasq resolves xyzzy.xyzzy.xyzzy. to unknown IP Status in dnsmasq package in Ubuntu: Invalid Bug description: [enzo@Feynman ~/Temp] host xyzzy.xyzzy.xyzzy. xyzzy.xyzzy.xyzzy has address 54.72.52.58 Host xyzzy.xyzzy.xyzzy not found: 3(NXDOMAIN) Host xyzzy.xyzzy.xyzzy not found: 3(NXDOMAIN) [enzo@Feynman ~/Temp] host 54.72.52.58 58.52.72.54.in-addr.arpa domain name pointer ec2-54-72-52-58.eu-west-1.compute.amazonaws.com. This is unacceptable and a potential security risk! "xyzzy.xyzzy.xyzzy." is an invalidDNS name that needs to always fail when resolved. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq (not installed) ProcVersionSignature: Ubuntu 4.4.0-21.37-lowlatency 4.4.6 Uname: Linux 4.4.0-21-lowlatency x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 CurrentDesktop: KDE Date: Tue May 3 12:34:10 2016 InstallationDate: Installed on 2016-04-22 (10 days ago) InstallationMedia: Kubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1577720/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1575644] Re: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used
*** This bug is a duplicate of bug 1003842 *** https://bugs.launchpad.net/bugs/1003842 What remains unexplained is why the dnsmasq package was installed on your machine at all. Is it the case that dnsmasq was not installed before the upgrade and it was installed after the upgrade? In that case, please file a new bug report describing that particular misbehavior. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1575644 Title: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used Status in dnsmasq package in Ubuntu: Incomplete Bug description: By default, when installing ubuntu-desktop (and when installing some other packages as well), apt will also install dnsmasq as a dependency. When dnsmasq is installed, and static IP addresses are used, resolv.conf creates a nearly empty /etc/resolv.conf file. The file only contains entries for localhost and the search domain. If static IP addresses are defined in /etc/network/interfaces, then shouldn't those DNS servers should be included in /etc/resolv.conf regardless of the presence of dnsmasq? ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: resolvconf 1.78ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Wed Apr 27 08:34:24 2016 InstallationDate: Installed on 2016-04-26 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1575644/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1575644] Re: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used
*** This bug is a duplicate of bug 1003842 *** https://bugs.launchpad.net/bugs/1003842 ** This bug has been marked a duplicate of bug 1003842 dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers ** Package changed: resolvconf (Ubuntu) => dnsmasq (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1575644 Title: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used Status in dnsmasq package in Ubuntu: Incomplete Bug description: By default, when installing ubuntu-desktop (and when installing some other packages as well), apt will also install dnsmasq as a dependency. When dnsmasq is installed, and static IP addresses are used, resolv.conf creates a nearly empty /etc/resolv.conf file. The file only contains entries for localhost and the search domain. If static IP addresses are defined in /etc/network/interfaces, then shouldn't those DNS servers should be included in /etc/resolv.conf regardless of the presence of dnsmasq? ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: resolvconf 1.78ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Wed Apr 27 08:34:24 2016 InstallationDate: Installed on 2016-04-26 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1575644/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1575644] Re: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used
That name service does not work properly when dnsmasq is installed is most probably due to bug #1003842. If that is the case then if you remove 8.8.8.8 from the list of nameserver addresses then name service will work reliably. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1575644 Title: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used Status in resolvconf package in Ubuntu: Incomplete Bug description: By default, when installing ubuntu-desktop (and when installing some other packages as well), apt will also install dnsmasq as a dependency. When dnsmasq is installed, and static IP addresses are used, resolv.conf creates a nearly empty /etc/resolv.conf file. The file only contains entries for localhost and the search domain. If static IP addresses are defined in /etc/network/interfaces, then shouldn't those DNS servers should be included in /etc/resolv.conf regardless of the presence of dnsmasq? ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: resolvconf 1.78ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Wed Apr 27 08:34:24 2016 InstallationDate: Installed on 2016-04-26 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1575644/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1575644] Re: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used
Everything looks correct. Does name service work both when dnsmasq is installed and when it is not installed? If so then there is no problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1575644 Title: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used Status in resolvconf package in Ubuntu: Incomplete Bug description: By default, when installing ubuntu-desktop (and when installing some other packages as well), apt will also install dnsmasq as a dependency. When dnsmasq is installed, and static IP addresses are used, resolv.conf creates a nearly empty /etc/resolv.conf file. The file only contains entries for localhost and the search domain. If static IP addresses are defined in /etc/network/interfaces, then shouldn't those DNS servers should be included in /etc/resolv.conf regardless of the presence of dnsmasq? ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: resolvconf 1.78ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Wed Apr 27 08:34:24 2016 InstallationDate: Installed on 2016-04-26 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1575644/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1575644] Re: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used
If you install the dnsmasq package then that package starts a standalone instance of the dnsmasq program and resolv.conf will contain a line `nameserver 127.0.0.1` which tells the resolver to consult that instance of the dnsmasq program, which will by default forward DNS queries to the nameservers which would otherwise have been directly consulted by the resolver. The answer to the question "shouldn't those DNS servers should be included in /etc/resolv.conf regardless of the presence of dnsmasq?" is "no". Resolvconf doesn't list any nameserver addresses after any loopback address, unless TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no in /etc/default/resolvconf. When dnsmasq is installed does DNS function correctly? If so then there is no problem. ** Description changed: By default, when installing ubuntu-desktop (and when installing some other packages as well), apt will also install dnsmasq as a dependency. - When dnsmask is installed, and static IP addresses are used, resolv.conf + When dnsmasq is installed, and static IP addresses are used, resolv.conf creates a nearly empty /etc/resolv.conf file. The file only contains entries for localhost and the search domain. If static IP addresses are defined in /etc/network/interfaces, then shouldn't those DNS servers should be included in /etc/resolv.conf regardless of the presence of - dnsmask? + dnsmasq? ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: resolvconf 1.78ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Wed Apr 27 08:34:24 2016 InstallationDate: Installed on 2016-04-26 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1575644 Title: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used Status in resolvconf package in Ubuntu: Incomplete Bug description: By default, when installing ubuntu-desktop (and when installing some other packages as well), apt will also install dnsmasq as a dependency. When dnsmasq is installed, and static IP addresses are used, resolv.conf creates a nearly empty /etc/resolv.conf file. The file only contains entries for localhost and the search domain. If static IP addresses are defined in /etc/network/interfaces, then shouldn't those DNS servers should be included in /etc/resolv.conf regardless of the presence of dnsmasq? ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: resolvconf 1.78ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Wed Apr 27 08:34:24 2016 InstallationDate: Installed on 2016-04-26 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1575644/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1575644] Re: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used
Not dnsmasq but dnsmasq-base is pulled in by ubuntu-desktop. If you define your interfaces statically using /etc/network/interfaces then you have to add the nameserver information to /etc/network/interfaces on lines like "dns-nameserver 1.2.3.4". See resolvconf(8) for more info. ** Changed in: resolvconf (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1575644 Title: resolvconf doesn't create the correct /etc/resolv.conf file when static IP addresses are used Status in resolvconf package in Ubuntu: Incomplete Bug description: By default, when installing ubuntu-desktop (and when installing some other packages as well), apt will also install dnsmasq as a dependency. When dnsmask is installed, and static IP addresses are used, resolv.conf creates a nearly empty /etc/resolv.conf file. The file only contains entries for localhost and the search domain. If static IP addresses are defined in /etc/network/interfaces, then shouldn't those DNS servers should be included in /etc/resolv.conf regardless of the presence of dnsmask? ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: resolvconf 1.78ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Wed Apr 27 08:34:24 2016 InstallationDate: Installed on 2016-04-26 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1575644/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1516329] Re: DNS BUG delay resolution of LAN DNS
*** This bug is a duplicate of bug 1003842 *** https://bugs.launchpad.net/bugs/1003842 This is the known bug #1003842. Workaround: comment out "dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf ** This bug has been marked a duplicate of bug 1003842 dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1516329 Title: DNS BUG delay resolution of LAN DNS Status in dnsmasq package in Ubuntu: New Bug description: I have a little LAN (3 computers) where each computer uses UBUNTU 14.04 LTS. The LAN has a server that assigns the IP address by MAC ADDRESS and provides DNS resolution for local computers. The BUG is for each computer of the network (I have not tested the server that is and ODROID and has not monitor and keyboard). For example a computer is called "core". If I try to connect to "core I got the following message: ssh -X core ssh: Could not resolve hostname core: Name or service not known and if I try lookup command I got User:marco Computer:i7 Base:marco Current:/media/data/users/home/marco Command 1003 of 14 $nslookup gaia Server: 127.0.1.1 Address: 127.0.1.1#53 ** server can't find core: NXDOMAIN After a random time (it can be few seconds or some minutes) the address is resolved $nslookup gaia Server: 127.0.1.1 Address: 127.0.1.1#53 Name: gaia.lab Address: 10.10.100.11 and after the first resolution the address are resolved for all the computers of the LAN. I have not problems to resolve the address outside the LAN. the reverse address is decoded: nslookup 10.10.100.11 Server: 127.0.1.1 Address: 127.0.1.1#53 11.100.10.10.in-addr.arpa name = gaia.lab. The DNS servers are: nameserver 10.10.100.7 nameserver 8.8.8.8 nameserver 8.8.4.4 /etc/resolvconf/resolv.conf.d/base (END) where 10.10.100.7 is the server of the network. Please contact me if I can provide you more information. Best Marco Righi ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.19.0-33.38~14.04.1-generic 3.19.8-ckt7 Uname: Linux 3.19.0-33-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.1-0ubuntu3.18 Architecture: amd64 CurrentDesktop: Unity Date: Sun Nov 15 01:47:48 2015 InstallationDate: Installed on 2015-10-29 (16 days ago) InstallationMedia: Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.resolvconf.resolv.conf.d.base: nameserver 10.10.100.7 nameserver 8.8.8.8 nameserver 8.8.4.4 mtime.conffile..etc.resolvconf.resolv.conf.d.base: 2015-11-08T22:04:24.170916 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1516329/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1568787] Re: resolveconf does not reliable receive nameserver information from network manager
** Description changed: - resolveconf does not reliable receive nameserver information from - network manager. + resolvconf does not reliable receive nameserver information from + NetworkManager. In the journal I see things like: Apr 11 11:13:52 ottawa dnsmasq[3122]: setting upstream servers from DBus Apr 11 11:13:52 ottawa dnsmasq[3122]: using nameserver fe80::1#53 Apr 11 11:13:52 ottawa dnsmasq[3122]: using nameserver 192.168.1.254#53 Apr 11 11:13:52 ottawa dbus[978]: [system] Rejected send message, 13 matched rules; type="method_return", sender=":1.99" (uid=0 pid=3122 comm="/usr/sbin/dnsmasq --no-resolv --keep-in-foreground") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.8" (uid=0 pid=1017 comm="/usr/sbin/NetworkManager --no-daemon ") Apr 11 11:04:21 ottawa NetworkManager[1017]: DNS: starting dnsmasq... Apr 11 11:04:21 ottawa NetworkManager[1017]: dnsmasq not available on the bus, can't update servers. Apr 11 11:04:21 ottawa NetworkManager[1017]: [1460369061.825658] [dns-manager/nm-dns-dnsmasq.c:387] update(): dnsmasq owner not found on bus: Could not get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name - - Doing this via dbus seems really odd, but I suspect messages between NetworkManager and the dnsmasq it spawns should not be rejected. + Doing this via dbus seems really odd, but I suspect messages between + NetworkManager and the dnsmasq it spawns should not be rejected. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq-base 2.75-1 ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6 Uname: Linux 4.4.0-18-generic x86_64 ApportVersion: 2.20.1-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Mon Apr 11 11:17:34 2016 InstallationDate: Installed on 2016-01-26 (76 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160125) SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) ** Summary changed: - resolveconf does not reliable receive nameserver information from network manager + resolvconf does not reliable receive nameserver information from NetworkManager -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1568787 Title: resolvconf does not reliable receive nameserver information from NetworkManager Status in dbus package in Ubuntu: New Status in dnsmasq package in Ubuntu: New Status in network-manager package in Ubuntu: New Bug description: resolvconf does not reliable receive nameserver information from NetworkManager. In the journal I see things like: Apr 11 11:13:52 ottawa dnsmasq[3122]: setting upstream servers from DBus Apr 11 11:13:52 ottawa dnsmasq[3122]: using nameserver fe80::1#53 Apr 11 11:13:52 ottawa dnsmasq[3122]: using nameserver 192.168.1.254#53 Apr 11 11:13:52 ottawa dbus[978]: [system] Rejected send message, 13 matched rules; type="method_return", sender=":1.99" (uid=0 pid=3122 comm="/usr/sbin/dnsmasq --no-resolv --keep-in-foreground") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.8" (uid=0 pid=1017 comm="/usr/sbin/NetworkManager --no-daemon ") Apr 11 11:04:21 ottawa NetworkManager[1017]: DNS: starting dnsmasq... Apr 11 11:04:21 ottawa NetworkManager[1017]: dnsmasq not available on the bus, can't update servers. Apr 11 11:04:21 ottawa NetworkManager[1017]: [1460369061.825658] [dns-manager/nm-dns-dnsmasq.c:387] update(): dnsmasq owner not found on bus: Could not get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name Doing this via dbus seems really odd, but I suspect messages between NetworkManager and the dnsmasq it spawns should not be rejected. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq-base 2.75-1 ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6 Uname: Linux 4.4.0-18-generic x86_64 ApportVersion: 2.20.1-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Mon Apr 11 11:17:34 2016 InstallationDate: Installed on 2016-01-26 (76 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160125) SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1568787/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384394] Re: /etc/network/interfaces: "dns-nameservers" entries for bridge "br*" interfaces are ignored i.e. they are not listed in "/etc/resolv.conf" when invoking "ifup" comman
br matching was added to interface-order in Debian release 1.77, thus in wily which has resolvconf 1.77ubuntu1. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1384394 Title: /etc/network/interfaces: "dns-nameservers" entries for bridge "br*" interfaces are ignored i.e. they are not listed in "/etc/resolv.conf" when invoking "ifup" command Status in dnsmasq package in Ubuntu: Triaged Bug description: lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 apt-cache policy resolvconf resolvconf: Installed: 1.69ubuntu1.1 Candidate: 1.69ubuntu1.1 Version table: *** 1.69ubuntu1.1 0 500 http://ch.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 100 /var/lib/dpkg/status 1.69ubuntu1 0 500 http://ch.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages DESCRIPTION: network-manager: My "eth0" and "wlan0" cards are managed by the network-manager and this works fine. /etc/network/interfaces: My 2 bridges "br0" and "br1" are managed in "/etc/network/interfaces" as follows: ... iface br0 inet static address 192.168.10.1 netmask 255.255.255.0 dns-nameservers 192.168.10.2 bridge_ports none bridge_stp off bridge_fd 0 bridge_maxwait 0 iface br1 inet static address 192.168.0.1 netmask 255.255.255.0 dns-nameservers 192.168.0.2 bridge_ports none bridge_stp off bridge_fd 0 bridge_maxwait 0 ... When I now bring up the bridge interfaces using: sudo ifup br0 br1 Then they show up fine in "ifconfig". BUT "dns-nameservers 192.168.10.2" and "dns-nameservers 192.168.0.2" DO NOT show up in "/etc/resolv.conf" WORKAROUND: Until this has been fixed the following workaround works fine for me: sudo vi /etc/resolvconf/interface-order #Add the following entry (this entry can be put on any line BUT it has to come before the last entry "*"): ... br* ... * PS: Based on the workaround in "/etc/resolvconf/interface-order" I think the issue is in package "resolvconf" otherwise I would have reported the error against the "ifupdown scripts". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1384394/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1546624] Re: resolvconf -u does not incorporate /etc/resolvconf/resolv.conf.d/base file into /etc/resolv.conf
The content of the base file is processed, but due to resolvconf's rules they may fail to show up in resolv.conf. Comments in the base file get discarded. Lines like "nameserver w.x.y.z" are omitted if another line is, e.g., "nameserver 127.0.1.1.". If you set TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=n in /etc/default/resolvconf then "nameserver" lines from the base file will be included. ** Changed in: resolvconf (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1546624 Title: resolvconf -u does not incorporate /etc/resolvconf/resolv.conf.d/base file into /etc/resolv.conf Status in resolvconf package in Ubuntu: Incomplete Bug description: == Requested Info == System details This may be a generic problem with Debian resolvconf, as it has been a long-standing issue in my lab, since I run a local DNS server, and I have reproduced it on several hosts running Debian derivatives: Ubunti 14.04.3 LTS systems, e.g: $ uname -a Linux leno 3.19.0-49-generic #55~14.04.1-Ubuntu SMP Fri Jan 22 11:23:34 UTC 2016 i686 i686 i686 GNU/Linux $ apt-cache policy resolvconf resolvconf: Installed: 1.69ubuntu1.1 Candidate: 1.69ubuntu1.1 Version table: *** 1.69ubuntu1.1 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main i386 Packages 100 /var/lib/dpkg/status 1.69ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main i386 Packages Mint: $ uname -a Linux nas2 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ apt-cache policy resolvconf resolvconf: Installed: 1.69ubuntu1.1 Candidate: 1.69ubuntu1.1 Version table: *** 1.69ubuntu1.1 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main i386 Packages 100 /var/lib/dpkg/status 1.69ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main i386 Packages raspbian: $ uname -a Linux raspi2 4.1.17-v7+ #834 SMP Mon Feb 1 15:17:54 GMT 2016 armv7l GNU/Linux $ apt-cache policy resolvconf resolvconf: Installed: 1.67 Candidate: 1.67 Version table: *** 1.67 0 500 http://mirrordirector.raspbian.org/raspbian/ wheezy/main armhf Packages 100 /var/lib/dpkg/status -- What I expected to happen: The man page for resolvconf states: The dynamically generated resolver configuration file always starts with the contents of /etc/resolvconf/resolv.conf.d/head and ends with the contents of /etc/resolvconf/resolv.conf.d/tail. Between head and tail the libc script inserts dynamic nameserver information compiled from, first, information provided for configured interfaces; second, static information from /etc/resolvconf/resolv.conf.d/base. What happens instead: Updating /etc/resolv.conf (which is a symlink to /run/resolvconf/resolv.conf) with resolvconf -u dappears to do everything EXCEPT incorporate the contents of the /etc/resolvconf/resolv.conf.d/base file. == My analysis and steps to reproduce the problem The resolvconf manpage and many web resources claim that one can make "permanent changes" (e.g. local nameserver, search domain, etc) by editing the /etc/resolvconf/resolv.conf.d/base file, and that executing "resolvconf -u" build a new /etc/resolv.conf (actually /run/resolvconf/resolv.conf) from the contents of the head, base and tail files in /etc/resolvcond/resolv.conf.d. In fact, resolvconf -u does incorporate the head and tail files, but not the base file. Steps to reproduce: 1 - on a system that has resolvconf installed, display the content of /etc/resolv.conf, e.g.: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1 2 - cd /etc/resolvconf/resolv.conf.d 3 - (as root) edit the head, base and tail files, by adding an identifying comment line, e.g.: # this is the head file # this is the base file # this is the tail file 4 - (as root) run resolvconf -u 5 - Again, display the content of /etc/resolv.conf: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # this is the head file nameserver 127.0.1.1 # this is the tail file Note that the content of the head and tail files has been
[Touch-packages] [Bug 1534501] Re: [URGENT] dnsmasq errors fills up syslogs extremely fast
Do you have the "dnsmasq" package installed and is the instance of the dnsmasq program started by the "dnsmasq" package configured to listen at 127.0.1.1? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1534501 Title: [URGENT] dnsmasq errors fills up syslogs extremely fast Status in dnsmasq package in Ubuntu: New Status in network-manager package in Ubuntu: New Status in resolvconf package in Ubuntu: New Status in rsyslog package in Ubuntu: New Bug description: snippet of logs. Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq update failed Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30416]: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30416]: FAILED to start up Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2) Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq child quit unexpectedly; refreshing DNS Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: starting dnsmasq... Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq not available on the bus, can't update servers. Jan 15 00:28:24 localhost NetworkManager[1211]: [1452846504.397836] [dns-manager/nm-dns-dnsmasq.c:387] update(): dnsmasq owner not found on bus: Could not get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq update failed Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30429]: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30429]: FAILED to start up Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2) Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq child quit unexpectedly; refreshing DNS Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: starting dnsmasq... Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq not available on the bus, can't update servers. Jan 15 00:28:24 localhost NetworkManager[1211]: [1452846504.407691] [dns-manager/nm-dns-dnsmasq.c:387] update(): dnsmasq owner not found on bus: Could not get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq update failed Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30442]: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30442]: FAILED to start up Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2) Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq child quit unexpectedly; refreshing DNS Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: starting dnsmasq... Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq not available on the bus, can't update servers. Jan 15 00:28:24 localhost NetworkManager[1211]: [1452846504.419365] [dns-manager/nm-dns-dnsmasq.c:387] update(): dnsmasq owner not found on bus: Could not get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq update failed Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30455]: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30455]: FAILED to start up Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq exited
[Touch-packages] [Bug 1534501] Re: [URGENT] dnsmasq errors fills up syslogs extremely fast
First, it appears that NetworkManager doesn't handle the error well and retries without sleeping. Needs fixing. Separate issue: Why is the error occurring on your machine? Why do you get "dnsmasq[30613]: failed to create listening socket for 127.0.1.1: Address already in use"? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1534501 Title: [URGENT] dnsmasq errors fills up syslogs extremely fast Status in dnsmasq package in Ubuntu: New Status in network-manager package in Ubuntu: New Status in resolvconf package in Ubuntu: New Status in rsyslog package in Ubuntu: New Bug description: snippet of logs. Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq update failed Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30416]: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30416]: FAILED to start up Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2) Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq child quit unexpectedly; refreshing DNS Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: starting dnsmasq... Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq not available on the bus, can't update servers. Jan 15 00:28:24 localhost NetworkManager[1211]: [1452846504.397836] [dns-manager/nm-dns-dnsmasq.c:387] update(): dnsmasq owner not found on bus: Could not get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq update failed Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30429]: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30429]: FAILED to start up Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2) Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq child quit unexpectedly; refreshing DNS Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: starting dnsmasq... Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq not available on the bus, can't update servers. Jan 15 00:28:24 localhost NetworkManager[1211]: [1452846504.407691] [dns-manager/nm-dns-dnsmasq.c:387] update(): dnsmasq owner not found on bus: Could not get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq update failed Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30442]: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30442]: FAILED to start up Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2) Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq child quit unexpectedly; refreshing DNS Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: starting dnsmasq... Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq not available on the bus, can't update servers. Jan 15 00:28:24 localhost NetworkManager[1211]: [1452846504.419365] [dns-manager/nm-dns-dnsmasq.c:387] update(): dnsmasq owner not found on bus: Could not get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name Jan 15 00:28:24 localhost NetworkManager[1211]: DNS: plugin dnsmasq update failed Jan 15 00:28:24 localhost NetworkManager[1211]: Writing DNS information to /sbin/resolvconf Jan 15 00:28:24 localhost NetworkManager[1211]: dnsmasq: failed to create listening socket for 127.0.1.1: Address already in use Jan 15 00:28:24 localhost dnsmasq[30455]: failed to create listening socket for 127.0.1.1: Address already in use Jan
[Touch-packages] [Bug 1130651] Re: Can't decide priority for 127.0.0.1 on /etc/resolv.conf
To prioritize pdns-recursor's listen address in resolv.conf, edit /etc/resolvconf/interface-order and replace the line lo.!(pdns|pdns-recursor) with the following line. lo.* See https://bugs.debian.org/308677 for background. ** Package changed: resolvconf (Ubuntu) => pdns-recursor (Ubuntu) ** Bug watch added: Debian Bug tracker #308677 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308677 ** Changed in: pdns-recursor (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1130651 Title: Can't decide priority for 127.0.0.1 on /etc/resolv.conf Status in pdns-recursor package in Ubuntu: Incomplete Bug description: The start_resolvconf() and stop_resolvconf() functions in /etc/init.d /pdns-recursor can only append 127.0.0.1 to the list of nameservers in /etc/resolv.conf. There should be a way to add it on the top of the list to prioritise the use of the local cache instead of the external dns resolvers first. It could be a new config parameter in /etc/powerdns/recursor.conf but it's really up to you guys. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pdns-recursor/+bug/1130651/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1525613] Re: package resolvconf 1.78ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
Try purging and reinstalling the resolvconf package. Is there anything unusual about your machine? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1525613 Title: package resolvconf 1.78ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 Status in resolvconf package in Ubuntu: New Bug description: After upgrading to the current built of 16.04, I'm always greeted with the same error: resolvconf 1.78ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 ProblemType: Package DistroRelease: Ubuntu 16.04 Package: resolvconf 1.78ubuntu1 ProcVersionSignature: Ubuntu 4.3.0-2.11-generic 4.3.0 Uname: Linux 4.3.0-2-generic x86_64 ApportVersion: 2.19.3-0ubuntu2 AptOrdering: resolvconf: Configure NULL: ConfigurePending Architecture: amd64 Date: Sat Dec 12 17:33:10 2015 DpkgTerminalLog: Setting up resolvconf (1.78ubuntu1) ... Processing triggers for resolvconf (1.78ubuntu1) ... resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory dpkg: error processing package resolvconf (--configure): subprocess installed post-installation script returned error exit status 1 DuplicateSignature: Processing triggers for resolvconf (1.78ubuntu1) ... resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory dpkg: error processing package resolvconf (--configure): subprocess installed post-installation script returned error exit status 1 ErrorMessage: subprocess installed post-installation script returned error exit status 1 InstallationDate: Installed on 2014-08-09 (490 days ago) InstallationMedia: Xubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140723) PackageArchitecture: all RelatedPackageVersions: dpkg 1.18.3ubuntu1 apt 1.1.4 SourcePackage: resolvconf Title: package resolvconf 1.78ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 UpgradeStatus: Upgraded to xenial on 2015-12-12 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1525613/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1516329] Re: DNS BUG delay resolution of LAN DNS
** Package changed: resolvconf (Ubuntu) => dnsmasq (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1516329 Title: DNS BUG delay resolution of LAN DNS Status in dnsmasq package in Ubuntu: New Bug description: I have a little LAN (3 computers) where each computer uses UBUNTU 14.04 LTS. The LAN has a server that assigns the IP address by MAC ADDRESS and provides DNS resolution for local computers. The BUG is for each computer of the network (I have not tested the server that is and ODROID and has not monitor and keyboard). For example a computer is called "core". If I try to connect to "core I got the following message: ssh -X core ssh: Could not resolve hostname core: Name or service not known and if I try lookup command I got User:marco Computer:i7 Base:marco Current:/media/data/users/home/marco Command 1003 of 14 $nslookup gaia Server: 127.0.1.1 Address: 127.0.1.1#53 ** server can't find core: NXDOMAIN After a random time (it can be few seconds or some minutes) the address is resolved $nslookup gaia Server: 127.0.1.1 Address: 127.0.1.1#53 Name: gaia.lab Address: 10.10.100.11 and after the first resolution the address are resolved for all the computers of the LAN. I have not problems to resolve the address outside the LAN. the reverse address is decoded: nslookup 10.10.100.11 Server: 127.0.1.1 Address: 127.0.1.1#53 11.100.10.10.in-addr.arpa name = gaia.lab. The DNS servers are: nameserver 10.10.100.7 nameserver 8.8.8.8 nameserver 8.8.4.4 /etc/resolvconf/resolv.conf.d/base (END) where 10.10.100.7 is the server of the network. Please contact me if I can provide you more information. Best Marco Righi ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.19.0-33.38~14.04.1-generic 3.19.8-ckt7 Uname: Linux 3.19.0-33-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.1-0ubuntu3.18 Architecture: amd64 CurrentDesktop: Unity Date: Sun Nov 15 01:47:48 2015 InstallationDate: Installed on 2015-10-29 (16 days ago) InstallationMedia: Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.resolvconf.resolv.conf.d.base: nameserver 10.10.100.7 nameserver 8.8.8.8 nameserver 8.8.4.4 mtime.conffile..etc.resolvconf.resolv.conf.d.base: 2015-11-08T22:04:24.170916 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1516329/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1501189] Re: DNS breaks when port=0 is used in dnsmasq.conf
*** This bug is a duplicate of bug 1042275 ***
https://bugs.launchpad.net/bugs/1042275
** This bug has been marked a duplicate of bug 1042275
Please enhance dnsmasq to talk directly to resolvconf and to register only
its actual listening address(es)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1501189
Title:
DNS breaks when port=0 is used in dnsmasq.conf
Status in dnsmasq package in Ubuntu:
Triaged
Bug description:
The following function is defined in /etc/init.d/dnsmasq:
start_resolvconf()
{
# If interface "lo" is explicitly disabled in /etc/default/dnsmasq
# Then dnsmasq won't be providing local DNS, so don't add it to
# the resolvconf server set.
for interface in $DNSMASQ_EXCEPT
do
[ $interface = lo ] && return
done
if [ -x /sbin/resolvconf ] ; then
echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
fi
return 0
}
When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it
only as a (proxy)DHCP/TFTP server,
127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens
there.
One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
But that doesn't make much sense, we don't want to exclude some interface,
we're not running a DNS server at all.
So it would be nice if dnsmasq checked if port=0 is defined in its
configuration, and didn't add 127.0.0.1 to resolvconf then.
Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf
]`:
grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1501189/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1497959] Re: package resolvconf (not installed) failed to install/upgrade: subprocess installed post-removal script returned error exit status 128
Can you please try to figure out what part of the resolvconf postrm script is yielding the exit status 128? ** Changed in: resolvconf (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1497959 Title: package resolvconf (not installed) failed to install/upgrade: subprocess installed post-removal script returned error exit status 128 Status in resolvconf package in Ubuntu: Incomplete Bug description: I use dnsmasq as a local DNS on my ethernet network, while I have a shared wifi connection on the same PC. I had to solve some conflicts with NetworkManager (by commenting the line dns=dnsmasq in NetworkManager's configuration). It worked, but dnsmasq didn't see when the computer's DNS configuration was updated (namely, when the wifi connection was turned on or off). After some Internet search, I found a forum, explaining that there was a conflict between NetworkManager and resolvconf packages, with the same symptoms as my problem (the resolv.conf file was saying "configured by resolvconf", and not "configured by NetworkManager", and was not updated with wifi DNS). This forum explained that resolvconf could be uninstalled, as NetworkManager was doing the job. So I uninstalled resolvconf, which work perfectly: NetworkManager now updates resolv.conf file, and dnsmasq takes it into account. But since I did it, I have this error on each start-up. ProblemType: Package DistroRelease: Ubuntu 15.04 Package: resolvconf (not installed) ProcVersionSignature: Ubuntu 3.19.0-28.30-generic 3.19.8-ckt5 Uname: Linux 3.19.0-28-generic x86_64 ApportVersion: 2.17.2-0ubuntu1.4 AptOrdering: ubuntu-minimal: Remove resolvconf: Remove NULL: ConfigurePending Architecture: amd64 Date: Wed Sep 16 11:31:44 2015 DuplicateSignature: package:resolvconf:(not installed):subprocess installed post-removal script returned error exit status 128 ErrorMessage: subprocess installed post-removal script returned error exit status 128 InstallationDate: Installed on 2015-09-03 (17 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) RelatedPackageVersions: dpkg 1.17.25ubuntu1 apt 1.0.9.7ubuntu4.1 SourcePackage: resolvconf Title: package resolvconf (not installed) failed to install/upgrade: subprocess installed post-removal script returned error exit status 128 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1497959/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1473727] Re: No DNS servers after netboot
** Changed in: resolvconf (Ubuntu) Status: Expired => New ** Changed in: resolvconf (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1473727 Title: No DNS servers after netboot Status in resolvconf package in Ubuntu: Incomplete Bug description: Ubuntu 14.04 / resolvconf 1.69ubuntu1.1 When netbooting a xen VM, I see the following output: address: 192.168.1.180broadcast: 192.168.1.255netmask: 255.255.255.0 gateway: 192.168.1.1 dns0 : 192.168.1.1 dns1 : 0.0.0.0 So I know DHCP is working. However, resolv.conf doesn't get updated - the interface is set to manual as DHCP was handled at the initrd level. Please let me know how I can help get this fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1473727/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1485316] Re: dnsmasq breaks DNS, if not used as DNS server
Best to submit this wish to the Debian bug tracking system so that Debian will also benefit from this enhancement. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1485316 Title: dnsmasq breaks DNS, if not used as DNS server Status in dnsmasq package in Ubuntu: New Bug description: I use dnsmasq mainly as a TFTP/DHCP combination and disable the part of the dns-resolver. So i use codeport=0/code to disable the DNS part. But the init- script always rewrites the resolv.conf, no matter if DNS is actually used. Could you add an option to the defaults-file, which the init-script checks and dependent on this, rewrites the config-file? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1485316/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1473727] Re: No DNS servers after netboot
Is the resolvconf package even installed? Assuming it is, why doesn't it get called when the interfaces are configured? Can things be changed so that resolvconf does get called in the normal way when interfaces are configured? (The normal way and all other things resolvconf are explained in /usr/share/doc/resolvconf/README.gz .) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1473727 Title: No DNS servers after netboot Status in resolvconf package in Ubuntu: Incomplete Bug description: Ubuntu 14.04 / resolvconf 1.69ubuntu1.1 When netbooting a xen VM, I see the following output: address: 192.168.1.180broadcast: 192.168.1.255netmask: 255.255.255.0 gateway: 192.168.1.1 dns0 : 192.168.1.1 dns1 : 0.0.0.0 So I know DHCP is working. However, resolv.conf doesn't get updated - the interface is set to manual as DHCP was handled at the initrd level. Please let me know how I can help get this fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1473727/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1473727] Re: No DNS servers after netboot
Here is a rough draft, untested, of a script that would be run once in
the main boot sequence in order to bring the resolvconf database up to
date. The main difference from your script is that it sends the info to
resolvconf instead of writing directly to resolv.conf. (I am assuming
that /etc/resolv.conf is a symbolic link to
/run/resolvconf/resolv.conf.) Can you please test this (or some improved
variant of it)?
#!/bin/sh
for F in /run/net-*.conf ; do
. $F
IFACE=${F%.conf}
IFACE=${IFACE#/run/net-}
S=
if [ $IPV4DNS0 != 0.0.0.0 ] ; then
S=${S}nameserver $IPV4DNS0
fi
if [ $IPV4DNS1 != 0.0.0.0 ] ; then
S=${S}nameserver $IPV4DNS1
fi
if [ $DOMAINSEARCH ] ; then
S=${S}search $DOMAINSEARCH
fi
If [ $S ] ; then
echo $S | resolvconf -a ${IFACE}.initramfs
fi
done
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1473727
Title:
No DNS servers after netboot
Status in resolvconf package in Ubuntu:
Incomplete
Bug description:
Ubuntu 14.04 / resolvconf 1.69ubuntu1.1
When netbooting a xen VM, I see the following output:
address: 192.168.1.180broadcast: 192.168.1.255netmask:
255.255.255.0
gateway: 192.168.1.1 dns0 : 192.168.1.1 dns1 :
0.0.0.0
So I know DHCP is working.
However, resolv.conf doesn't get updated - the interface is set to
manual as DHCP was handled at the initrd level.
Please let me know how I can help get this fixed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1473727/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1473727] Re: No DNS servers after netboot
Hi there and thanks for your report. I don't see any evidence here of a bug in resolvconf. There is most probably something wrong with your machine's configuration. So this report should be reassigned to something else... or closed if the configuration shortcomings are purely local. Where did you get / how did you build the virtual machine you are running? The script you posted provides some useful clues as to what the problem is but it is for several reasons not a clean solution. ** Changed in: resolvconf (Ubuntu) Status: New = Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1473727 Title: No DNS servers after netboot Status in resolvconf package in Ubuntu: Incomplete Bug description: Ubuntu 14.04 / resolvconf 1.69ubuntu1.1 When netbooting a xen VM, I see the following output: address: 192.168.1.180broadcast: 192.168.1.255netmask: 255.255.255.0 gateway: 192.168.1.1 dns0 : 192.168.1.1 dns1 : 0.0.0.0 So I know DHCP is working. However, resolv.conf doesn't get updated - the interface is set to manual as DHCP was handled at the initrd level. Please let me know how I can help get this fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1473727/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
Christian, the workaround is to comment out the line dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Status in dnsmasq source package in Precise: Confirmed Status in network-manager source package in Precise: Triaged Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1466608] Re: Unable to resolve domains with large EDNS0 replies
To add that, or any other, option to resolv.conf permanently, add the line options edns0 to the file /etc/resolvconf/resolv.conf.d/base and then resolvconf will include it in the resolv.conf that it generates. ** Changed in: dnsmasq (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1466608 Title: Unable to resolve domains with large EDNS0 replies Status in dnsmasq package in Ubuntu: Invalid Bug description: Not sure resolvconf is the correct place to report this bug, but I'm unable to resolve domains with large EDNS0 replies. A couple of examples are www.sciencedaily.com and www.ncbi.nlm.nih.gov. Interestingly, they resolve when I use dig domain, but if I enter a URL with either of those domains in my browser (tried Chromium and Firefox), then name resolution fails. Ping also fails with a name resolution error message. Here's an example: $ dig www.ncbi.nlm.nih.gov ; DiG 9.9.5-3ubuntu0.2-Ubuntu www.ncbi.nlm.nih.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8409 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1280 ;; QUESTION SECTION: ;www.ncbi.nlm.nih.gov.IN A ;; ANSWER SECTION: www.ncbi.nlm.nih.gov. 2358IN CNAME www.wip.ncbi.nlm.nih.gov. www.ncbi.nlm.nih.gov. 2358IN RRSIG CNAME 7 5 86400 20151213102025 20150616102025 52670 ncbi.nlm.nih.gov. dZt9uuyLImbB23vdqcsSK+nWK77BREttiAP80Ovq2/xV48JsII3Uxzxc W8OkLmc5dSdPNkfwc6QFC/+wqe+4ORb1TC4Qxw5HQxo4nCindPFGZAgJ SEFcWRJ2HrU5BKz/MeVMALJ3YN6LSHIwkTIwJbKweTGLQTZPZTryp1M7 UQrqd0hs7tjjwVl/6zRIA5UGgFbdrLwX9jmh4ykBTqK8u0Rt/wrTeHbp UpVMxAUdUW1CJ7xAnn/k4td6zdx7Tm5+CkS99Qva0cPfSSo6Qh4Uplun LKwT9GR4zqBTQRjBWSTf2YdhrAU8oyh9WbQ66WHLYkC8Kp55iskL8E8p E5wOYA== www.wip.ncbi.nlm.nih.gov. 30 IN A 130.14.29.110 www.wip.ncbi.nlm.nih.gov. 30 IN RRSIG A 7 6 30 20150708223631 20150617223631 34334 wip.ncbi.nlm.nih.gov. aF9abjtGNMz+8NkcTGIY8GwjfZBCcL532B2sdJM891OAP2V9GwPCDGNY VzMPzZjMGN9qHsBgXuFY5jZQNWFvWfIQctTJEZTxClyJyFhe5JbyIspg NIO6ZXxjD3h7Ax/Sr5peyf8mfCU/8FZHPGJOhsNEFOwL3RjIddTK6Ibc PQ55CWOuVrvw26kKj9gxBG8r6iBcKe89xHQYPm1w+Osp8c2twGhqBmfd 7zcRxFLyF0BpY63kcQiF5lJ2fI31x+zCAROL9H3L1jm/K7aMAiO5kuWl DK57upsmtQNzjWX8coYpm7/3Gebfmpjx4BtC75L5IP/WfwVBfzHeRjAG KY/7aQ== ;; Query time: 132 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Thu Jun 18 20:26:50 CEST 2015 ;; MSG SIZE rcvd: 699 $ ping www.ncbi.nlm.nih.gov ping: unknown host www.ncbi.nlm.nih.gov I also watched with tcpdump when trying to look up the domain www.sciencedaily.com, and when I use dig I immediately get the reply, but when trying with ping I don't get any reply, and it gives up after 4 queries are sent. Must have something to do with the DNS flags that are set on the query in the different cases. Here's a lookup with dig: 20:01:47.857269 IP 127.0.0.1.56927 127.0.1.1.53: 9907+ [1au] A? www.sciencedaily.com. (49) 20:01:47.869516 IP 127.0.1.1.53 127.0.0.1.56927: 9907 2/6/43 CNAME ed5n3.x.incapdns.net., A 149.126.72.70 (879) and here's a name resolution triggered by running ping: 20:02:47.969527 IP 127.0.0.1.35905 127.0.1.1.53: 59118+ A? www.sciencedaily.com. (38) 20:02:52.974752 IP 127.0.0.1.35905 127.0.1.1.53: 59118+ A? www.sciencedaily.com. (38) 20:02:57.980296 IP 127.0.0.1.48738 127.0.1.1.53: 3668+ A? www.sciencedaily.com. (38) 20:03:02.985493 IP 127.0.0.1.48738 127.0.1.1.53: 3668+ A? www.sciencedaily.com. (38) I've not experienced this before, though these aren't domains I commonly visit. Is this a new issue? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.13.0-52.86-generic 3.13.11-ckt18 Uname: Linux 3.13.0-52-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: Unity Date: Thu Jun 18 20:23:19 2015 InstallationDate: Installed on 2014-10-19 (241 days ago) InstallationMedia: Ubuntu 14.04.1 LTS Trusty Tahr - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1466608/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1466608] Re: Unable to resolve domains with large EDNS0 replies
Hi. I don't see how resolvconf could be responsible for this problem. Initial observation: it seems that dig gets the correct answer from dnsmasq when it supplies the additional option udp:1280, but the glibc resolver doesn't get the right answer from dnsmasq when it fails to supply that option. Reassigning to dnsmasq. ** Package changed: resolvconf (Ubuntu) = dnsmasq (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1466608 Title: Unable to resolve domains with large EDNS0 replies Status in dnsmasq package in Ubuntu: New Bug description: Not sure resolvconf is the correct place to report this bug, but I'm unable to resolve domains with large EDNS0 replies. A couple of examples are www.sciencedaily.com and www.ncbi.nlm.nih.gov. Interestingly, they resolve when I use dig domain, but if I enter a URL with either of those domains in my browser (tried Chromium and Firefox), then name resolution fails. Ping also fails with a name resolution error message. Here's an example: $ dig www.ncbi.nlm.nih.gov ; DiG 9.9.5-3ubuntu0.2-Ubuntu www.ncbi.nlm.nih.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8409 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1280 ;; QUESTION SECTION: ;www.ncbi.nlm.nih.gov.IN A ;; ANSWER SECTION: www.ncbi.nlm.nih.gov. 2358IN CNAME www.wip.ncbi.nlm.nih.gov. www.ncbi.nlm.nih.gov. 2358IN RRSIG CNAME 7 5 86400 20151213102025 20150616102025 52670 ncbi.nlm.nih.gov. dZt9uuyLImbB23vdqcsSK+nWK77BREttiAP80Ovq2/xV48JsII3Uxzxc W8OkLmc5dSdPNkfwc6QFC/+wqe+4ORb1TC4Qxw5HQxo4nCindPFGZAgJ SEFcWRJ2HrU5BKz/MeVMALJ3YN6LSHIwkTIwJbKweTGLQTZPZTryp1M7 UQrqd0hs7tjjwVl/6zRIA5UGgFbdrLwX9jmh4ykBTqK8u0Rt/wrTeHbp UpVMxAUdUW1CJ7xAnn/k4td6zdx7Tm5+CkS99Qva0cPfSSo6Qh4Uplun LKwT9GR4zqBTQRjBWSTf2YdhrAU8oyh9WbQ66WHLYkC8Kp55iskL8E8p E5wOYA== www.wip.ncbi.nlm.nih.gov. 30 IN A 130.14.29.110 www.wip.ncbi.nlm.nih.gov. 30 IN RRSIG A 7 6 30 20150708223631 20150617223631 34334 wip.ncbi.nlm.nih.gov. aF9abjtGNMz+8NkcTGIY8GwjfZBCcL532B2sdJM891OAP2V9GwPCDGNY VzMPzZjMGN9qHsBgXuFY5jZQNWFvWfIQctTJEZTxClyJyFhe5JbyIspg NIO6ZXxjD3h7Ax/Sr5peyf8mfCU/8FZHPGJOhsNEFOwL3RjIddTK6Ibc PQ55CWOuVrvw26kKj9gxBG8r6iBcKe89xHQYPm1w+Osp8c2twGhqBmfd 7zcRxFLyF0BpY63kcQiF5lJ2fI31x+zCAROL9H3L1jm/K7aMAiO5kuWl DK57upsmtQNzjWX8coYpm7/3Gebfmpjx4BtC75L5IP/WfwVBfzHeRjAG KY/7aQ== ;; Query time: 132 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Thu Jun 18 20:26:50 CEST 2015 ;; MSG SIZE rcvd: 699 $ ping www.ncbi.nlm.nih.gov ping: unknown host www.ncbi.nlm.nih.gov I also watched with tcpdump when trying to look up the domain www.sciencedaily.com, and when I use dig I immediately get the reply, but when trying with ping I don't get any reply, and it gives up after 4 queries are sent. Must have something to do with the DNS flags that are set on the query in the different cases. Here's a lookup with dig: 20:01:47.857269 IP 127.0.0.1.56927 127.0.1.1.53: 9907+ [1au] A? www.sciencedaily.com. (49) 20:01:47.869516 IP 127.0.1.1.53 127.0.0.1.56927: 9907 2/6/43 CNAME ed5n3.x.incapdns.net., A 149.126.72.70 (879) and here's a name resolution triggered by running ping: 20:02:47.969527 IP 127.0.0.1.35905 127.0.1.1.53: 59118+ A? www.sciencedaily.com. (38) 20:02:52.974752 IP 127.0.0.1.35905 127.0.1.1.53: 59118+ A? www.sciencedaily.com. (38) 20:02:57.980296 IP 127.0.0.1.48738 127.0.1.1.53: 3668+ A? www.sciencedaily.com. (38) 20:03:02.985493 IP 127.0.0.1.48738 127.0.1.1.53: 3668+ A? www.sciencedaily.com. (38) I've not experienced this before, though these aren't domains I commonly visit. Is this a new issue? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.13.0-52.86-generic 3.13.11-ckt18 Uname: Linux 3.13.0-52-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: Unity Date: Thu Jun 18 20:23:19 2015 InstallationDate: Installed on 2014-10-19 (241 days ago) InstallationMedia: Ubuntu 14.04.1 LTS Trusty Tahr - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1466608/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1430077] Re: [vivid] VPN connection breaks /etc/resolv.conf
Should this be reassigned to network-manager-openvpn? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1430077 Title: [vivid] VPN connection breaks /etc/resolv.conf Status in network-manager package in Ubuntu: Confirmed Bug description: After some recent update in vivid, connecting to my employer's VPN with network-manager-openvpn has resulted in broken name resolution. Previously, the VPN-provided nameserver setting would be pushed into the config of the dnsmasq run by NM. Now, it is being pushed instead to /etc/resolv.conf. nameserver 10.99.244.1 nameserver 127.0.1.1 This is breaking the DNS handling for libvirt-bin, which has its own forwarding dnsmasq instance which it expects to be able to talk to the first nameserver listed here. The nameserver in question does not work (and is not meant to be used) for any name lookups except company-internal domains. Connecting to the VPN also pushes search paths to /etc/resolv.conf - overriding the search domains that I have already configured, and which should take precedence. (This part is not a regression.) I understand that the purpose of these provided domains is to specify the domains for which DNS lookups should be forwarded to the VPN DNS server, and *not* to modify the system's DNS lookups for non-FQDN requests. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu9 ProcVersionSignature: Ubuntu 3.19.0-7.7-generic 3.19.0 Uname: Linux 3.19.0-7-generic x86_64 ApportVersion: 2.16.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Mon Mar 9 17:16:05 2015 InstallationDate: Installed on 2010-09-24 (1627 days ago) InstallationMedia: Ubuntu 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.1) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WWanEnabled=true SourcePackage: network-manager UpgradeStatus: Upgraded to vivid on 2014-12-06 (93 days ago) nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1430077/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
** Changed in: network-manager (Ubuntu) Status: In Progress = New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: New Status in dnsmasq source package in Precise: Confirmed Status in network-manager source package in Precise: Triaged Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 434477] Re: Nameserver addresses 4.2.2.1 and 4.2.2.2 end up in resolv.conf instead of ISP nameserver addresses -- Huawei E220
Does this bug still affect anyone? ** Changed in: network-manager (Ubuntu) Status: Confirmed = Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/434477 Title: Nameserver addresses 4.2.2.1 and 4.2.2.2 end up in resolv.conf instead of ISP nameserver addresses -- Huawei E220 Status in network-manager package in Ubuntu: Incomplete Bug description: Binary package hint: network-manager When connecting in Karmic to my broadband connection the DNS informations isn't received around 70-80% of the times I connect, so I need to disconnect and reconnect until the info is received. (Confirmed by /etc/resolv.conf being empty except for a comment by the network manager) I don't know if this relates to the same problem, but I also some times have a problem accessing pages after a while, like it somehow decided to block all signals. (resolv.conf still has the info and the modem shows it's connected) I hope there's information enough to fix it, otherwise please instruct me on what to do to help debugging. ProblemType: Bug Architecture: amd64 CheckboxSubmission: 2483b723db6bd40eab5dccee54ef36fb CheckboxSystem: fb5f7a2788cceff50ba915d7273d1642 Date: Tue Sep 22 08:43:42 2009 DistroRelease: Ubuntu 9.10 IfupdownConfig: auto lo iface lo inet loopback IpRoute: 10.64.64.64 dev ppp0 proto kernel scope link src 95.209.250.39 169.254.0.0/16 dev ppp0 scope link metric 1000 default via 10.64.64.64 dev ppp0 proto static Package: network-manager 0.8~a~git.20090911t130220.4c77fa0-0ubuntu6 ProcEnviron: LANGUAGE=en_US.UTF-8 LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-10.34-generic SourcePackage: network-manager Uname: Linux 2.6.31-10-generic x86_64 WpaSupplicantLog: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/434477/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1430077] Re: [vivid] VPN connection breaks /etc/resolv.conf
Now, it is being pushed instead to /etc/resolv.conf. nameserver 10.99.244.1 nameserver 127.0.1.1 [...] Connecting to the VPN also pushes search paths to /etc/resolv.conf - overriding the search domains that I have already configured, and which should take precedence. Is this being done in NM itself, i.e., does NM send these two addresses in this order to resolvconf? Or does something else send the 10.99.244.1 address to resolvconf? Or does something else write directly to /etc/resolv.conf? This is breaking the DNS handling for libvirt-bin, which has its own forwarding dnsmasq instance which it expects to be able to talk to the first nameserver listed here. (As an aside, you may be interested in the discussion at #1163147. It is proposed there that the forwarding dnsmasq instance for libvirt compile its nameserver list using a resolvconf hook script, in the same manner as the plain dnsmasq does. Then if it is configured to listen on some loopback address it can be used on the host system to look up names of vm guests as well as other names.) The nameserver in question does not work (and is not meant to be used) for any name lookups except company-internal domains. Ah, so the VPN nameserver does not provide general DNS service; you rely on dnsmasq to route queries. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1430077 Title: [vivid] VPN connection breaks /etc/resolv.conf Status in network-manager package in Ubuntu: Confirmed Bug description: After some recent update in vivid, connecting to my employer's VPN with network-manager-openvpn has resulted in broken name resolution. Previously, the VPN-provided nameserver setting would be pushed into the config of the dnsmasq run by NM. Now, it is being pushed instead to /etc/resolv.conf. nameserver 10.99.244.1 nameserver 127.0.1.1 This is breaking the DNS handling for libvirt-bin, which has its own forwarding dnsmasq instance which it expects to be able to talk to the first nameserver listed here. The nameserver in question does not work (and is not meant to be used) for any name lookups except company-internal domains. Connecting to the VPN also pushes search paths to /etc/resolv.conf - overriding the search domains that I have already configured, and which should take precedence. (This part is not a regression.) I understand that the purpose of these provided domains is to specify the domains for which DNS lookups should be forwarded to the VPN DNS server, and *not* to modify the system's DNS lookups for non-FQDN requests. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu9 ProcVersionSignature: Ubuntu 3.19.0-7.7-generic 3.19.0 Uname: Linux 3.19.0-7-generic x86_64 ApportVersion: 2.16.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Mon Mar 9 17:16:05 2015 InstallationDate: Installed on 2010-09-24 (1627 days ago) InstallationMedia: Ubuntu 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.1) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WWanEnabled=true SourcePackage: network-manager UpgradeStatus: Upgraded to vivid on 2014-12-06 (93 days ago) nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1430077/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1319805] Re: DNS confused with multiple interfaces (eth/wlan)
A workaround may be to edit /etc/NetworkManager/NetworkManager.conf and comment out the line dns=dnsmasq. ** Description changed: - Using a laptop with a hardware switch for enable/disable WLAN. - Connected to two different LANs using DHCP on ETH/WLAN. + I have a laptop with a hardware switch to enable or disable the WLAN + interface. - When both interfaces are active (in different networks), the system uses the LAN interface as the default route as expected. - But it does not use the the nameserver on that interface consistently. - It often tries to use the WLAN nameserver which leads to trouble as the WLAN nameserver does not know about the hosts on the LAN. + I am connected to two different LANs using DHCP via eth and wlan, + respectively. + + When both interfaces are active (in different networks), the system uses + the LAN interface as the default route as expected. + + However, it does not use the the nameserver on that interface + consistently. It often tries to use the WLAN nameserver which leads to + trouble as the WLAN nameserver does not know about the hosts on the LAN. The nameserver should be taken from the same interface as the default route to avoid messups. Ubuntu 12.04 did not have that behavior. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: network-manager 0.9.8.8-0ubuntu7 Uname: Linux 3.15.0-031500rc2-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.1-0ubuntu3.1 Architecture: amd64 CurrentDesktop: XFCE Date: Thu May 15 14:28:46 2014 IfupdownConfig: - # interfaces(5) file used by ifup(8) and ifdown(8) - auto lo - iface lo inet loopback + # interfaces(5) file used by ifup(8) and ifdown(8) + auto lo + iface lo inet loopback InstallationDate: Installed on 2014-04-24 (20 days ago) InstallationMedia: Xubuntu 14.04 LTS Trusty Tahr - Release amd64 (20140416.2) IpRoute: - default via 10.1.1.254 dev eth0 proto static - 8.0.0.0/24 dev vboxnet0 proto kernel scope link src 8.0.0.1 - 10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.42 metric 1 + default via 10.1.1.254 dev eth0 proto static + 8.0.0.0/24 dev vboxnet0 proto kernel scope link src 8.0.0.1 + 10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.42 metric 1 NetworkManager.state: - [main] - NetworkingEnabled=true - WirelessEnabled=true - WWANEnabled=true - WimaxEnabled=true + [main] + NetworkingEnabled=true + WirelessEnabled=true + WWANEnabled=true + WimaxEnabled=true RfKill: - 0: phy0: Wireless LAN - Soft blocked: yes - Hard blocked: yes + 0: phy0: Wireless LAN + Soft blocked: yes + Hard blocked: yes SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.NetworkManager.NetworkManager.conf: 2014-04-30T15:18:11.879306 nmcli-con: - NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH - Wired connection 158608da7-d199-4c51-a8f4-a7913363637f 802-3-ethernet1400156985 Do 15 Mai 2014 14:29:45 CEST yes no /org/freedesktop/NetworkManager/Settings/2 - afxhome 213a5a1b-daf7-4b28-b682-6c8934b20e4d 802-11-wireless 1400132352 Do 15 Mai 2014 07:39:12 CEST yes no /org/freedesktop/NetworkManager/Settings/1 - AtSec guest 6d860806-d458-4de0-bfcb-8e40c2185437 802-11-wireless 1400141574 Do 15 Mai 2014 10:12:54 CEST yes no /org/freedesktop/NetworkManager/Settings/0 + NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH + Wired connection 158608da7-d199-4c51-a8f4-a7913363637f 802-3-ethernet1400156985 Do 15 Mai 2014 14:29:45 CEST yes no /org/freedesktop/NetworkManager/Settings/2 + afxhome 213a5a1b-daf7-4b28-b682-6c8934b20e4d 802-11-wireless 1400132352 Do 15 Mai 2014 07:39:12 CEST yes no /org/freedesktop/NetworkManager/Settings/1 + AtSec guest 6d860806-d458-4de0-bfcb-8e40c2185437 802-11-wireless 1400141574 Do 15 Mai 2014 10:12:54 CEST yes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: - DEVICE TYPE STATE DBUS-PATH - wlan0 802-11-wireless unavailable /org/freedesktop/NetworkManager/Devices/1 - eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 + DEVICE TYPE STATE DBUS-PATH + wlan0 802-11-wireless unavailable /org/freedesktop/NetworkManager/Devices/1 + eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: - RUNNING
[Touch-packages] [Bug 1460990] [NEW] bogus rc symlink field for resolvconf
Public bug reported: The following versions of resolvconf have a postinst that runs update- rc.d resolvconf defaults. * 1.77ubuntu1 YES * 1.76ubuntu1 in Vivid 15.04 YES * 1.69ubuntu4 in Utopic 14.10 YES * 1.69ubuntu1.1 in Trusty-updates YES * 1.69ubuntu1 in Trusty 14.04 YES * 1.63ubuntu16 in Precise-updates NO * 1.63ubuntu11 in Precise NO * 1.45ubuntu1 in Lucid NO Prior to Vivid, some or all Ubuntu releases included versions of the update-rc.d program which would install a default rc symlink field when run with the arguments foo defaults — this despite what was in the LSB headers of the initscript. A default rc symlink field for initscript foo looks as follows. /etc/ rc0.d/Knnfoo rc1.d/Knnfoo rc2.d/Snnfoo ... rc5.d/Snnfoo rc6.d/Knnfoo If sysvinit were being used then this would be very bad because the resolvconf initscript is only supposed to be executed in runlevels S (with start), and 0 and 6 (with stop). Running the resolvconf initscript with the start argument causes the runtime directories to be wiped. That is supposed to happen only extremely early, before any network interfaces are configured. AIUI, however, rc symlinks have no effect in Ubuntu. So this problem is only cosmetic. But I am still inclined to fix it since it's misleading. Resolvconf doesn't need an initscript in Ubuntu. Neither the Upstart job configuration file nor the systemd unit configuration file uses the initscript. So I'd say: in the next release of resolvconf drop the initscript from the package and do update-rc.d resolvconf remove in the postinst. ** Affects: resolvconf (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1460990 Title: bogus rc symlink field for resolvconf Status in resolvconf package in Ubuntu: New Bug description: The following versions of resolvconf have a postinst that runs update-rc.d resolvconf defaults. * 1.77ubuntu1 YES * 1.76ubuntu1 in Vivid 15.04 YES * 1.69ubuntu4 in Utopic 14.10 YES * 1.69ubuntu1.1 in Trusty-updates YES * 1.69ubuntu1 in Trusty 14.04 YES * 1.63ubuntu16 in Precise-updates NO * 1.63ubuntu11 in Precise NO * 1.45ubuntu1 in Lucid NO Prior to Vivid, some or all Ubuntu releases included versions of the update-rc.d program which would install a default rc symlink field when run with the arguments foo defaults — this despite what was in the LSB headers of the initscript. A default rc symlink field for initscript foo looks as follows. /etc/ rc0.d/Knnfoo rc1.d/Knnfoo rc2.d/Snnfoo ... rc5.d/Snnfoo rc6.d/Knnfoo If sysvinit were being used then this would be very bad because the resolvconf initscript is only supposed to be executed in runlevels S (with start), and 0 and 6 (with stop). Running the resolvconf initscript with the start argument causes the runtime directories to be wiped. That is supposed to happen only extremely early, before any network interfaces are configured. AIUI, however, rc symlinks have no effect in Ubuntu. So this problem is only cosmetic. But I am still inclined to fix it since it's misleading. Resolvconf doesn't need an initscript in Ubuntu. Neither the Upstart job configuration file nor the systemd unit configuration file uses the initscript. So I'd say: in the next release of resolvconf drop the initscript from the package and do update-rc.d resolvconf remove in the postinst. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1460990/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1446681] Re: resolvconf interface-order gives bridge interfaces too low a priority
Fixed upstream in resolvconf 1.77. ** Changed in: resolvconf (Debian) Status: In Progress = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1446681 Title: resolvconf interface-order gives bridge interfaces too low a priority Status in resolvconf package in Ubuntu: Fix Released Status in resolvconf package in Debian: Fix Released Bug description: The interface-order that ships with 1.70 does not correctly detect bridge interfaces and therefore renders IPv4 resolvers before IPv6 when they are in use. I believe the automatic bug reporter has attached the interface-order I hurriedly patched in which detects bridges separately from eth interfaces. It might make sense to combine these as @(br|eth) as is done with the wifi. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.13.0-48.80-generic 3.13.11-ckt16 Uname: Linux 3.13.0-48-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.10 Architecture: amd64 Date: Tue Apr 21 10:02:47 2015 InstallationDate: Installed on 2012-12-14 (857 days ago) InstallationMedia: Ubuntu-Server 12.04.1 LTS Precise Pangolin - Release amd64 (20120817.3) PackageArchitecture: all ProcEnviron: TERM=screen PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: Upgraded to trusty on 2014-08-18 (245 days ago) mtime.conffile..etc.resolvconf.interface.order: 2015-04-20T23:43:05.861928 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1446681/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1446681] Re: resolvconf interface-order gives bridge interfaces too low a priority
Fixed in resolvconf 1.77ubuntu1. ** Changed in: resolvconf (Ubuntu) Status: Confirmed = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1446681 Title: resolvconf interface-order gives bridge interfaces too low a priority Status in resolvconf package in Ubuntu: Fix Released Status in resolvconf package in Debian: Fix Released Bug description: The interface-order that ships with 1.70 does not correctly detect bridge interfaces and therefore renders IPv4 resolvers before IPv6 when they are in use. I believe the automatic bug reporter has attached the interface-order I hurriedly patched in which detects bridges separately from eth interfaces. It might make sense to combine these as @(br|eth) as is done with the wifi. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.13.0-48.80-generic 3.13.11-ckt16 Uname: Linux 3.13.0-48-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.10 Architecture: amd64 Date: Tue Apr 21 10:02:47 2015 InstallationDate: Installed on 2012-12-14 (857 days ago) InstallationMedia: Ubuntu-Server 12.04.1 LTS Precise Pangolin - Release amd64 (20120817.3) PackageArchitecture: all ProcEnviron: TERM=screen PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: Upgraded to trusty on 2014-08-18 (245 days ago) mtime.conffile..etc.resolvconf.interface.order: 2015-04-20T23:43:05.861928 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1446681/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1453185] Re: resolvconf: updates are not enabled right after installation
You know, I didn't even look closely at those warnings. Duh. Now that I read them I see that I am being warned that I have runlevel symlinks in 1 2 3 4 5. Those aren't supposed to be there! (I run Ubuntu 15.04 upgraded from 14.04 originally.) What the aytch-e-double-hockey-stick? Consider the history of the Debian package. Formerly when Debian had traditional System V-style init, dh_installinit was run from debian/rules as follows. dh_installinit --no-start -- start 38 S . stop 89 0 6 . Then someone filed Debian bug report #718232. As I understood it, Debian had switched to dependency-based booting and start and stop arguments could no longer be passed through to update-rc.d. To close that report I changed the line to the following in May 2014. dh_installinit --no-start Possibly this is one of the causes of the problem, but there must be another factor. On Debian the result of installing resolvconf is symlinks in S, 0 and 6 as prescribed by the LSB headers in the initscript. On my current Ubuntu 15.04 system I get the same result when I run update-rc.d resolvconf defaults as root from the command line, or upgrade the resolvconf package. So why do I have a default set of rc symlinks for the resolvconf initscript on my machine? Hmm. On my system the extraneous symlinks were created on 1 December 2014. $ ls -l --time-style=long-iso /etc/rc2.d/*resolvconf* lrwxrwxrwx 1 root root 20 2014-12-01 23:57 /etc/rc2.d/S01resolvconf - ../init.d/resolvconf This was about one half hour after, but not during, an overnight apt update run. - BEGIN of snippet from /var/log/apt/history.log -- Start-Date: 2014-12-01 23:20:52 Commandline: apt-get upgrade Upgrade: libsystemd-login0:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), ppp:amd64 (2.4.5-5.1ubuntu2, 2.4.5-5.1ubuntu2.1), libappindicator1:amd64 (12.10.1+13.10.20130920-0ubuntu4, 12.10.1+13.10.20130920-0ubuntu4.1), systemd-services:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), libnautilus-extension1a:amd64 (3.10.1-0ubuntu9.3, 3.10.1-0ubuntu9.4), unity:amd64 (7.2.2+14.04.20140714-0ubuntu1.1, 7.2.3+14.04.20140826-0ubuntu1), libunity-core-6.0-9:amd64 (7.2.2+14.04.20140714-0ubuntu1.1, 7.2.3+14.04.20140826-0ubuntu1), libsystemd-daemon0:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), libgudev-1.0-0:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), libpam-systemd:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), unity-services:amd64 (7.2.2+14.04.20140714-0ubuntu1.1, 7.2.3+14.04.20140826-0ubuntu1), udev:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), gir1.2-appindicator3-0.1:amd64 (12.10.1+13.10.20130920-0ubuntu4, 12.10.1+13.10.20130920-0ubuntu4.1), gir1.2-gudev-1.0:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), libappindicator3-1 :amd64 (12.10.1+13.10.20130920-0ubuntu4, 12.10.1+13.10.20130920-0ubuntu4.1), libudev1:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), libudev1:i386 (204-5ubuntu20.8, 204-5ubuntu20.9), nautilus:amd64 (3.10.1-0ubuntu9.3, 3.10.1-0ubuntu9.4), libsystemd-journal0:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), nautilus-data:amd64 (3.10.1-0ubuntu9.3, 3.10.1-0ubuntu9.4) End-Date: 2014-12-01 23:21:21 Start-Date: 2014-12-01 23:21:37 Commandline: apt-get --purge autoremove Purge: firefox-locale-nl:amd64 (33.0+build2-0ubuntu0.14.04.1) End-Date: 2014-12-01 23:21:38 Start-Date: 2014-12-02 22:59:04 Commandline: apt-get upgrade Upgrade: firefox-locale-en:amd64 (33.0+build2-0ubuntu0.14.10.1, 34.0+build2-0ubuntu0.14.10.2), firefox:amd64 (33.0+build2-0ubuntu0.14.10.1, 34.0+build2-0ubuntu0.14.10.2) End-Date: 2014-12-02 22:59:10 - END of snippet from /var/log/apt/history.log -- Question 1: What went wrong? Was there a short-lived bug in the sysv-rc package? Did packages not get upgraded in the right order? Question 2: What is the impact of these extraneous symlinks on machines with Ubuntu 14.04 and 14.10 (Upstart-based) and on those with 15.04 and later (Systemd-based)? In the traditional System V init world it would have been bad for /etc/init.d/resolvconf start to be run in runlevel 2-5 because that would have caused the working directories to be emptied too late in the boot sequence. To what extent are these rc symlinks still active in Ubuntu? If there is a negative impact then, yes, we need to add code to the postinst to fix up machines like mine that got broken by some earlier upgrade. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1453185 Title: resolvconf: updates are not enabled right after installation Status in resolvconf package in Ubuntu: Fix Released Bug description: Previously, updates were enabled in postinst script, but this enablement was removed in a favour of upstart service (https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/931335). This worked fine till the switch to systemd - no postinst action to activate resolvconf.service right after installation, one needs to reboot node in order
[Touch-packages] [Bug 1385010] Re: Unexpected behavior: make_resolv_conf is not undefined if /etc/resolv.conf is not a symlink
Yay. We may now get a complaint from someone who has deleted the symlink at /etc/resolv.conf but still has resolvconf installed and relies upon dhclient updating /etc/resolv.conf dynamically. Their problem: /etc/resolv.conf is no longer updated after resolvconf is upgraded to 1.77ubuntu1. Solution for this person: they should remove the (unused) resolvconf package. Or change dhclient-enter-hooks.d/resolvconf to look as it did before; or make some other custom change to their already customized system. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1385010 Title: Unexpected behavior: make_resolv_conf is not undefined if /etc/resolv.conf is not a symlink Status in resolvconf package in Ubuntu: Fix Released Bug description: The resolvconf package comes with /etc/dhcp/dhclient-enter- hooks.d/resolvconf which, if /sbin/resolvconf is present, redefines the make_resolv_conf function (previously defined by dhclient-script) to send nameserver information to resolvconf instead of writing it directly to /etc/resolv.conf. However, the hook also checks if /etc/resolv.conf is a symlink. This is problematic because if /etc/resolv.conf is not a symlink then the script does not redefine make_resolv_conf() and so dhclient will overwrite /etc/resolv.conf when it configures an interface, even though the resolvconf package is installed. The behavior I would expect would be /etc/resolv.conf never changing if resolvconf is installed and /etc/resolv.conf is not a symlink. Debian implements the behavior I would expect. At the very least, I think that the different behavior in Ubuntu should be documented in the man pages for resolvconf. As far as I can tell, there's no reason to check for /etc/resolv.conf being a symlink when resolvconf itself already does that. The patch was introduced by: http://bazaar.launchpad.net/~ubuntu- branches/ubuntu/trusty/resolvconf/trusty/revision/32/etc/dhcp /dhclient-enter-hooks.d/resolvconf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1385010/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1392297] Re: resolvconf 1.69ubuntu1.1 breaks network install
** Changed in: resolvconf (Ubuntu) Status: Confirmed = Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1392297 Title: resolvconf 1.69ubuntu1.1 breaks network install Status in resolvconf package in Ubuntu: Incomplete Bug description: We are experiencing problems with Ubuntu 14.04 network installations, when using the 1.69ubuntu1.1 version of resolvconf. With this version the file /etc/resolv.conf gets reset to an empty file (does only include just the standard resolvconf comments) during the installation of the resolvconf package. After that the name resolution doesn't work anymore and the subsequent installation steps fail. If we use the 1.69ubuntu1 version, everything works fine. If I make a diff of both package contents, the most significant change seems to be the inclusion of a new Sys-V init script, which (besides other things) removes the contents of the resolvconf runtime directories when called with the option start, and the postinst script calls invoke-rc.d resolvconf start at the end (included by dh_installinit), which I think should do nothing during the installation because of policy-rc.d (right?), but I wonder if it actually get's called and removes the resolv.conf file that got migrated to the runtime directories earlier in the postinst script. At least that would explain our problems, because I don't really see anything else, that could cause this problem. I see that the inclusion of the new init script is coming from debian, and they call the dh_installinit with the option --no-start in debian/rules, while the Ubuntu package calls the dh_installinit only with the option -r. And debian inserts the debhelper code a lot earlier in the postinst script. Could this be what's causing the problem? As soon I have more time, I will try to debug this further and provide more information. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1392297/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1085849] Re: Please don't change the answer to linkify-resolvconf
This was fixed in some release prior to 1.77ubuntu1. ** Changed in: resolvconf (Ubuntu) Status: Confirmed = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1085849 Title: Please don't change the answer to linkify-resolvconf Status in resolvconf package in Ubuntu: Fix Released Bug description: Resolvconf postinst does this: db_get resolvconf/linkify-resolvconf if [ $RET = true ] ; then [...] # Create the link and make sure we don't convert it again on upgrade [...] ln -nsf ../run/resolvconf/resolv.conf /etc/resolv.conf db_set resolvconf/linkify-resolvconf false fi The problem with the last line is that it obliterates the original answer to the question, which makes debugging more difficult. This is a non-trivial drawback in connection with bug #1000244 . We could achieve the same result without the aforementioned drawback if we used an additional debconf question to store the information that we have made at least one attempt to linkify. Roughly: db_get resolvconf/linkify-resolvconf if [ $RET = true ] ; then [...] db_get resolvconf/already-linkified-resolvconf if [ $RET != true ] ; then ln -nsf ... db_set resolvconf/already-linkified-resolvconf true fi fi The additional debconf question would not be presented to the user and would default to false. (I am waiving here the more philosophical objections that may be brought against the use of debconf as a registry. :) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1085849/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1392297] Re: resolvconf 1.69ubuntu1.1 breaks network install
@Cs-gon: Can you reproduce this problem (bug #1392297) with resolvconf 1.77ubuntu1? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1392297 Title: resolvconf 1.69ubuntu1.1 breaks network install Status in resolvconf package in Ubuntu: Incomplete Bug description: We are experiencing problems with Ubuntu 14.04 network installations, when using the 1.69ubuntu1.1 version of resolvconf. With this version the file /etc/resolv.conf gets reset to an empty file (does only include just the standard resolvconf comments) during the installation of the resolvconf package. After that the name resolution doesn't work anymore and the subsequent installation steps fail. If we use the 1.69ubuntu1 version, everything works fine. If I make a diff of both package contents, the most significant change seems to be the inclusion of a new Sys-V init script, which (besides other things) removes the contents of the resolvconf runtime directories when called with the option start, and the postinst script calls invoke-rc.d resolvconf start at the end (included by dh_installinit), which I think should do nothing during the installation because of policy-rc.d (right?), but I wonder if it actually get's called and removes the resolv.conf file that got migrated to the runtime directories earlier in the postinst script. At least that would explain our problems, because I don't really see anything else, that could cause this problem. I see that the inclusion of the new init script is coming from debian, and they call the dh_installinit with the option --no-start in debian/rules, while the Ubuntu package calls the dh_installinit only with the option -r. And debian inserts the debhelper code a lot earlier in the postinst script. Could this be what's causing the problem? As soon I have more time, I will try to debug this further and provide more information. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1392297/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1279760] Re: Resolvconf creates /etc/resolvconf/resolv.conf.d/tail-original symlink in debootstrap environment
debian/templates in 1.77ubuntu1: [...] Template: resolvconf/link-tail-to-original Type: boolean Default: false [...] debian/changelog in 1.77ubuntu1: [...] - resolvconf/link-tail-to-original debconf question again defaults to false; it's rather irrelevant as we install resolvconf by default. [...] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1279760 Title: Resolvconf creates /etc/resolvconf/resolv.conf.d/tail-original symlink in debootstrap environment Status in resolvconf package in Ubuntu: Fix Released Bug description: When installing resolvconf inside the debootstrapped system it will create /etc/resolv.conf.d/original with the DNS server addresses available on the host system. This will add the unwanted DNS server addresses to the deboostrapped system. Resolution: don't inherit the DNS servers from the host system when installing resolvconf inside the deboostrapped chroot. ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: resolvconf 1.69ubuntu1 Uname: Linux 3.12.9-x86-linode56 i686 ApportVersion: 2.9.2-0ubuntu8.5 Architecture: i386 Date: Thu Feb 13 11:36:14 2014 InstallationDate: Installed on 2012-10-22 (478 days ago) InstallationMedia: MarkForUpload: True PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: Upgraded to raring on 2013-06-14 (243 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1279760/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1279760] Re: Resolvconf creates /etc/resolvconf/resolv.conf.d/tail-original symlink in debootstrap environment
Fixed in 1.77ubuntu1. ** Changed in: resolvconf (Ubuntu) Status: Confirmed = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1279760 Title: Resolvconf creates /etc/resolvconf/resolv.conf.d/tail-original symlink in debootstrap environment Status in resolvconf package in Ubuntu: Fix Released Bug description: When installing resolvconf inside the debootstrapped system it will create /etc/resolv.conf.d/original with the DNS server addresses available on the host system. This will add the unwanted DNS server addresses to the deboostrapped system. Resolution: don't inherit the DNS servers from the host system when installing resolvconf inside the deboostrapped chroot. ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: resolvconf 1.69ubuntu1 Uname: Linux 3.12.9-x86-linode56 i686 ApportVersion: 2.9.2-0ubuntu8.5 Architecture: i386 Date: Thu Feb 13 11:36:14 2014 InstallationDate: Installed on 2012-10-22 (478 days ago) InstallationMedia: MarkForUpload: True PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: Upgraded to raring on 2013-06-14 (243 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1279760/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1453185] Re: resolvconf: updates are not enabled right after installation
The indirection via /etc/resolvconf/run dates from the era before /run/. I introduced resolvconf in 2003 as part of a larger effort to make it possible to run Debian with a read-only root filesystem[1] but the project to introduce the /run/ tmpfs into Debian base failed due to lack of consensus about the need for it[2][3] and disagreement about what to call it[4]. (The references are just a few examples out of several long exhausting threads.) Not being even a Debian Developer myself, I shelved the controversial /run project[5] and carried on developing resolvconf which still needed some location for its state files, preferably on a tmpfs. The best available location at first was /dev/shm/. Later /lib/init/rw/ was introduced and I converted resolvconf to use that by default. I knew that /dev/shm/ was a controversial and probably temporary solution and I also wanted to accomodate people who didn't want to use any tmpfs at all, so I made the ultimate location of the state directory configurable by means of the symbolic link /etc/resolvconf/run. When /run/ became part of the Debian base system in 2011[6] the need for this configurability disappeared. Nowadays there is no good reason not to keep the files under /run/resolvconf/. Accordingly, debian/NOTES already includes the following TODO list. --- MAINTAINER NOTES for resolvconf TODO * File bug reports against all packages containing suppliers of nameserver information, asking each to add a resolvconf packaging-event hook script. Still to be submitted: dhcpcd5, pump, udhcpc * In Jessie+1, drop the use of /etc/resolvconf/run; use /run/resolvconf directly. -- When I have a few free hours I will take care of the second item. Writing maintainer script code to transition existing resolvconf-using machines to the new setup without breaking anything is not entirely trivial. :) [1]https://lists.debian.org/debian-devel/2003/04/msg02057.html [2]https://lists.debian.org/debian-devel/2003/05/msg00280.html [3]https://lists.debian.org/debian-devel/2003/05/msg00247.html [4]https://lists.debian.org/debian-devel/2003/04/msg00158.html [5]https://lists.debian.org/debian-devel/2003/05/msg01479.html [6]https://wiki.debian.org/ReleaseGoals/RunDirectory -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1453185 Title: resolvconf: updates are not enabled right after installation Status in resolvconf package in Ubuntu: Fix Released Bug description: Previously, updates were enabled in postinst script, but this enablement was removed in a favour of upstart service (https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/931335). This worked fine till the switch to systemd - no postinst action to activate resolvconf.service right after installation, one needs to reboot node in order to get updates enabled. Description: Ubuntu 15.04 Release: 15.04 resolvconf 1.76ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1453185/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1453185] Re: resolvconf: updates are not enabled right after installation
Yep, I see that debian/triggers is present in 1.77ubuntu1, and when I install the package I see the report of the trigger being processed. Thx! P.S. Is there something we should do to silence those insserv warnings? $ sudo dpkg -i resolvconf_1.77ubuntu1_all.deb (Reading database ... 282465 files and directories currently installed.) Preparing to unpack resolvconf_1.77ubuntu1_all.deb ... Unpacking resolvconf (1.77ubuntu1) over (1.76.1ubuntu2) ... Setting up resolvconf (1.77ubuntu1) ... Installing new version of config file /etc/dhcp/dhclient-enter-hooks.d/resolvconf ... Installing new version of config file /etc/resolvconf/interface-order ... insserv: warning: current start runlevel(s) (2 3 4 5) of script `resolvconf' overrides LSB defaults (S). insserv: warning: current stop runlevel(s) (0 1 6) of script `resolvconf' overrides LSB defaults (0 6). Processing triggers for ureadahead (0.100.0-19) ... Processing triggers for systemd (219-7ubuntu5) ... Processing triggers for man-db (2.7.0.2-5) ... Processing triggers for resolvconf (1.77ubuntu1) ... insserv: warning: current start runlevel(s) (2 3 4 5) of script `resolvconf' overrides LSB defaults (S). insserv: warning: current stop runlevel(s) (0 1 6) of script `resolvconf' overrides LSB defaults (0 6). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1453185 Title: resolvconf: updates are not enabled right after installation Status in resolvconf package in Ubuntu: Fix Released Bug description: Previously, updates were enabled in postinst script, but this enablement was removed in a favour of upstart service (https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/931335). This worked fine till the switch to systemd - no postinst action to activate resolvconf.service right after installation, one needs to reboot node in order to get updates enabled. Description: Ubuntu 15.04 Release: 15.04 resolvconf 1.76ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1453185/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1392297] Re: resolvconf 1.69ubuntu1.1 breaks network install
Resolvconf 1.77ubuntu1's debian/rules runs dh_installinit with `--no- start` and so there is no longer a `invoke-rc.d resolvconf start` (which wipes runtime directories) in debian/postinst. To enable resolvconf updates, postinst simply does resolvconf --enable-updates. If `invoke-rc.d resolvconf start` was the cause of the problem then the problem should be solved in 1.77ubuntu1. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1392297 Title: resolvconf 1.69ubuntu1.1 breaks network install Status in resolvconf package in Ubuntu: Incomplete Bug description: We are experiencing problems with Ubuntu 14.04 network installations, when using the 1.69ubuntu1.1 version of resolvconf. With this version the file /etc/resolv.conf gets reset to an empty file (does only include just the standard resolvconf comments) during the installation of the resolvconf package. After that the name resolution doesn't work anymore and the subsequent installation steps fail. If we use the 1.69ubuntu1 version, everything works fine. If I make a diff of both package contents, the most significant change seems to be the inclusion of a new Sys-V init script, which (besides other things) removes the contents of the resolvconf runtime directories when called with the option start, and the postinst script calls invoke-rc.d resolvconf start at the end (included by dh_installinit), which I think should do nothing during the installation because of policy-rc.d (right?), but I wonder if it actually get's called and removes the resolv.conf file that got migrated to the runtime directories earlier in the postinst script. At least that would explain our problems, because I don't really see anything else, that could cause this problem. I see that the inclusion of the new init script is coming from debian, and they call the dh_installinit with the option --no-start in debian/rules, while the Ubuntu package calls the dh_installinit only with the option -r. And debian inserts the debhelper code a lot earlier in the postinst script. Could this be what's causing the problem? As soon I have more time, I will try to debug this further and provide more information. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1392297/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1453185] Re: resolvconf: updates are not enabled right after installation
Continuing with my investigation of how a default symlink field got created for resolvconf on my machine... (What I am calling a 'default symlink field' is the set of symlinks /etc/rc[1-5].d/S??resolvconf - ../init.d/resolvconf as would be created by update-rc.d resolvconf defaults with update-rc.d from older sysv-rc packages.) Debian -- Support for start and stop commands to update-rc.d was dropped in sysvinit 2.88dsf-42 which was released 13 July 2013. This is what led to Debian bug report #718232 which led to the change to resolvconf mentioned above, which saw the light of day in resolvconf 1.75 released in May 2014. Unfortunately, this resolvconf release didn't constrain the version of sysv-rc with which it could be installed. It should have declared something like Breaks: sysv-rc ( 2.88dsf-42). This is a bug in Debian resolvconf. Jessie includes sysv-rc 2.88dsf-59 but the previous release Wheezy contains only 2.88dsf-41, so on upgrade from Wheezy to Jessie it is possible that resolvconf upgrades first and its postinst executes update-rc.d from the previous release. I imagine that this could create a default symlink field for resolvconf. Ubuntu -- The start-and-stopless version of sysvinit appeared in Ubuntu only in 15.04. But Ubuntu resolvconf postinst was doing update-rc.d resolvconf defaults even earlier than May 2014 as evidenced by insserv warnings in my logs. Checking old versions of Ubuntu resolvconf I see that the following versions did update-rc.d resolvconf defaults. * 1.77ubuntu1 YES * 1.76ubuntu1 in Vivid 15.04 YES * 1.69ubuntu4 in Utopic 14.10 YES * 1.69ubuntu1.1 in Trusty-updates YES * 1.69ubuntu1 in Trusty 14.04YES * 1.63ubuntu16 in Precise-updates NO * 1.63ubuntu11 in Precise NO * 1.45ubuntu1 in Lucid NO I think that this means that a LOT of Ubuntu machines have default symlink fields for resolvconf. Which is wrong and bad unless these symlinks can have no effect, in which case it's merely ugly. Resolvconf has long had an Upstart job configuration file and now has a systemd unit file, so I hope that this means that the bogus symlinks could never have had any effect. What do you think, Martin? Was there in Trusty or later an option to run Ubuntu with sysvinit instead of Upstart, or do the rc symlinks have side effects even when Upstart is used? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1453185 Title: resolvconf: updates are not enabled right after installation Status in resolvconf package in Ubuntu: Fix Released Bug description: Previously, updates were enabled in postinst script, but this enablement was removed in a favour of upstart service (https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/931335). This worked fine till the switch to systemd - no postinst action to activate resolvconf.service right after installation, one needs to reboot node in order to get updates enabled. Description: Ubuntu 15.04 Release: 15.04 resolvconf 1.76ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1453185/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1453185] Re: resolvconf: updates are not enabled right after installation
I'd like to comment on the remaining differences between Debian resolvconf and Ubuntu resolvconf. Besides the extensive source-textual differences arising from Debian's use of /etc/resolvconf/run versus Ubuntu's direct use of /run/resolvconf, I see only three substantial differences. 1. The omission of debian/triggers in Ubuntu As mentioned previously (comment 6) I am guessing that this is an oversight. 2. Debconf question resolvconf/link-tail-to-original defaulting to true in Ubuntu versus false in Debian This only makes a difference, and the answer true is only useful, when installing resolvconf on a resolvconfless system that already had a handcrafted /etc/resolv.conf file and the admin doesn't want to take the time right away to move the nameserver lines from /etc/resolvconf/resolv.conf.d/original to the appropriate place in /etc/network/interfaces. This use case seems very far from the typical circumstances on an Ubuntu system where resolvconf is part of the base system. I'd say drop this difference unless there is a known good reason to preserve it. If there is a reason then please document it somewhere, e.g., in debian/NOTES. 3. dhclient-enter-hooks.d/resolvconf undefining make_resolv_conf() only if /etc/resolv.conf is a symbolic link, in contrast with Debian resolvconf where that script undefines make_resolv_conf() even if /etc/resolv.conf is not a symbolic link. See bug #1385010 for discussion. My position is that this diff should be dropped. It's a feature of resolvconf that when you install it, other programs don't engage in their legacy behavior of overwriting /etc/resolv.conf. With the diff in question here, Ubuntu reactivates dhclient's legacy behavior (which Debian resolvconf had deactivated) of overwriting /etc/resolv.conf if the latter is not a symbolic link. Some people might want that; others do not (bug #1385010). My view is that people who want the legacy behavior should de-install resolvconf to obtain it. The resolvconf package and the symbolic link at /etc/resolv.conf are on the system by default, so the diff in question has no effect on a typical Ubuntu system. So twhat reason is there to depart from Debian in this respect? Perhaps it's a concession to the expectations of admins who are more familiar with other distros. If there is a reason then whatever the reason is, please document it in a comment. Cheers! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1453185 Title: resolvconf: updates are not enabled right after installation Status in resolvconf package in Ubuntu: Fix Released Bug description: Previously, updates were enabled in postinst script, but this enablement was removed in a favour of upstart service (https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/931335). This worked fine till the switch to systemd - no postinst action to activate resolvconf.service right after installation, one needs to reboot node in order to get updates enabled. Description: Ubuntu 15.04 Release: 15.04 resolvconf 1.76ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1453185/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1453185] Re: resolvconf: updates are not enabled right after installation
@Martin: My previous comment raced with your release of 1.76.1ubuntu2. Looks good. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1453185 Title: resolvconf: updates are not enabled right after installation Status in resolvconf package in Ubuntu: Fix Released Bug description: Previously, updates were enabled in postinst script, but this enablement was removed in a favour of upstart service (https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/931335). This worked fine till the switch to systemd - no postinst action to activate resolvconf.service right after installation, one needs to reboot node in order to get updates enabled. Description: Ubuntu 15.04 Release: 15.04 resolvconf 1.76ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1453185/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1453185] Re: resolvconf: updates are not enabled right after installation
In the Debian postinst there is a case clause at the end whose purpose is to enable updates. In Debian this is done by means of a trigger. resolvconf 1.77 [...] case $1 in reconfigure) resolvconf --enable-updates ;; configure) if [ $DEBCONF_RECONFIGURE = 1 ] ; then resolvconf --enable-updates else # Trigger self to enable updates later dpkg-trigger --no-await resolvconf-enable-updates || resolvconf --enable-updates fi ;; triggered) # Runs after this and other packages have been configured for trggr in $2 ; do case $trggr in resolvconf-enable-updates) resolvconf --enable-updates break ;; esac done ;; [...] The Ubuntu postinst omits that whole clause. In the Upstart era updates were enabled by means of an invoke-rc.d resolvconf start at the end of the file, inserted by dh_installinit called without --no-start. --- resolvconf 1.69ubuntu1 - [...] # Automatically added by dh_installinit if [ -x /etc/init.d/resolvconf ]; then if [ ! -e /etc/init/resolvconf.conf ]; then update-rc.d resolvconf defaults /dev/null fi invoke-rc.d resolvconf start || exit $? fi # End automatically added section # Automatically added by dh_installinit update-rc.d -f resolvconf remove /dev/null || exit $? # End automatically added section exit 0 I would suggest that Ubuntu resolvconf's postinst simply add a clause at the end, like the one in Debian, which runs resolvconf --enable- updates on configure. This will minimize the diff with the Debian postinst. For background on the sorts of problems that can arise when changes are made to the postinst that haven't been fully thought through, see bug #1085862. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1453185 Title: resolvconf: updates are not enabled right after installation Status in resolvconf package in Ubuntu: Fix Released Bug description: Previously, updates were enabled in postinst script, but this enablement was removed in a favour of upstart service (https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/931335). This worked fine till the switch to systemd - no postinst action to activate resolvconf.service right after installation, one needs to reboot node in order to get updates enabled. Description: Ubuntu 15.04 Release: 15.04 resolvconf 1.76ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1453185/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1392297] Re: resolvconf 1.69ubuntu1.1 breaks network install
@Cs-gon: Do you have any problem with resolvconf 1.76ubuntu1? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1392297 Title: resolvconf 1.69ubuntu1.1 breaks network install Status in resolvconf package in Ubuntu: Confirmed Bug description: We are experiencing problems with Ubuntu 14.04 network installations, when using the 1.69ubuntu1.1 version of resolvconf. With this version the file /etc/resolv.conf gets reset to an empty file (does only include just the standard resolvconf comments) during the installation of the resolvconf package. After that the name resolution doesn't work anymore and the subsequent installation steps fail. If we use the 1.69ubuntu1 version, everything works fine. If I make a diff of both package contents, the most significant change seems to be the inclusion of a new Sys-V init script, which (besides other things) removes the contents of the resolvconf runtime directories when called with the option start, and the postinst script calls invoke-rc.d resolvconf start at the end (included by dh_installinit), which I think should do nothing during the installation because of policy-rc.d (right?), but I wonder if it actually get's called and removes the resolv.conf file that got migrated to the runtime directories earlier in the postinst script. At least that would explain our problems, because I don't really see anything else, that could cause this problem. I see that the inclusion of the new init script is coming from debian, and they call the dh_installinit with the option --no-start in debian/rules, while the Ubuntu package calls the dh_installinit only with the option -r. And debian inserts the debhelper code a lot earlier in the postinst script. Could this be what's causing the problem? As soon I have more time, I will try to debug this further and provide more information. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1392297/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1085862] Re: #DEBHELPER# token is in the wrong place, and other resolvconf postinst nits
Just to note that nowadays, e.g., in 1.76ubuntu1, Ubuntu also does `dh_installinit --no-start`. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1085862 Title: #DEBHELPER# token is in the wrong place, and other resolvconf postinst nits Status in resolvconf package in Ubuntu: Fix Released Bug description: Background: In the Debian version of the resolvconf package, dh_installinit is run with the --no-start option and actions equivalent to invoke-rc.d resolvconf start are performed later in the postinst after necessary preparation has been done. The problem: While converting from sysvinit to Upstart, --no-start was replaced with -r but there are still some loose ends, some minor, but I take this opportunity to mention them as well. * First, the #DEBHELPER# token is in the wrong place. It should be placed after the postinst code that linkifies and initializes the database. The reason is that dh_installinit inserts invoke-rc.d resolvconf start at the position of the token. (1) If the invoke- rc.d resolvconf start happens before initialization of the database then the initial contents of resolv.conf are out of date. (2) If the invoke-rc.d resolvconf start happens before linkification and an update script returns an error condition then linkification does not happen. This may be one of the reasons for the malfunctions reported in bug #1000244. A good place to put the token is right at the end of the file, just before the exit 0 line. This was supposedly fixed at one point as indicated by the following changelog entry - Move the #DEBHELPER# token in debian/postinst to after the resolv.conf symlink is set, [...] but the current version (1.67ubuntu2) has the #DEBHELPER# token back up at the top of the file. * Second, the comment in the postinst still says that --no-start is used # We use dh_installinit with --no-start whereas this is not true in the Ubuntu version. Please remove this line. * Third, this comment # Even though we create this dir in the preinst, # don't assume that it's still here; a reboot # after unpack may have left us with no upstart # job in place and /run cleaned out. mkdir -p /run/resolvconf/interface has irregular indentation and duplicates the comment that precedes the if-then block. Simplest thing is to remove the comment (but not the mkdir line!). * Fourth, this comment # FHS violation; get rid of it, we use /run directly now. incorrectly (IMHO) states that the use of a symbolic link /etc/resolvconf/run - (some-tmpfs)/resolvconf in the Debian version of the package is a FHS violation. It is not. The run-time state directory of Debian resolvconf is no more in /etc/ than the vi program is in /etc/ just because $ ls -l /usr/bin/vi lrwxrwxrwx 1 root root 20 Jun 13 09:55 /usr/bin/vi - /etc/alternatives/vi In Debian, /etc/resolvconf/run has only ever been a symbolic link to some tmpfs. It is a configurable symbolic link. So please replace the comment with something less controversial, such as the following. # We use /run directly now. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1085862/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1449083] Re: dnsmasq reverses order of dns servers
Dnsmasq treats all nameservers as equivalent (except insofar as it is instructed to use particular nameservers to resolve names in particular domains). The C library resolver, on the other hand, tries one nameserver at a time in the order that their addresses are listed in resolv.conf. If you must try the nameservers in a particular order then don't use dnsmasq on the local machine. If you are using NetworkManager which by default starts a slave dnsmasq instance to serve as a local forwarding nameserver then with root privileges edit /etc/NetworkManager/NetworkManager.conf to comment out the line `dns=dnsmasq` (by putting a `#` at the beginning of the line) and then restart the machine. ** Changed in: dnsmasq (Ubuntu) Status: New = Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1449083 Title: dnsmasq reverses order of dns servers Status in dnsmasq package in Ubuntu: Incomplete Bug description: I have a carefully sorted order of dns servers that my dhcp server gives out. When booting lubuntu, I can't resolve names that should be resolvable by the first two name servers from the list. The names are local private names, but since the local nameserver is first, I expect them to resolve. But apparently because the order has been reversed, resolving fails. rhialto@glicca:~$ lsb_release -rd Description: Ubuntu 14.04.2 LTS Release: 14.04 rhialto@glicca:~$ apt-cache policy dnsmasq-base dnsmasq-base: Installed: 2.68-1 Candidate: 2.68-1 Version table: *** 2.68-1 0 500 http://nl.archive.ubuntu.com/ubuntu/ trusty/main i386 Packages 100 /var/lib/dpkg/status Extract from /var/log/messages (I munged a few numbers here and there). Note how the order at the end is the reverse of the first one. Apr 27 16:04:49 glicca NetworkManager[783]: info (eth0): DHCPv4 state changed nbi - preinit Apr 27 16:04:49 glicca dhclient: Listening on LPF/eth0/00:22: Apr 27 16:04:49 glicca dhclient: Sending on LPF/eth0/00:22: Apr 27 16:04:49 glicca dhclient: Sending on Socket/fallback Apr 27 16:04:49 glicca dhclient: DHCPREQUEST of 10.0.0.14 on eth0 to 255.255.255.255 port 67 (xid=0x72024df1) Apr 27 16:04:49 glicca ntpd[974]: Deferring DNS for 0.ubuntu.pool.ntp.org 1 Apr 27 16:04:49 glicca ntpd[974]: Deferring DNS for 1.ubuntu.pool.ntp.org 1 Apr 27 16:04:49 glicca ntpd[974]: Deferring DNS for 2.ubuntu.pool.ntp.org 1 Apr 27 16:04:49 glicca ntpd[974]: Deferring DNS for 3.ubuntu.pool.ntp.org 1 Apr 27 16:04:49 glicca dhclient: DHCPACK of 10.0.0.14 from 10.0.0.16 Apr 27 16:04:49 glicca dhclient: bound to 10.0.0.14 -- renewal in 247908 seconds. Apr 27 16:04:49 glicca NetworkManager[783]: info (eth0): DHCPv4 state changed preinit - reboot Apr 27 16:04:49 glicca NetworkManager[783]: info address 10.0.0.14 Apr 27 16:04:49 glicca NetworkManager[783]: info prefix 24 (255.255.255.0) Apr 27 16:04:49 glicca NetworkManager[783]: info gateway 10.0.0.16 Apr 27 16:04:49 glicca NetworkManager[783]: info hostname 'glicca.falu.nl' Apr 27 16:04:49 glicca NetworkManager[783]: info nameserver '83.162.x.y' Apr 27 16:04:49 glicca NetworkManager[783]: info nameserver '10.0.0.16' Apr 27 16:04:49 glicca NetworkManager[783]: info nameserver '194.109.104.104' Apr 27 16:04:49 glicca NetworkManager[783]: info nameserver '194.109.9.99' Apr 27 16:04:49 glicca NetworkManager[783]: info nameserver '194.109.6.66' Apr 27 16:04:49 glicca NetworkManager[783]: info domain name 'falu.nl' Apr 27 16:04:49 glicca NetworkManager[783]: info Activation (eth0) Stage 5 of 5 (IPv4 Configure Commit) scheduled... Apr 27 16:04:50 glicca NetworkManager[783]: info Activation (eth0) Stage 5 of 5 (IPv4 Commit) started... Apr 27 16:04:50 glicca avahi-daemon... Apr 27 16:04:51 glicca NetworkManager[783]: info (eth0): device state change: ip-config - secondaries (reason 'none') [70 90 0] Apr 27 16:04:51 glicca NetworkManager[783]: info Activation (eth0) Stage 5 of 5 (IPv4 Commit) complete. Apr 27 16:04:51 glicca NetworkManager[783]: info (wlan0): supplicant interface state: disconnected - inactive Apr 27 16:04:51 glicca NetworkManager[783]: info (eth0): device state change: secondaries - activated (reason 'none') [90 100 0] Apr 27 16:04:51 glicca NetworkManager[783]: info NetworkManager state is now CONNECTED_GLOBAL Apr 27 16:04:51 glicca NetworkManager[783]: info Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Apr 27 16:04:51 glicca NetworkManager[783]: info DNS: starting dnsmasq... Apr 27 16:04:51 glicca NetworkManager[783]: warn dnsmasq not available on the bus, can't update servers. Apr 27 16:04:51 glicca NetworkManager[783]: error [1430143491.244228] [nm-dns-dnsmasq.c:396] update(): dnsmasq owner not found on bus: Could not get owner
[Touch-packages] [Bug 1446681] Re: resolvconf v4/v6 order does not handle bridge interfaces correctly
** Also affects: resolvconf (Debian) Importance: Undecided Status: New ** Changed in: resolvconf (Debian) Assignee: (unassigned) = Thomas Hood (jdthood) ** Changed in: resolvconf (Debian) Status: New = In Progress ** Changed in: resolvconf (Debian) Assignee: Thomas Hood (jdthood) = (unassigned) ** Changed in: resolvconf (Debian) Assignee: (unassigned) = Thomas Hood (jdthood) ** Summary changed: - resolvconf v4/v6 order does not handle bridge interfaces correctly + resolvconf interface-order gives bridge interfaces too low a priority -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1446681 Title: resolvconf interface-order gives bridge interfaces too low a priority Status in resolvconf package in Ubuntu: Confirmed Status in resolvconf package in Debian: In Progress Bug description: The interface-order that ships with 1.70 does not correctly detect bridge interfaces and therefore renders IPv4 resolvers before IPv6 when they are in use. I believe the automatic bug reporter has attached the interface-order I hurriedly patched in which detects bridges separately from eth interfaces. It might make sense to combine these as @(br|eth) as is done with the wifi. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.13.0-48.80-generic 3.13.11-ckt16 Uname: Linux 3.13.0-48-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.10 Architecture: amd64 Date: Tue Apr 21 10:02:47 2015 InstallationDate: Installed on 2012-12-14 (857 days ago) InstallationMedia: Ubuntu-Server 12.04.1 LTS Precise Pangolin - Release amd64 (20120817.3) PackageArchitecture: all ProcEnviron: TERM=screen PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: Upgraded to trusty on 2014-08-18 (245 days ago) mtime.conffile..etc.resolvconf.interface.order: 2015-04-20T23:43:05.861928 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1446681/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1446681] Re: resolvconf v4/v6 order does not handle bridge interfaces correctly
Try this. lo.inet6 lo.inet lo.@(dnsmasq|pdnsd) lo.!(pdns|pdns-recursor) lo tun* tap* hso* em+([0-9])?(_+([0-9]))* p+([0-9])p+([0-9])?(_+([0-9]))* @(br|eth)*([^.]).inet6 @(br|eth)*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc) @(br|eth)*([^.]).inet @(br|eth)*([^.]).@(dhclient|dhcpcd|pump|udhcpc) @(br|eth)* @(ath|wifi|wlan)*([^.]).inet6 @(ath|wifi|wlan)*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc) @(ath|wifi|wlan)*([^.]).inet @(ath|wifi|wlan)*([^.]).@(dhclient|dhcpcd|pump|udhcpc) @(ath|wifi|wlan)* ppp* * -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1446681 Title: resolvconf v4/v6 order does not handle bridge interfaces correctly Status in resolvconf package in Ubuntu: Confirmed Bug description: The interface-order that ships with 1.70 does not correctly detect bridge interfaces and therefore renders IPv4 resolvers before IPv6 when they are in use. I believe the automatic bug reporter has attached the interface-order I hurriedly patched in which detects bridges separately from eth interfaces. It might make sense to combine these as @(br|eth) as is done with the wifi. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.13.0-48.80-generic 3.13.11-ckt16 Uname: Linux 3.13.0-48-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.10 Architecture: amd64 Date: Tue Apr 21 10:02:47 2015 InstallationDate: Installed on 2012-12-14 (857 days ago) InstallationMedia: Ubuntu-Server 12.04.1 LTS Precise Pangolin - Release amd64 (20120817.3) PackageArchitecture: all ProcEnviron: TERM=screen PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: Upgraded to trusty on 2014-08-18 (245 days ago) mtime.conffile..etc.resolvconf.interface.order: 2015-04-20T23:43:05.861928 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1446681/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1349011] Re: nm-l2tp-service needs exception in ppp ip-up/down scripts
** Changed in: resolvconf (Ubuntu)
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1349011
Title:
nm-l2tp-service needs exception in ppp ip-up/down scripts
Status in resolvconf package in Ubuntu:
Fix Released
Bug description:
There is an actively maintained NetworkManager L2TP VPN plugin,
available as an Ubuntu package here: https://launchpad.net/~seriy-
pr/+archive/ubuntu/network-manager-l2tp. Hopefully it will be a part
of Ubuntu soon.
Like nm-pptp-service, it needs an exception in
/etc/ppp/ip-{up,down}.d/000resolvconf (part of the resolvconf package)
as follows:
% diff /etc/ppp/ip-up.d/000resolvconf
/tmp/resolvconf-1.69ubuntu1.1/debian/resolvconf.000resolvconf.ppp.ip-up
16c16
nm-l2tp-service-*|nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*)
---
nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*)
Since that's how it works for the PPTP plugin, could we add the L2TP
one as well so that it can work out of the box on Ubuntu?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1349011/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1110331] Re: nscd no longer needs to be restarted by libc's resolvconf update script
** Changed in: resolvconf (Ubuntu) Status: Confirmed = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1110331 Title: nscd no longer needs to be restarted by libc's resolvconf update script Status in resolvconf package in Ubuntu: Fix Released Bug description: Browsing the eglibc mailing list archives I notice[0] that the eglibc resolver has been enhanced[1] such that if /etc/resolv.conf's mtime changes then the client re-initializes the resolver state. This feature gives us an opportunity to eliminate from /etc/resolvconf/update.d/libc the code that restarts nscd after an alteration in resolv.conf. That would be a beneficial simplification. Possibly ditto for some other resolvconf update scripts. Can we take advantage of this eglibc enhancement in order to simplify resolvconf update scripts? Do we want to? [0]http://www.eglibc.org/archives/patches/msg00977.html [1]http://patch-tracker.debian.org/patch/series/view/eglibc/2.11.3-4/any/submitted-resolv.conf-thread.diff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1110331/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1094345] Re: IPv6 DHCP record too late, and other irregularities, in resolvconf interface-order
The original problem was fixed in resolvconf 1.70 which has since been merged to Vivid. ** Changed in: resolvconf (Ubuntu) Status: Confirmed = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1094345 Title: IPv6 DHCP record too late, and other irregularities, in resolvconf interface-order Status in resolvconf package in Ubuntu: Fix Released Bug description: I am using /etc/network/interfaces rather than NetworkManager on this machine. resolvconf is always writing the IPv4 nameservers and search domains before the IPv6. I would like the IPv6 resolver information to be given priority or a method to select the behavior. kjotte@pegasus:~$ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet6 auto dhcp 1 iface eth0 inet dhcp kjotte@pegasus:~$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 172.31.3.4 nameserver 2001:470:8:64f::4 search nivex.lan home.nivex.net ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: resolvconf 1.67ubuntu2 ProcVersionSignature: Ubuntu 3.5.0-21.32-generic 3.5.7.1 Uname: Linux 3.5.0-21-generic i686 NonfreeKernelModules: nvidia ApportVersion: 2.6.1-0ubuntu6 Architecture: i386 Date: Fri Dec 28 15:33:41 2012 MarkForUpload: True PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: Upgraded to quantal on 2012-05-10 (232 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1094345/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1392297] Re: resolvconf 1.69ubuntu1.1 breaks network install
** Changed in: resolvconf (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1392297 Title: resolvconf 1.69ubuntu1.1 breaks network install Status in resolvconf package in Ubuntu: Confirmed Bug description: We are experiencing problems with Ubuntu 14.04 network installations, when using the 1.69ubuntu1.1 version of resolvconf. With this version the file /etc/resolv.conf gets reset to an empty file (does only include just the standard resolvconf comments) during the installation of the resolvconf package. After that the name resolution doesn't work anymore and the subsequent installation steps fail. If we use the 1.69ubuntu1 version, everything works fine. If I make a diff of both package contents, the most significant change seems to be the inclusion of a new Sys-V init script, which (besides other things) removes the contents of the resolvconf runtime directories when called with the option start, and the postinst script calls invoke-rc.d resolvconf start at the end (included by dh_installinit), which I think should do nothing during the installation because of policy-rc.d (right?), but I wonder if it actually get's called and removes the resolv.conf file that got migrated to the runtime directories earlier in the postinst script. At least that would explain our problems, because I don't really see anything else, that could cause this problem. I see that the inclusion of the new init script is coming from debian, and they call the dh_installinit with the option --no-start in debian/rules, while the Ubuntu package calls the dh_installinit only with the option -r. And debian inserts the debhelper code a lot earlier in the postinst script. Could this be what's causing the problem? As soon I have more time, I will try to debug this further and provide more information. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1392297/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1279760] Re: Resolvconf creates /etc/resolvconf/resolv.conf.d/tail-original symlink in debootstrap environment
Not fixed in 1.76ubuntu1. debian/templates in 1.76ubuntu1: [...] Template: resolvconf/link-tail-to-original Type: boolean Default: true [...] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1279760 Title: Resolvconf creates /etc/resolvconf/resolv.conf.d/tail-original symlink in debootstrap environment Status in resolvconf package in Ubuntu: Confirmed Bug description: When installing resolvconf inside the debootstrapped system it will create /etc/resolv.conf.d/original with the DNS server addresses available on the host system. This will add the unwanted DNS server addresses to the deboostrapped system. Resolution: don't inherit the DNS servers from the host system when installing resolvconf inside the deboostrapped chroot. ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: resolvconf 1.69ubuntu1 Uname: Linux 3.12.9-x86-linode56 i686 ApportVersion: 2.9.2-0ubuntu8.5 Architecture: i386 Date: Thu Feb 13 11:36:14 2014 InstallationDate: Installed on 2012-10-22 (478 days ago) InstallationMedia: MarkForUpload: True PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: Upgraded to raring on 2013-06-14 (243 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1279760/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1432829] Re: resolv.conf not updated correctly for interfaces configured in initramfs
** Summary changed: - resolvconf not updated correctly for interfaces configured in initramfs + resolv.conf not updated correctly for interfaces configured in initramfs -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1432829 Title: resolv.conf not updated correctly for interfaces configured in initramfs Status in systemd package in Ubuntu: Fix Released Bug description: maas images utilize cloud-initramfs-dyn-netconf . The way this works is basically: * /etc/network/interfaces in image is a link to ../../run/network/dynamic-interfaces * kernel command line 'ip=' convince the initramfs to bring up networking using 'ipconfig' example: ip=maas-enlist:BOOTIF * ipconfig writes files in /run/net-*.conf for each interface it configures. * cloud-initramfs-dyn-netconf module writes /run/network/dyanmic-interfaces based on /run/net-*.conf files that 'ipconfig' creates. end result is that after the move to real root, /etc/network/interfaces should be a symlink to /run/ that ends up having something like this: | ## This file is generated by cloud-initramfs-dyn-netconf | auto lo | iface lo inet loopback | manual eth0 | iface eth0 inet dhcp | dns-nameservers 192.168.64.3 | dns-search maas resolvconf seems not to be working as well as it should be. In vivid (now using systemd), I have only the resolvconf header in the file. in all other supported ubuntu releases, doing the above results in functional resolv.conf via resolv.conf. Seen here from trusty: | # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) | # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN | nameserver 192.168.64.3 Related Bugs: * bug 1432821: something deleting /run/network after during boot ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.7 Architecture: amd64 Date: Mon Mar 16 20:42:24 2015 PackageArchitecture: all ProcEnviron: TERM=vt102 PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1432829/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1432829] Re: resolvconf not updated correctly for interfaces configured in initramfs
First a parenthetical remark. According to interfaces(5) the manual keyword is used exclusively in the method field, as in `iface eth0 inet manual`. But in your example you use it at the beginning of a line. Perhaps you think that in that context manual means the opposite of auto (non-auto?) but so far as I can tell by reading the manual page and the source code it does not have any meaning in that context. If a logical interface is not declared as auto then it is non-auto and there is no way affirmatively to declare a logical interface as non- auto. If I am right, please see to it that the software you are using gets fixed so that it doesn't write out meaningless manual ... lines. If I am not right then please let me know. :) The submitter wrote: | ## This file is generated by cloud-initramfs-dyn-netconf | auto lo | iface lo inet loopback | manual eth0 | iface eth0 inet dhcp | dns-nameservers 192.168.64.3 | dns-search maas -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1432829 Title: resolvconf not updated correctly for interfaces configured in initramfs Status in resolvconf package in Ubuntu: New Bug description: maas images utilize cloud-initramfs-dyn-netconf . The way this works is basically: * /etc/network/interfaces in image is a link to ../../run/network/dynamic-interfaces * kernel command line 'ip=' convince the initramfs to bring up networking using 'ipconfig' example: ip=maas-enlist:BOOTIF * ipconfig writes files in /run/net-*.conf for each interface it configures. * cloud-initramfs-dyn-netconf module writes /run/network/dyanmic-interfaces based on /run/net-*.conf files that 'ipconfig' creates. end result is that after the move to real root, /etc/network/interfaces should be a symlink to /run/ that ends up having something like this: | ## This file is generated by cloud-initramfs-dyn-netconf | auto lo | iface lo inet loopback | manual eth0 | iface eth0 inet dhcp | dns-nameservers 192.168.64.3 | dns-search maas resolvconf seems not to be working as well as it should be. In vivid (now using systemd), I have only the resolvconf header in the file. in all other supported ubuntu releases, doing the above results in functional resolv.conf via resolv.conf. Seen here from trusty: | # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) | # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN | nameserver 192.168.64.3 Related Bugs: * bug 1432821: something deleting /run/network after during boot ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.7 Architecture: amd64 Date: Mon Mar 16 20:42:24 2015 PackageArchitecture: all ProcEnviron: TERM=vt102 PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1432829/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1432829] Re: resolvconf not updated correctly for interfaces configured in initramfs
I just tried to reproduce the bug in Ubuntu 14.10 by editing the file /etc/network/interfaces to look like the following (complete with bogus manual line). # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback manual eth0 iface eth0 inet dhcp dns-nameservers 1.2.3.4 dns-search maas I do `ifup eth0` and get the following in /etc/resolv.conf (content actually at /run/resolvconf/resolv.conf). # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 1.2.3.4 nameserver 192.168.1.254 search maas mydomain (The nameserver address 192.168.1.254 and search domain mydomain come in via DHCP.) This is exactly what I would expect. The bug must arise from something in your system that differs from mine. AIUI you can still boot Vivid using Upstart. If you boot using Upstart, does the bug still occur? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1432829 Title: resolvconf not updated correctly for interfaces configured in initramfs Status in resolvconf package in Ubuntu: New Bug description: maas images utilize cloud-initramfs-dyn-netconf . The way this works is basically: * /etc/network/interfaces in image is a link to ../../run/network/dynamic-interfaces * kernel command line 'ip=' convince the initramfs to bring up networking using 'ipconfig' example: ip=maas-enlist:BOOTIF * ipconfig writes files in /run/net-*.conf for each interface it configures. * cloud-initramfs-dyn-netconf module writes /run/network/dyanmic-interfaces based on /run/net-*.conf files that 'ipconfig' creates. end result is that after the move to real root, /etc/network/interfaces should be a symlink to /run/ that ends up having something like this: | ## This file is generated by cloud-initramfs-dyn-netconf | auto lo | iface lo inet loopback | manual eth0 | iface eth0 inet dhcp | dns-nameservers 192.168.64.3 | dns-search maas resolvconf seems not to be working as well as it should be. In vivid (now using systemd), I have only the resolvconf header in the file. in all other supported ubuntu releases, doing the above results in functional resolv.conf via resolv.conf. Seen here from trusty: | # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) | # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN | nameserver 192.168.64.3 Related Bugs: * bug 1432821: something deleting /run/network after during boot ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.7 Architecture: amd64 Date: Mon Mar 16 20:42:24 2015 PackageArchitecture: all ProcEnviron: TERM=vt102 PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1432829/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1313392] Re: dnsmasq crashes dhcp/internet connection and uses a lot of cpu
*** This bug is a duplicate of bug 1314697 *** https://bugs.launchpad.net/bugs/1314697 ** This bug has been marked a duplicate of bug 1314697 DNS resolution no longer works; dnsmasq uses 100% CPU -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1313392 Title: dnsmasq crashes dhcp/internet connection and uses a lot of cpu Status in dnsmasq package in Ubuntu: New Bug description: dnsmasq crashes dhcp/internet connection and uses a lot of cpu. One has to use dhclient eth0 or wlan0 as root, to connect to the internet although the LAN is connected between pcs on the local network. Temporary solution is to edit /etc/NetworkManager/NetworkManager.conf by placing # in front of the line: dns=dnsnmasq,in order for network-manager to auto connect to eth0 or wlan0 at login. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: xorg 1:7.7+1ubuntu8 ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 CurrentDesktop: KDE Date: Sun Apr 27 12:41:01 2014 InstallationDate: Installed on 2014-04-11 (15 days ago) InstallationMedia: Kubuntu 14.04 LTS Trusty Tahr - Daily amd64 (20140407) ProcEnviron: LANGUAGE=en_CA:en PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_CA.UTF-8 SHELL=/bin/bash SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1313392/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1416895] Re: /etc/dnsmasq.conf does not contain an ending newline character
Confirmed that the bug affects 2.72-2. $ cat /etc/dnsmasq.conf | tail -n 2 # Include all files in a directory which end in .conf #conf-dir=/etc/dnsmasq.d/*.conf$ od -t c /etc/dnsmasq.conf | tail -n 2 0062620 / * . c o n f 0062627 $ ** Changed in: dnsmasq (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1416895 Title: /etc/dnsmasq.conf does not contain an ending newline character Status in dnsmasq package in Ubuntu: Confirmed Bug description: I'm using Ubuntu 15.04 dev with dnsmasq 2.72-2 and there is no ending newline character in /etc/dnsmasq.conf. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1416895/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1416895] Re: /etc/dnsmasq.conf does not contain an ending newline character
Just checked 2.72-1 and it doesn't seem to have this problem. $ cat /etc/dnsmasq.conf | tail -n 2 #conf-file=/etc/dnsmasq.more.conf #conf-dir=/etc/dnsmasq.d $ od -t c /etc/dnsmasq.conf | tail -n 2 0062320 / e t c / d n s m a s q . d \n 0062337 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1416895 Title: /etc/dnsmasq.conf does not contain an ending newline character Status in dnsmasq package in Ubuntu: Confirmed Bug description: I'm using Ubuntu 15.04 dev with dnsmasq 2.72-2 and there is no ending newline character in /etc/dnsmasq.conf. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1416895/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1414887] Re: dns query from localnetwork ignored
First, as suggested by the author of dnsmasq, the `local-service` should be in the default configuration. However, Ubuntu 14.10 doesn't have that What the man page exactly says is that local-service only has effect i[f] there are no --interface --except-interface, --listen-address or --auth-server options. Here is what I found out how dnsmasq is started in Ubuntu 14.10: /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.1.1 [...] This is not the dnsmasq process started by the dnsmasq package. It is the local forwarding dnsmasq process started by NetworkManager. If your complaint is that the local forwarding dnsmasq process started by NetworkManager doesn't respond to queries coming from the network then the answer is that this process is not supposed to do that. But I don't think that this is your complaint because you said that you didn't have the problem in Ubuntu 13.10. On my machine, the dnsmasq process started by the dnsmasq package looks like this in ps -elf output /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -r /var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old ,.dpkg-new --local-service As no --interface --except-interface, --listen-address or --auth-server option is given, the --local-service option is active. In order to deactivate the local-service feature, I suggest you configure dnsmasq with one of the above mentioned options. ** Changed in: dnsmasq (Ubuntu) Status: New = Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1414887 Title: dns query from localnetwork ignored Status in dnsmasq package in Ubuntu: Incomplete Bug description: Hi, I followed the following to config dnsmasq as DHCP and DNS server http://sfxpt.wordpress.com/2013/11/30/dnsmasq-installation- configuration-5/ It works well till Ubuntu 13.10. However, with Ubuntu 14.10, the dns query from localnetwork will always timeout. The configurations are exactly the same, What could be the problem? From within localnetwork: ~~~ $ dig google.ca ; DiG 9.9.5-4.3-Ubuntu google.ca ;; global options: +cmd ;; connection timed out; no servers could be reached dig @192.168.2.100 maroon ; DiG 9.9.5-4.3-Ubuntu @192.168.2.100 maroon ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ~~~ On the DNS sever itself: ~~~ $ dig google.ca @127.0.0.1 ... ;; ANSWER SECTION: google.ca. 299 IN A 173.194.43.111 ... ;; Query time: 50 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) $ dig @192.168.2.100 maroon ... ;; ANSWER SECTION: maroon. 0 IN A 192.168.2.100 ;; Query time: 1 msec ;; SERVER: 192.168.2.100#53(192.168.2.100) ... ~~~ This is the debug output from dnsmasq log: ~~~ Jan 1 13:26:10 maroon dnsmasq[2833]: reply google.ca is 173.194.43.119 Jan 1 13:26:10 maroon dnsmasq[2833]: reply google.ca is 173.194.43.120 *** DEBUG 2015-01-01 13:26:21-05:00 DEBUG *** Jan 1 13:27:42 maroon dnsmasq[2833]: query[A] maroon from 192.168.2.100 Jan 1 13:27:42 maroon dnsmasq[2833]: /etc/dnsmasq.hosts maroon is 192.168.2.100 *** DEBUG 2015-01-01 13:28:19-05:00 DEBUG *** ~~~ All other dns queries from localnetwork did not generate any log entries. So, because the local dns query work, I think something is blocking the dnsmasq from sending the dns query results back to localnetwork. What could it be? I didn't limit the dnsmasq listen address: ~~~ $ grep listen-address /etc/dnsmasq.conf /etc/dnsmasq.d/* /etc/dnsmasq.conf:#listen-address= ~~~ My /etc/hosts.deny and hosts.allow files are untouched either, and I can ping my DNS server, and ssh into its IP address as well. So I think the blocking is only at the DNS level since other access are just fine. It is not because of iptables rules either: $ sudo iptables-save | wc 0 0 0 I've installed dnsmasq on two different machines, one being freshly installed today, and both of them are showing exactly the same symptom. Again, it only happens to Ubuntu 14.10. It was working well till Ubuntu 13.10 before. I've run out of all the possibilities. What could be the problem? Thanks $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 14.10 Release:14.10 Codename: utopic $ apt-cache policy dnsmasq dnsmasq: Installed: 2.71-1 Candidate: 2.71-1 Version table: *** 2.71-1 0 500 http://us.archive.ubuntu.com/ubuntu/ utopic/universe amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to:
[Touch-packages] [Bug 1414887] Re: dns query from localnetwork are blocked
Ubuntu 13.10 (Saucy) included dnsmasq 2.66 or so. In dnsmasq 2.69 an important change was made which may be the cause of your problem. This change affects Ubuntu 14.10 and later, but not Ubuntu 14.04LTS (Trusty) which shipped with dnsmasq 2.68-1. The change is mentioned in the changelog (quoted below) and it should be obvious how this might be affecting you. Read the new dnsmasq manpage for a longer description of the local-service option. dnsmasq (2.69-1) unstable; urgency=low * New upstream. * Set --local-service. (closes: #732610) This tells dnsmasq to ignore DNS requests that don't come from a local network. It's automatically ignored if --interface --except-interface, --listen-address or --auth-server exist in the configuration, so for most installations, it will have no effect, but for otherwise-unconfigured installations, it stops dnsmasq from being vulnerable to DNS-reflection attacks. -- Simon Kelley si...@thekelleys.org.uk Tue, 4 Feb 2014 16:28:12 + ** Changed in: dnsmasq (Ubuntu) Status: New = Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1414887 Title: dns query from localnetwork are blocked Status in dnsmasq package in Ubuntu: Incomplete Bug description: Hi, I followed the following to config dnsmasq as DHCP and DNS server http://sfxpt.wordpress.com/2013/11/30/dnsmasq-installation- configuration-5/ It works well till Ubuntu 13.10. However, with Ubuntu 14.10, the dns query from localnetwork will always timeout. The configurations are exactly the same, What could be the problem? From within localnetwork: ~~~ $ dig google.ca ; DiG 9.9.5-4.3-Ubuntu google.ca ;; global options: +cmd ;; connection timed out; no servers could be reached dig @192.168.2.100 maroon ; DiG 9.9.5-4.3-Ubuntu @192.168.2.100 maroon ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ~~~ On the DNS sever itself: ~~~ $ dig google.ca @127.0.0.1 ... ;; ANSWER SECTION: google.ca. 299 IN A 173.194.43.111 ... ;; Query time: 50 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) $ dig @192.168.2.100 maroon ... ;; ANSWER SECTION: maroon. 0 IN A 192.168.2.100 ;; Query time: 1 msec ;; SERVER: 192.168.2.100#53(192.168.2.100) ... ~~~ This is the debug output from dnsmasq log: ~~~ Jan 1 13:26:10 maroon dnsmasq[2833]: reply google.ca is 173.194.43.119 Jan 1 13:26:10 maroon dnsmasq[2833]: reply google.ca is 173.194.43.120 *** DEBUG 2015-01-01 13:26:21-05:00 DEBUG *** Jan 1 13:27:42 maroon dnsmasq[2833]: query[A] maroon from 192.168.2.100 Jan 1 13:27:42 maroon dnsmasq[2833]: /etc/dnsmasq.hosts maroon is 192.168.2.100 *** DEBUG 2015-01-01 13:28:19-05:00 DEBUG *** ~~~ All other dns queries from localnetwork did not generate any log entries. So, because the local dns query work, I think something is blocking the dnsmasq from sending the dns query results back to localnetwork. What could it be? I didn't limit the dnsmasq listen address: ~~~ $ grep listen-address /etc/dnsmasq.conf /etc/dnsmasq.d/* /etc/dnsmasq.conf:#listen-address= ~~~ My /etc/hosts.deny and hosts.allow files are untouched either, and I can ping my DNS server, and ssh into its IP address as well. So I think the blocking is only at the DNS level since other access are just fine. It is not because of iptables rules either: $ sudo iptables-save | wc 0 0 0 I've installed dnsmasq on two different machines, one being freshly installed today, and both of them are showing exactly the same symptom. Again, it only happens to Ubuntu 14.10. It was working well till Ubuntu 13.10 before. I've run out of all the possibilities. What could be the problem? Thanks $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 14.10 Release:14.10 Codename: utopic $ apt-cache policy dnsmasq dnsmasq: Installed: 2.71-1 Candidate: 2.71-1 Version table: *** 2.71-1 0 500 http://us.archive.ubuntu.com/ubuntu/ utopic/universe amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1414887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 978356] Re: squid3 gets killed at startup with dnsmasq
** Summary changed: - squid3 gets killed at startup with dnsmasq and no networkmanager + squid3 gets killed at startup with dnsmasq -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/978356 Title: squid3 gets killed at startup with dnsmasq Status in Squid Web Proxy Cache: New Status in dnsmasq package in Ubuntu: Invalid Status in squid3 package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Invalid Status in squid3 source package in Precise: Fix Released Bug description: [ Test case ] This is difficult to test as it is a race condition, however there are multiple users affected. 1. install squid3 on a system which has a system level network connection 2. reboot 3. on bootup, check to see if squid3 is running (service squid3 status). If it is not running, check /var/log/syslog and the system console for a message about squid3 being killed by SIGHUP. 4. Install updated package 5. repeat step 3, If it is running, this *might* be fixed (but as it is a race, there are no guarantees). [ Regression Potential ] This update only touches the upstart job, so it will only affect that. Upstart's respawn code is fairly conservative, and the upstart job is fairly straight forward. Definitely a few reboots with updates installed should prove this update regression-free. - I've 12.04 - 32bit pae, and removed networkmanager (aptitude purge) since I'm using it as a LTSP server. squid3 3.1.19-1ubuntu1, dnsmasq 2.59-4 Linux gnusc 3.2.0-22-generic-pae #35-Ubuntu SMP Tue Apr 3 20:37:36 UTC 2012 i686 athlon i386 GNU/Linux I install dnsmasq and squid3. I've noticed that squid3 was never working at boot. dmesg shows a: root@gs1204:~# dmesg | grep squid [ 20.227964] init: squid3 main process (1310) killed by HUP signal If I remove dnsmasq (aptitude purge) squid has no problem. Don't know if is related to the recent mechanism so resolv.conf is automatically updated by dnsmasq or not. At the moment I've setup the workaround of run squid3 from rc.local, but of course is not a clean solution To manage notifications about this bug go to: https://bugs.launchpad.net/squid/+bug/978356/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1349011] Re: nm-l2tp-service needs exception in ppp ip-up/down scripts
undesirable behavior: all DNS queries go to the VPN nameservers
That is in most cases the *desired* behavior
On today's systems, I don't think so. [...] Ubuntu run a dnsmasq instance...
Rather than overwrite this...
You are right in saying that when there is a local forwarding nameserver
then it should be used (i.e., its address should be listed in
resolv.conf) instead of external nameservers.
Resolvconf is designed to implement this. If a nameserver address is
127.* or ::1 then resolvconf doesn't list any more addresses (provided
the value of the environment variable
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS is 'y'). And if the
interface configurer follows resolvconf conventions and registers the
address using the pattern lo.CONFIGURER then resolvconf's interface
prioritization will cause a 127.* address to be listed first, and thus
listed exclusively.
Unfortunately, in Ubuntu, network-manager does not follow resolvconf
conventions. NetworkManager starts a local forwarding nameserver and
registers its listening address 127.0.1.1 under the record name
NetworkManager instead of the correct lo.NetworkManager.
Consequently NetworkManager's record has a low priority as defined by
/etc/resolvconf/interface-order instead of a high priority. Consequently
nameserver addresses registered by other interface configurers can pre-
empt NetworkManager's local forwarding nameserver address. This is a
longstanding bug in NetworkManager.
Well, if you work at home and connect to an employer's VPN,
what earthly reason is there to send them all your Internet
DNS lookups?
The only reason is that the most commonly used resolver libraries can't
route DNS traffic according to the name looked up; such a library
connects to a single nameserver which is expected to answer all queries.
The idea that the local system should know about multiple nameservers
having different information is foreign to DNS. So in general you want
to configure the resolver to contact the nameserver with the most
complete information.
Having said that, I grant that in the special case where you have a
private network with its own nameservers which have information about a
private (sub)namespace and you have a local forwarding nameserver
capable of routing DNS queries to the appropriate servers based on the
domain then there may be speed and privacy benefits to doing such
routing.
There has to be a better way of handling this than excluding every one
specifically...
If the aforementioned bug were fixed then, in the case where
NetworkManager runs a local forwarding nameserver, it wouldn't do any
harm for PPP to register nameserver addresses with resolvconf because
those addresses would have lower priority than the loopback address in
lo.NetworkManager and wouldn't end up appearing in resolv.conf.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1349011
Title:
nm-l2tp-service needs exception in ppp ip-up/down scripts
Status in resolvconf package in Ubuntu:
Confirmed
Bug description:
There is an actively maintained NetworkManager L2TP VPN plugin,
available as an Ubuntu package here: https://launchpad.net/~seriy-
pr/+archive/ubuntu/network-manager-l2tp. Hopefully it will be a part
of Ubuntu soon.
Like nm-pptp-service, it needs an exception in
/etc/ppp/ip-{up,down}.d/000resolvconf (part of the resolvconf package)
as follows:
% diff /etc/ppp/ip-up.d/000resolvconf
/tmp/resolvconf-1.69ubuntu1.1/debian/resolvconf.000resolvconf.ppp.ip-up
16c16
nm-l2tp-service-*|nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*)
---
nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*)
Since that's how it works for the PPTP plugin, could we add the L2TP
one as well so that it can work out of the box on Ubuntu?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1349011/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1349011] Re: nm-l2tp-service needs exception in ppp ip-up/down scripts
Returning to the main issue...
Could this fix be considered for trusty-updates?
The patch is very simple and applying it involves little risk, so I'd
say yes.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1349011
Title:
nm-l2tp-service needs exception in ppp ip-up/down scripts
Status in resolvconf package in Ubuntu:
Confirmed
Bug description:
There is an actively maintained NetworkManager L2TP VPN plugin,
available as an Ubuntu package here: https://launchpad.net/~seriy-
pr/+archive/ubuntu/network-manager-l2tp. Hopefully it will be a part
of Ubuntu soon.
Like nm-pptp-service, it needs an exception in
/etc/ppp/ip-{up,down}.d/000resolvconf (part of the resolvconf package)
as follows:
% diff /etc/ppp/ip-up.d/000resolvconf
/tmp/resolvconf-1.69ubuntu1.1/debian/resolvconf.000resolvconf.ppp.ip-up
16c16
nm-l2tp-service-*|nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*)
---
nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*)
Since that's how it works for the PPTP plugin, could we add the L2TP
one as well so that it can work out of the box on Ubuntu?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1349011/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1349011] Re: nm-l2tp-service needs exception in ppp ip-up/down scripts
I see that your change has made it to vivid
\o/
undesirable behavior: all DNS queries go to the VPN nameservers
That is in most cases the *desired* behavior, since only the VPN
nameservers have name information about both the VPN and the Internet.
Also, under what circumstances do you not trust the VPN with your DNS
traffic?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1349011
Title:
nm-l2tp-service needs exception in ppp ip-up/down scripts
Status in “resolvconf” package in Ubuntu:
Confirmed
Bug description:
There is an actively maintained NetworkManager L2TP VPN plugin,
available as an Ubuntu package here: https://launchpad.net/~seriy-
pr/+archive/ubuntu/network-manager-l2tp. Hopefully it will be a part
of Ubuntu soon.
Like nm-pptp-service, it needs an exception in
/etc/ppp/ip-{up,down}.d/000resolvconf (part of the resolvconf package)
as follows:
% diff /etc/ppp/ip-up.d/000resolvconf
/tmp/resolvconf-1.69ubuntu1.1/debian/resolvconf.000resolvconf.ppp.ip-up
16c16
nm-l2tp-service-*|nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*)
---
nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*)
Since that's how it works for the PPTP plugin, could we add the L2TP
one as well so that it can work out of the box on Ubuntu?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1349011/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1394081] Re: Add manual options for administrators
*** This bug is a duplicate of bug 1385010 *** https://bugs.launchpad.net/bugs/1385010 did not know I am stepping on your toe here No toes being stepped on here. had to take care of this, so I generate the resolv.conf from a package - no link anymore OK. Leave the resolvconf package installed; remove the symlink. once you ifdown/ifup one of the dhcp interfaces, the resolv.conf got overwritten It's not resolvconf doing that. It was bug #1385010 ... that caused this. Ah, glad you figured it out. I'll merge this report with that one. ** This bug has been marked a duplicate of bug 1385010 Unexpected behavior: make_resolv_conf is not undefined if /etc/resolv.conf is not a symlink -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1394081 Title: Add manual options for administrators Status in “resolvconf” package in Ubuntu: Incomplete Bug description: Currently - trusty LTS - there is no way to turn off the regeneration of /etc/resolv.conf that would survive a package upgrade. - you cannot remove resolvconf as it is needed by minimal - you cannot disable-upgrades as this flag is removed by reboots - if you disable the resolvconf job in upstart package upgrade will reset the disable-upgrade flags - if you hack the scripts - it will only last until the next upgrade There are two ways to ensure that admins willing to turn it off can do so: First solution: add a run=no to /etc/default/resolvconf and bail out if it is set. The second solution is more subtile. In /etc/network/if- up.d/000resolvconf you will find this line: [ -x /sbin/resolvconf ] || exit 0 While in /etc/dhcp/dhclient-enter-hooks.d/resolvconf it says if [ -x /sbin/resolvconf ] [ -L /etc/resolv.conf ]; then Way more clever! So if you do not want to implement the default option, why not check if its a link all the way? So at least a conf gets not overwritten once the admin wrote his own. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1394081/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1394081] Re: Add manual options for administrators
I wrote: The proper way for the admin to stop /etc/resolv.conf from being updated by resolvconf is for him or her to remove the symbolic link /etc/resolv.conf - ../run/resolvconf/resolv.conf. HeinMueck wrote: what you describe as the proper way will not work at all - take a look at /etc/network/if-up.d/000resolvconf. It only checks if /sbin/resolvconf exists and if it is executable. As it does not check for resolv.conf being a symlink it will never stop if it is not. It checks if /sbin/resolvconf exists and is executable and if so it goes ahead and sends information to resolvconf, otherwise aborting. Resolvconf will process the information that has been sent to it and will generally write out a new /run/resolvconf/resolv.conf. However, if /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf then the latter file will not be accessible via the path /etc/resolv.conf and changes to it will therefore have no effect on the resolver. Thus, removing the symbolic link /etc/resolv.conf - ../run/resolvconf/resolv.conf stops resolvconf from updating /etc/resolv.conf, just as I said. Furthermore, the mere presence of /sbin/resolvconf stops most other programs from updating resolv.conf directly because they check for the presence of /sbin/resolvconf and refrain from stomping on /etc/resolv.conf if it is present. (The exception to this rule is dhclient, which updates /etc/resolv.conf even if /sbin/resolvconf is present, if the aforementioned symlink is missing; but I consider that to be an undesirable exception: see bug #1385010.) So the correct way to prevent /etc/resolv.conf from being updated is to leave the resolvconf package installed and to remove the symbolic link /etc/resolv.conf - ../run/resolvconf/resolv.conf. (And (in Ubuntu) to do something additional to stop dhclient from updating the file, e.g., removing the isc-dhcp-client package... but now we are getting off topic.) If this explanation isn't clear to you then it's possible that you are confused about how resolvconf works. In that case I suggest you read the resolvconf package README file at /usr/share/doc/resolvconf/README.gz. If you have a question about how correctly to configure your system(s) in order to obtain a certain desired behavior then please contact me directly. ** Changed in: resolvconf (Ubuntu) Status: New = Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1394081 Title: Add manual options for administrators Status in “resolvconf” package in Ubuntu: Incomplete Bug description: Currently - trusty LTS - there is no way to turn off the regeneration of /etc/resolv.conf that would survive a package upgrade. - you cannot remove resolvconf as it is needed by minimal - you cannot disable-upgrades as this flag is removed by reboots - if you disable the resolvconf job in upstart package upgrade will reset the disable-upgrade flags - if you hack the scripts - it will only last until the next upgrade There are two ways to ensure that admins willing to turn it off can do so: First solution: add a run=no to /etc/default/resolvconf and bail out if it is set. The second solution is more subtile. In /etc/network/if- up.d/000resolvconf you will find this line: [ -x /sbin/resolvconf ] || exit 0 While in /etc/dhcp/dhclient-enter-hooks.d/resolvconf it says if [ -x /sbin/resolvconf ] [ -L /etc/resolv.conf ]; then Way more clever! So if you do not want to implement the default option, why not check if its a link all the way? So at least a conf gets not overwritten once the admin wrote his own. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1394081/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1284607] Re: resolvconf ignores given dns-servers in /etc/network/interfaces
Is dnsmasq getting its DNS server information from resolvconf, which in turn gets it from /etc/network/interfaces? Or, does dnsmasq take what it likes from /etc/network/interfaces directly, discarding the rest? 1. If you have only the dnsmasq-base and network-manager packages installed then a dnsmasq process is run as a slave of NetworkManager and gets its nameserver information exclusively from NetworkManager. This dnsmasq process provides name service exclusively at IP address 127.0.1.1. 2. If you have the dnsmasq package installed then a(nother) dnsmasq process is run independently of NetworkManager. By default this independent dnsmasq service is configured to obtain its nameserver information exclusively from resolvconf which in turn gets nameserver information from interface configuration processes including ifup, whose configuration file is /etc/network/interfaces. The fact that you have no /etc/dnsmasq.conf strongly suggests that you do not have the dnsmasq package installed and so you fall into class #1. Dnsmasq itself never looks in /etc/network/interfaces. To understand how resolvconf works, please consult /usr/share/doc/resolvconf/README.gz . To understand how Ubuntu uses NetworkManager, dnsmasq and resolvconf, please consult https://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/ . ** Changed in: dnsmasq (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1284607 Title: resolvconf ignores given dns-servers in /etc/network/interfaces Status in “dnsmasq” package in Ubuntu: Invalid Status in “resolvconf” package in Ubuntu: Invalid Bug description: resolvconf ignores given dns-servers in /etc/network/interfaces if the interface in question is configured by dhcp: auto em1 iface em1 inet dhcp dns-nameservers 10.161.18.34 10.129.18.34 dns-search xxx.yy the dns-nameservers-line is ignored (it shouldn't), while the dns- search-line is honoured: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search xxx.yy Together with dnsmasq handling name resolution no names other tan local known ones are resolved. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1 ProcVersionSignature: Ubuntu 3.13.0-12.32-generic 3.13.4 Uname: Linux 3.13.0-12-generic x86_64 ApportVersion: 2.13.2-0ubuntu5 Architecture: amd64 Date: Tue Feb 25 12:57:34 2014 InstallationDate: Installed on 2014-01-31 (25 days ago) InstallationMedia: Ubuntu-Server 13.10 Saucy Salamander - Release amd64 (20131016) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: resolvconf UpgradeStatus: Upgraded to trusty on 2014-01-31 (25 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1284607/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1394081] Re: Add manual options for administrators
The proper way for the admin to stop /etc/resolv.conf from being updated by resolvconf is for him or her to remove the symbolic link /etc/resolv.conf - ../run/resolvconf/resolv.conf. The resolvconf program only ever writes to the target of that symlink. Thus, in the absence of that link, resolvconf has no effect on resolv.conf. Yes, Ubuntu's dhclient-enter-hooks.d/resolvconf checks /etc/resolv.conf and stomps on it if no symbolic link is there. That is different from what the Debian version of the script does and is a departure from the Debian convention. That has been complained about in bug #1385010. Can you please describe more fully what you perceive to be the problem? That's not clear to me yet. In advance I will say that it is supposed to be the case that if the admin has removed the symlink at /etc/resolv.conf then upgrading the package does not restore the symlink. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1394081 Title: Add manual options for administrators Status in “resolvconf” package in Ubuntu: New Bug description: Currently - trusty LTS - there is no way to turn off the regeneration of /etc/resolv.conf that would survive a package upgrade. - you cannot remove resolvconf as it is needed by minimal - you cannot disable-upgrades as this flag is removed by reboots - if you disable the resolvconf job in upstart package upgrade will reset the disable-upgrade flags - if you hack the scripts - it will only last until the next upgrade There are two ways to ensure that admins willing to turn it off can do so: First solution: add a run=no to /etc/default/resolvconf and bail out if it is set. The second solution is more subtile. In /etc/network/if- up.d/000resolvconf you will find this line: [ -x /sbin/resolvconf ] || exit 0 While in /etc/dhcp/dhclient-enter-hooks.d/resolvconf it says if [ -x /sbin/resolvconf ] [ -L /etc/resolv.conf ]; then Way more clever! So if you do not want to implement the default option, why not check if its a link all the way? So at least a conf gets not overwritten once the admin wrote his own. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1394081/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384394] Re: /etc/network/interfaces: dns-nameservers entries for bridge br* interfaces are ignored i.e. they are not listed in /etc/resolv.conf when invoking ifup comman
I gather that you want to use the fact that the resolver happens to try one address after another, in the order that they are listed in resolv.conf, as a way of giving precedence of one domain name system (the service provided over the br* interfaces) over another domain name system (the one serving the Internet and accessible by the forwarder on your machine at 127.0.1.1). That's not how DNS or the resolver were meant to be used and hence that is not implemented by the default system configuration. Given your aims, it's up to you to configure /etc/resolvconf/interface-order so that br* is listed before lo*. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1384394 Title: /etc/network/interfaces: dns-nameservers entries for bridge br* interfaces are ignored i.e. they are not listed in /etc/resolv.conf when invoking ifup command Status in “dnsmasq” package in Ubuntu: Triaged Bug description: lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 apt-cache policy resolvconf resolvconf: Installed: 1.69ubuntu1.1 Candidate: 1.69ubuntu1.1 Version table: *** 1.69ubuntu1.1 0 500 http://ch.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 100 /var/lib/dpkg/status 1.69ubuntu1 0 500 http://ch.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages DESCRIPTION: network-manager: My eth0 and wlan0 cards are managed by the network-manager and this works fine. /etc/network/interfaces: My 2 bridges br0 and br1 are managed in /etc/network/interfaces as follows: ... iface br0 inet static address 192.168.10.1 netmask 255.255.255.0 dns-nameservers 192.168.10.2 bridge_ports none bridge_stp off bridge_fd 0 bridge_maxwait 0 iface br1 inet static address 192.168.0.1 netmask 255.255.255.0 dns-nameservers 192.168.0.2 bridge_ports none bridge_stp off bridge_fd 0 bridge_maxwait 0 ... When I now bring up the bridge interfaces using: sudo ifup br0 br1 Then they show up fine in ifconfig. BUT dns-nameservers 192.168.10.2 and dns-nameservers 192.168.0.2 DO NOT show up in /etc/resolv.conf WORKAROUND: Until this has been fixed the following workaround works fine for me: sudo vi /etc/resolvconf/interface-order #Add the following entry (this entry can be put on any line BUT it has to come before the last entry *): ... br* ... * PS: Based on the workaround in /etc/resolvconf/interface-order I think the issue is in package resolvconf otherwise I would have reported the error against the ifupdown scripts. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1384394/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1385010] Re: unexpected behavior: make_resolv_conf not undefined
** Description changed: The resolvconf package comes with /etc/dhcp/dhclient-enter- - hooks.d/resolvconf which convieniently undefines make_resolve_conf - (previously defined by dhclient-script) and calls resolvconf. + hooks.d/resolvconf which, if /sbin/resolvconf is present, undefines + make_resolv_conf() (previously defined by dhclient-script) and calls + resolvconf. However, the hook checks if /etc/resolv.conf is a symlink even though /sbin/resolvconf already handles this. This is problematic because it never undefines the make_resolv_conf function which dhclient-script defines itself. - For me, the expect behavior would be /etc/resolv.conf never changing if - resolvconf is installed and the file is not a symlink. + For me, the expected behavior would be /etc/resolv.conf never changing + if resolvconf is installed and /etc/resolv.conf is not a symlink. At the very least, I think this behavior should be documented in the man pages for resolvconf. Furthermore, debian does not implement this patch and it exists starting in 12.04 until current. As far as I can tell, there's absolutely no reason to check it twice if resolvconf already implements it. It was introduced by: http://bazaar.launchpad.net/~ubuntu- branches/ubuntu/trusty/resolvconf/trusty/revision/32/etc/dhcp/dhclient- enter-hooks.d/resolvconf -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1385010 Title: unexpected behavior: make_resolv_conf not undefined Status in “resolvconf” package in Ubuntu: New Bug description: The resolvconf package comes with /etc/dhcp/dhclient-enter- hooks.d/resolvconf which, if /sbin/resolvconf is present, undefines make_resolv_conf() (previously defined by dhclient-script) and calls resolvconf. However, the hook checks if /etc/resolv.conf is a symlink even though /sbin/resolvconf already handles this. This is problematic because it never undefines the make_resolv_conf function which dhclient-script defines itself. For me, the expected behavior would be /etc/resolv.conf never changing if resolvconf is installed and /etc/resolv.conf is not a symlink. At the very least, I think this behavior should be documented in the man pages for resolvconf. Furthermore, debian does not implement this patch and it exists starting in 12.04 until current. As far as I can tell, there's absolutely no reason to check it twice if resolvconf already implements it. It was introduced by: http://bazaar.launchpad.net/~ubuntu- branches/ubuntu/trusty/resolvconf/trusty/revision/32/etc/dhcp /dhclient-enter-hooks.d/resolvconf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1385010/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
