[Touch-packages] [Bug 1858883] Re: date utility format unexpectedly changed after upgrade from bionic to focal

[Mike Pontillo]

Thanks for taking a look. Yes, it looks like the `date` utility now
observes locale-based defaults, such as the new default:

$ date
Wed 25 Mar 2020 09:47:47 AM PDT

Here are some other combinations I tried:

$ LC_TIME="" date
Wed 25 Mar 2020 09:47:53 AM PDT

(setting LC_TIME to an empty string has no effect; the LC_TIME value
most likely obtains a default value based on a different setting.)

The following variations produce the (formerly, at least) expected
output:

$ LC_TIME="C" date
Wed Mar 25 09:47:59 PDT 2020

$ LC_ALL="C" date
Wed Mar 25 09:48:25 PDT 2020

$ LANG="C" date
Wed Mar 25 09:52:08 PDT 2020

This post suggests that LC_ALL should be set to C if the output of these
utilities is meant to be read by computers:

https://unix.stackexchange.com/a/87763/4295

So while this new default does have the potential to cause regressions
in users' scripts (and could be considered a regression in that sense),
the fix is to correctly set LC_ALL=C in when the `date` utility is
invoked in situations where its output is intended to be parsed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1858883

Title:
  date utility format unexpectedly changed after upgrade from bionic to
  focal

Status in coreutils package in Ubuntu:
  New

Bug description:
  After upgrading my Bionic system to Focal, I noticed a significant
  change in the output of the `date` utility. This could potentially
  cause regressions for those who are relying on a consistent date
  format when using `date` in shell scripts.

  EXPECTED BEHAVIOR
  =

  I expected to see the same date format that can be seen on Ubuntu
  releases (at least) from Trusty through Bionic:

  $ date -u
  Wed Jan  8 21:00:14 UTC 2020

  ACTUAL BEHAVIOR
  ===

  On Focal (and Eoan) the following date format is seen by default:

  $ date -u
  Wed 08 Jan 2020 09:00:14 PM UTC

  Note the differences in zero-padding, whitespace, placement of the
  year, and the extraneous "PM" (I had expected to see a 24-hour time).

  FURTHER DETAILS
  ===

  This machine was originally on Bionic and has been upgraded to
  development releases between Bionic and Focal.

  $ locale
  LANG=en_US.UTF-8
  LANGUAGE=
  LC_CTYPE="en_US.UTF-8"
  LC_NUMERIC="en_US.UTF-8"
  LC_TIME="en_US.UTF-8"
  LC_COLLATE="en_US.UTF-8"
  LC_MONETARY="en_US.UTF-8"
  LC_MESSAGES="en_US.UTF-8"
  LC_PAPER="en_US.UTF-8"
  LC_NAME="en_US.UTF-8"
  LC_ADDRESS="en_US.UTF-8"
  LC_TELEPHONE="en_US.UTF-8"
  LC_MEASUREMENT="en_US.UTF-8"
  LC_IDENTIFICATION="en_US.UTF-8"
  LC_ALL=

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1858883/+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 1858883] [NEW] date utility format unexpectedly changed after upgrade from bionic to focal

[Mike Pontillo]

Public bug reported:

After upgrading my Bionic system to Focal, I noticed a significant
change in the output of the `date` utility. This could potentially cause
regressions for those who are relying on a consistent date format when
using `date` in shell scripts.

EXPECTED BEHAVIOR
=

I expected to see the same date format that can be seen on Ubuntu
releases (at least) from Trusty through Bionic:

$ date -u
Wed Jan  8 21:00:14 UTC 2020

ACTUAL BEHAVIOR
===

On Focal (and Eoan) the following date format is seen by default:

$ date -u
Wed 08 Jan 2020 09:00:14 PM UTC

Note the differences in zero-padding, whitespace, placement of the year,
and the extraneous "PM" (I had expected to see a 24-hour time).

FURTHER DETAILS
===

This machine was originally on Bionic and has been upgraded to
development releases between Bionic and Focal.

$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

** Affects: coreutils (Ubuntu)
 Importance: Undecided
 Status: New

** Attachment added: "ubuntu-bug.txt"
   
https://bugs.launchpad.net/bugs/1858883/+attachment/5318665/+files/ubuntu-bug.txt

** Description changed:

  After upgrading my Bionic system to Focal, I noticed a significant
  change in the output of the `date` utility. This could potentially cause
  regressions for those who are relying on a consistent date format when
  using `date` in shell scripts.
  
- 
  EXPECTED BEHAVIOR
  =
  
- The date format seen below can be seen on Ubuntu releases from Trusty
- through Bionic:
+ I expected to see the same date format that can be seen on Ubuntu
+ releases (at least) from Trusty through Bionic:
  
  $ date -u
  Wed Jan  8 21:00:14 UTC 2020
- 
  
  ACTUAL BEHAVIOR
  ===
  
  On Focal (and Eoan) the following date format is seen by default:
  
  $ date -u
  Wed 08 Jan 2020 09:00:14 PM UTC
  
  Note the differences in zero-padding, whitespace, placement of the year,
  and the extraneous "PM" (I had expected to see a 24-hour time).
- 
  
  FURTHER DETAILS
  ===
  
  This machine was originally on Bionic and has been upgraded to
  development releases between Bionic and Focal.
  
  $ locale
  LANG=en_US.UTF-8
  LANGUAGE=
  LC_CTYPE="en_US.UTF-8"
  LC_NUMERIC="en_US.UTF-8"
  LC_TIME="en_US.UTF-8"
  LC_COLLATE="en_US.UTF-8"
  LC_MONETARY="en_US.UTF-8"
  LC_MESSAGES="en_US.UTF-8"
  LC_PAPER="en_US.UTF-8"
  LC_NAME="en_US.UTF-8"
  LC_ADDRESS="en_US.UTF-8"
  LC_TELEPHONE="en_US.UTF-8"
  LC_MEASUREMENT="en_US.UTF-8"
  LC_IDENTIFICATION="en_US.UTF-8"
  LC_ALL=

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1858883

Title:
  date utility format unexpectedly changed after upgrade from bionic to
  focal

Status in coreutils package in Ubuntu:
  New

Bug description:
  After upgrading my Bionic system to Focal, I noticed a significant
  change in the output of the `date` utility. This could potentially
  cause regressions for those who are relying on a consistent date
  format when using `date` in shell scripts.

  EXPECTED BEHAVIOR
  =

  I expected to see the same date format that can be seen on Ubuntu
  releases (at least) from Trusty through Bionic:

  $ date -u
  Wed Jan  8 21:00:14 UTC 2020

  ACTUAL BEHAVIOR
  ===

  On Focal (and Eoan) the following date format is seen by default:

  $ date -u
  Wed 08 Jan 2020 09:00:14 PM UTC

  Note the differences in zero-padding, whitespace, placement of the
  year, and the extraneous "PM" (I had expected to see a 24-hour time).

  FURTHER DETAILS
  ===

  This machine was originally on Bionic and has been upgraded to
  development releases between Bionic and Focal.

  $ locale
  LANG=en_US.UTF-8
  LANGUAGE=
  LC_CTYPE="en_US.UTF-8"
  LC_NUMERIC="en_US.UTF-8"
  LC_TIME="en_US.UTF-8"
  LC_COLLATE="en_US.UTF-8"
  LC_MONETARY="en_US.UTF-8"
  LC_MESSAGES="en_US.UTF-8"
  LC_PAPER="en_US.UTF-8"
  LC_NAME="en_US.UTF-8"
  LC_ADDRESS="en_US.UTF-8"
  LC_TELEPHONE="en_US.UTF-8"
  LC_MEASUREMENT="en_US.UTF-8"
  LC_IDENTIFICATION="en_US.UTF-8"
  LC_ALL=

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1858883/+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 1779767] [NEW] Default cron PATH does not include /snap/bin

[Mike Pontillo]

Public bug reported:

I recently changed from a .deb install of LXD to a snap, and was
surprised that one of my crontab scripts stopped working.

I see that $PATH in a cron script only contains "/usr/bin:/bin", whereas
my default shell also includes "/snap/bin".

It seems to me that for the best user experience with snaps, "/snap/bin"
should be part of the default $PATH in cron.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: cron 3.0pl1-128.1ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_40 
kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_39 
livepatch_livepatch_Ubuntu_4_15_0_20_21_generic_ zfs zunicode zavl icp zcommon 
znvpair
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon Jul  2 14:30:06 2018
InstallationDate: Installed on 2017-12-20 (194 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20171219)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: cron
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: cron (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic

** Description changed:

- I recently change from a .deb install of LXD to a snap, and was
+ I recently changed from a .deb install of LXD to a snap, and was
  surprised that one of my crontab scripts stopped working.
  
  I see that $PATH in a cron script only contains "/usr/bin:/bin", whereas
  my default shell also includes "/snap/bin".
  
  It seems to me that for the best user experience with snaps, "/snap/bin"
  should be part of the default $PATH in cron.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cron 3.0pl1-128.1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_40 
kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_39 
livepatch_livepatch_Ubuntu_4_15_0_20_21_generic_ zfs zunicode zavl icp zcommon 
znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Jul  2 14:30:06 2018
  InstallationDate: Installed on 2017-12-20 (194 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20171219)
  ProcEnviron:
-  TERM=xterm-256color
-  PATH=(custom, no user)
-  XDG_RUNTIME_DIR=
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
+  TERM=xterm-256color
+  PATH=(custom, no user)
+  XDG_RUNTIME_DIR=
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
  SourcePackage: cron
  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 cron in Ubuntu.
https://bugs.launchpad.net/bugs/1779767

Title:
  Default cron PATH does not include /snap/bin

Status in cron package in Ubuntu:
  New

Bug description:
  I recently changed from a .deb install of LXD to a snap, and was
  surprised that one of my crontab scripts stopped working.

  I see that $PATH in a cron script only contains "/usr/bin:/bin",
  whereas my default shell also includes "/snap/bin".

  It seems to me that for the best user experience with snaps,
  "/snap/bin" should be part of the default $PATH in cron.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cron 3.0pl1-128.1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_40 
kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_39 
livepatch_livepatch_Ubuntu_4_15_0_20_21_generic_ zfs zunicode zavl icp zcommon 
znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Jul  2 14:30:06 2018
  InstallationDate: Installed on 2017-12-20 (194 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20171219)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: cron
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1779767/+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 1763534] Re: ifconfig -s (or -a -s) only outputs 8 characters of the interface name, when interfaces are 10+ characters.

[Mike Pontillo]

Note: if you are using a Xenial based MAAS that has not been patched to
use `ip` instead, and you use it to commission on Bionic, it will fail
due to this issue.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to net-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1763534

Title:
  ifconfig -s (or -a -s) only outputs 8 characters of the interface
  name, when interfaces are 10+ characters.

Status in net-tools package in Ubuntu:
  Confirmed
Status in net-tools source package in Bionic:
  Confirmed

Bug description:
  When executing ifconfig, it outputs the whole 10 characters of the
  interface name. However, when using ifconfig -s (or ifconfig -a -s) it
  doesn't include all the name of the interface (or 10+ characters).
  Instead, it outputs only 8 characters of the interface.

  ubuntu@dradis:~$ ifconfig -a
  enP2p1s0f0: flags=4163  mtu 1500
  inet 10.245.71.108  netmask 255.255.248.0  broadcast 10.245.71.255
  inet6 fe80::ae1f:6bff:fe09:c052  prefixlen 64  scopeid 0x20
  ether ac:1f:6b:09:c0:52  txqueuelen 1000  (Ethernet)
  RX packets 154570  bytes 229998298 (229.9 MB)
  RX errors 0  dropped 0  overruns 0  frame 0
  TX packets 61080  bytes 6131460 (6.1 MB)
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

  enP2p1s0f1: flags=4098  mtu 1500
  ether ac:1f:6b:09:c0:53  txqueuelen 1000  (Ethernet)
  RX packets 0  bytes 0 (0.0 B)
  RX errors 0  dropped 0  overruns 0  frame 0
  TX packets 0  bytes 0 (0.0 B)
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

  
  ubuntu@dradis:~$ ifconfig -a -s
  Iface  MTURX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR Flg
  enP2p1s0  1500   154607  0  0 0 61101  0  0  0 
BMRU
  enP2p1s0  15000  0  0 0 0  0  0  0 BM

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/1763534/+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 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Mike Pontillo]

We discussed this today and decided that the proper place to fix this is
not in MAAS; the v1 YAML containing global DNS servers should be
converted to equivalent valid Netplan (using a heuristic).

Alternatively, global DNS could be added to the Netplan schema (possibly
as a shortcut to apply configuration to a group of interfaces).

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

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Triaged
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
  address 10.90.90.162/24
  gateway 10.90.90.1
  mtu 1500
  ubuntu@node05:~$ 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 10.90.90.1
  search maaslab maas

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1750884/+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 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Mike Pontillo]

** Changed in: maas
   Status: Triaged => Won't Fix

** Changed in: maas
 Assignee: Mike Pontillo (mpontillo) => (unassigned)

** Changed in: maas
Milestone: 2.4.0alpha2 => None

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

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Triaged
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
  address 10.90.90.162/24
  gateway 10.90.90.1
  mtu 1500
  ubuntu@node05:~$ 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 10.90.90.1
  search maaslab maas

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1750884/+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 1752737] Re: [2.3.0-6434] mDNS observer problems

[Mike Pontillo]

** Also affects: avahi via
   https://github.com/lathiat/avahi/issues/169
   Importance: Unknown
   Status: Unknown

