from:"Gavin Panella"

[Touch-packages] [Bug 1603953] Re: timesyncd is not stopped when ntp is first installed

2017-03-16 Thread Gavin Panella

*** This bug is a duplicate of bug 1597909 ***
https://bugs.launchpad.net/bugs/1597909

** This bug has been marked a duplicate of bug 1597909
   systemd-timesyncd unit still running after installation of ntp package

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

Title:
  timesyncd is not stopped when ntp is first installed

Status in ntp package in Ubuntu:
  New

Bug description:
  In Xenial, /lib/systemd/system/systemd-timesyncd.service.d/disable-
  with-time-daemon.conf ensures that systemd-timesyncd.service does not
  _start_ when ntp is installed, but when installing ntp for the first
  time nothing stops systemd-timesyncd before ntp is started: they're
  both running at the same time.

  It could be some time between installing ntp and, say, rebooting,
  during which time both services will be trying to manage the local
  clock. This might not matter much for a client, but might be important
  for an NTP server.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ntp 1:4.2.8p4+dfsg-3ubuntu5
  ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
  Uname: Linux 4.4.0-31-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Mon Jul 18 12:17:25 2016
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1603953/+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 1629972] Re: networking stop incorrectly disconnects from (network) root filesystem

2016-12-20 Thread Gavin Panella

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

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

Title:
  networking stop incorrectly disconnects from (network) root filesystem

Status in MAAS:
  Confirmed
Status in ifupdown package in Ubuntu:
  Fix Released
Status in ifupdown source package in Xenial:
  Fix Released
Status in ifupdown source package in Yakkety:
  Fix Released
Status in ifupdown package in Debian:
  New

Bug description:
  === Begin SRU Template ===
  [Impact]
  The systemd networking.service unit will bring down the loopback device (lo)
  when it is stopped.  This behavior differs from the behavior in other
  Ubuntu releases (upstart's networking.conf), where 'lo' is not taken down.

  The problem that was seen was that iscsi root over ipv6 would hang on
  shutdown.  

  [Test Case]
  Test is fairly simple and can be demonstrated in lxc container.
  The key is really that the lo device should not have its link set down
  after stopping networking.service.  So, below:
out=$(ip address show dev lo up); [ -n "$out" ] && echo "$out" || echo empty

  should not show 'empty', but should have LOOPBACK,UP,LOWER in its
  output.

  $ release=yakkety; name=y1
  $ lxc launch ubuntu-daily:$release $name
  $ sleep 10
  $ lxc exec $name /bin/bash

  ## show only things that are up (note output has LOOPBACK,UP,LOWER_UP)
  % ip link show dev lo
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

  % ip address show dev lo up
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever

  ## Stop the service and show lo link is down (no 'UP' or 'LOWER_UP').
  % systemctl stop networking.service
  % ip link show dev lo
  1: lo:  mtu 65536 qdisc noqueue state DOWN mode DEFAULT group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  % out=$(ip address show dev lo up); [ -n "$out" ] && echo "$out" || echo empty
  empty

  ## Now enable proposed, install update, reboot and show.
  % rel=$(lsb_release -sc)
  % echo "deb http://archive.ubuntu.com/ubuntu $rel-proposed main" |
  sudo tee /etc/apt/sources.list.d/proposed.list
  % sudo apt update -qy && sudo apt install -qy ifupdown  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  % ip address show dev lo up
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
  % systemctl stop networking.service
  % ip link show dev lo
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  % out=$(ip address show dev lo up); [ -n "$out" ] && echo "$out" || echo empty
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever

  
  [Regression Potential]
  Should be pretty low.  zesty and  yakkety-proposed have this.
  Taking down 'lo' is often cause of problems, and never the solution to
  problems as far as I'm aware.

  [Other Info]

  === End SRU Template ===

  With the switch to systemd, all support for iscsi root (and other)
  filesystems disappeared, since shutdown yanks the rug out from under
  us.

  Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
  creates..), the DEV check should be expanded to include iscsi devices,
  and networking.service ExecStop should honor those checks.

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1629972/+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

2016-09-26 Thread Gavin Panella

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

-- 
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:
  In Progress
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in klibc package in Ubuntu:
  New
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 Committed
Status in klibc source package in Xenial:
  New
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 1603953] [NEW] timesyncd is not stopped when ntp is first installed

