[Touch-packages] [Bug 1680811] Re: Request to add wireguard interface to interface-order

2017-04-08 Thread Thomas Hood
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

2017-02-20 Thread Thomas Hood
** 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

2017-02-19 Thread Thomas Hood
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

2017-02-19 Thread Thomas Hood
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

2017-02-14 Thread Thomas Hood
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

2017-02-13 Thread Thomas Hood
** 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

2017-02-13 Thread Thomas Hood
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

2017-02-13 Thread Thomas Hood
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

2016-12-28 Thread Thomas Hood
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

2016-12-27 Thread Thomas Hood
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

2016-11-04 Thread Thomas Hood
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

2016-11-04 Thread Thomas Hood
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

2016-10-29 Thread Thomas Hood
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

2016-10-29 Thread Thomas Hood
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

2016-10-29 Thread Thomas Hood
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

2016-10-29 Thread Thomas Hood
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

2016-10-21 Thread Thomas Hood
** 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

2016-09-29 Thread Thomas Hood
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

2016-09-28 Thread Thomas Hood
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

2016-09-28 Thread Thomas Hood
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

2016-08-24 Thread Thomas Hood
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

2016-06-17 Thread Thomas Hood
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

2016-05-08 Thread Thomas Hood
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

2016-05-08 Thread Thomas Hood
** 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

2016-05-06 Thread Thomas Hood
** 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

2016-04-28 Thread Thomas Hood
*** 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

2016-04-27 Thread Thomas Hood
*** 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

2016-04-27 Thread Thomas Hood
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

2016-04-27 Thread Thomas Hood
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

2016-04-27 Thread Thomas Hood
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

2016-04-27 Thread Thomas Hood
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

2016-04-25 Thread Thomas Hood
*** 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

2016-04-12 Thread Thomas Hood
** 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

2016-03-10 Thread Thomas Hood
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

2016-02-17 Thread Thomas Hood
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

2016-01-16 Thread Thomas Hood
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

2016-01-15 Thread Thomas Hood
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

2016-01-06 Thread Thomas Hood
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

2015-12-13 Thread Thomas Hood
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

2015-11-15 Thread Thomas Hood
** 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

2015-10-06 Thread Thomas Hood
*** 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

2015-09-21 Thread Thomas Hood
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

2015-09-12 Thread Thomas Hood
** 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

2015-08-16 Thread Thomas Hood
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

2015-07-13 Thread Thomas Hood
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

2015-07-13 Thread Thomas Hood
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

2015-07-12 Thread Thomas Hood
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

2015-07-09 Thread Thomas Hood
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

2015-06-19 Thread Thomas Hood
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

2015-06-18 Thread Thomas Hood
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

2015-06-05 Thread Thomas Hood
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

2015-06-05 Thread Thomas Hood
** 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

2015-06-05 Thread Thomas Hood
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

2015-06-05 Thread Thomas Hood
 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)

2015-06-05 Thread Thomas Hood
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

2015-06-02 Thread Thomas Hood
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

2015-06-01 Thread Thomas Hood
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

2015-06-01 Thread Thomas Hood
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

2015-06-01 Thread Thomas Hood
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

2015-06-01 Thread Thomas Hood
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

2015-06-01 Thread Thomas Hood
** 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

2015-06-01 Thread Thomas Hood
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

2015-06-01 Thread Thomas Hood
@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

2015-06-01 Thread Thomas Hood
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

2015-06-01 Thread Thomas Hood
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

2015-06-01 Thread Thomas Hood
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

2015-06-01 Thread Thomas Hood
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

2015-06-01 Thread Thomas Hood
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

2015-06-01 Thread Thomas Hood
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

2015-05-31 Thread Thomas Hood
@Martin: Ubuntu resolvconf 1.76.1ubuntu2 includes the trigger-sending
and trigger-processing section at the end of the postinst but fails to
include the debian/triggers file from Debian. Without this file the
resolvconf package doesn't register an interest in the trigger
resolvconf-enable-updates.

-- 
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

2015-05-31 Thread Thomas Hood
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

2015-05-28 Thread Thomas Hood
@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

2015-05-27 Thread Thomas Hood
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

2015-05-27 Thread Thomas Hood
@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

2015-05-27 Thread Thomas Hood
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

2015-04-27 Thread Thomas Hood
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

2015-04-24 Thread Thomas Hood
** 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

2015-04-21 Thread Thomas Hood
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

2015-04-21 Thread Thomas Hood
** 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

2015-04-21 Thread Thomas Hood
** 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

2015-04-21 Thread Thomas Hood
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

2015-04-21 Thread Thomas Hood
** 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

2015-04-21 Thread Thomas Hood
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

2015-03-19 Thread Thomas Hood
** 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

2015-03-17 Thread Thomas Hood
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

2015-03-17 Thread Thomas Hood
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

2015-02-20 Thread Thomas Hood
*** 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

2015-02-01 Thread Thomas Hood
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

2015-02-01 Thread Thomas Hood
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

2015-01-31 Thread Thomas Hood
 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

2015-01-29 Thread Thomas Hood
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

2014-12-11 Thread Thomas Hood
** 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

2014-11-28 Thread Thomas Hood
 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

2014-11-28 Thread Thomas Hood
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

2014-11-27 Thread Thomas Hood
 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

2014-11-27 Thread Thomas Hood
*** 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

2014-11-21 Thread Thomas Hood
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

2014-11-21 Thread Thomas Hood
 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

2014-11-20 Thread Thomas Hood
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

2014-11-14 Thread Thomas Hood
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


  1   2   >