** Also affects: avahi (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1752737

Title:
  [2.3.0-6434] mDNS observer problems

Status in Avahi:
  Unknown
Status in MAAS:
  Triaged
Status in avahi package in Ubuntu:
  New

Bug description:
  I see avahi-browser choking on non-utf8 characters in my rackd.log:

  ==> rackd.log <==
  2018-02-28 16:54:33 provisioningserver.utils.services: [info] mDNS 
observation process started.
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
Traceback (most recent call last):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 87, in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 83, in main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
run()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 52, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
from provisioningserver.__main__ import main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/__main__.py", line 55, 
in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
91, in __call__
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
self.execute(argv)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
86, in execute
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
args.handler.run(args)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
221, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
_observe_mdns(reader, output, args.verbose)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
145, in _observe_mdns
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in observer(events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
161, in _observe_resolver_found
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in filter(_p_resolver_found, events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
125, in _extract_mdns_events
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in map(parse_avahi_event, lines):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3.5/codecs.py", line 321, in decode
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
(result, consumed) = self._buffer_decode(data, self.errors, final)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 240: 
invalid continuation byte
  2018-02-28 16:54:36 provisioningserver.utils.services: [critical] mDNS 
observation process failed.

  Traceback (most recent call last):
  Failure: twisted.internet.error.ProcessTerminated: A process has ended with a 
probable error condition: process ended with exit code 1.

  ==> regiond.log <==
  2018-02-28 16:54:50 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)
  2018-02-28 16:55:20 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)

  ==> maas.log <==
  Feb 28 16:53:52 MAAS-RC01 maas.interface: [info] ens33 (physical) on 
MAAS-RC01: New MAC, IP binding observed: 08:eb:74:ca:d3:6f, 192.168.1.82

  Similar traceback when running from command line:

  maasuser@MAAS-RC01:~$ maas-rack observe-mdns
  {"hostname": "Apple-TV", "interface": "ens33", "address": "192.168.1.81"}
  Got SIGTERM, quitting.
  Traceback (most recent

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Mike Pontillo]

I don't want to change the v1 YAML in MAAS to output per-interface DNS,
because this risks causing a change of behavior in pre-netplan
deployments. It seems this is necessary in Netplan, but it isn't clear
to me that this is correct. I think it's valuable to take a step back
and look at the requirements here. With DNS resolution being a system-
wide function, is it really correct for it to be associated with a
particular interface? If I think about the user stories, it's:

 - I want to use a specific DNS server to resolve DNS names for a particular 
forward or reverse domain.
 - I want the set of configured DNS servers to be symmetrical with enabled 
interfaces. (In other words, if I have a DMZ interface and an internal 
interface, I might want queries for *.example.com to hit 10.0.0.2, but I want 
queries for anything else to hit 8.8.8.8.)

Somewhat of a tangent here, but don't like search lists. That just makes
DNS names ambiguous. If my search list is 'example.com', now when I type
"foo.com", the resolver has to decide whether I meant
"foo.com.example.com" or just plain "foo.com". I don't want a /search/
list. I want a /match/ list. (But that sounds like a separate bug.)

Back to the current problem: if we blindly configure global default DNS
servers on interfaces that can't reach them, we risk that resolvconf
will calculate an incorrect global configuration. That is, the MAAS
administrator might have expected that the per-interface configuration
take precedence over the default configuration. Would having default
configuration inside an interface cause it to take priority?

Then again, I'm not entirely clear on what the expected behavior is
here, even for the v1 YAML. If I specify global DNS servers *and* per-
interface DNS servers (for a subset of interfaces), is there an
unambiguous way to render that in /e/n/i?

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

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Triaged
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disabl

[Touch-packages] [Bug 1744015] Re: [bionic] Locating necessary Network Manager plugins (for example, OpenVPN) is not a good experience

[Mike Pontillo]

** Summary changed:

- [bionic] Installing network-manager-openvpn is not enough to add OpenVPN 
options to the connection editor
+ [bionic] Locating necessary Network Manager plugins (for example, OpenVPN) is 
not a good experience

** Description changed:

  Steps to reproduce:
  
  (0) Install Bionic desktop
  (1) Observe that only PPTP connection type is available when adding a VPN in 
the UI (using any method).
  (2) Run `sudo apt-get install network-manager-openvpn`.
  (3) Observe that in the top panel "VPN Settings" option, clicking the "+" 
next to "VPN" does not reveal any new VPN type options.
  (4) Run `nm-connection-editor` from the command-line, and observe that not 
only is there no option to add an OpenVPN connection, but in addition, the 
following message is printed on the console:
  
  ** Message: vpn: (openvpn,/usr/lib/NetworkManager/VPN/nm-openvpn-
  service.name) file "libnm-vpn-plugin-openvpn.so" not found. Did you
  install the client package?
+ 
+ Installing `network-manager-openvpn-gnome` seems to do the right thing,
+ but the process of finding what should be installed isn't obvious to the
+ user.

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

Title:
  [bionic] Locating necessary Network Manager plugins (for example,
  OpenVPN) is not a good experience

Status in network-manager package in Ubuntu:
  New

Bug description:
  Steps to reproduce:

  (0) Install Bionic desktop
  (1) Observe that only PPTP connection type is available when adding a VPN in 
the UI (using any method).
  (2) Run `sudo apt-get install network-manager-openvpn`.
  (3) Observe that in the top panel "VPN Settings" option, clicking the "+" 
next to "VPN" does not reveal any new VPN type options.
  (4) Run `nm-connection-editor` from the command-line, and observe that not 
only is there no option to add an OpenVPN connection, but in addition, the 
following message is printed on the console:

  ** Message: vpn: (openvpn,/usr/lib/NetworkManager/VPN/nm-openvpn-
  service.name) file "libnm-vpn-plugin-openvpn.so" not found. Did you
  install the client package?

  Installing `network-manager-openvpn-gnome` seems to do the right
  thing, but the process of finding what should be installed isn't
  obvious to the user.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1744015/+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 1744015] Re: [bionic] Installing network-manager-openvpn is not enough to add OpenVPN options to the connection editor

[Mike Pontillo]

IMHO, it would be nice if the Desktop install supported all the VPN
plugins out-of-the-box. Users shouldn't need to hunt for plugin packages
to install.

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

Title:
  [bionic] Locating necessary Network Manager plugins (for example,
  OpenVPN) is not a good experience

Status in network-manager package in Ubuntu:
  New

Bug description:
  Steps to reproduce:

  (0) Install Bionic desktop
  (1) Observe that only PPTP connection type is available when adding a VPN in 
the UI (using any method).
  (2) Run `sudo apt-get install network-manager-openvpn`.
  (3) Observe that in the top panel "VPN Settings" option, clicking the "+" 
next to "VPN" does not reveal any new VPN type options.
  (4) Run `nm-connection-editor` from the command-line, and observe that not 
only is there no option to add an OpenVPN connection, but in addition, the 
following message is printed on the console:

  ** Message: vpn: (openvpn,/usr/lib/NetworkManager/VPN/nm-openvpn-
  service.name) file "libnm-vpn-plugin-openvpn.so" not found. Did you
  install the client package?

  Installing `network-manager-openvpn-gnome` seems to do the right
  thing, but the process of finding what should be installed isn't
  obvious to the user.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1744015/+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 1744015] [NEW] [bionic] Locating necessary Network Manager plugins (for example, OpenVPN) is not a good experience

[Mike Pontillo]

Public bug reported:

Steps to reproduce:

(0) Install Bionic desktop
(1) Observe that only PPTP connection type is available when adding a VPN in 
the UI (using any method).
(2) Run `sudo apt-get install network-manager-openvpn`.
(3) Observe that in the top panel "VPN Settings" option, clicking the "+" next 
to "VPN" does not reveal any new VPN type options.
(4) Run `nm-connection-editor` from the command-line, and observe that not only 
is there no option to add an OpenVPN connection, but in addition, the following 
message is printed on the console:

** Message: vpn: (openvpn,/usr/lib/NetworkManager/VPN/nm-openvpn-
service.name) file "libnm-vpn-plugin-openvpn.so" not found. Did you
install the client package?

Installing `network-manager-openvpn-gnome` seems to do the right thing,
but the process of finding what should be installed isn't obvious to the
user.

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New

** Description changed:

  Steps to reproduce:
  
  (0) Install Bionic desktop
  (1) Observe that only PPTP connection type is available when adding a VPN in 
the UI (using any method).
  (2) Run `sudo apt-get install network-manager-openvpn`.
  (3) Observe that in the top panel "VPN Settings" option, clicking the "+" 
next to "VPN" does not reveal any new VPN type options.
- (4) Run `nm-connection-editor` from the command-line, and observe that not 
only is there no option to add an OpenVPN connection, but in addition, the 
following message is printed on the console
+ (4) Run `nm-connection-editor` from the command-line, and observe that not 
only is there no option to add an OpenVPN connection, but in addition, the 
following message is printed on the console:
  
  ** Message: vpn: (openvpn,/usr/lib/NetworkManager/VPN/nm-openvpn-
  service.name) file "libnm-vpn-plugin-openvpn.so" not found. Did you
  install the client package?

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

Title:
  [bionic] Locating necessary Network Manager plugins (for example,
  OpenVPN) is not a good experience

Status in network-manager package in Ubuntu:
  New

Bug description:
  Steps to reproduce:

  (0) Install Bionic desktop
  (1) Observe that only PPTP connection type is available when adding a VPN in 
the UI (using any method).
  (2) Run `sudo apt-get install network-manager-openvpn`.
  (3) Observe that in the top panel "VPN Settings" option, clicking the "+" 
next to "VPN" does not reveal any new VPN type options.
  (4) Run `nm-connection-editor` from the command-line, and observe that not 
only is there no option to add an OpenVPN connection, but in addition, the 
following message is printed on the console:

  ** Message: vpn: (openvpn,/usr/lib/NetworkManager/VPN/nm-openvpn-
  service.name) file "libnm-vpn-plugin-openvpn.so" not found. Did you
  install the client package?

  Installing `network-manager-openvpn-gnome` seems to do the right
  thing, but the process of finding what should be installed isn't
  obvious to the user.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1744015/+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 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

[Mike Pontillo]

Workaround:

grep -q 'LLMNR=no' /etc/systemd/resolved.conf || \
echo 'LLMNR=no' | sudo tee -a /etc/systemd/resolved.conf
sudo service systemd-networkd restart

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

Title:
  Regression in getaddrinfo(): calls block for much longer on Bionic
  (compared to Xenial)

Status in glibc package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  When testing MAAS on Bionic, we noticed sluggish performance that we
  could not immediately explain.

  After comparing the results from a run of the test suite on Xenial to
  a run on Bionic, we determined that the slowdowns had to do with DNS
  lookups. In particular, if MAAS attempts to resolve a hostname using
  getaddrinfo() and the call fails, on Xenial the negative result is
  returned in a fraction of a second. On Bionic, the negative result is
  returned in ~1.6 seconds, according to some measures.

  ### To run the test ###

  git clone https://github.com/mpontillo/test-getaddrinfo
  cd test-getaddrinfo
  make

  ### Results on Xenial ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Success
  getaddrinfo() return value: -2 (Name or service not known)

  real  0m0.015s
  user  0m0.000s
  sys   0m0.000s

  ### Results on Bionic ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Resource temporarily unavailable
  getaddrinfo() return value: -3 (Temporary failure in name resolution)

  real  0m1.609s
  user  0m0.004s
  sys   0m0.000s

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

[Mike Pontillo]

Interesting; the first thing I tried when triaging this was to edit
/etc/nsswitch.conf as follows:

# hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
hosts:  files dns

... to eliminate the possibility that it was multicast DNS causing the
slowdown. But it appears I'm behind the times. ;-) (And didn't this only
affect the .local domain?)

Does this mean there are now two subsystems responsible for link-local
address resolution? (avahi and systemd-resolved?)

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

Title:
  Regression in getaddrinfo(): calls block for much longer on Bionic
  (compared to Xenial)

Status in glibc package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  When testing MAAS on Bionic, we noticed sluggish performance that we
  could not immediately explain.

  After comparing the results from a run of the test suite on Xenial to
  a run on Bionic, we determined that the slowdowns had to do with DNS
  lookups. In particular, if MAAS attempts to resolve a hostname using
  getaddrinfo() and the call fails, on Xenial the negative result is
  returned in a fraction of a second. On Bionic, the negative result is
  returned in ~1.6 seconds, according to some measures.

  ### To run the test ###

  git clone https://github.com/mpontillo/test-getaddrinfo
  cd test-getaddrinfo
  make

  ### Results on Xenial ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Success
  getaddrinfo() return value: -2 (Name or service not known)

  real  0m0.015s
  user  0m0.000s
  sys   0m0.000s

  ### Results on Bionic ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Resource temporarily unavailable
  getaddrinfo() return value: -3 (Temporary failure in name resolution)

  real  0m1.609s
  user  0m0.004s
  sys   0m0.000s

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

[Mike Pontillo]

** Tags added: bionic

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

Title:
  Regression in getaddrinfo(): calls block for much longer on Bionic
  (compared to Xenial)

Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  New

Bug description:
  When testing MAAS on Bionic, we noticed sluggish performance that we
  could not immediately explain.

  After comparing the results from a run of the test suite on Xenial to
  a run on Bionic, we determined that the slowdowns had to do with DNS
  lookups. In particular, if MAAS attempts to resolve a hostname using
  getaddrinfo() and the call fails, on Xenial the negative result is
  returned in a fraction of a second. On Bionic, the negative result is
  returned in ~1.6 seconds, according to some measures.

  ### To run the test ###

  git clone https://github.com/mpontillo/test-getaddrinfo
  cd test-getaddrinfo
  make

  ### Results on Xenial ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Success
  getaddrinfo() return value: -2 (Name or service not known)

  real  0m0.015s
  user  0m0.000s
  sys   0m0.000s

  ### Results on Bionic ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Resource temporarily unavailable
  getaddrinfo() return value: -3 (Temporary failure in name resolution)

  real  0m1.609s
  user  0m0.004s
  sys   0m0.000s

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