2016-07-18 Thread Gavin Panella

Public bug reported:

In Xenial, /lib/systemd/system/systemd-timesyncd.service.d/disable-with-
time-daemon.conf ensures that systemd-timesyncd.service does not _start_
when ntp is installed, but when installing ntp for the first time
nothing stops systemd-timesyncd before ntp is started: they're both
running at the same time.

It could be some time between installing ntp and, say, rebooting, during
which time both services will be trying to manage the local clock. This
might not matter much for a client, but might be important for an NTP
server.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ntp 1:4.2.8p4+dfsg-3ubuntu5
ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
Uname: Linux 4.4.0-31-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
Date: Mon Jul 18 12:17:25 2016
SourcePackage: ntp
UpgradeStatus: No upgrade log present (probably fresh install)

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


** Tags: amd64 apport-bug xenial

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

Title:
  timesyncd is not stopped when ntp is first installed

Status in ntp package in Ubuntu:
  New

Bug description:
  In Xenial, /lib/systemd/system/systemd-timesyncd.service.d/disable-
  with-time-daemon.conf ensures that systemd-timesyncd.service does not
  _start_ when ntp is installed, but when installing ntp for the first
  time nothing stops systemd-timesyncd before ntp is started: they're
  both running at the same time.

  It could be some time between installing ntp and, say, rebooting,
  during which time both services will be trying to manage the local
  clock. This might not matter much for a client, but might be important
  for an NTP server.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ntp 1:4.2.8p4+dfsg-3ubuntu5
  ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
  Uname: Linux 4.4.0-31-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Mon Jul 18 12:17:25 2016
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1603953/+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 1603947] Re: ntp dhclient exit hook does not remove most servers

2016-07-18 Thread Gavin Panella

** No longer affects: maas

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

Title:
  ntp dhclient exit hook does not remove most servers

Status in ntp package in Ubuntu:
  New

Bug description:
  /etc/dhcp/dhclient-exit-hooks.d/ntp uses the following command to copy
  /etc/ntp.conf, stripping all-but-local NTP servers:

sed -r -e '/^ *(server *[^1][^2][^7]\.|peer).*$/d' $NTP_CONF

  However this expression is almost completely broken. It will eliminate
  "server foo.example.com" but not "server foobar.example.com", "server
  216.1.2.3" but not "server 217.1.2.3" or "server 10.1.2.3".

  This has been noted in bug 575458 by Jeffrey Hutzelman and Robie Basak
  has corrected this problem in Xenial, but this behaviour MAY cause
  problems for MAAS 2.1 (currently in development) when Trusty is deployed
  or used on a device on a MAAS-managed network.

  Context: MAAS 2.1 will be managing an NTP service and informing DHCP
  clients to use it via the ntp-servers option.

  I estimate that this would be a low-impact problem; failure modes are
  likely to be fairly benign. I'm filing this bug because, well, it is a
  bug, and it's documenting what might turn out to be a genuine problem.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: ntp 1:4.2.6.p5+dfsg-3ubuntu2.14.04.8
  ProcVersionSignature: Ubuntu 4.2.0-42.49~14.04.1-generic 4.2.8-ckt12
  Uname: Linux 4.2.0-42-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.21
  Architecture: amd64
  Date: Mon Jul 18 11:24:15 2016
  InstallationDate: Installed on 2016-04-13 (95 days ago)
  InstallationMedia: Ubuntu-Server 14.04.4 LTS "Trusty Tahr" - Release amd64 
(20160217.1)
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1603947/+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 1603947] [NEW] ntp dhclient exit hook does not remove most servers

2016-07-18 Thread Gavin Panella

Public bug reported:

/etc/dhcp/dhclient-exit-hooks.d/ntp uses the following command to copy
/etc/ntp.conf, stripping all-but-local NTP servers:

  sed -r -e '/^ *(server *[^1][^2][^7]\.|peer).*$/d' $NTP_CONF

However this expression is almost completely broken. It will eliminate
"server foo.example.com" but not "server foobar.example.com", "server
216.1.2.3" but not "server 217.1.2.3" or "server 10.1.2.3".