[Mike Pontillo]

** Description changed:

  When testing MAAS on Bionic, we noticed sluggish performance that we
  could not immediately explain.
  
  After comparing the results from a run of the test suite on Xenial to a
  run on Bionic, we determined that the slowdowns had to do with DNS
  lookups. In particular, if MAAS attempts to resolve a hostname using
  getaddrinfo() and the call fails, on Xenial the negative result is
  returned in a fraction of a second. On Bionic, the negative result is
  returned in ~1.6 seconds, according to some measures.
  
  ### To run the test ###
  
  git clone https://github.com/mpontillo/test-getaddrinfo
  cd test-getaddrinfo
  make
  
- 
  ### Results on Xenial ###
- time ./test not-a-real-hostname
+ $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
- getaddrinfo errno: Success
- getaddrinfo() return value: -2 (Name or service not known)
+ getaddrinfo errno: Success
+ getaddrinfo() return value: -2 (Name or service not known)
  
  real  0m0.015s
  user  0m0.000s
  sys   0m0.000s
  
- 
  ### Results on Bionic ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
- getaddrinfo errno: Resource temporarily unavailable
- getaddrinfo() return value: -3 (Temporary failure in name resolution)
+ getaddrinfo errno: Resource temporarily unavailable
+ getaddrinfo() return value: -3 (Temporary failure in name resolution)
  
  real  0m1.609s
  user  0m0.004s
  sys   0m0.000s

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

Title:
  Regression in getaddrinfo(): calls block for much longer on Bionic
  (compared to Xenial)

Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  New

Bug description:
  When testing MAAS on Bionic, we noticed sluggish performance that we
  could not immediately explain.

  After comparing the results from a run of the test suite on Xenial to
  a run on Bionic, we determined that the slowdowns had to do with DNS
  lookups. In particular, if MAAS attempts to resolve a hostname using
  getaddrinfo() and the call fails, on Xenial the negative result is
  returned in a fraction of a second. On Bionic, the negative result is
  returned in ~1.6 seconds, according to some measures.

  ### To run the test ###

  git clone https://github.com/mpontillo/test-getaddrinfo
  cd test-getaddrinfo
  make

  ### Results on Xenial ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Success
  getaddrinfo() return value: -2 (Name or service not known)

  real  0m0.015s
  user  0m0.000s
  sys   0m0.000s

  ### Results on Bionic ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Resource temporarily unavailable
  getaddrinfo() return value: -3 (Temporary failure in name resolution)

  real  0m1.609s
  user  0m0.004s
  sys   0m0.000s

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

[Mike Pontillo]

I just tested with the Xenial kernel and Bionic userspace and observed
that the bug still occurs, so marked Invalid for 'linux'.

** Changed in: linux (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  Regression in getaddrinfo(): calls block for much longer on Bionic
  (compared to Xenial)

Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  New

Bug description:
  When testing MAAS on Bionic, we noticed sluggish performance that we
  could not immediately explain.

  After comparing the results from a run of the test suite on Xenial to
  a run on Bionic, we determined that the slowdowns had to do with DNS
  lookups. In particular, if MAAS attempts to resolve a hostname using
  getaddrinfo() and the call fails, on Xenial the negative result is
  returned in a fraction of a second. On Bionic, the negative result is
  returned in ~1.6 seconds, according to some measures.

  ### To run the test ###

  git clone https://github.com/mpontillo/test-getaddrinfo
  cd test-getaddrinfo
  make

  
  ### Results on Xenial ###
  time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Success
  getaddrinfo() return value: -2 (Name or service not known)

  real  0m0.015s
  user  0m0.000s
  sys   0m0.000s

  
  ### Results on Bionic ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Resource temporarily unavailable
  getaddrinfo() return value: -3 (Temporary failure in name resolution)

  real  0m1.609s
  user  0m0.004s
  sys   0m0.000s

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

[Mike Pontillo]

Note: I doubt this bug is in the kernel itself; I initially attempted to
file it under glibc at first, but for some reason the `linux` package
was selected.

I also added `systemd` in case the difference in behavior can be
explained by the addition of resolved.

Note that these tests were run on Bionic Desktop, so it's using network-
manager, not networkd.

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

Title:
  Regression in getaddrinfo(): calls block for much longer on Bionic
  (compared to Xenial)

Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  When testing MAAS on Bionic, we noticed sluggish performance that we
  could not immediately explain.

  After comparing the results from a run of the test suite on Xenial to
  a run on Bionic, we determined that the slowdowns had to do with DNS
  lookups. In particular, if MAAS attempts to resolve a hostname using
  getaddrinfo() and the call fails, on Xenial the negative result is
  returned in a fraction of a second. On Bionic, the negative result is
  returned in ~1.6 seconds, according to some measures.

  ### To run the test ###

  git clone https://github.com/mpontillo/test-getaddrinfo
  cd test-getaddrinfo
  make

  
  ### Results on Xenial ###
  time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Success
  getaddrinfo() return value: -2 (Name or service not known)

  real  0m0.015s
  user  0m0.000s
  sys   0m0.000s

  
  ### Results on Bionic ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Resource temporarily unavailable
  getaddrinfo() return value: -3 (Temporary failure in name resolution)

  real  0m1.609s
  user  0m0.004s
  sys   0m0.000s

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1739672] [NEW] Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

[Mike Pontillo]

Public bug reported:

When testing MAAS on Bionic, we noticed sluggish performance that we
could not immediately explain.

After comparing the results from a run of the test suite on Xenial to a
run on Bionic, we determined that the slowdowns had to do with DNS
lookups. In particular, if MAAS attempts to resolve a hostname using
getaddrinfo() and the call fails, on Xenial the negative result is
returned in a fraction of a second. On Bionic, the negative result is
returned in ~1.6 seconds, according to some measures.

### To run the test ###

git clone https://github.com/mpontillo/test-getaddrinfo
cd test-getaddrinfo
make


### Results on Xenial ###
time ./test not-a-real-hostname
Trying to resolve: not-a-real-hostname
getaddrinfo errno: Success
getaddrinfo() return value: -2 (Name or service not known)

real0m0.015s
user0m0.000s
sys 0m0.000s


### Results on Bionic ###
$ time ./test not-a-real-hostname
Trying to resolve: not-a-real-hostname
getaddrinfo errno: Resource temporarily unavailable
getaddrinfo() return value: -3 (Temporary failure in name resolution)

real0m1.609s
user0m0.004s
sys 0m0.000s

** Affects: glibc (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Incomplete

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: xenial

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: glibc (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Regression in getaddrinfo(): calls block for much longer on Bionic
  (compared to Xenial)

Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  When testing MAAS on Bionic, we noticed sluggish performance that we
  could not immediately explain.

  After comparing the results from a run of the test suite on Xenial to
  a run on Bionic, we determined that the slowdowns had to do with DNS
  lookups. In particular, if MAAS attempts to resolve a hostname using
  getaddrinfo() and the call fails, on Xenial the negative result is
  returned in a fraction of a second. On Bionic, the negative result is
  returned in ~1.6 seconds, according to some measures.

  ### To run the test ###

  git clone https://github.com/mpontillo/test-getaddrinfo
  cd test-getaddrinfo
  make

  
  ### Results on Xenial ###
  time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Success
  getaddrinfo() return value: -2 (Name or service not known)

  real  0m0.015s
  user  0m0.000s
  sys   0m0.000s

  
  ### Results on Bionic ###
  $ time ./test not-a-real-hostname
  Trying to resolve: not-a-real-hostname
  getaddrinfo errno: Resource temporarily unavailable
  getaddrinfo() return value: -3 (Temporary failure in name resolution)

  real  0m1.609s
  user  0m0.004s
  sys   0m0.000s

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1664846] Re: [Wishlist] Support for teaming driver

[Mike Pontillo]

If we decide to implement this (I think it's still a wishlist item), I
would prefer it to be more of a 'preferred driver choice' type of
option. That is, model it like a normal bond in the YAML, but have
something like a "preferred-driver: teaming" or similar, with a way to
pass in additional ad-hoc custom parameters for that driver. (Only
options very specific to that particular driver should ever be used in
this ad-hoc manner. Bonds should be modeled as generically as possible,
with industry-standard options exposed in the generalized YAML.)

My $0.02.

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

Title:
  [Wishlist] Support for teaming driver

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  The MAAS team is supporting a customer who is using the 'teaming'
  driver rather than the 'bonding' driver. This is essentially a bonding
  driver which also delivers some additional features, and has
  additional userspace runtime control.

  Netplan should allow for bonds to be configured with the teaming
  driver in addition to the bonding driver.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1664846/+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 1640147] Re: [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE" on commissioning

[Mike Pontillo]

I'm still seeing this on trunk.

Mar 28 22:58:05 skylake dhclient[4804]: no link-local IPv6 address for eno1
Mar 28 22:58:05 skylake dhclient[4804]:
Mar 28 22:58:05 skylake dhclient[4804]: If you think you have received this 
message due to a bug rather
Mar 28 22:58:05 skylake dhclient[4804]: than a configuration issue please read 
the section on submitting
Mar 28 22:58:05 skylake dhclient[4804]: bugs on either our web page at 
www.isc.org or in the README file
Mar 28 22:58:05 skylake dhclient[4804]: before submitting a bug.  These pages 
explain the proper
Mar 28 22:58:05 skylake dhclient[4804]: process and the information we find 
helpful for debugging..
Mar 28 22:58:05 skylake dhclient[4804]:
Mar 28 22:58:05 skylake dhclient[4804]: exiting.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1640147

Title:
  [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE"
  on commissioning

Status in MAAS:
  Fix Released
Status in MAAS 2.1 series:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Invalid

Bug description:
  When commissioning, /var/log/maas/rsyslog/ is flooded with the
  repeated messages below with over 30,000 lines.

  
  Nov  8 11:57:54 bunyip dhclient[4734]: no link-local IPv6 address for enp4s0f0
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: If you think you have received this 
message due to a bug rather
  Nov  8 11:57:54 bunyip dhclient[4734]: than a configuration issue please read 
the section on submitting
  Nov  8 11:57:54 bunyip dhclient[4734]: bugs on either our web page at 
www.isc.org or in the README file
  Nov  8 11:57:54 bunyip dhclient[4734]: before submitting a bug.  These pages 
explain the proper
  Nov  8 11:57:54 bunyip dhclient[4734]: process and the information we find 
helpful for debugging..
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: exiting.
  

  $ wc -l /var/log/maas/rsyslog/bunyip/2016-11-08/messages
  39278 /var/log/maas/rsyslog/bunyip/2016-11-08/messages

  It would be nice to suppress those lines if those could be safely
  ignored. It would make troubleshooting easier when something wrong
  happened on commissioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1640147/+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 1640147] Re: [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE" on commissioning

[Mike Pontillo]

Note, this is NOT a case where IPv6 has been disabled explicitly; this
is the case where I have a link-down interface. (`ip link` reports NO-
CARRIER.)

3: eno1:  mtu 1500 qdisc pfifo_fast state 
DOWN mode DEFAULT group default qlen 1000
link/ether 0c:c4:7a:c0:31:fa brd ff:ff:ff:ff:ff:ff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1640147

Title:
  [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE"
  on commissioning

Status in MAAS:
  Fix Released
Status in MAAS 2.1 series:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Invalid

Bug description:
  When commissioning, /var/log/maas/rsyslog/ is flooded with the
  repeated messages below with over 30,000 lines.

  
  Nov  8 11:57:54 bunyip dhclient[4734]: no link-local IPv6 address for enp4s0f0
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: If you think you have received this 
message due to a bug rather
  Nov  8 11:57:54 bunyip dhclient[4734]: than a configuration issue please read 
the section on submitting
  Nov  8 11:57:54 bunyip dhclient[4734]: bugs on either our web page at 
www.isc.org or in the README file
  Nov  8 11:57:54 bunyip dhclient[4734]: before submitting a bug.  These pages 
explain the proper
  Nov  8 11:57:54 bunyip dhclient[4734]: process and the information we find 
helpful for debugging..
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: exiting.
  

  $ wc -l /var/log/maas/rsyslog/bunyip/2016-11-08/messages
  39278 /var/log/maas/rsyslog/bunyip/2016-11-08/messages

  It would be nice to suppress those lines if those could be safely
  ignored. It would make troubleshooting easier when something wrong
  happened on commissioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1640147/+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 1664748] Re: wifi connection drops, reconnects every 10 minutes

[Mike Pontillo]

One last note on this. It might be possible to get this setup to work
(on the client) using the following sysctl changes:

net.ipv4.conf.all.arp_filter = 1 (or 0)
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.all.arp_ignore = 2

This is completely untested. But in theory[1]:

 - arp_filter = 1:  "allows you to have multiple network interfaces on
the same subnet", according to the kernel docs. However, the decision is
"based on whether or not the kernel would route a packet from the ARP'd
IP out that interface". So that might need to remain set to zero. So
worst case, it still wouldn't work, or the DHCP server would get
conflicting ARP replies (possibly making the problem worse for the wired
interface).

 - rp_filter = 2: the default in Ubuntu is for strict reverse-path
filtering, which might cause us to fail to receive unicast DHCP ACK
replies, if we see packets coming to a wireless interface [with a lower
metric] which we don't expect. Loose reverse-path filtering should allow
this, though it would roll back significant security properties that
rp_filter=1 adds.

 - arp_ignore = 2: an attempt to mitigate the fact that ARP filtering
might allow more than interface to reply to the ARP by ensuring that
only interfaces configured with the address can reply. (Use this if
arp_filter=1 isn't doing the trick and you need to try arp_filter=0.)

[1]: based on https://www.kernel.org/doc/Documentation/networking/ip-
sysctl.txt

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

Title:
  wifi connection drops, reconnects every 10 minutes

Status in maas package in Ubuntu:
  Invalid
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  I recently moved my home DHCP and DNS server over to MAAS (2.1.3 from
  xenial-updates).

  Since doing so, I've noticed that my wifi connection drops and
  reconnects (with corresponding Unity pop-up notifications) exactly
  every 10 minutes.

  I suppose this is due to the fact that MAAS sets DHCP leases to 10
  minutes by default?

  Has anyone else noticed this behavior?

  Is there a suitable workaround?  Increasing the DHCP lease time?
  Using static addresses?  Something else?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1664748/+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 1664748] Re: wifi connection drops, reconnects every 10 minutes

[Mike Pontillo]

After further investigation, this is also invalid for MAAS.

The root cause of this issue is: two separate interfaces requesting an
address from the same DHCP server cannot be supported. (At least, not
without some serious sysctl hacking at a minimum, but I'm not even sure
about that.)

If you have a wired and a wireless NIC running alongside NetworkManager,
NetworkManager will kindly ensure that the metric of your wireless
interface is higher than for your wired interface.

When the DHCP client goes to renew the lease in question, it will send
out the renewal on the interface it is currently bound to. (the wireless
interface) So far so good.

Now the DHCP server will receive the DHCP renewal request, and then
create a unicast UDP reply packet. This packet will be addressed to the
wireless interface. So the DHCP server will need to ARP for the
currently-leased IP address on the wireless interface. So far so good.
The ARP request will be sent to the MAC owner of the lease, since that's
what should be cached for that IP address. So far so good.

Your laptop (happily, or so it thinks, sitting on both the wireless and
wired networks) receives an ARP request on the wireless owned-MAC. So
far so good.

Your laptop, in sending its ARP reply, wants to be sure that the
requester has the best possible interface to communicate with said IP
address on. "Oh, hey", the kernel says to itself, "it says here in my
table that wired0 is a better interface than wlan0 to communicate with
10.0.0.3 on". So it constructs an ARP reply to the DHCP server,
effectively saying "hey, wait, I have better information about
10.0.0.46. You should talk to it on wired0. Then we won't have to worry
about that stupid unreliable radio, OK? OK."

So the DHCP server dutifully processes the ARP reply and blasts the
lease renewal ACK to... wired0. Which promptly drops it after saying to
itself "I didn't ask for that IP address; go away".

So the poor wireless interface is a third-wheel in all this, thinking
that the server hates it or the network must have dropped its packets.
Until lease renewal comes along, the IP address goes away, the route
goes away, and the initial (broadcast-based) discover/offer/request/ack
cycle works just fine, giving it a short-lived glimmer of hope.

QED.

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

Title:
  wifi connection drops, reconnects every 10 minutes

Status in maas package in Ubuntu:
  Invalid
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  I recently moved my home DHCP and DNS server over to MAAS (2.1.3 from
  xenial-updates).

  Since doing so, I've noticed that my wifi connection drops and
  reconnects (with corresponding Unity pop-up notifications) exactly
  every 10 minutes.

  I suppose this is due to the fact that MAAS sets DHCP leases to 10
  minutes by default?

  Has anyone else noticed this behavior?

  Is there a suitable workaround?  Increasing the DHCP lease time?
  Using static addresses?  Something else?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1664748/+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 1664748] Re: wifi connection drops, reconnects every 10 minutes

[Mike Pontillo]

** Changed in: maas (Ubuntu)
   Status: Opinion => Invalid

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

Title:
  wifi connection drops, reconnects every 10 minutes

Status in maas package in Ubuntu:
  Invalid
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  I recently moved my home DHCP and DNS server over to MAAS (2.1.3 from
  xenial-updates).

  Since doing so, I've noticed that my wifi connection drops and
  reconnects (with corresponding Unity pop-up notifications) exactly
  every 10 minutes.

  I suppose this is due to the fact that MAAS sets DHCP leases to 10
  minutes by default?

  Has anyone else noticed this behavior?

  Is there a suitable workaround?  Increasing the DHCP lease time?
  Using static addresses?  Something else?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1664748/+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 1664748] Re: wifi connection drops, reconnects every 10 minutes

[Mike Pontillo]

Marking 'Opinion' for MAAS since we might want to discuss if it's
possible to better balance renewal times for clients on unreliable
networks.

I do not believe this is a bug in the ISC DHCP client or NetworkManager,
so marking 'Invalid' for NM.

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

Title:
  wifi connection drops, reconnects every 10 minutes

Status in maas package in Ubuntu:
  Opinion
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  I recently moved my home DHCP and DNS server over to MAAS (2.1.3 from
  xenial-updates).

  Since doing so, I've noticed that my wifi connection drops and
  reconnects (with corresponding Unity pop-up notifications) exactly
  every 10 minutes.

  I suppose this is due to the fact that MAAS sets DHCP leases to 10
  minutes by default?

  Has anyone else noticed this behavior?

  Is there a suitable workaround?  Increasing the DHCP lease time?
  Using static addresses?  Something else?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1664748/+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 1664748] Re: wifi connection drops, reconnects every 10 minutes

[Mike Pontillo]

Normal behavior is that the DHCP client begins to renew the lease half
way through the lease time. So, for MAAS's 10 minute lease, it should be
after ~5 minutes. After ~85-90% of the time (the rebind time), the
client will give up on the lease and try to get a new one, under the
assumption that maybe a different DHCP server took over.

Taking a closer look at the leases file, we can estimate when each lease
renewed (though that information is unstated), and whether or not it was
an expected outcome:


[Wired]
Lease 1: Not from MAAS. [10.1.8.277]
Lease 2: Renews 23:33:53 (so granted ~23:28:53) [OK] [10.0.0.112]
Lease 3: Renews 23:38:02 (so granted ~23:33:02) [RENEWED-OK] [10.0.0.112]
Lease 4: Renews 23:41:55 (so granted ~23:36:55) [RENEWED-OK] [10.0.0.112]
Lease 5: Renews 23:46:17 (so granted ~23:41:17) [RENEWED-OK] [10.0.0.112]

[WLAN]
Lease 6: Renews 23:30:52 (so granted ~23:25:52) [OK] [10.0.0.46]
Lease 7: Renews 23:41:27 (so granted ~23:36:27) [REBOUND; granted after rebind 
time of 23:35:43] [10.0.0.46]

On the wired interface, everything looks great. Leases are being renewed
as expected.

The only questionable data point is the last lease (on the WLAN
interface); it appears that this lease extended beyond the REBIND
timeout, which caused the client to give up on the current lease and try
to get a new lease instead.

Since the wired interface is okay, I think it's safe to assume that
there is greater packet loss on the wireless interface, leading to the
normal DHCP client behavior of giving up on the lease if it hasn't heard
back from the server.

So on one hand, everything is operating normally, and maybe you should
look at upgrading your WiFi network to prevent packet loss. ;-) On the
other hand, yes, if you were to increase the timeout, that might help
somewhat with this situation.

Increasing the timeout is a tricky balance; make it too long, and
customers with small or highly utilized dynamic ranges will not be able
to deploy new machines. Make it too short, and clients on networks
experiencing packet loss, and/or poorly-written DHCP clients will lose
their leases.

** Changed in: network-manager (Ubuntu)
   Status: New => Invalid

** Changed in: maas (Ubuntu)
   Status: New => Opinion

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

Title:
  wifi connection drops, reconnects every 10 minutes

Status in maas package in Ubuntu:
  Opinion
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  I recently moved my home DHCP and DNS server over to MAAS (2.1.3 from
  xenial-updates).

  Since doing so, I've noticed that my wifi connection drops and
  reconnects (with corresponding Unity pop-up notifications) exactly
  every 10 minutes.

  I suppose this is due to the fact that MAAS sets DHCP leases to 10
  minutes by default?

  Has anyone else noticed this behavior?

  Is there a suitable workaround?  Increasing the DHCP lease time?
  Using static addresses?  Something else?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1664748/+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 1664748] Re: wifi connection drops, reconnects every 10 minutes

[Mike Pontillo]

^ That is, please run that command on the client so we can see the full
transaction history.

It's hard to tell if the DHCP client isn't renewing fast enough, or
possibly it's trying to renew but for some reason the server no longer
recognizes the lease.

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

Title:
  wifi connection drops, reconnects every 10 minutes

Status in maas package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  I recently moved my home DHCP and DNS server over to MAAS (2.1.3 from
  xenial-updates).

  Since doing so, I've noticed that my wifi connection drops and
  reconnects (with corresponding Unity pop-up notifications) exactly
  every 10 minutes.

  I suppose this is due to the fact that MAAS sets DHCP leases to 10
  minutes by default?

  Has anyone else noticed this behavior?

  Is there a suitable workaround?  Increasing the DHCP lease time?
  Using static addresses?  Something else?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1664748/+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 1661869] Re: maas install fails inside of a 16.04 lxd container due to avahi problems

[Mike Pontillo]

Since [the released version of] MAAS declares avahi-utils as a
"Recommends", you can use `apt-get --no-install-recommends` as an
alternate workaround. But then you'll lose zeroconf hostname discoveries
in MAAS.

I understand that this has been changed to a hard dependency in MAAS
2.2, so I'm glad this is getting some attention upstream.

** Changed in: maas
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1661869

Title:
  maas install fails inside of a 16.04 lxd container due to avahi
  problems

Status in MAAS:
  Invalid
Status in avahi package in Ubuntu:
  New
Status in lxd package in Ubuntu:
  Invalid

Bug description:
  The bug, and workaround, are clearly described in this mailing list
  thread:

  https://lists.linuxcontainers.org/pipermail/lxc-
  users/2016-January/010791.html

  I'm trying to install MAAS in a LXD container, but that's failing due
  to avahi package install problems.  I'm tagging all packages here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1661869/+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 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[Mike Pontillo]

I have regression-tested MAAS images (supplied by LaMont) containing the
proposed fixes on a set of amd64 virtual machines in an IPv4
environment, and LaMont has carried out testing in an IPv6 environment.

Everything seems to be working, so I'm setting this to verification-
done.

** Tags removed: verification-needed
** Tags added: verification-done

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1621507

Title:
  initramfs-tools configure_networking() fails to dhcp ipv6 addresses

Status in MAAS:
  Triaged
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Confirmed
Status in open-iscsi package in Ubuntu:
  Fix Committed
Status in initramfs-tools source package in Xenial:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Confirmed
Status in open-iscsi source package in Xenial:
  Fix Committed
Status in klibc package in Debian:
  New

Bug description:
  initramfs' configure_networking function uses ipconfig to configure the 
network.
  ipconfig does not support dhcpv6.  See: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627164

  Related bugs:
* bug 1229458: grub2 needed changes
    * bug 1621615: network not configured when ipv6 netbooted into cloud-init

  [Impact]

  It is not possible to netboot Ubuntu with a network-based root
  filesystem in an ipv6-only environment.  Anyone wanting to netboot in
  an ipv6-only environment is affected.

  These uploads address this by replacing the one-off klibc dhcp client
  (IPv4-only) with the defacto standard isc-dhcp-client, and thereby
  provide both ipv6 and ipv4 DHCP configuration.

  [Test Case]

  See Bug 1229458.  Configure radvd, dhcpd, and tftpd for your ipv6-only
  netbooting world.  Pass the boot process an ipv6 address to talk to,
  and see it fail to configure the network.

  [Regression Potential]

  1) This increases the uncompressed initramfs size by approximately 500KB, 
since isc-dhcp-client is added, but klibc is still needed for some other 
things, and is therefore present.  On systems with a very small /boot 
partition, this could result in failure to upgrade the initramfs.
  2) In at least some cases, DHCP network configuration shifts from klibc's 
ipconfig to isc-dhcp-client's dhclient.  This should be of minimal risk, as 
isc-dhcp-client is in very very widespread use.  In the event of a regression, 
network boot would fail, but the prior kernel should still be bootable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1621507/+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 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

[Mike Pontillo]

Actually, please disregard the portion of my previous comment where I
suspected we should consider patching systemd as well. I no longer think
that is necessary. (My test case was flawed.) After correcting the issue
(ensuring I was running with the properly-updated dbus fix), I was able
to run eight parallel continuous-SSH scripts against the LXC with the
fixed dbus (without the systemd patch).

ubuntu@test:~$ uptime
 20:13:55 up 4 min,  1 user,  load average: 5.87, 3.70, 2.01

Over 10,000 sessions so far, and no issues. Ship it!

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

Title:
  systemd-logind must be restarted every ~1000 SSH logins to prevent a
  ~25 second delay

Status in dbus package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in dbus source package in Xenial:
  New
Status in systemd source package in Xenial:
  Confirmed

Bug description:
  I noticed on a system that accepts large numbers of SSH connections
  that after awhile, SSH sessions were taking ~25 seconds to complete.

  Looking in /var/log/auth.log, systemd-logind starts failing with the
  following:

  Jun 10 23:55:28 test sshd[3666]: pam_unix(sshd:session): session opened for 
user ubuntu by (uid=0)
  Jun 10 23:55:28 test systemd-logind[105]: New session c1052 of user ubuntu.
  Jun 10 23:55:28 test systemd-logind[105]: Failed to abandon session scope: 
Transport endpoint is not connected
  Jun 10 23:55:28 test sshd[3666]: pam_systemd(sshd:session): Failed to create 