This has been noted in bug 575458 by Jeffrey Hutzelman and Robie Basak
has corrected this problem in Xenial, but this behaviour MAY cause
problems for MAAS 2.1 (currently in development) when Trusty is deployed
or used on a device on a MAAS-managed network.

Context: MAAS 2.1 will be managing an NTP service and informing DHCP
clients to use it via the ntp-servers option.

I estimate that this would be a low-impact problem; failure modes are
likely to be fairly benign. I'm filing this bug because, well, it is a
bug, and it's documenting what might turn out to be a genuine problem.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: ntp 1:4.2.6.p5+dfsg-3ubuntu2.14.04.8
ProcVersionSignature: Ubuntu 4.2.0-42.49~14.04.1-generic 4.2.8-ckt12
Uname: Linux 4.2.0-42-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.21
Architecture: amd64
Date: Mon Jul 18 11:24:15 2016
InstallationDate: Installed on 2016-04-13 (95 days ago)
InstallationMedia: Ubuntu-Server 14.04.4 LTS "Trusty Tahr" - Release amd64 
(20160217.1)
SourcePackage: ntp
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: maas
 Importance: Low
 Status: Triaged

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


** Tags: amd64 apport-bug trusty

** Also affects: maas
   Importance: Undecided
   Status: New

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

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

** Summary changed:

- dhclient exit hook does not remove most servers
+ ntp dhclient exit hook does not remove most servers

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

Title:
  ntp dhclient exit hook does not remove most servers

Status in MAAS:
  Triaged
Status in ntp package in Ubuntu:
  New

Bug description:
  /etc/dhcp/dhclient-exit-hooks.d/ntp uses the following command to copy
  /etc/ntp.conf, stripping all-but-local NTP servers:

sed -r -e '/^ *(server *[^1][^2][^7]\.|peer).*$/d' $NTP_CONF

  However this expression is almost completely broken. It will eliminate
  "server foo.example.com" but not "server foobar.example.com", "server
  216.1.2.3" but not "server 217.1.2.3" or "server 10.1.2.3".

  This has been noted in bug 575458 by Jeffrey Hutzelman and Robie Basak
  has corrected this problem in Xenial, but this behaviour MAY cause
  problems for MAAS 2.1 (currently in development) when Trusty is deployed
  or used on a device on a MAAS-managed network.

  Context: MAAS 2.1 will be managing an NTP service and informing DHCP
  clients to use it via the ntp-servers option.

  I estimate that this would be a low-impact problem; failure modes are
  likely to be fairly benign. I'm filing this bug because, well, it is a
  bug, and it's documenting what might turn out to be a genuine problem.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: ntp 1:4.2.6.p5+dfsg-3ubuntu2.14.04.8
  ProcVersionSignature: Ubuntu 4.2.0-42.49~14.04.1-generic 4.2.8-ckt12
  Uname: Linux 4.2.0-42-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.21
  Architecture: amd64
  Date: Mon Jul 18 11:24:15 2016
  InstallationDate: Installed on 2016-04-13 (95 days ago)
  InstallationMedia: Ubuntu-Server 14.04.4 LTS "Trusty Tahr" - Release amd64 
(20160217.1)
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1603947/+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 1523847] [NEW] dircolors produces no colour information

2015-12-08 Thread Gavin Panella

Public bug reported:

The dircolors default database is populated:

  $ dircolors --print-database
  # Configuration file for dircolors, a utility to help you set the
  # LS_COLORS environment variable used by GNU ls with the --color option.
  ...
  .axa 00;36
  .oga 00;36
  .spx 00;36
  .xspf 00;36

However nothing gets produced when asking it to render LS_COLORS:

  $ dircolors --bourne-shell
  LS_COLORS='';
  export LS_COLORS

  $ dircolors --csh
  setenv LS_COLORS ''

I would expect something more like:

  $ dircolors --bourne-shell
  LS_COLORS='...=00;36:*.spx=00;36:*.xspf=00;36:';
  export LS_COLORS

and:

  $ dircolors --csh
  setenv LS_COLORS '...=00;36:*.spx=00;36:*.xspf=00;36:'

where the ellipsis represents many similar rules.