session: Message recipient disconnected from message bus without replying

  I reproduced this in an LXD container by doing something like:

  lxc launch ubuntu:x test
  lxc exec test -- login -f ubuntu
  ssh-import-id 

  Then ran a script as follows (passing in ubuntu@):

  while [ 1 ]; do
  (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log
  done

  In my case, after 1052 logins, the 1053rd and thereafter were taking
  25+ seconds to complete. Here are some snippets from the log file:

  $ cat log | grep 0m0 | wc -l
  1052

  $ cat log | grep 0m25 | wc -l
  4

  $ tail -5 log
  real  0m0.222s
  real  0m25.232s
  real  0m25.235s
  real  0m25.236s
  real  0m25.239s

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: systemd 229-4ubuntu5
  ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
  Uname: Linux 4.4.0-22-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Sat Jun 11 00:09:34 2016
  MachineType: Notebook W230SS
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-22-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/15/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4.6.5
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: W230SS
  dmi.board.vendor: Notebook
  dmi.board.version: Not Applicable
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: Notebook
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd04/15/2014:svnNotebook:pnW230SS:pvrNotApplicable:rvnNotebook:rnW230SS:rvrNotApplicable:cvnNotebook:ct9:cvrN/A:
  dmi.product.name: W230SS
  dmi.product.version: Not Applicable
  dmi.sys.vendor: Notebook

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1591411/+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 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

[Mike Pontillo]

I would like to thank the GitLab team for their excellent work triaging
this issue (and getting a patch ready). Very nice work. I tested the
version of dbus in Stan Hu's PPA here:

https://launchpad.net/~stanhu/+archive/ubuntu/dbus

After updating dbus to the version in this PPA, I ran my "ssh to a
container" test (which I used as a test case reproduce the bug to file
this), and also on another test system that was experiencing this issue
with a real-world use case.

This time, I was able to SSH into the system several thousand times, and
everything worked fine.

Next I turned it up to eleven by running eight continuous-SSH scripts in
a loop. In a minute or two, it fell over and went back to the 25-second
delay behavior. So while the behavior is *much* improved with the dbus
patch, there are still lingering issues, and I think we should consider
patching systemd as well (in addition to triaging further to determine
if there is larger design flaw that can be fixed separately).

I think it's worth patching dbus alone as a first step. I will test
Łukasz's systemd PPA to see if that further improves things.

Thanks again to everyone in the community who helped pull together a
fix!

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

Title:
  systemd-logind must be restarted every ~1000 SSH logins to prevent a
  ~25 second delay

Status in dbus package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in dbus source package in Xenial:
  New
Status in systemd source package in Xenial:
  Confirmed

Bug description:
  I noticed on a system that accepts large numbers of SSH connections
  that after awhile, SSH sessions were taking ~25 seconds to complete.

  Looking in /var/log/auth.log, systemd-logind starts failing with the
  following:

  Jun 10 23:55:28 test sshd[3666]: pam_unix(sshd:session): session opened for 
user ubuntu by (uid=0)
  Jun 10 23:55:28 test systemd-logind[105]: New session c1052 of user ubuntu.
  Jun 10 23:55:28 test systemd-logind[105]: Failed to abandon session scope: 
Transport endpoint is not connected
  Jun 10 23:55:28 test sshd[3666]: pam_systemd(sshd:session): Failed to create 
session: Message recipient disconnected from message bus without replying

  I reproduced this in an LXD container by doing something like:

  lxc launch ubuntu:x test
  lxc exec test -- login -f ubuntu
  ssh-import-id 

  Then ran a script as follows (passing in ubuntu@):

  while [ 1 ]; do
  (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log
  done

  In my case, after 1052 logins, the 1053rd and thereafter were taking
  25+ seconds to complete. Here are some snippets from the log file:

  $ cat log | grep 0m0 | wc -l
  1052

  $ cat log | grep 0m25 | wc -l
  4

  $ tail -5 log
  real  0m0.222s
  real  0m25.232s
  real  0m25.235s
  real  0m25.236s
  real  0m25.239s

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: systemd 229-4ubuntu5
  ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
  Uname: Linux 4.4.0-22-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Sat Jun 11 00:09:34 2016
  MachineType: Notebook W230SS
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-22-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/15/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4.6.5
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: W230SS
  dmi.board.vendor: Notebook
  dmi.board.version: Not Applicable
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: Notebook
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd04/15/2014:svnNotebook:pnW230SS:pvrNotApplicable:rvnNotebook:rnW230SS:rvrNotApplicable:cvnNotebook:ct9:cvrN/A:
  dmi.product.name: W230SS
  dmi.product.version: Not Applicable
  dmi.sys.vendor: Notebook

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1591411/+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 1519120] Re: NetworkManager VLAN support fails unless vlan package is manually installed

[Mike Pontillo]

Another note: in addition to VLANs, NetworkManager lists other interface
types for which the dependencies aren't installed as well:

Bond
Bridge
Team

The "ifenslave" and "bridge-utils" package would be needed for bonds and
bridges to work out of the box. (I think bridge-utils might already be
present on Xenial server since LXD requires bridges, but I'm not sure
about desktop.)

The "Team" option seems to be a Red Hat technology (in 'universe' in
Ubuntu) which should probably be hidden from the menu unless the
dependency is installed (separate issue).

In summary, I think that not having these packages installed by default
is a usability problem for both Ubuntu Server and Ubuntu Desktop. IMHO,
we should ensure the following packages are recommended by at least
`network-manager` and possibly `ifupdown`:

vlan
bridge-utils
ifenslave

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

Title:
  NetworkManager VLAN support fails unless vlan package is manually
  installed

Status in network-manager package in Ubuntu:
  Confirmed
Status in vlan package in Ubuntu:
  Invalid

Bug description:
  I tried to use the network manager UI to define a VLAN interface, and
  nothing happened. There are a few bugs here:

  (1) When creating a VLAN interface through the UI, the "vlan interface
  name" must be filled in. This should just default to ., rather than being a required field. (I typed in "vlan100"
  to get the "Save" button to activate.)

  (2) After creating my VLAN interface, nothing happened. No new
  interface appeared. I then realized that I had not installed the
  "vlan" package, and assumed that NetworkManager therefore could not
  complete configuration of the interface.

  (3) After installing the 'vlan' package (and then telling
  NetworkManager to disconnect and reconnect my Ethernet interface from
  the UI, just for good measure), still no VLAN interfaces were present
  on my system.

  I also tried editing the VLAN interface in the UI, and specifying
  "enp4s0f1.100", but still no VLAN interface came online.

  # apt-cache policy network-manager
  network-manager:
Installed: 1.0.4-0ubuntu6
Candidate: 1.0.4-0ubuntu6
Version table:
   *** 1.0.4-0ubuntu6 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  # apt-cache policy vlan
  vlan:
Installed: 1.9-3.2ubuntu1
Candidate: 1.9-3.2ubuntu1
Version table:
   *** 1.9-3.2ubuntu1 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1519120/+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 1519120] Re: Xenial: VLAN interfaces don't work until after a reboot

[Mike Pontillo]

I'll leave this bug open, because as an Ubuntu Desktop user, I would
expect this to work properly out-of-the-box without installing a package
or rebooting. (That is, I shouldn't have to figure out that I needed to
install the "vlan" package to get it to work, as a desktop user trying
to point-and-click.)

The user experience of the dialog in the screenshot is a separate
concern.

** Changed in: vlan (Ubuntu)
   Status: New => Invalid

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

Title:
  Xenial: VLAN interfaces don't work until after a reboot

Status in network-manager package in Ubuntu:
  Confirmed
Status in vlan package in Ubuntu:
  Invalid

Bug description:
  I tried to use the network manager UI to define a VLAN interface, and
  nothing happened. There are a few bugs here:

  (1) When creating a VLAN interface through the UI, the "vlan interface
  name" must be filled in. This should just default to ., rather than being a required field. (I typed in "vlan100"
  to get the "Save" button to activate.)

  (2) After creating my VLAN interface, nothing happened. No new
  interface appeared. I then realized that I had not installed the
  "vlan" package, and assumed that NetworkManager therefore could not
  complete configuration of the interface.

  (3) After installing the 'vlan' package (and then telling
  NetworkManager to disconnect and reconnect my Ethernet interface from
  the UI, just for good measure), still no VLAN interfaces were present
  on my system.

  I also tried editing the VLAN interface in the UI, and specifying
  "enp4s0f1.100", but still no VLAN interface came online.

  # apt-cache policy network-manager
  network-manager:
Installed: 1.0.4-0ubuntu6
Candidate: 1.0.4-0ubuntu6
Version table:
   *** 1.0.4-0ubuntu6 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  # apt-cache policy vlan
  vlan:
Installed: 1.9-3.2ubuntu1
Candidate: 1.9-3.2ubuntu1
Version table:
   *** 1.9-3.2ubuntu1 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1519120/+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 1519120] Re: Xenial: VLAN interfaces don't work until after a reboot

[Mike Pontillo]

How does the script in /etc/network/if-pre-up.d have anything to do with
this bug? I thought that was placed there for ifupdown. This bug is
about configuring VLANs with Network Manager, so that script shouldn't
be relevant here.

I just tried it again today on a freshly installed Xenial desktop. The
steps I took were:

(0) Install the "vlan" package.
(1) Configure the VLAN interface in the Network Manager UI (with the expected 
name). (see screenshot)
(2) Go to the "IPv4 Settings" tab and configure the VLAN appropriately.

This all seems to work for me now. That said, the user experience isn't
as nice as it could be. (Either the "vlan" package should be installed
by default, or I should be prompted to install it.) And I have to type
way too much redundant information in the UI. But it seems to be working
properly for me now.

** Attachment added: "Screenshot from 2016-06-14 12-22-30.png"
   
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1519120/+attachment/4683807/+files/Screenshot%20from%202016-06-14%2012-22-30.png

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

Title:
  Xenial: VLAN interfaces don't work until after a reboot

Status in network-manager package in Ubuntu:
  Confirmed
Status in vlan package in Ubuntu:
  Invalid

Bug description:
  I tried to use the network manager UI to define a VLAN interface, and
  nothing happened. There are a few bugs here:

  (1) When creating a VLAN interface through the UI, the "vlan interface
  name" must be filled in. This should just default to ., rather than being a required field. (I typed in "vlan100"
  to get the "Save" button to activate.)

  (2) After creating my VLAN interface, nothing happened. No new
  interface appeared. I then realized that I had not installed the
  "vlan" package, and assumed that NetworkManager therefore could not
  complete configuration of the interface.

  (3) After installing the 'vlan' package (and then telling
  NetworkManager to disconnect and reconnect my Ethernet interface from
  the UI, just for good measure), still no VLAN interfaces were present
  on my system.

  I also tried editing the VLAN interface in the UI, and specifying
  "enp4s0f1.100", but still no VLAN interface came online.

  # apt-cache policy network-manager
  network-manager:
Installed: 1.0.4-0ubuntu6
Candidate: 1.0.4-0ubuntu6
Version table:
   *** 1.0.4-0ubuntu6 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  # apt-cache policy vlan
  vlan:
Installed: 1.9-3.2ubuntu1
Candidate: 1.9-3.2ubuntu1
Version table:
   *** 1.9-3.2ubuntu1 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1519120/+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 1591411] [NEW] systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

[Mike Pontillo]

Public bug reported:

I noticed on a system that accepts large numbers of SSH connections that
after awhile, SSH sessions were taking ~25 seconds to complete.

Looking in /var/log/auth.log, systemd-logind starts failing with the
following:

Jun 10 23:55:28 test sshd[3666]: pam_unix(sshd:session): session opened for 
user ubuntu by (uid=0)
Jun 10 23:55:28 test systemd-logind[105]: New session c1052 of user ubuntu.
Jun 10 23:55:28 test systemd-logind[105]: Failed to abandon session scope: 
Transport endpoint is not connected
Jun 10 23:55:28 test sshd[3666]: pam_systemd(sshd:session): Failed to create 
session: Message recipient disconnected from message bus without replying

I reproduced this in an LXD container by doing something like:

lxc launch ubuntu:x test
lxc exec test -- login -f ubuntu
ssh-import-id 

Then ran a script as follows (passing in ubuntu@):

while [ 1 ]; do
(time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log
done

In my case, after 1052 logins, the 1053rd and thereafter were taking 25+
seconds to complete. Here are some snippets from the log file:

$ cat log | grep 0m0 | wc -l
1052

$ cat log | grep 0m25 | wc -l
4

$ tail -5 log
real0m0.222s
real0m25.232s
real0m25.235s
real0m25.236s
real0m25.239s

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: systemd 229-4ubuntu5
ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
Date: Sat Jun 11 00:09:34 2016
MachineType: Notebook W230SS
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-22-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash
SourcePackage: systemd
SystemdDelta:
 [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
 [EXTENDED]   /lib/systemd/system/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

 2 overridden configuration files found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/15/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4.6.5
dmi.board.asset.tag: Tag 12345
dmi.board.name: W230SS
dmi.board.vendor: Notebook
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: Notebook
dmi.chassis.version: N/A
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd04/15/2014:svnNotebook:pnW230SS:pvrNotApplicable:rvnNotebook:rnW230SS:rvrNotApplicable:cvnNotebook:ct9:cvrN/A:
dmi.product.name: W230SS
dmi.product.version: Not Applicable
dmi.sys.vendor: Notebook

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug uec-images xenial

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

Title:
  systemd-logind must be restarted every ~1000 SSH logins to prevent a
  ~25 second delay

Status in systemd package in Ubuntu:
  New

Bug description:
  I noticed on a system that accepts large numbers of SSH connections
  that after awhile, SSH sessions were taking ~25 seconds to complete.

  Looking in /var/log/auth.log, systemd-logind starts failing with the
  following:

  Jun 10 23:55:28 test sshd[3666]: pam_unix(sshd:session): session opened for 
user ubuntu by (uid=0)
  Jun 10 23:55:28 test systemd-logind[105]: New session c1052 of user ubuntu.
  Jun 10 23:55:28 test systemd-logind[105]: Failed to abandon session scope: 
Transport endpoint is not connected
  Jun 10 23:55:28 test sshd[3666]: pam_systemd(sshd:session): Failed to create 
session: Message recipient disconnected from message bus without replying

  I reproduced this in an LXD container by doing something like:

  lxc launch ubuntu:x test
  lxc exec test -- login -f ubuntu
  ssh-import-id 

  Then ran a script as follows (passing in ubuntu@):

  while [ 1 ]; do
  (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log
  done

  In my case, after 1052 logins, the 1053rd and thereafter were taking
  25+ seconds to complete. Here are some snippets from the log file:

  $ cat log | grep 0m0 | wc -l
  1052

  $ cat log | grep 0m25 | wc -l
  4

  $ tail -5 log
  real  0m0.222s
  real  0m25.232s
  real  0m25.235s
  real  0m25.236s
  real  0m25.239s

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: systemd 229-4ubuntu5
  ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
  Uname: Linux 4.4.0-22-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Sat Jun 11 00:09:34 2016
  MachineType: Notebook W230SS
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-22-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/syste

[Touch-packages] [Bug 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

[Mike Pontillo]

Here's my (sad) workaround:

$ sudo crontab -l
1,11,21,31,41,51 * * * * service systemd-logind restart


** Description changed:

  I noticed on a system that accepts large numbers of SSH connections that
  after awhile, SSH sessions were taking ~25 seconds to complete.
  
  Looking in /var/log/auth.log, systemd-logind starts failing with the
  following:
  
+ Jun 10 23:55:28 test sshd[3666]: pam_unix(sshd:session): session opened for 
user ubuntu by (uid=0)
+ Jun 10 23:55:28 test systemd-logind[105]: New session c1052 of user ubuntu.
  Jun 10 23:55:28 test systemd-logind[105]: Failed to abandon session scope: 
Transport endpoint is not connected
  Jun 10 23:55:28 test sshd[3666]: pam_systemd(sshd:session): Failed to create 
session: Message recipient disconnected from message bus without replying
  
  I reproduced this in an LXD container by doing something like:
  
  lxc launch ubuntu:x test
  lxc exec test -- login -f ubuntu
  ssh-import-id 
  
  Then ran a script as follows (passing in ubuntu@:
  
  while [ 1 ]; do
- (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log
+ (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log
  done
  
  In my case, after 1052 logins, the 1053rd and thereafter were taking 25+
  seconds to complete. Here are some snippets from the log file:
  
  $ cat log.confirmed_with_password | grep 0m0 | wc -l
  1052
  
  $ cat log.confirmed_with_password | grep 0m25 | wc -l
  4
  
  $ tail -5 log.confirmed_with_password
  real  0m0.222s
  real  0m25.232s
  real  0m25.235s
  real  0m25.236s
  real  0m25.239s
  
  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: systemd 229-4ubuntu5
  ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
  Uname: Linux 4.4.0-22-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Sat Jun 11 00:09:34 2016
  MachineType: Notebook W230SS
  ProcEnviron:
-  TERM=xterm-256color
-  PATH=(custom, no user)
+  TERM=xterm-256color
+  PATH=(custom, no user)
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-22-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash
  SourcePackage: systemd
  SystemdDelta:
-  [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
-  [EXTENDED]   /lib/systemd/system/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
-  
-  2 overridden configuration files found.
+  [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
+  [EXTENDED]   /lib/systemd/system/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
+ 
+  2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/15/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4.6.5
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: W230SS
  dmi.board.vendor: Notebook
  dmi.board.version: Not Applicable
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: Notebook
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd04/15/2014:svnNotebook:pnW230SS:pvrNotApplicable:rvnNotebook:rnW230SS:rvrNotApplicable:cvnNotebook:ct9:cvrN/A:
  dmi.product.name: W230SS
  dmi.product.version: Not Applicable
  dmi.sys.vendor: Notebook

** Description changed:

  I noticed on a system that accepts large numbers of SSH connections that
  after awhile, SSH sessions were taking ~25 seconds to complete.
  
  Looking in /var/log/auth.log, systemd-logind starts failing with the
  following:
  
  Jun 10 23:55:28 test sshd[3666]: pam_unix(sshd:session): session opened for 
user ubuntu by (uid=0)
  Jun 10 23:55:28 test systemd-logind[105]: New session c1052 of user ubuntu.
  Jun 10 23:55:28 test systemd-logind[105]: Failed to abandon session scope: 
Transport endpoint is not connected
  Jun 10 23:55:28 test sshd[3666]: pam_systemd(sshd:session): Failed to create 
session: Message recipient disconnected from message bus without replying
  
  I reproduced this in an LXD container by doing something like:
  
  lxc launch ubuntu:x test
  lxc exec test -- login -f ubuntu
  ssh-import-id 
  
  Then ran a script as follows (passing in ubuntu@:
  
  while [ 1 ]; do
  (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log
  done
  
  In my case, after 1052 logins, the 1053rd and thereafter were taking 25+
  seconds to complete. Here are some snippets from the log file:
  
- $ cat log.confirmed_with_password | grep 0m0 | wc -l
+ $ cat log | grep 0m0 | wc -l
  1052
  
- $ cat log.confirmed_with_password | grep 0m25 | wc -l
+ $ cat log | grep 0m25 | wc -l
  4
  
- $ tail -5 log.confirmed_with_password
+ $ tail -5 log
  real  0m0.222s
  real  0m25.232s
  real  0m25.235s
  real  0m25.236s
  real  0m25.239s
  
  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: systemd 229-4ubuntu5
  ProcVersionSignature: Ubuntu

[Touch-packages] [Bug 1567744] Re: USB NICs get too long name for ifupdown aliases

[Mike Pontillo]

This is also an issue for VLAN interfaces. To support VLANs, 10
characters should be the max. (16 - 1 [for \0], -1 [.], -4 [vid])

Throw in VLANs plus aliases, and, well, I guess we ought to use shorter
names, such as (I don't know) "eth0". ;-)

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

Title:
  USB NICs get too long name for ifupdown aliases

Status in systemd package in Ubuntu:
  Triaged

Bug description:
  I have a USB NIC that is connected to my denial system. I tried to
  create an alias, and after reboot, it wasn't created. When I manually
  try to bring it up I have the error.

  /e/n/i:

  auto enx000ec688b79f
  iface enx000ec688b79f inet static
  address 10.90.90.1
  netmask 255.255.255.0

  auto enx000ec688b79f:1
  iface enx000ec688b79f:1 inet static
  address 192.168.100.1
  netmask 255.255.255.0

  ubuntu@maas00:~$ sudo ifup enx000ec688b79f
  ubuntu@maas00:~$ sudo ifup enx000ec688b79f:1
  RTNETLINK answers: Numerical result out of range
  Failed to bring up enx000ec688b79f:1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1567744/+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 1565804] Re: ifup of vlan interfaces failing during networking start - RTNETLINK answers: File exists

[Mike Pontillo]

In my testing on Xenial, you cannot set a child interface MTU to a value
greater than its parent. For example, if eth0's MTU is 1500, setting
eth0.100's MTU to 9000 (or 1501) causes:

SIOCSIFMTU: Numerical result out of range

This restriction makes sense when you consider the physical topology,
since packets from eth0.100 would be sent via eth0. If the system
attempts to send a packet larger than 1500 bytes via eth0 in this case,
it would be dropped.

This issue makes me wish it were possible to set a "L3 MTU" (i.e., one
that would be the default PMTU MSS, and fragment threshold for other
packet types such as UDP and ICMP).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1565804

Title:
  ifup of vlan interfaces failing during networking start - RTNETLINK
  answers: File exists

Status in ifupdown package in Ubuntu:
  New

Bug description:
  /e/n/i:

  auto lo
  iface lo inet loopback
  dns-nameservers 10.245.168.2
  dns-search dellstack
  auto eth0
  iface eth0 inet static
  gateway 10.245.168.1
  address 10.245.168.17/21
  dns-nameservers 10.245.168.2
  mtu 1500

  auto eth1
  iface eth1 inet manual
  mtu 1500

  auto eth1.2667
  iface eth1.2667 inet static
  address 10.245.184.20/24
  vlan-raw-device eth1
  mtu 9000
  vlan_id 2667

  output from networking startup:

  ● networking.service - Raise network interfaces
 Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor 
preset: enabled)
Drop-In: /run/systemd/generator/networking.service.d
 └─50-insserv.conf-$network.conf
 Active: failed (Result: exit-code) since Mon 2016-04-04 12:14:26 UTC; 1h 
33min ago
   Docs: man:interfaces(5)
Process: 1255 ExecStart=/sbin/ifup -a --read-environment (code=exited, 
status=1/FAILURE)
Process: 868 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && 
[ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle 
(code=exited, 
   Main PID: 1255 (code=exited, status=1/FAILURE)

  Apr 04 12:14:25 reflecting-attraction systemd[1]: Starting Raise network 
interfaces...
  Apr 04 12:14:26 reflecting-attraction ifup[1255]: Set name-type for VLAN 
subsystem. Should be visible in /proc/net/vlan/config
  Apr 04 12:14:26 reflecting-attraction ifup[1255]: RTNETLINK answers: File 
exists
  Apr 04 12:14:26 reflecting-attraction ifup[1255]: Failed to bring up 
eth1.2667.
  Apr 04 12:14:26 reflecting-attraction systemd[1]: networking.service: Main 
process exited, code=exited, status=1/FAILURE
  Apr 04 12:14:26 reflecting-attraction systemd[1]: Failed to start Raise 
network interfaces.
  Apr 04 12:14:26 reflecting-attraction systemd[1]: networking.service: Unit 
entered failed state.
  Apr 04 12:14:26 reflecting-attraction systemd[1]: networking.service: Failed 
with result 'exit-code'.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ifupdown 0.8.10ubuntu1
  ProcVersionSignature: User Name 4.4.0-16.32-generic 4.4.6
  Uname: Linux 4.4.0-16-generic x86_64
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  Date: Mon Apr  4 13:42:48 2016
  SourcePackage: ifupdown
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1565804/+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 1521618] Re: wrong subnet in DHCP answer when multiple networks are present

[Mike Pontillo]

Ah, disregard my previous question. When I re-read this bug I missed the
part where you said "So instead of picking up the /16 subnet correctly
for the 10.6.239.3 IP, it picks up the /24 from the network where it
gets it's default gateway from."

** Changed in: isc-dhcp (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1521618

Title:
  wrong subnet in DHCP answer when multiple networks are present

Status in MAAS:
  Triaged
Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  So I have 3 interfaces with 3, non-overlapping subnets defined in my
  maas cluster controller.

  The idea would be that there is a provisioning network (10.6.0.0/16)
  to do the actual provisioning and once the node gets deployed it is
  using a different network (because the provisioning network is only
  1x1Gbit while the production network is bonded (LACP) 10Gbit).

  However, when I boot up a fresh, new node to add to MAAS, it gets the
  following DHCP reply:

  ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0

  So instead of picking up the /16 subnet correctly for the 10.6.239.3
  IP, it picks up the /24 from the network where it gets it's default
  gateway from.

  Is this a bug or my understanding of how MAAS should behave when there
  are multiple networks flawed?

  Here is my /var/lib/maas/dhcpd.conf:

  subnet 9.4.113.0 netmask 255.255.255.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth0";
 ignore-client-uids true;
 option subnet-mask 255.255.255.0;
 option broadcast-address 9.4.113.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option routers 9.4.113.254;
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 9.4.113.150 9.4.113.190;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }
  subnet 10.6.0.0 netmask 255.255.0.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth1";
 ignore-client-uids true;
 option subnet-mask 255.255.0.0;
 option broadcast-address 10.6.255.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 10.6.239.0 10.6.239.239;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }

  Here is "subnets read":

  [
  {
  "dns_servers": [],
  "name": "9.4.113.0/24",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/0/",
  "fabric": "fabric-0",
  "vid": 0,
  "id": 0
  },
  "gateway_ip": "9.4.113.254",
  "cidr": "9.4.113.0/24",
  "id": 1,
  "resource_uri": "/MAAS/api/1.0/subnets/1/"
  },
  {
  "dns_servers": [],
  "name": "10.7.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5001/",
  "fabric": "fabric-1",
  "vid": 0,
  "id": 5001
  },
  "gateway_ip": null,
  "cidr": "10.7.0.0/16",
  "id": 2,
  "resource_uri": "/MAAS/api/1.0/subnets/2/"
  },
  {
  "dns_servers": [],
  "name": "10.6.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5002/",
  "fabric": "fabric-2",
  "vid": 0,
  "id": 5002
  },
  "gateway_ip": null,
  "cidr": "10.6.0.0/16",
  "id": 3,
  "resource_uri": "/MAAS/api/1.0/subnets/3/"
  }
  ]

  Running 1.9.0~rc2+bzr4509-0ubuntu1~trusty1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/

[Touch-packages] [Bug 1521618] Re: wrong subnet in DHCP answer when multiple networks are present

[Mike Pontillo]

As an aside, Zoltan, I'm curious what symptoms you see due to this
issue. Since the gateway is off-link, it should not be reachable from
the provisioning network. What errors occur in your environment due to
this bug?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1521618

Title:
  wrong subnet in DHCP answer when multiple networks are present

Status in MAAS:
  Triaged
Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  So I have 3 interfaces with 3, non-overlapping subnets defined in my
  maas cluster controller.

  The idea would be that there is a provisioning network (10.6.0.0/16)
  to do the actual provisioning and once the node gets deployed it is
  using a different network (because the provisioning network is only
  1x1Gbit while the production network is bonded (LACP) 10Gbit).

  However, when I boot up a fresh, new node to add to MAAS, it gets the
  following DHCP reply:

  ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0

  So instead of picking up the /16 subnet correctly for the 10.6.239.3
  IP, it picks up the /24 from the network where it gets it's default
  gateway from.

  Is this a bug or my understanding of how MAAS should behave when there
  are multiple networks flawed?

  Here is my /var/lib/maas/dhcpd.conf:

  subnet 9.4.113.0 netmask 255.255.255.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth0";
 ignore-client-uids true;
 option subnet-mask 255.255.255.0;
 option broadcast-address 9.4.113.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option routers 9.4.113.254;
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 9.4.113.150 9.4.113.190;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }
  subnet 10.6.0.0 netmask 255.255.0.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth1";
 ignore-client-uids true;
 option subnet-mask 255.255.0.0;
 option broadcast-address 10.6.255.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 10.6.239.0 10.6.239.239;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }

  Here is "subnets read":

  [
  {
  "dns_servers": [],
  "name": "9.4.113.0/24",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/0/",
  "fabric": "fabric-0",
  "vid": 0,
  "id": 0
  },
  "gateway_ip": "9.4.113.254",
  "cidr": "9.4.113.0/24",
  "id": 1,
  "resource_uri": "/MAAS/api/1.0/subnets/1/"
  },
  {
  "dns_servers": [],
  "name": "10.7.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5001/",
  "fabric": "fabric-1",
  "vid": 0,
  "id": 5001
  },
  "gateway_ip": null,
  "cidr": "10.7.0.0/16",
  "id": 2,
  "resource_uri": "/MAAS/api/1.0/subnets/2/"
  },
  {
  "dns_servers": [],
  "name": "10.6.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5002/",
  "fabric": "fabric-2",
  "vid": 0,
  "id": 5002
  },
  "gateway_ip": null,
  "cidr": "10.6.0.0/16",
  "id": 3,
  "resource_uri": "/MAAS/api/1.0/subnets/3/"
  }
  ]

  Running 1.9.0~rc2+bzr4509-0ubuntu1~trusty1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1521618/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to   

[Touch-packages] [Bug 1521618] Re: wrong subnet in DHCP answer when multiple networks are present

[Mike Pontillo]

Ah, thanks for all the information. (I didn't realize you were pasting
the kernel parameter.)

After researching this problem, I think this definitely looks like a bug
in isc-dhcp. (The other possibility is that MAAS is configuring dhcpd
incorrectly in this situation, but so far it looks like our
configuration is correct, but dhcpd is interpreting it incorrectly.)

I noticed that on Trusty we are using 4.2.4-7ubuntu12.3, while on Xenial
we are using 4.3.1-5ubuntu4. 4.3.1-5ubuntu4. The latest "Extended
support" version from ISC seems to be 4.3.3.[1]

To move forward, we'll need to further triage this to see if the bug
occurs on other versions of dhcpd.

Meanwhile, I think you should be able to work around this issue by
changing your hosts' network configuration after commissioning. You can
configure MAAS to disable the boot interface upon deployment, so that
your provisioning network will only be used for the initial PXE boot.

[1]: https://www.isc.org/downloads/

** Changed in: maas
   Status: Incomplete => Triaged

** Changed in: maas
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1521618

Title:
  wrong subnet in DHCP answer when multiple networks are present

Status in MAAS:
  Triaged
Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  So I have 3 interfaces with 3, non-overlapping subnets defined in my
  maas cluster controller.

  The idea would be that there is a provisioning network (10.6.0.0/16)
  to do the actual provisioning and once the node gets deployed it is
  using a different network (because the provisioning network is only
  1x1Gbit while the production network is bonded (LACP) 10Gbit).

  However, when I boot up a fresh, new node to add to MAAS, it gets the
  following DHCP reply:

  ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0

  So instead of picking up the /16 subnet correctly for the 10.6.239.3
  IP, it picks up the /24 from the network where it gets it's default
  gateway from.

  Is this a bug or my understanding of how MAAS should behave when there
  are multiple networks flawed?

  Here is my /var/lib/maas/dhcpd.conf:

  subnet 9.4.113.0 netmask 255.255.255.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth0";
 ignore-client-uids true;
 option subnet-mask 255.255.255.0;
 option broadcast-address 9.4.113.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option routers 9.4.113.254;
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 9.4.113.150 9.4.113.190;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }
  subnet 10.6.0.0 netmask 255.255.0.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth1";
 ignore-client-uids true;
 option subnet-mask 255.255.0.0;
 option broadcast-address 10.6.255.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 10.6.239.0 10.6.239.239;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }

  Here is "subnets read":

  [
  {
  "dns_servers": [],
  "name": "9.4.113.0/24",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/0/",
  "fabric": "fabric-0",
  "vid": 0,
  "id": 0
  },
  "gateway_ip": "9.4.113.254",
  "cidr": "9.4.113.0/24",
  "id": 1,
  "resource_uri": "/MAAS/api/1.0/subnets/1/"
  },
  {
  "dns_servers": [],
  "name": "10.7.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5001/",
  "fabric": "fabric-1",

[Touch-packages] [Bug 1521618] Re: wrong subnet in DHCP answer when multiple networks are present

[Mike Pontillo]

Would it be possible for you to capture the DHCP packets (for example,
using Wireshark) and attach them to the bug? Thanks!

** Changed in: maas
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1521618

Title:
  wrong subnet in DHCP answer when multiple networks are present

Status in MAAS:
  Incomplete
Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  So I have 3 interfaces with 3, non-overlapping subnets defined in my
  maas cluster controller.

  The idea would be that there is a provisioning network (10.6.0.0/16)
  to do the actual provisioning and once the node gets deployed it is
  using a different network (because the provisioning network is only
  1x1Gbit while the production network is bonded (LACP) 10Gbit).

  However, when I boot up a fresh, new node to add to MAAS, it gets the
  following DHCP reply:

  ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0

  So instead of picking up the /16 subnet correctly for the 10.6.239.3
  IP, it picks up the /24 from the network where it gets it's default
  gateway from.

  Is this a bug or my understanding of how MAAS should behave when there
  are multiple networks flawed?

  Here is my /var/lib/maas/dhcpd.conf:

  subnet 9.4.113.0 netmask 255.255.255.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth0";
 ignore-client-uids true;
 option subnet-mask 255.255.255.0;
 option broadcast-address 9.4.113.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option routers 9.4.113.254;
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 9.4.113.150 9.4.113.190;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }
  subnet 10.6.0.0 netmask 255.255.0.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth1";
 ignore-client-uids true;
 option subnet-mask 255.255.0.0;
 option broadcast-address 10.6.255.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 10.6.239.0 10.6.239.239;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }

  Here is "subnets read":

  [
  {
  "dns_servers": [],
  "name": "9.4.113.0/24",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/0/",
  "fabric": "fabric-0",
  "vid": 0,
  "id": 0
  },
  "gateway_ip": "9.4.113.254",
  "cidr": "9.4.113.0/24",
  "id": 1,
  "resource_uri": "/MAAS/api/1.0/subnets/1/"
  },
  {
  "dns_servers": [],
  "name": "10.7.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5001/",
  "fabric": "fabric-1",
  "vid": 0,
  "id": 5001
  },
  "gateway_ip": null,
  "cidr": "10.7.0.0/16",
  "id": 2,
  "resource_uri": "/MAAS/api/1.0/subnets/2/"
  },
  {
  "dns_servers": [],
  "name": "10.6.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5002/",
  "fabric": "fabric-2",
  "vid": 0,
  "id": 5002
  },
  "gateway_ip": null,
  "cidr": "10.6.0.0/16",
  "id": 3,
  "resource_uri": "/MAAS/api/1.0/subnets/3/"
  }
  ]

  Running 1.9.0~rc2+bzr4509-0ubuntu1~trusty1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1521618/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.ne