The same happens when using dircolors with an existing database file:

  $ dircolors --bourne-shell /path/to/dircolors/database
  LS_COLORS='';
  export LS_COLORS

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: coreutils 8.23-4ubuntu2
ProcVersionSignature: Ubuntu 4.3.0-2.11-generic 4.3.0
Uname: Linux 4.3.0-2-generic x86_64
ApportVersion: 2.19.2-0ubuntu9
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Dec  8 09:45:16 2015
InstallationDate: Installed on 2014-03-16 (631 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140316)
SourcePackage: coreutils
UpgradeStatus: Upgraded to xenial on 2015-11-22 (15 days ago)

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


** Tags: amd64 apport-bug xenial

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

Title:
  dircolors produces no colour information

Status in coreutils package in Ubuntu:
  New

Bug description:
  The dircolors default database is populated:

    $ dircolors --print-database
    # Configuration file for dircolors, a utility to help you set the
    # LS_COLORS environment variable used by GNU ls with the --color option.
    ...
    .axa 00;36
    .oga 00;36
    .spx 00;36
    .xspf 00;36

  However nothing gets produced when asking it to render LS_COLORS:

    $ dircolors --bourne-shell
    LS_COLORS='';
    export LS_COLORS

    $ dircolors --csh
    setenv LS_COLORS ''

  I would expect something more like:

    $ dircolors --bourne-shell
    LS_COLORS='...=00;36:*.spx=00;36:*.xspf=00;36:';
    export LS_COLORS

  and:

    $ dircolors --csh
    setenv LS_COLORS '...=00;36:*.spx=00;36:*.xspf=00;36:'

  where the ellipsis represents many similar rules.

  The same happens when using dircolors with an existing database file:

    $ dircolors --bourne-shell /path/to/dircolors/database
    LS_COLORS='';
    export LS_COLORS

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: coreutils 8.23-4ubuntu2
  ProcVersionSignature: Ubuntu 4.3.0-2.11-generic 4.3.0
  Uname: Linux 4.3.0-2-generic x86_64
  ApportVersion: 2.19.2-0ubuntu9
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Dec  8 09:45:16 2015
  InstallationDate: Installed on 2014-03-16 (631 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140316)
  SourcePackage: coreutils
  UpgradeStatus: Upgraded to xenial on 2015-11-22 (15 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1523847/+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 1355813] Re: Interface MTU management across MAAS/juju

2015-09-03 Thread Gavin Panella

** Tags removed: network
** Tags added: networking

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

Title:
  Interface MTU management across MAAS/juju

Status in juju-core:
  Fix Released
Status in MAAS:
  Triaged
Status in juju-core package in Ubuntu:
  Triaged
Status in lxc package in Ubuntu:
  Invalid

Bug description:
  Context:

  juju + MAAS deployed OpenStack environment, misc services deployed
  under LXC on the bootstrap node, interfaces configured for jumbo
  frames - note that I had to manually set the LXC container interfaces
  to mtu 9000 before the bridge would do the same.

  Action:

  Reboot one of the containers; MTU on br0 resets from 9000 -> 1500.

  This feels like more of a 'we need a better way to orchestrate MTU
  configuration across different services' so raising tasks for MAAS and
  Juju as well.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: lxc 1.0.5-0ubuntu0.1
  ProcVersionSignature: User Name 3.13.0-24.47-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.3
  Architecture: amd64
  Date: Tue Aug 12 13:26:00 2014
  KernLog:

  SourcePackage: lxc
  UpgradeStatus: No upgrade log present (probably fresh install)
  defaults.conf:
   lxc.network.type = veth
   lxc.network.link = lxcbr0
   lxc.network.flags = up
   lxc.network.hwaddr = 00:16:3e:xx:xx:xx
  lxcsyslog:

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1355813/+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 1603953] Re: timesyncd is not stopped when ntp is first installed

[Touch-packages] [Bug 1629972] Re: networking stop incorrectly disconnects from (network) root filesystem

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[Touch-packages] [Bug 1603953] [NEW] timesyncd is not stopped when ntp is first installed

[Touch-packages] [Bug 1603947] Re: ntp dhclient exit hook does not remove most servers

[Touch-packages] [Bug 1603947] [NEW] ntp dhclient exit hook does not remove most servers

[Touch-packages] [Bug 1523847] [NEW] dircolors produces no colour information

[Touch-packages] [Bug 1355813] Re: Interface MTU management across MAAS/juju

8 matches

Site Navigation

Mail list logo

Footer information