[Touch-packages] [Bug 1521618] Re: wrong subnet in DHCP answer when multiple networks are present

[Mike Pontillo]

Thanks for taking the time to report a bug in MAAS.

Can you give us more information on this line in your bug report:

ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0

Is this from a packet capture? (if so, on which interface?) I'm trying
to figure out what this means. In it you have:

10.6.239.3 <-- seems to be an IP address within "range dynamic-bootp 10.6.239.0 
10.6.239.239"
10.6.250.250 <-- seems to be another IP address within your /16
9.4.113.254 <-- router
255.255.255.0 <-- /24

It's interesting that dhcpd would behave in this way; it seems to be
picking up the "option routers" from a subnet it didn't select. It looks
like this may be a dhcpd bug...

** Also affects: isc-dhcp (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1521618

Title:
  wrong subnet in DHCP answer when multiple networks are present

Status in MAAS:
  Incomplete
Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  So I have 3 interfaces with 3, non-overlapping subnets defined in my
  maas cluster controller.

  The idea would be that there is a provisioning network (10.6.0.0/16)
  to do the actual provisioning and once the node gets deployed it is
  using a different network (because the provisioning network is only
  1x1Gbit while the production network is bonded (LACP) 10Gbit).

  However, when I boot up a fresh, new node to add to MAAS, it gets the
  following DHCP reply:

  ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0

  So instead of picking up the /16 subnet correctly for the 10.6.239.3
  IP, it picks up the /24 from the network where it gets it's default
  gateway from.

  Is this a bug or my understanding of how MAAS should behave when there
  are multiple networks flawed?

  Here is my /var/lib/maas/dhcpd.conf:

  subnet 9.4.113.0 netmask 255.255.255.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth0";
 ignore-client-uids true;
 option subnet-mask 255.255.255.0;
 option broadcast-address 9.4.113.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option routers 9.4.113.254;
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 9.4.113.150 9.4.113.190;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }
  subnet 10.6.0.0 netmask 255.255.0.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth1";
 ignore-client-uids true;
 option subnet-mask 255.255.0.0;
 option broadcast-address 10.6.255.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 10.6.239.0 10.6.239.239;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }

  Here is "subnets read":

  [
  {
  "dns_servers": [],
  "name": "9.4.113.0/24",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/0/",
  "fabric": "fabric-0",
  "vid": 0,
  "id": 0
  },
  "gateway_ip": "9.4.113.254",
  "cidr": "9.4.113.0/24",
  "id": 1,
  "resource_uri": "/MAAS/api/1.0/subnets/1/"
  },
  {
  "dns_servers": [],
  "name": "10.7.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5001/",
  "fabric": "fabric-1",
  "vid": 0,
  "id": 5001
  },
  "gateway_ip": null,
  "cidr": "10.7.0.0/16",
  "id": 2,
  "resource_uri": "/MAAS/api/1.0/subnets/2/"
  },
  {
  "dns_servers": [],
  "name": "10.6.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": 

[Touch-packages] [Bug 1519120] Re: Xenial: VLAN interfaces don't work until after a reboot

[Mike Pontillo]

After I rebooted, the "vlan100" interface was created. So perhaps this
bug just has to do with the fact that I tried to configure the a VLAN
without the 'vlan' package installed.

** Summary changed:

- Xenial: VLAN interfaces don't work when defined in the UI
+ Xenial: VLAN interfaces don't work until after a 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/1519120

Title:
  Xenial: VLAN interfaces don't work until after a reboot

Status in network-manager package in Ubuntu:
  New

Bug description:
  I tried to use the network manager UI to define a VLAN interface, and
  nothing happened. There are a few bugs here:

  (1) When creating a VLAN interface through the UI, the "vlan interface
  name" must be filled in. This should just default to ., rather than being a required field. (I typed in "vlan100"
  to get the "Save" button to activate.)

  (2) After creating my VLAN interface, nothing happened. No new
  interface appeared. I then realized that I had not installed the
  "vlan" package, and assumed that NetworkManager therefore could not
  complete configuration of the interface.

  (3) After installing the 'vlan' package (and then telling
  NetworkManager to disconnect and reconnect my Ethernet interface from
  the UI, just for good measure), still no VLAN interfaces were present
  on my system.

  I also tried editing the VLAN interface in the UI, and specifying
  "enp4s0f1.100", but still no VLAN interface came online.

  # apt-cache policy network-manager
  network-manager:
Installed: 1.0.4-0ubuntu6
Candidate: 1.0.4-0ubuntu6
Version table:
   *** 1.0.4-0ubuntu6 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  # apt-cache policy vlan
  vlan:
Installed: 1.9-3.2ubuntu1
Candidate: 1.9-3.2ubuntu1
Version table:
   *** 1.9-3.2ubuntu1 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1519120/+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 1519120] [NEW] Xenial: VLAN interfaces don't work when defined in the UI

[Mike Pontillo]

Public bug reported:

I tried to use the network manager UI to define a VLAN interface, and
nothing happened. There are a few bugs here:

(1) When creating a VLAN interface through the UI, the "vlan interface
name" must be filled in. This should just default to ., rather than being a required field. (I typed in "vlan100"
to get the "Save" button to activate.)

(2) After creating my VLAN interface, nothing happened. No new interface
appeared. I then realized that I had not installed the "vlan" package,
and assumed that NetworkManager therefore could not complete
configuration of the interface.

(3) After installing the 'vlan' package (and then telling NetworkManager
to disconnect and reconnect my Ethernet interface from the UI, just for
good measure), still no VLAN interfaces were present on my system.

I also tried editing the VLAN interface in the UI, and specifying
"enp4s0f1.100", but still no VLAN interface came online.

# apt-cache policy network-manager
network-manager:
  Installed: 1.0.4-0ubuntu6
  Candidate: 1.0.4-0ubuntu6
  Version table:
 *** 1.0.4-0ubuntu6 0
500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
100 /var/lib/dpkg/status

# apt-cache policy vlan
vlan:
  Installed: 1.9-3.2ubuntu1
  Candidate: 1.9-3.2ubuntu1
  Version table:
 *** 1.9-3.2ubuntu1 0
500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
100 /var/lib/dpkg/status

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  Xenial: VLAN interfaces don't work when defined in the UI

Status in network-manager package in Ubuntu:
  New

Bug description:
  I tried to use the network manager UI to define a VLAN interface, and
  nothing happened. There are a few bugs here:

  (1) When creating a VLAN interface through the UI, the "vlan interface
  name" must be filled in. This should just default to ., rather than being a required field. (I typed in "vlan100"
  to get the "Save" button to activate.)

  (2) After creating my VLAN interface, nothing happened. No new
  interface appeared. I then realized that I had not installed the
  "vlan" package, and assumed that NetworkManager therefore could not
  complete configuration of the interface.

  (3) After installing the 'vlan' package (and then telling
  NetworkManager to disconnect and reconnect my Ethernet interface from
  the UI, just for good measure), still no VLAN interfaces were present
  on my system.

  I also tried editing the VLAN interface in the UI, and specifying
  "enp4s0f1.100", but still no VLAN interface came online.

  # apt-cache policy network-manager
  network-manager:
Installed: 1.0.4-0ubuntu6
Candidate: 1.0.4-0ubuntu6
Version table:
   *** 1.0.4-0ubuntu6 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  # apt-cache policy vlan
  vlan:
Installed: 1.9-3.2ubuntu1
Candidate: 1.9-3.2ubuntu1
Version table:
   *** 1.9-3.2ubuntu1 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1519120/+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 1519120] Re: Xenial: VLAN interfaces don't work when defined in the UI

[Mike Pontillo]

(For the record, 172.16.42.88 is my local mirror of
us.archive.ubuntu.com and is updated hourly.)

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

Title:
  Xenial: VLAN interfaces don't work when defined in the UI

Status in network-manager package in Ubuntu:
  New

Bug description:
  I tried to use the network manager UI to define a VLAN interface, and
  nothing happened. There are a few bugs here:

  (1) When creating a VLAN interface through the UI, the "vlan interface
  name" must be filled in. This should just default to ., rather than being a required field. (I typed in "vlan100"
  to get the "Save" button to activate.)

  (2) After creating my VLAN interface, nothing happened. No new
  interface appeared. I then realized that I had not installed the
  "vlan" package, and assumed that NetworkManager therefore could not
  complete configuration of the interface.

  (3) After installing the 'vlan' package (and then telling
  NetworkManager to disconnect and reconnect my Ethernet interface from
  the UI, just for good measure), still no VLAN interfaces were present
  on my system.

  I also tried editing the VLAN interface in the UI, and specifying
  "enp4s0f1.100", but still no VLAN interface came online.

  # apt-cache policy network-manager
  network-manager:
Installed: 1.0.4-0ubuntu6
Candidate: 1.0.4-0ubuntu6
Version table:
   *** 1.0.4-0ubuntu6 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  # apt-cache policy vlan
  vlan:
Installed: 1.9-3.2ubuntu1
Candidate: 1.9-3.2ubuntu1
Version table:
   *** 1.9-3.2ubuntu1 0
  500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1519120/+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 1518118] [NEW] IBus 1.5.11 needs to be packaged, to avoid breaking certain software

[Mike Pontillo]

Public bug reported:

IBus 1.5.11 needs to be packaged.

Whenever I launch a recent JetBrains IDE (such as PyCharm), it warns on
startup that IBus has a bug that can cause input to be blocked.

See: https://youtrack.jetbrains.com/issue/IDEA-78860

They claim that IBus 1.5.11 is needed in order to resolve the issue.

** Affects: ibus (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ibus in Ubuntu.
https://bugs.launchpad.net/bugs/1518118

Title:
  IBus 1.5.11 needs to be packaged, to avoid breaking certain software

Status in ibus package in Ubuntu:
  New

Bug description:
  IBus 1.5.11 needs to be packaged.

  Whenever I launch a recent JetBrains IDE (such as PyCharm), it warns
  on startup that IBus has a bug that can cause input to be blocked.

  See: https://youtrack.jetbrains.com/issue/IDEA-78860

  They claim that IBus 1.5.11 is needed in order to resolve the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1518118/+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 1439436] Re: NM in vivid tries to take over my libvirt bridge, deconfigures its address

[Mike Pontillo]

I missed some relevant logs:

SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/eth0.1, iface: 
eth0.1)
SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/eth0.1, iface: 
eth0.1): no ifupdown configuration found.

>From that, I think I found the root cause. After doing "apt-get source
network-manager" and grepping for "no ifupdown configuration found", I
looked in src/settings/plugins/ifupdown/plugin.c and found the function
udev_device_added(), which does a g_hash_table_lookup() to find out if
the interface is managed or not.

It appears that NetworkManager doesn't ever refresh its idea of the
interfaces list. So if you edit /etc/network/interfaces, NetworkManager
doesn't update its internal hashtable of unmanaged interfaces.

Therefore, the following is a workaround:

sudo invoke-rc.d network-manager restart
sudo ifup 

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

Title:
  NM in vivid tries to take over my libvirt bridge, deconfigures its
  address

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  Over the past couple of months in vivid, from time to time I have
  noticed that my virbr0 interface, which is set up and managed by
  libvirt-bin, has been in an "up" state with no IP address configured.

  As I don't use VMs on my laptop very frequently, I don't know when the
  problem started and I don't know when exactly the problem is being
  triggered.  But a search through logs shows the following:

  Mar 16 16:48:56 virgil systemd[1]: Stopping Network Manager...
  [...]
  Mar 16 16:48:56 virgil NetworkManager[32588]:  (virbr0): device state 
change: activated -> deactivating (reason 'removed') [100 110 36]
  Mar 16 16:48:56 virgil NetworkManager[32588]:  (virbr0): device state 
change: deactivating -> unmanaged (reason 'removed') [110 10 36]
  Mar 16 16:48:56 virgil NetworkManager[32588]:  (virbr0): deactivating 
device (reason 'removed') [36]
  Mar 16 16:48:56 virgil avahi-daemon[1336]: Withdrawing address record for 
192.168.122.1 on virbr0.
  [...]
  Mar 16 16:48:56 virgil systemd[1]: Starting Network Manager Script Dispatcher 
Service...
  [...]
  Mar 16 16:48:56 virgil systemd[1]: Started Network Manager Script Dispatcher 
Service.
  [...]
  Mar 16 16:48:56 virgil nm-dispatcher: Dispatching action 'down' for virbr0
  [...]
  Mar 16 16:48:56 virgil systemd[1]: Starting Network Manager...
  [...]
  Mar 16 16:48:56 virgil NetworkManager[6097]:  devices added (path: 
/sys/devices/virtual/net/virbr0, iface: virbr0)
  Mar 16 16:48:56 virgil NetworkManager[6097]:  device added (path: 
/sys/devices/virtual/net/virbr0, iface: virbr0): no ifupdown configuration 
found.
  [...]
  Mar 16 16:49:01 virgil systemd[1]: Started Network Manager.
  [...]
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): carrier is OFF
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): new Bridge 
device (driver: 'bridge' ifindex: 5)
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): exported as 
/org/freedesktop/NetworkManager/Devices/4
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): device state 
change: unmanaged -> unavailable (reason 'managed') [10 20 2]
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): device not up 
after timeout!
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): preparing device
  Mar 16 16:49:02 virgil NetworkManager[6097]: nm_device_get_device_type: 
assertion 'NM_IS_DEVICE (self)' failed

  
  The interface 'virbr0' also shows up in nm-applet's display, which was never 
the case before.  This interface has always been managed by the libvirt-bin 
startup scripts (which causes problems of its own, since a 'service libvirt-bin 
restart' does not reinitialize the network and a 'service libvirt-bin stop' 
does not stop it).  The bring-up of virbr0 appears to still be handled by 
libvirt-bin, not by NM; but somehow NM has a device configuration for it and is 
downing the interface on service stop - and not restoring it on service start.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: network-manager 0.9.10.0-4ubuntu13
  ProcVersionSignature: Ubuntu 3.19.0-7.7-generic 3.19.0
  Uname: Linux 3.19.0-7-generic x86_64
  ApportVersion: 2.17-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Apr  1 15:48:28 2015
  InstallationDate: Installed on 2010-09-24 (1650 days ago)
  InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 
(20100816.1)
  IpRoute:
   default via 192.168.15.1 dev wlan2  proto static  metric 1024 
   169.254.0.0/16 dev virbr0  scope link  metric 1000 
   192.168.15.0/24 dev wlan2  proto kernel  scope link  src 192.168.15.71 
   192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 
   207.224.24.209 via 192.168.15.1 dev wlan2  proto dhcp  metric 10
  NetworkManager.state:
   [main]
   NetworkingEnable

[Touch-packages] [Bug 1439436] Re: NM in vivid tries to take over my libvirt bridge, deconfigures its address

[Mike Pontillo]

I'm seeing this on Trusty for VLAN interfaces. In the log I see:

 (eth0.1): carrier is OFF
 (eth0.1): VLAN ID 1 with parent eth0
 (eth0.1): new VLAN device (driver: '8021q' ifindex: 26)
 (eth0.1): exported as /org/freedesktop/NetworkManager/Devices/18
 (eth0.1): device state change: unmanaged -> unavailable (reason 
'managed') [10 20 2]
 (eth0.1): deactivating device (reason 'managed') [2]

In /etc/NetworkManager/NetworkManager.conf I have:

[ifupdown]
managed=false

... which should mean that anything listed in /etc/network/interfaces
should be ignored.

In my /etc/network/interfaces file I have:

auto eth0.1
iface eth0.1 inet static
  address 100.64.0.1/24

So NetworkManager is incorrectly marking this interface as managed.
(according to the man page, you don't need "auto" for non-physical
interfaces, but I tried putting it in there anyway, in case
NetworkManager was looking for it in /etc/network/interfaces)

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

Title:
  NM in vivid tries to take over my libvirt bridge, deconfigures its
  address

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  Over the past couple of months in vivid, from time to time I have
  noticed that my virbr0 interface, which is set up and managed by
  libvirt-bin, has been in an "up" state with no IP address configured.

  As I don't use VMs on my laptop very frequently, I don't know when the
  problem started and I don't know when exactly the problem is being
  triggered.  But a search through logs shows the following:

  Mar 16 16:48:56 virgil systemd[1]: Stopping Network Manager...
  [...]
  Mar 16 16:48:56 virgil NetworkManager[32588]:  (virbr0): device state 
change: activated -> deactivating (reason 'removed') [100 110 36]
  Mar 16 16:48:56 virgil NetworkManager[32588]:  (virbr0): device state 
change: deactivating -> unmanaged (reason 'removed') [110 10 36]
  Mar 16 16:48:56 virgil NetworkManager[32588]:  (virbr0): deactivating 
device (reason 'removed') [36]
  Mar 16 16:48:56 virgil avahi-daemon[1336]: Withdrawing address record for 
192.168.122.1 on virbr0.
  [...]
  Mar 16 16:48:56 virgil systemd[1]: Starting Network Manager Script Dispatcher 
Service...
  [...]
  Mar 16 16:48:56 virgil systemd[1]: Started Network Manager Script Dispatcher 
Service.
  [...]
  Mar 16 16:48:56 virgil nm-dispatcher: Dispatching action 'down' for virbr0
  [...]
  Mar 16 16:48:56 virgil systemd[1]: Starting Network Manager...
  [...]
  Mar 16 16:48:56 virgil NetworkManager[6097]:  devices added (path: 
/sys/devices/virtual/net/virbr0, iface: virbr0)
  Mar 16 16:48:56 virgil NetworkManager[6097]:  device added (path: 
/sys/devices/virtual/net/virbr0, iface: virbr0): no ifupdown configuration 
found.
  [...]
  Mar 16 16:49:01 virgil systemd[1]: Started Network Manager.
  [...]
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): carrier is OFF
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): new Bridge 
device (driver: 'bridge' ifindex: 5)
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): exported as 
/org/freedesktop/NetworkManager/Devices/4
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): device state 
change: unmanaged -> unavailable (reason 'managed') [10 20 2]
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): device not up 
after timeout!
  Mar 16 16:49:02 virgil NetworkManager[6097]:  (virbr0): preparing device
  Mar 16 16:49:02 virgil NetworkManager[6097]: nm_device_get_device_type: 
assertion 'NM_IS_DEVICE (self)' failed

  
  The interface 'virbr0' also shows up in nm-applet's display, which was never 
the case before.  This interface has always been managed by the libvirt-bin 
startup scripts (which causes problems of its own, since a 'service libvirt-bin 
restart' does not reinitialize the network and a 'service libvirt-bin stop' 
does not stop it).  The bring-up of virbr0 appears to still be handled by 
libvirt-bin, not by NM; but somehow NM has a device configuration for it and is 
downing the interface on service stop - and not restoring it on service start.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: network-manager 0.9.10.0-4ubuntu13
  ProcVersionSignature: Ubuntu 3.19.0-7.7-generic 3.19.0
  Uname: Linux 3.19.0-7-generic x86_64
  ApportVersion: 2.17-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Apr  1 15:48:28 2015
  InstallationDate: Installed on 2010-09-24 (1650 days ago)
  InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 
(20100816.1)
  IpRoute:
   default via 192.168.15.1 dev wlan2  proto static  metric 1024 
   169.254.0.0/16 dev virbr0  scope link  metric 1000 
   192.168.15.0/24 dev wlan2  proto kernel  scope link  src 192.168.15.71 
   192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 
   207.224.24.209 via 192.168.15.1 dev wlan2  proto dhcp