[Touch-packages] [Bug 1920836] Re: Show Extended Security Maintenence status

2021-03-26 Thread Chad Smith
Another thing to note/expect: ua client in release in xenial and bionic
at the moment is a completed incompatible commandine (which we are
planning on SRUing prior to Xenial ESM, so `ua status --format=json`
will not work on something <  version 20. I'm fairly certain you
shouldn't care to support this old version of ua-tools, but you might
want to just do a pre-flight check on Xenial and bionic 'ua version' >=
20 and return (False, False) in that case notiing that those
environments should update their versionn of ubuntu-advantage-tools.

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

Title:
  Show Extended Security Maintenence status

Status in software-properties package in Ubuntu:
  New
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  New
Status in software-properties source package in Focal:
  New
Status in software-properties source package in Hirsute:
  New

Bug description:
  [Impact]
  There is not currently a graphical method of determining if a system is 
subscribed to [Extended Security Maintenance](https://ubuntu.com/security/esm) 
updates. This is resolved by adding some [new 
UI](https://wiki.ubuntu.com/SoftwareUpdates#Extended_Security_Maintenance) to 
the software properties application.

  [Test Case]
  1. Install latest version of Ubuntu advantage:
  $ sudo add-apt-repository ppa:ua-client/stable
  $ sudo apt update
  $ sudo apt upgrade
  2. Open Software Properties
  3. Go to Updates tab.

  Expected result:
  Information is shown that indicates if this system is using Extended Security 
Maintenance updates, when updates will supported until, and a link to upgrade 
to ESM.

  Observed result:
  No ESM information currently shown.

  [Where problems could occur]
  - Software properties could hit a bug getting a response from the ua app. The 
current code carefully checks if and what is returned, falling back to a safe 
default behavior.
  - Launching software properties could trigger a bug in the ua app.
  - Software properties could show incorrect information, causing confusion for 
the user. The solution uses information from distro-info and the ua app which 
means software-properties contains no data about ESM, and instead relies on 
these apps that can be updated if things change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1920836/+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 1920836] Re: Show Extended Security Maintenence status

2021-03-26 Thread Chad Smith
Thanks @robert-ancell for setting up the PPA.

I tested on Xenial Ubuntu Desktop LiveCD and would like to report
Failure on this implementation.

Your use of subprocess is passing capture_output on xenial and that is
raising an error in python before calling ua client.


On a system attached to esm-apps:


python3 -c 'import gi; gi.require_version("Gtk", "3.0"); from 
softwareproperties.gtk.utils import get_esm_apps_status; 
print(get_esm_apps_status())'
Failed to call ubuntu advantage client:
__init__() got an unexpected keyword argument 'capture_output'
(False, False)


Note that run(capture_output) param is not available on python3.5 (it was 
introduced only in 3.7).

Also just dropping that capture_output param you've got some other logic
relying on result.stdout which is None in this case.

while you iterate on this work, you could substitute esm-infra  in your 
get_esm_apps_status function as it'll behave the same way as app, and all 
contracts are entitled to esm-infra at the moment so it will be easier to test 
enabled, available etc.
 
If you'd like review on the iterations of these SRU branches related to this 
just assign lamoura or chad.smith too and we can take a look.

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

Title:
  Show Extended Security Maintenence status

Status in software-properties package in Ubuntu:
  New
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  New
Status in software-properties source package in Focal:
  New
Status in software-properties source package in Hirsute:
  New

Bug description:
  [Impact]
  There is not currently a graphical method of determining if a system is 
subscribed to [Extended Security Maintenance](https://ubuntu.com/security/esm) 
updates. This is resolved by adding some [new 
UI](https://wiki.ubuntu.com/SoftwareUpdates#Extended_Security_Maintenance) to 
the software properties application.

  [Test Case]
  1. Install latest version of Ubuntu advantage:
  $ sudo add-apt-repository ppa:ua-client/stable
  $ sudo apt update
  $ sudo apt upgrade
  2. Open Software Properties
  3. Go to Updates tab.

  Expected result:
  Information is shown that indicates if this system is using Extended Security 
Maintenance updates, when updates will supported until, and a link to upgrade 
to ESM.

  Observed result:
  No ESM information currently shown.

  [Where problems could occur]
  - Software properties could hit a bug getting a response from the ua app. The 
current code carefully checks if and what is returned, falling back to a safe 
default behavior.
  - Launching software properties could trigger a bug in the ua app.
  - Software properties could show incorrect information, causing confusion for 
the user. The solution uses information from distro-info and the ua app which 
means software-properties contains no data about ESM, and instead relies on 
these apps that can be updated if things change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1920836/+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 1915547] Re: Users are prompted by ucf on upgrade from Trusty to Xenial

2021-03-23 Thread Chad Smith
** 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 unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1915547

Title:
  Users are prompted by ucf on upgrade from Trusty to Xenial

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  During an upgrade from trusty to xenial, users will be prompted to make a 
decision regarding the diff on unattended-upgrades. This is not a good user 
experience, specially because the user can make an uninformed decision of 
keeping the old config file, which will make unattended-upgrades to not work as 
we expect.

  [Test case]

  To reproduce the issue, you can:

  1. Launch a trusty vm
  2. Perform a do-release-upgrade and observe that you will be prompted with 
the 50unattended-upgrades change

  To verify that the error is fixed:

  1. Launch a trusty vm
  2. Import this ppa into the system:
 https://launchpad.net/~lamoura/+archive/ubuntu/unattended-upgrades-ppa
  3. Configure do-release-upgrade to allow using third parties during upgrade
  4. Run a do-release-upgrade
  5. Verify the prompt is no longer there and that we end up with the 
 expected 50unattended-upgrades config file

  [Where problems could occur]

  The changes in this package should only surface during an upgrade
  operation.  With this change, we are now delivering a new file to the
  system and configuring postinst to use it. Because of that, we believe
  this is the only scenario that could be affected in case of a
  regression is discovered in the package.

  
  [Discussion]
  When upgrading from trusty to xenial, we are prompted about config changes on 
50unattended-upgrades with the following diff:

  --- /etc/apt/apt.conf.d/50unattended-upgrades root.root 0644 2017-05-08 
19:21:39
  +++ /etc/apt/apt.conf.d/50unattended-upgrades.ucftmp root.root 0644 
2020-02-17 18:03:38
  @@ -1,11 +1,13 @@
   // Automatically upgrade packages from these (origin:archive) pairs
   Unattended-Upgrade::Allowed-Origins {
  + "${distro_id}:${distro_codename}";
   "${distro_id}:${distro_codename}-security";
   // Extended Security Maintenance; doesn't necessarily exist for
   // every release and this system may not have it installed, but if
   // available, the policy for updates is such that unattended-upgrades
   // should also install from here by default.
  - "${distro_id}ESM:${distro_codename}";
  + "${distro_id}ESMApps:${distro_codename}-apps-security";
  + "${distro_id}ESM:${distro_codename}-infra-security";
   // "${distro_id}:${distro_codename}-updates";
   // "${distro_id}:${distro_codename}-proposed";
   // "${distro_id}:${distro_codename}-backports";

  The reason we are presented with this diff is that the xenial package
  does not contain a md5sum history file that informs ucf about all the
  supported configs for 50unattended-upgrades. To fix that upgrade
  problem, we are prosing the following changes on the xenial package of
  unattended-upgrades:

  - Add 50unattended-upgrades.md5sum file into the xenial package
  - Add md5sum of the current xenial 50unattende-upgrades file into the 
md5sum history file
  - Modify ucf command in postinst to be aware of the md5sum history file

  See the changelog entry below for a full list of changes and bugs.

  We have performed a manual test with a modified version of the xenial package:
  https://launchpad.net/~lamoura/+archive/ubuntu/unattended-upgrades-ppa

  Using that package, we were able to verify that the config change
  prompt no longer happens from trusty to xenial.

  Since we are modifying are features on unattended-upgrades, just
  adding a new file to package, we don't believe there is any regression
  potential

  
  == Changelog ==

    * data: add md5sum history file on the data folder
  - This file contains md5sum of several supported 50unattended-upgrades
    config files
    * data: add xenial md5sum of 50unattented-upgrades into md5sum file
    * debian/postint: make ucf command reference the md5sum history file

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1915547/+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 1915547] Re: Users are prompted by ucf on upgrade from Trusty to Xenial

2021-03-03 Thread Chad Smith
> For this SRU, I'd therefore expect to see being added only the hashes
involved in the specific issue being fixed - presumably only one -
rather than 117. Usually the above never comes up, but I think it's
relevant when there are 117, rather than the one or two entries that are
common.

> Similarly, for Hirsute, I'd have expected only the hashes since Focal
and onwards to be included.

Agreed Robie, I think this project needs that release-specific set of
md5sums to add. Lucas will limit this SRU to just the needed md5sum for
trusty -> xenial to avoid prompting.

Ultimately I'd like to track an upstream bug for the md5sum filtering
per release because there are 5 different versions of 50unattended-
upgrades for Debian/Raspbian/SteamOS/Devuan and the tooling to generate
these md5sum files should be distribution and release aware. This is
risk that we don't want to inadvertently add to this SRU.

So, let's track that upstream feature as LP:# 1917677

I think you are right that a subset of md5sums should be

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

Title:
  Users are prompted by ucf on upgrade from Trusty to Xenial

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Triaged

Bug description:
  [Impact]
  During an upgrade from trusty to xenial, users will be prompted to make a 
decision regarding the diff on unattended-upgrades. This is not a good user 
experience, specially because the user can make an uninformed decision of 
keeping the old config file, which will make unattended-upgrades to not work as 
we expect.

  [Test case]

  To reproduce the issue, you can:

  1. Launch a trusty vm
  2. Perform a do-release-upgrade and observe that you will be prompted with 
the 50unattended-upgrades change

  To verify that the error is fixed:

  1. Launch a trusty vm
  2. Import this ppa into the system:
 https://launchpad.net/~lamoura/+archive/ubuntu/unattended-upgrades-ppa
  3. Configure do-release-upgrade to allow using third parties during upgrade
  4. Run a do-release-upgrade
  5. Verify the prompt is no longer there and that we end up with the 
 expected 50unattended-upgrades config file

  [Where problems could occur]

  The changes in this package should only surface during an upgrade
  operation.  With this change, we are now delivering a new file to the
  system and configuring postinst to use it. Because of that, we believe
  this is the only scenario that could be affected in case of a
  regression is discovered in the package.

  
  [Discussion]
  When upgrading from trusty to xenial, we are prompted about config changes on 
50unattended-upgrades with the following diff:

  --- /etc/apt/apt.conf.d/50unattended-upgrades root.root 0644 2017-05-08 
19:21:39
  +++ /etc/apt/apt.conf.d/50unattended-upgrades.ucftmp root.root 0644 
2020-02-17 18:03:38
  @@ -1,11 +1,13 @@
   // Automatically upgrade packages from these (origin:archive) pairs
   Unattended-Upgrade::Allowed-Origins {
  + "${distro_id}:${distro_codename}";
   "${distro_id}:${distro_codename}-security";
   // Extended Security Maintenance; doesn't necessarily exist for
   // every release and this system may not have it installed, but if
   // available, the policy for updates is such that unattended-upgrades
   // should also install from here by default.
  - "${distro_id}ESM:${distro_codename}";
  + "${distro_id}ESMApps:${distro_codename}-apps-security";
  + "${distro_id}ESM:${distro_codename}-infra-security";
   // "${distro_id}:${distro_codename}-updates";
   // "${distro_id}:${distro_codename}-proposed";
   // "${distro_id}:${distro_codename}-backports";

  The reason we are presented with this diff is that the xenial package
  does not contain a md5sum history file that informs ucf about all the
  supported configs for 50unattended-upgrades. To fix that upgrade
  problem, we are prosing the following changes on the xenial package of
  unattended-upgrades:

  - Add 50unattended-upgrades.md5sum file into the xenial package
  - Add md5sum of the current xenial 50unattende-upgrades file into the 
md5sum history file
  - Modify ucf command in postinst to be aware of the md5sum history file

  See the changelog entry below for a full list of changes and bugs.

  We have performed a manual test with a modified version of the xenial package:
  https://launchpad.net/~lamoura/+archive/ubuntu/unattended-upgrades-ppa

  Using that package, we were able to verify that the config change
  prompt no longer happens from trusty to xenial.

  Since we are modifying are features on unattended-upgrades, just
  adding a new file to package, we don't believe there is any regression
  potential

  
  == Changelog ==

    * data: add md5sum history file on the data folder
  - This file contains md5sum of several supported 

[Touch-packages] [Bug 1917677] [NEW] ubuntu: ucf tracking of valid known md5sums should be limited to only those md5sums that affect a given distro release

2021-03-03 Thread Chad Smith
Public bug reported:

Currently the project tracks all valid md5sums of permutations of
50unattended-upgrades.conf in a single md5sum file that contains every
md5sum of every historic version of all unique distros:

 50unattended-upgrades.Debian
 50unattended-upgrades.Devuan
 50unattended-upgrades.Raspbian
 50unattended-upgrades.Ubuntu

Ultimately ucf for a given packaging release should only track the
applicable md5sums which are expected to be seen on that particular
distribution and release.

For example:
   On Ubuntu Bionic: valid md5sums should be limited to the md5sum of the most 
recent Ubuntu Xenial 50unattended-upgrades.conf and the md5sums of previous 
Ubuntu Bionic releases to allow Xenial->Bionic and Bionic->Bionic upgrades 
without prompt.

** Affects: unattended-upgrades (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: unattended-upgrades (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Affects: unattended-upgrades (Ubuntu Focal)
 Importance: Undecided
 Status: New

** Affects: unattended-upgrades (Ubuntu Groovy)
 Importance: Undecided
 Status: New

** Affects: unattended-upgrades (Ubuntu Hirsute)
 Importance: Undecided
 Status: New

** Also affects: unattended-upgrades (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

Title:
  ubuntu: ucf tracking of valid known md5sums   should be limited to
  only those md5sums that affect a given distro release

Status in unattended-upgrades package in Ubuntu:
  New
Status in unattended-upgrades source package in Bionic:
  New
Status in unattended-upgrades source package in Focal:
  New
Status in unattended-upgrades source package in Groovy:
  New
Status in unattended-upgrades source package in Hirsute:
  New

Bug description:
  Currently the project tracks all valid md5sums of permutations of
  50unattended-upgrades.conf in a single md5sum file that contains every
  md5sum of every historic version of all unique distros:

   50unattended-upgrades.Debian
   50unattended-upgrades.Devuan
   50unattended-upgrades.Raspbian
   50unattended-upgrades.Ubuntu

  Ultimately ucf for a given packaging release should only track the
  applicable md5sums which are expected to be seen on that particular
  distribution and release.

  For example:
 On Ubuntu Bionic: valid md5sums should be limited to the md5sum of the 
most recent Ubuntu Xenial 50unattended-upgrades.conf and the md5sums of 
previous Ubuntu Bionic releases to allow Xenial->Bionic and Bionic->Bionic 
upgrades without prompt.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1917677/+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 1915471] [NEW] FFe: base-files update MOTD help text formatting

2021-02-11 Thread Chad Smith
Public bug reported:

[Description]
Provide updated messaging text and formatting for MOTD 10-help-text related to 
text message organization, layout and verbiage.  Minor improvements for cleaner 
formatting of messages greeting ssh attaches to a machine.

[Rationale]
MOTD messaging is one of the primary means of communicating to Ubuntu server 
customers, we wish to improve the layout and messaging a bit to polish that 
experience a little bit for Hirsute and later.


[Timeline]
Current specs are in flight for base-files and update-notifier MOTD changes 
expect that we have final usability doc updates there by beginning of March.

[Risks]
Low risk as these changes are text-only formatting and potentially 
color-control characters. Potentially errors in any new partsdir files in 
/etc/update-motd.d/ are trapped and the offending text or invalid shell logic 
is geneally trapped and ignored without affecting other MOTD text

** Affects: base-files (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  FFe: base-files update MOTD help text formatting

Status in base-files package in Ubuntu:
  New

Bug description:
  [Description]
  Provide updated messaging text and formatting for MOTD 10-help-text related 
to text message organization, layout and verbiage.  Minor improvements for 
cleaner formatting of messages greeting ssh attaches to a machine.

  [Rationale]
  MOTD messaging is one of the primary means of communicating to Ubuntu server 
customers, we wish to improve the layout and messaging a bit to polish that 
experience a little bit for Hirsute and later.

  
  [Timeline]
  Current specs are in flight for base-files and update-notifier MOTD changes 
expect that we have final usability doc updates there by beginning of March.

  [Risks]
  Low risk as these changes are text-only formatting and potentially 
color-control characters. Potentially errors in any new partsdir files in 
/etc/update-motd.d/ are trapped and the offending text or invalid shell logic 
is geneally trapped and ignored without affecting other MOTD text

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1915471/+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 1867029] Re: Package ifupdown breaks network configuration by cloud-init

2020-05-08 Thread Chad Smith
This bug is believed to be fixed in cloud-init in version 20.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

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

Title:
  Package ifupdown breaks network configuration by cloud-init

Status in cloud-init:
  Fix Released
Status in ifupdown package in Ubuntu:
  New

Bug description:
  It appears the `ifupdown` package breaks networking configuration that
  cloud-init would normally handle (?) on both providers. The result, if
  you image an instance with the `ifupdown` package installed, is that
  the image is not bootable by Azure/AWS. I'm not familiar with how
  Azure/AWS/etc use cloud-init for network start up however. I'm filing
  here for now, in case `cloud-init` needs to be more defensive against
  `ifupdown`.

  To reproduce with Packer (I confirmed this method):

  * Add necessary Azure subscription env vars from `ifupdown-bug.json`
  * `packer build ifupdown-bug.json`
  * Try to boot an instance with resulting image
  * Instance will never boot -- more specifically, networking never comes up. 
See `boot.log` for an example boot

  To reproduce manually (only a guess, I did not confirm):

  * Boot 18.04 ubuntu instance
  * Install ifupdown
  * Image the instance
  * Try to boot instance using new image
  * Instance won't boot

  I hit this with Packer, creating new images for booting instances in
  scaling groups -- `ifupdown` is brought in by `salt`. If this is
  reproducible via manual installation, there could be some backup
  images/snapshots that are unable to boot though.

  This appears to be because cloud-init network start up operations are
  broken by whatever `ifupdown` sysv/systemd scripts perform on boot.
  With `ifupdown` installed on Azure, `eth0` does not get an IP address,
  the instance never fully boots according to Azure, and it will enter
  an error state. On AWS, the instance boots, but network operations
  like SSH fail.

  The `boot.log` is from Azure. Eventually `cloud-init` gives an
  exception (see `exception.log`), but this seems like a secondary issue
  related to networking being down.

  I did try to upgrade cloud-init using nightly PPAs (version 20.1 I
  believe), but no luck. This is on Ubuntu 18.04 instances from Azure
  marketplace and AWS Canonical AMI, cloud-init version
  `19.4-33-gbb4131a2-0ubuntu1~18.04.1`.

  Related: https://github.com/Azure/WALinuxAgent/issues/1612

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1867029/+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 1867029] Re: Package ifupdown breaks network configuration by cloud-init

2020-04-15 Thread Chad Smith
** Changed in: cloud-init
   Status: In Progress => Fix Committed

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

Title:
  Package ifupdown breaks network configuration by cloud-init

Status in cloud-init:
  Fix Committed
Status in ifupdown package in Ubuntu:
  New

Bug description:
  It appears the `ifupdown` package breaks networking configuration that
  cloud-init would normally handle (?) on both providers. The result, if
  you image an instance with the `ifupdown` package installed, is that
  the image is not bootable by Azure/AWS. I'm not familiar with how
  Azure/AWS/etc use cloud-init for network start up however. I'm filing
  here for now, in case `cloud-init` needs to be more defensive against
  `ifupdown`.

  To reproduce with Packer (I confirmed this method):

  * Add necessary Azure subscription env vars from `ifupdown-bug.json`
  * `packer build ifupdown-bug.json`
  * Try to boot an instance with resulting image
  * Instance will never boot -- more specifically, networking never comes up. 
See `boot.log` for an example boot

  To reproduce manually (only a guess, I did not confirm):

  * Boot 18.04 ubuntu instance
  * Install ifupdown
  * Image the instance
  * Try to boot instance using new image
  * Instance won't boot

  I hit this with Packer, creating new images for booting instances in
  scaling groups -- `ifupdown` is brought in by `salt`. If this is
  reproducible via manual installation, there could be some backup
  images/snapshots that are unable to boot though.

  This appears to be because cloud-init network start up operations are
  broken by whatever `ifupdown` sysv/systemd scripts perform on boot.
  With `ifupdown` installed on Azure, `eth0` does not get an IP address,
  the instance never fully boots according to Azure, and it will enter
  an error state. On AWS, the instance boots, but network operations
  like SSH fail.

  The `boot.log` is from Azure. Eventually `cloud-init` gives an
  exception (see `exception.log`), but this seems like a secondary issue
  related to networking being down.

  I did try to upgrade cloud-init using nightly PPAs (version 20.1 I
  believe), but no luck. This is on Ubuntu 18.04 instances from Azure
  marketplace and AWS Canonical AMI, cloud-init version
  `19.4-33-gbb4131a2-0ubuntu1~18.04.1`.

  Related: https://github.com/Azure/WALinuxAgent/issues/1612

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1867029/+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 1867029] Re: Package ifupdown breaks network configuration by cloud-init

2020-03-22 Thread Chad Smith
A separate bug has been filed against ifupdown package as well. Though
I'm not sure it will be a bug that will be fixed because Ubuntu Bionic
and later do not really support ifupdown, they support using netplan for
network configuration.

https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1868329

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

Title:
  Package ifupdown breaks network configuration by cloud-init

Status in cloud-init:
  In Progress
Status in ifupdown package in Ubuntu:
  New

Bug description:
  It appears the `ifupdown` package breaks networking configuration that
  cloud-init would normally handle (?) on both providers. The result, if
  you image an instance with the `ifupdown` package installed, is that
  the image is not bootable by Azure/AWS. I'm not familiar with how
  Azure/AWS/etc use cloud-init for network start up however. I'm filing
  here for now, in case `cloud-init` needs to be more defensive against
  `ifupdown`.

  To reproduce with Packer (I confirmed this method):

  * Add necessary Azure subscription env vars from `ifupdown-bug.json`
  * `packer build ifupdown-bug.json`
  * Try to boot an instance with resulting image
  * Instance will never boot -- more specifically, networking never comes up. 
See `boot.log` for an example boot

  To reproduce manually (only a guess, I did not confirm):

  * Boot 18.04 ubuntu instance
  * Install ifupdown
  * Image the instance
  * Try to boot instance using new image
  * Instance won't boot

  I hit this with Packer, creating new images for booting instances in
  scaling groups -- `ifupdown` is brought in by `salt`. If this is
  reproducible via manual installation, there could be some backup
  images/snapshots that are unable to boot though.

  This appears to be because cloud-init network start up operations are
  broken by whatever `ifupdown` sysv/systemd scripts perform on boot.
  With `ifupdown` installed on Azure, `eth0` does not get an IP address,
  the instance never fully boots according to Azure, and it will enter
  an error state. On AWS, the instance boots, but network operations
  like SSH fail.

  The `boot.log` is from Azure. Eventually `cloud-init` gives an
  exception (see `exception.log`), but this seems like a secondary issue
  related to networking being down.

  I did try to upgrade cloud-init using nightly PPAs (version 20.1 I
  believe), but no luck. This is on Ubuntu 18.04 instances from Azure
  marketplace and AWS Canonical AMI, cloud-init version
  `19.4-33-gbb4131a2-0ubuntu1~18.04.1`.

  Related: https://github.com/Azure/WALinuxAgent/issues/1612

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1867029/+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 1867029] Re: Package ifupdown breaks network configuration by cloud-init

2020-03-22 Thread Chad Smith
An upstream commit is up for review with a fix for this issue:
https://github.com/canonical/cloud-init/pull/267

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

Title:
  Package ifupdown breaks network configuration by cloud-init

Status in cloud-init:
  In Progress
Status in ifupdown package in Ubuntu:
  New

Bug description:
  It appears the `ifupdown` package breaks networking configuration that
  cloud-init would normally handle (?) on both providers. The result, if
  you image an instance with the `ifupdown` package installed, is that
  the image is not bootable by Azure/AWS. I'm not familiar with how
  Azure/AWS/etc use cloud-init for network start up however. I'm filing
  here for now, in case `cloud-init` needs to be more defensive against
  `ifupdown`.

  To reproduce with Packer (I confirmed this method):

  * Add necessary Azure subscription env vars from `ifupdown-bug.json`
  * `packer build ifupdown-bug.json`
  * Try to boot an instance with resulting image
  * Instance will never boot -- more specifically, networking never comes up. 
See `boot.log` for an example boot

  To reproduce manually (only a guess, I did not confirm):

  * Boot 18.04 ubuntu instance
  * Install ifupdown
  * Image the instance
  * Try to boot instance using new image
  * Instance won't boot

  I hit this with Packer, creating new images for booting instances in
  scaling groups -- `ifupdown` is brought in by `salt`. If this is
  reproducible via manual installation, there could be some backup
  images/snapshots that are unable to boot though.

  This appears to be because cloud-init network start up operations are
  broken by whatever `ifupdown` sysv/systemd scripts perform on boot.
  With `ifupdown` installed on Azure, `eth0` does not get an IP address,
  the instance never fully boots according to Azure, and it will enter
  an error state. On AWS, the instance boots, but network operations
  like SSH fail.

  The `boot.log` is from Azure. Eventually `cloud-init` gives an
  exception (see `exception.log`), but this seems like a secondary issue
  related to networking being down.

  I did try to upgrade cloud-init using nightly PPAs (version 20.1 I
  believe), but no luck. This is on Ubuntu 18.04 instances from Azure
  marketplace and AWS Canonical AMI, cloud-init version
  `19.4-33-gbb4131a2-0ubuntu1~18.04.1`.

  Related: https://github.com/Azure/WALinuxAgent/issues/1612

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1867029/+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 1868329] Re: ifupdown does not render viable /etc/network/interfaces on bionic ec2 cloud-images

2020-03-21 Thread Chad Smith
** Also affects: ifupdown (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: ifupdown (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: ifupdown (Ubuntu Eoan)
   Importance: Undecided
   Status: New

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

Title:
  ifupdown does not render viable /etc/network/interfaces on bionic ec2
  cloud-images

Status in ifupdown package in Ubuntu:
  New
Status in ifupdown source package in Bionic:
  New
Status in ifupdown source package in Eoan:
  New
Status in ifupdown source package in Focal:
  New

Bug description:
  Filing this bug for clarification and tracking on Ubuntu Bionic and
  later.

  Canonical cloudimages for Ec2 and other clouds leave an artifact that
  disables /etc/network/interface with the following content:

  # ifupdown has been replaced by netplan(5) on this system.  See
  # /etc/netplan for current configuration.
  # To re-enable ifupdown on this system, you can run:
  #sudo apt install ifupdown

  In following the suggested text, installing the ifupdown deb continues
  to leave a broken system because ifupdown.postinst script creates an
  /etc/network/interfaces.d parts directory but does not write out a
  working /etc/network/interfaces file if the file exists on the system.

  This leaves a broken /etc/network/interfaces files which doesn't
  source /etc/network/interfaces.d/* and 3rd parties cannot use the
  interfaces.d parts directory to extend networking config.

  Cloud-init is one of those users of /etc/network/interfaces.d/ for
  rendering system networking on cloud images. Per LP: #1867029

  I have attached ifupdwown-test.sh which exercises this issue on lxc by
  mocking the CPC cloudimage artifact.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1868329/+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 1868329] Re: ifupdown does not render viable /etc/network/interfaces on bionic ec2 cloud-images

2020-03-20 Thread Chad Smith
** Description changed:

  Filing this bug for clarification and tracking on Ubuntu Bionic and
  later.
  
  Canonical cloudimages for Ec2 and other clouds leave an artifact that
  disables /etc/network/interface with the following content:
  
  # ifupdown has been replaced by netplan(5) on this system.  See
  # /etc/netplan for current configuration.
  # To re-enable ifupdown on this system, you can run:
  #sudo apt install ifupdown
  
  In following the suggested text, installing the ifupdown deb continues
  to leave a broken system because ifupdown.postinst script creates an
  /etc/network/interfaces.d parts directory but does not write out a
  working /etc/network/interfaces file if the file exists on the system.
  
  This leaves a broken /etc/network/interfaces files which doesn't source
  /etc/network/interfaces.d/* and 3rd parties cannot use the interfaces.d
  parts directory to extend networking config.
  
  Cloud-init is one of those users of /etc/network/interfaces.d/ for
  rendering system networking on cloud images. Per LP: #1867029
+ 
+ I have attached ifupdwown-test.sh which exercises this issue on lxc by
+ mocking the CPC cloudimage artifact.

** Attachment added: "ifupdown-test.sh"
   
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1868329/+attachment/5339500/+files/ifupdown-test.sh

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

Title:
  ifupdown does not render viable /etc/network/interfaces on bionic ec2
  cloud-images

Status in ifupdown package in Ubuntu:
  New

Bug description:
  Filing this bug for clarification and tracking on Ubuntu Bionic and
  later.

  Canonical cloudimages for Ec2 and other clouds leave an artifact that
  disables /etc/network/interface with the following content:

  # ifupdown has been replaced by netplan(5) on this system.  See
  # /etc/netplan for current configuration.
  # To re-enable ifupdown on this system, you can run:
  #sudo apt install ifupdown

  In following the suggested text, installing the ifupdown deb continues
  to leave a broken system because ifupdown.postinst script creates an
  /etc/network/interfaces.d parts directory but does not write out a
  working /etc/network/interfaces file if the file exists on the system.

  This leaves a broken /etc/network/interfaces files which doesn't
  source /etc/network/interfaces.d/* and 3rd parties cannot use the
  interfaces.d parts directory to extend networking config.

  Cloud-init is one of those users of /etc/network/interfaces.d/ for
  rendering system networking on cloud images. Per LP: #1867029

  I have attached ifupdwown-test.sh which exercises this issue on lxc by
  mocking the CPC cloudimage artifact.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1868329/+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 1868329] [NEW] ifupdown does not render viable /etc/network/interfaces on bionic ec2 cloud-images

2020-03-20 Thread Chad Smith
Public bug reported:

Filing this bug for clarification and tracking on Ubuntu Bionic and
later.

Canonical cloudimages for Ec2 and other clouds leave an artifact that
disables /etc/network/interface with the following content:

# ifupdown has been replaced by netplan(5) on this system.  See
# /etc/netplan for current configuration.
# To re-enable ifupdown on this system, you can run:
#sudo apt install ifupdown

In following the suggested text, installing the ifupdown deb continues
to leave a broken system because ifupdown.postinst script creates an
/etc/network/interfaces.d parts directory but does not write out a
working /etc/network/interfaces file if the file exists on the system.

This leaves a broken /etc/network/interfaces files which doesn't source
/etc/network/interfaces.d/* and 3rd parties cannot use the interfaces.d
parts directory to extend networking config.

Cloud-init is one of those users of /etc/network/interfaces.d/ for
rendering system networking on cloud images. Per LP: #1867029

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


** Tags: uec-images

** Description changed:

  Filing this bug for clarification and tracking on Ubuntu Bionic and
  later.
  
- 
- Canonical cloudimages for Ec2 and other clouds leave an artifact that 
disables /etc/network/interface with the following content:
+ Canonical cloudimages for Ec2 and other clouds leave an artifact that
+ disables /etc/network/interface with the following content:
  
  # ifupdown has been replaced by netplan(5) on this system.  See
  # /etc/netplan for current configuration.
  # To re-enable ifupdown on this system, you can run:
  #sudo apt install ifupdown
  
- 
- In following the suggested text, installing the ifupdown deb continues to 
leave a broken system because ifupdown.postinst script creates an 
/etc/network/interfaces.d parts directory but does not write out a working 
/etc/network/interfaces file if the file exists on the system.
+ In following the suggested text, installing the ifupdown deb continues
+ to leave a broken system because ifupdown.postinst script creates an
+ /etc/network/interfaces.d parts directory but does not write out a
+ working /etc/network/interfaces file if the file exists on the system.
  
  This leaves a broken /etc/network/interfaces files which doesn't source
  /etc/network/interfaces.d/* and 3rd parties cannot use the interfaces.d
  parts directory to extend networking config.
+ 
+ Cloud-init is one of those users of /etc/network/interfaces.d/ for
+ rendering system networking on cloud images. Per LP: #1867029

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

Title:
  ifupdown does not render viable /etc/network/interfaces on bionic ec2
  cloud-images

Status in ifupdown package in Ubuntu:
  New

Bug description:
  Filing this bug for clarification and tracking on Ubuntu Bionic and
  later.

  Canonical cloudimages for Ec2 and other clouds leave an artifact that
  disables /etc/network/interface with the following content:

  # ifupdown has been replaced by netplan(5) on this system.  See
  # /etc/netplan for current configuration.
  # To re-enable ifupdown on this system, you can run:
  #sudo apt install ifupdown

  In following the suggested text, installing the ifupdown deb continues
  to leave a broken system because ifupdown.postinst script creates an
  /etc/network/interfaces.d parts directory but does not write out a
  working /etc/network/interfaces file if the file exists on the system.

  This leaves a broken /etc/network/interfaces files which doesn't
  source /etc/network/interfaces.d/* and 3rd parties cannot use the
  interfaces.d parts directory to extend networking config.

  Cloud-init is one of those users of /etc/network/interfaces.d/ for
  rendering system networking on cloud images. Per LP: #1867029

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1868329/+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 1867029] Re: Package ifupdown breaks network configuration by cloud-init

2020-03-20 Thread Chad Smith
** Changed in: cloud-init
   Status: Confirmed => In Progress

** Changed in: cloud-init
 Assignee: (unassigned) => Chad Smith (chad.smith)

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

Title:
  Package ifupdown breaks network configuration by cloud-init

Status in cloud-init:
  In Progress
Status in ifupdown package in Ubuntu:
  New

Bug description:
  It appears the `ifupdown` package breaks networking configuration that
  cloud-init would normally handle (?) on both providers. The result, if
  you image an instance with the `ifupdown` package installed, is that
  the image is not bootable by Azure/AWS. I'm not familiar with how
  Azure/AWS/etc use cloud-init for network start up however. I'm filing
  here for now, in case `cloud-init` needs to be more defensive against
  `ifupdown`.

  To reproduce with Packer (I confirmed this method):

  * Add necessary Azure subscription env vars from `ifupdown-bug.json`
  * `packer build ifupdown-bug.json`
  * Try to boot an instance with resulting image
  * Instance will never boot -- more specifically, networking never comes up. 
See `boot.log` for an example boot

  To reproduce manually (only a guess, I did not confirm):

  * Boot 18.04 ubuntu instance
  * Install ifupdown
  * Image the instance
  * Try to boot instance using new image
  * Instance won't boot

  I hit this with Packer, creating new images for booting instances in
  scaling groups -- `ifupdown` is brought in by `salt`. If this is
  reproducible via manual installation, there could be some backup
  images/snapshots that are unable to boot though.

  This appears to be because cloud-init network start up operations are
  broken by whatever `ifupdown` sysv/systemd scripts perform on boot.
  With `ifupdown` installed on Azure, `eth0` does not get an IP address,
  the instance never fully boots according to Azure, and it will enter
  an error state. On AWS, the instance boots, but network operations
  like SSH fail.

  The `boot.log` is from Azure. Eventually `cloud-init` gives an
  exception (see `exception.log`), but this seems like a secondary issue
  related to networking being down.

  I did try to upgrade cloud-init using nightly PPAs (version 20.1 I
  believe), but no luck. This is on Ubuntu 18.04 instances from Azure
  marketplace and AWS Canonical AMI, cloud-init version
  `19.4-33-gbb4131a2-0ubuntu1~18.04.1`.

  Related: https://github.com/Azure/WALinuxAgent/issues/1612

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1867029/+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 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-02-21 Thread Chad Smith
### Eoan esm-apps * esm-infra verification on stock Eoan cloudimages
# This test will show no regression in unattended-upgrades because there are no 
ESM offerings
# on Eoan.


test script:
#!/bin/bash

if [ $# != 1 ]; then
 echo "usage: $0 "
 exit 1
fi
SERIES=$1
LXC_NAME=test-sru-$SERIES
echo 1. Launch ubuntu-daily $SERIES lxc
#lxc launch ubuntu-daily:$SERIES $LXC_NAME
echo 2. Run unattended-upgrades to confirm Allowed origins does not find esm 
packages
lxc exec $LXC_NAME -- unattended-upgrades --dry-run --verbose  2>&1 | egrep -i 
'Allowed|esm'
echo 3. Install unattended-upgrades from -proposed suites
cat > setup_proposed.sh &1 | grep unattended-upgrades
echo 5.Run unattended-upgrades to confirm -proposed Allowed origins does cause 
regressions
lxc exec $LXC_NAME -- unattended-upgrades --dry-run --verbose 2>&1


### Verification output

$ ./sru.sh eoan
1. Launch ubuntu-daily eoan lxc
2. Run unattended-upgrades to confirm Allowed origins does not find esm packages
Allowed origins are: o=Ubuntu,a=eoan, o=Ubuntu,a=eoan-security, 
o=UbuntuESM,a=eoan, o=UbuntuESM,a=eoan-security, o=UbuntuESM,a=eoan-security
3. Install unattended-upgrades from -proposed suites
  unattended-upgrades
Get:1 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 
unattended-upgrades all 1.14ubuntu1.2 [47.6 kB]
Preparing to unpack .../unattended-upgrades_1.14ubuntu1.2_all.deb ...
Unpacking unattended-upgrades (1.14ubuntu1.2) over (1.14ubuntu1.1) ...
Setting up unattended-upgrades (1.14ubuntu1.2) ...
Replacing config file /etc/apt/apt.conf.d/50unattended-upgrades with new version
5.Run unattended-upgrades to confirm -proposed Allowed origins does cause 
regressions
Initial blacklist : 
Initial whitelist: 
Starting unattended upgrades script
Allowed origins are: o=Ubuntu,a=eoan, o=Ubuntu,a=eoan-security, 
o=UbuntuESMApps,a=eoan-apps-security, o=UbuntuESM,a=eoan-infra-security, 
o=UbuntuESM,a=eoan-security
No packages found that can be upgraded unattended and no pending auto-removals
csmith@uptown:~/src/ubuntu-advantage-client$ echo $?
0


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

** Changed in: unattended-upgrades (Ubuntu Trusty)
   Status: In Progress => Won't Fix

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESMApps:${distro_codename}-apps-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  Won't Fix
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Changes to the ESM repo naming and the introduction of the new esm-infra 
and esm-apps suites require an update to unattended-upgrades to ensure the 
security pockets are used.
   * This change will ensure users are actually receiving updates, where as 
today they will not without making manual changes.

  [Test Case]

   * 1) Bionic and Xenial ESM-Apps/ESM-infra with Ubuntu Pro
   * 2) Trusty ESM

  [Regression Potential]

   * This change is ensuring users actually receive security updates when using 
ESM. Therefore, 1) users of ESM-apps on Ubuntu Pro and 2) ESM-infra on Trusty 
will be the only users affected.
   * The possible issue would be if/when users receive actual security updates 
that then regress or cause issues to the system.

  [Other Info]
   
  Previous description:

  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.

  Currently /etc/apt/apt.conf.d/50unattended-upgrades provides:
  Unattended-Upgrade::Allowed-Origins {
  "${distro_id}ESM:${distro_codename}";
  }

  Given that there have been ESM apt pocket renames over the last few
  months, the above ESM allowed-origin should not apply anymore and can
  be dropped or replaced.

  See RT #C122697 and #C121067 for the pocket/suite renames related to
  ESM

  What is needed after the ESM apt pocket/suite renames:

  Support for unattended upgrades for ESM for Infrastructure customers:

  Unattended-Upgrade::Allowed-Origins {
    // Extended Security Maintenance; doesn't necessarily exist for
    // every release and this system may not have it installed, but if
    // available, the policy for updates is such that unattended-upgrades
    // should also install from here by default.
    

[Touch-packages] [Bug 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-02-21 Thread Chad Smith
Verification complete for this SRU thanks. I marked trusty as Won't Fix
as ubuntu-advantage-tools already delivers the appropriate APT config
supplement for esm-infra-security and esm-apps-security. So, it's
unnecessary risk.

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESMApps:${distro_codename}-apps-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  Won't Fix
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Changes to the ESM repo naming and the introduction of the new esm-infra 
and esm-apps suites require an update to unattended-upgrades to ensure the 
security pockets are used.
   * This change will ensure users are actually receiving updates, where as 
today they will not without making manual changes.

  [Test Case]

   * 1) Bionic and Xenial ESM-Apps/ESM-infra with Ubuntu Pro
   * 2) Trusty ESM

  [Regression Potential]

   * This change is ensuring users actually receive security updates when using 
ESM. Therefore, 1) users of ESM-apps on Ubuntu Pro and 2) ESM-infra on Trusty 
will be the only users affected.
   * The possible issue would be if/when users receive actual security updates 
that then regress or cause issues to the system.

  [Other Info]
   
  Previous description:

  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.

  Currently /etc/apt/apt.conf.d/50unattended-upgrades provides:
  Unattended-Upgrade::Allowed-Origins {
  "${distro_id}ESM:${distro_codename}";
  }

  Given that there have been ESM apt pocket renames over the last few
  months, the above ESM allowed-origin should not apply anymore and can
  be dropped or replaced.

  See RT #C122697 and #C121067 for the pocket/suite renames related to
  ESM

  What is needed after the ESM apt pocket/suite renames:

  Support for unattended upgrades for ESM for Infrastructure customers:

  Unattended-Upgrade::Allowed-Origins {
    // Extended Security Maintenance; doesn't necessarily exist for
    // every release and this system may not have it installed, but if
    // available, the policy for updates is such that unattended-upgrades
    // should also install from here by default.
    "${distro_id}ESM:${distro_codename}-infra-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
  };

  === Confirmed proper origin on an attached Trusty instance with ESM-
  infra enabled:

   500 https://esm.ubuntu.com/ubuntu/ trusty-infra-security/main amd64 Packages
   release 
v=14.04,o=UbuntuESM,a=trusty-infra-security,n=trusty,l=UbuntuESM,c=main

  === Confirmed proper origins on Bionic for enabled ESM-infra and ESM-apps on 
an AWS Ubuntu PRO instance:
   500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64

   500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-security,n=bionic,l=UbuntuESMApps,c=main,b=amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051/+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 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-02-21 Thread Chad Smith
This changeset is not 'critical' for ESM support on trusty because
ubuntu-advantage-tools package already delivers a static APT config with
the appropriate values:

root@trusty-box:~# cat /etc/apt/apt.conf.d/51ubuntu-advantage-esm
Unattended-Upgrade::Allowed-Origins {
  "${distro_id}ESM:${distro_codename}-infra-security";
};
Unattended-Upgrade::Allowed-Origins {
  "${distro_id}ESMApps:${distro_codename}-apps-security";
};


Since ubuntu-advantage-tools already delivers the necessary config, we don't 
need to add risk to trusty unnecessarily for this optimization. As such, we can 
reject the trusty request as a workaround is in place.

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

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

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESMApps:${distro_codename}-apps-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  In Progress
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Changes to the ESM repo naming and the introduction of the new esm-infra 
and esm-apps suites require an update to unattended-upgrades to ensure the 
security pockets are used.
   * This change will ensure users are actually receiving updates, where as 
today they will not without making manual changes.

  [Test Case]

   * 1) Bionic and Xenial ESM-Apps/ESM-infra with Ubuntu Pro
   * 2) Trusty ESM

  [Regression Potential]

   * This change is ensuring users actually receive security updates when using 
ESM. Therefore, 1) users of ESM-apps on Ubuntu Pro and 2) ESM-infra on Trusty 
will be the only users affected.
   * The possible issue would be if/when users receive actual security updates 
that then regress or cause issues to the system.

  [Other Info]
   
  Previous description:

  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.

  Currently /etc/apt/apt.conf.d/50unattended-upgrades provides:
  Unattended-Upgrade::Allowed-Origins {
  "${distro_id}ESM:${distro_codename}";
  }

  Given that there have been ESM apt pocket renames over the last few
  months, the above ESM allowed-origin should not apply anymore and can
  be dropped or replaced.

  See RT #C122697 and #C121067 for the pocket/suite renames related to
  ESM

  What is needed after the ESM apt pocket/suite renames:

  Support for unattended upgrades for ESM for Infrastructure customers:

  Unattended-Upgrade::Allowed-Origins {
    // Extended Security Maintenance; doesn't necessarily exist for
    // every release and this system may not have it installed, but if
    // available, the policy for updates is such that unattended-upgrades
    // should also install from here by default.
    "${distro_id}ESM:${distro_codename}-infra-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
  };

  === Confirmed proper origin on an attached Trusty instance with ESM-
  infra enabled:

   500 https://esm.ubuntu.com/ubuntu/ trusty-infra-security/main amd64 Packages
   release 
v=14.04,o=UbuntuESM,a=trusty-infra-security,n=trusty,l=UbuntuESM,c=main

  === Confirmed proper origins on Bionic for enabled ESM-infra and ESM-apps on 
an AWS Ubuntu PRO instance:
   500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64

   500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-security,n=bionic,l=UbuntuESMApps,c=main,b=amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051/+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 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-02-18 Thread Chad Smith
### Verification Failure??? of ESM-infra for Eoan

Not much to verify here. The ESM-infra and ESM-Apps services are only
targeted to support LTS releases of Ubuntu, so ubuntu-advantage-tools
will not even allow enabling ESM services on Eoan.

As such, I don't think we should be targeting Eoan for this APT Allowed
Origin APT config changeset.

marking verification-failed-eoan so someone can confirm if the intent
here was to  keep APT configuration the same in all releases when you
SRU this change back to trusty.

** Tags removed: verification-needed-eoan
** Tags added: verification-failed-eoan

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESMApps:${distro_codename}-apps-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Changes to the ESM repo naming and the introduction of the new esm-infra 
and esm-apps suites require an update to unattended-upgrades to ensure the 
security pockets are used.
   * This change will ensure users are actually receiving updates, where as 
today they will not without making manual changes.

  [Test Case]

   * 1) Bionic and Xenial ESM-Apps/ESM-infra with Ubuntu Pro
   * 2) Trusty ESM

  [Regression Potential]

   * This change is ensuring users actually receive security updates when using 
ESM. Therefore, 1) users of ESM-apps on Ubuntu Pro and 2) ESM-infra on Trusty 
will be the only users affected.
   * The possible issue would be if/when users receive actual security updates 
that then regress or cause issues to the system.

  [Other Info]
   
  Previous description:

  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.

  Currently /etc/apt/apt.conf.d/50unattended-upgrades provides:
  Unattended-Upgrade::Allowed-Origins {
  "${distro_id}ESM:${distro_codename}";
  }

  Given that there have been ESM apt pocket renames over the last few
  months, the above ESM allowed-origin should not apply anymore and can
  be dropped or replaced.

  See RT #C122697 and #C121067 for the pocket/suite renames related to
  ESM

  What is needed after the ESM apt pocket/suite renames:

  Support for unattended upgrades for ESM for Infrastructure customers:

  Unattended-Upgrade::Allowed-Origins {
    // Extended Security Maintenance; doesn't necessarily exist for
    // every release and this system may not have it installed, but if
    // available, the policy for updates is such that unattended-upgrades
    // should also install from here by default.
    "${distro_id}ESM:${distro_codename}-infra-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
  };

  === Confirmed proper origin on an attached Trusty instance with ESM-
  infra enabled:

   500 https://esm.ubuntu.com/ubuntu/ trusty-infra-security/main amd64 Packages
   release 
v=14.04,o=UbuntuESM,a=trusty-infra-security,n=trusty,l=UbuntuESM,c=main

  === Confirmed proper origins on Bionic for enabled ESM-infra and ESM-apps on 
an AWS Ubuntu PRO instance:
   500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64

   500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-security,n=bionic,l=UbuntuESMApps,c=main,b=amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051/+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 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-02-18 Thread Chad Smith
Hi Łukasz,   Also there is a trusty series task on this bug, I'm unsure
whether to mark this SRU tag "verification-done" until we resolve both
the trusty task and potentially dropping the Eoan task

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESMApps:${distro_codename}-apps-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Changes to the ESM repo naming and the introduction of the new esm-infra 
and esm-apps suites require an update to unattended-upgrades to ensure the 
security pockets are used.
   * This change will ensure users are actually receiving updates, where as 
today they will not without making manual changes.

  [Test Case]

   * 1) Bionic and Xenial ESM-Apps/ESM-infra with Ubuntu Pro
   * 2) Trusty ESM

  [Regression Potential]

   * This change is ensuring users actually receive security updates when using 
ESM. Therefore, 1) users of ESM-apps on Ubuntu Pro and 2) ESM-infra on Trusty 
will be the only users affected.
   * The possible issue would be if/when users receive actual security updates 
that then regress or cause issues to the system.

  [Other Info]
   
  Previous description:

  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.

  Currently /etc/apt/apt.conf.d/50unattended-upgrades provides:
  Unattended-Upgrade::Allowed-Origins {
  "${distro_id}ESM:${distro_codename}";
  }

  Given that there have been ESM apt pocket renames over the last few
  months, the above ESM allowed-origin should not apply anymore and can
  be dropped or replaced.

  See RT #C122697 and #C121067 for the pocket/suite renames related to
  ESM

  What is needed after the ESM apt pocket/suite renames:

  Support for unattended upgrades for ESM for Infrastructure customers:

  Unattended-Upgrade::Allowed-Origins {
    // Extended Security Maintenance; doesn't necessarily exist for
    // every release and this system may not have it installed, but if
    // available, the policy for updates is such that unattended-upgrades
    // should also install from here by default.
    "${distro_id}ESM:${distro_codename}-infra-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
  };

  === Confirmed proper origin on an attached Trusty instance with ESM-
  infra enabled:

   500 https://esm.ubuntu.com/ubuntu/ trusty-infra-security/main amd64 Packages
   release 
v=14.04,o=UbuntuESM,a=trusty-infra-security,n=trusty,l=UbuntuESM,c=main

  === Confirmed proper origins on Bionic for enabled ESM-infra and ESM-apps on 
an AWS Ubuntu PRO instance:
   500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64

   500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-security,n=bionic,l=UbuntuESMApps,c=main,b=amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051/+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 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-02-18 Thread Chad Smith
Note for expected results on a typical Eoan system while trying to `ua
enable esm-infra`

One moment, checking your subscription first
ESM Infra is not available for Ubuntu 19.10 (Eoan Ermine).


So no ESM APT repos should be accessible on Eoan systems per product design.

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESMApps:${distro_codename}-apps-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Changes to the ESM repo naming and the introduction of the new esm-infra 
and esm-apps suites require an update to unattended-upgrades to ensure the 
security pockets are used.
   * This change will ensure users are actually receiving updates, where as 
today they will not without making manual changes.

  [Test Case]

   * 1) Bionic and Xenial ESM-Apps/ESM-infra with Ubuntu Pro
   * 2) Trusty ESM

  [Regression Potential]

   * This change is ensuring users actually receive security updates when using 
ESM. Therefore, 1) users of ESM-apps on Ubuntu Pro and 2) ESM-infra on Trusty 
will be the only users affected.
   * The possible issue would be if/when users receive actual security updates 
that then regress or cause issues to the system.

  [Other Info]
   
  Previous description:

  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.

  Currently /etc/apt/apt.conf.d/50unattended-upgrades provides:
  Unattended-Upgrade::Allowed-Origins {
  "${distro_id}ESM:${distro_codename}";
  }

  Given that there have been ESM apt pocket renames over the last few
  months, the above ESM allowed-origin should not apply anymore and can
  be dropped or replaced.

  See RT #C122697 and #C121067 for the pocket/suite renames related to
  ESM

  What is needed after the ESM apt pocket/suite renames:

  Support for unattended upgrades for ESM for Infrastructure customers:

  Unattended-Upgrade::Allowed-Origins {
    // Extended Security Maintenance; doesn't necessarily exist for
    // every release and this system may not have it installed, but if
    // available, the policy for updates is such that unattended-upgrades
    // should also install from here by default.
    "${distro_id}ESM:${distro_codename}-infra-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
  };

  === Confirmed proper origin on an attached Trusty instance with ESM-
  infra enabled:

   500 https://esm.ubuntu.com/ubuntu/ trusty-infra-security/main amd64 Packages
   release 
v=14.04,o=UbuntuESM,a=trusty-infra-security,n=trusty,l=UbuntuESM,c=main

  === Confirmed proper origins on Bionic for enabled ESM-infra and ESM-apps on 
an AWS Ubuntu PRO instance:
   500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64

   500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-security,n=bionic,l=UbuntuESMApps,c=main,b=amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051/+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 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-02-18 Thread Chad Smith
### Bionic esm-apps * esm-infra verification  on AWS Ubuntu Pro

test script:

#!/bin/bash

if [ $# != 1 ]; then
 echo "usage: $0 "
 exit 1
fi
echo 1. Launch AWs Ubuntu PRO Bionic which auto-enables both esm-apps and 
esm-infra
VM_IP=$1
echo 2. Remove ubuntu-advantage-tools Alllowed-Origins config
ssh ubuntu@$VM_IP sudo rm -f /etc/apt/apt.conf.d/51ubuntu-advantage-esm
echo 3. Run unattended-upgrades to confirm Allowed origins does not find esm 
packages
ssh ubuntu@$VM_IP dpkg-query --show unattended-upgrades
ssh ubuntu@$VM_IP sudo unattended-upgrades --dry-run --verbose 2>&1 | egrep -i 
'Allowed|esm'
echo 4. Install unattended-upgrades from -proposed suites
cat > setup_proposed.sh &1 | grep unattended-upgrades
echo 5.Run unattended-upgrades to confirm -proposed Allowed origins does find 
esm packages
ssh ubuntu@$VM_IP sudo unattended-upgrades --dry-run --verbose 2>&1 | egrep -i 
'Allowed|esm'
echo 6. Verify apt-cache policy shows matching origins and suites
ssh ubuntu@$VM_IP sudo apt-cache policy | grep -i esm


### Verification output
1. Launch AWs Ubuntu PRO Bionic which auto-enables both esm-apps and esm-infra
2. Remove ubuntu-advantage-tools Alllowed-Origins config
3. Run unattended-upgrades to confirm Allowed origins does not find esm packages
unattended-upgrades 1.1ubuntu1.18.04.12
Allowed origins are: o=Ubuntu,a=bionic, o=Ubuntu,a=bionic-security, 
o=UbuntuESM,a=bionic
4. Install unattended-upgrades from -proposed suites
setup_proposed.sh100%  203 3.3KB/s   00:00
  unattended-upgrades
Get:1 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
unattended-upgrades all 1.1ubuntu1.18.04.14 [41.7 kB]
Preparing to unpack .../unattended-upgrades_1.1ubuntu1.18.04.14_all.deb ...
Unpacking unattended-upgrades (1.1ubuntu1.18.04.14) over (1.1ubuntu1.18.04.12) 
...
Setting up unattended-upgrades (1.1ubuntu1.18.04.14) ...
Replacing config file /etc/apt/apt.conf.d/50unattended-upgrades with new version
Allowed origins are: o=Ubuntu,a=bionic, o=Ubuntu,a=bionic-security, 
o=UbuntuESMApps,a=bionic-apps-security, o=UbuntuESM,a=bionic-infra-security
/usr/bin/dpkg --status-fd 11 --no-triggers --unpack --auto-deconfigure 
/var/cache/apt/archives/krb5-locales_1.16-2ubuntu0.1+esm1_all.deb 
/usr/bin/dpkg --status-fd 11 --no-triggers --unpack --auto-deconfigure 
/var/cache/apt/archives/libk5crypto3_1.16-2ubuntu0.1+esm1_amd64.deb 
/usr/bin/dpkg --status-fd 11 --no-triggers --unpack --auto-deconfigure 
/var/cache/apt/archives/libkrb5support0_1.16-2ubuntu0.1+esm1_amd64.deb 
/var/cache/apt/archives/libgssapi-krb5-2_1.16-2ubuntu0.1+esm1_amd64.deb 
/var/cache/apt/archives/libkrb5-3_1.16-2ubuntu0.1+esm1_amd64.deb 
6. Verify apt-cache policy shows matching origins and suites
 500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-updates/main amd64 
Packages
 release 
v=18.04,o=UbuntuESM,a=bionic-infra-updates,n=bionic,l=UbuntuESM,c=main,b=amd64
 origin esm.ubuntu.com
 500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
 release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64
 origin esm.ubuntu.com
 500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-updates/main amd64 Packages
 release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-updates,n=bionic,l=UbuntuESMApps,c=main,b=amd64
 origin esm.ubuntu.com
 500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 Packages
 release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-security,n=bionic,l=UbuntuESMApps,c=main,b=amd64
 origin esm.ubuntu.com

### Verification output

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESMApps:${distro_codename}-apps-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Changes to the ESM repo naming and the introduction of the new esm-infra 
and esm-apps suites require an update to unattended-upgrades to ensure the 
security pockets are used.
   * This change will ensure users are actually receiving updates, where as 
today they will not without making manual changes.

  [Test Case]

   * 1) Bionic and Xenial ESM-Apps/ESM-infra with Ubuntu Pro
   * 2) 

[Touch-packages] [Bug 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-02-18 Thread Chad Smith
### Xenial AwS Ubuntu Pro instance test

test script:
#!/bin/bash

if [ $# != 1 ]; then
 echo "usage: $0 "
 exit 1
fi
echo 1. Launch AWs Ubuntu PRO Xenial which auto-enables both esm-apps and 
esm-infra
VM_IP=$1
echo 2. Remove ubuntu-advantage-tools Alllowed-Origins config
ssh ubuntu@$VM_IP sudo rm -f /etc/apt/apt.conf.d/51ubuntu-advantage-esm
echo 3. Run unattended-upgrades to confirm Allowed origins does not find esm 
packages
ssh ubuntu@$VM_IP dpkg-query --show unattended-upgrades
ssh ubuntu@$VM_IP sudo unattended-upgrades --dry-run --verbose 2>&1 | egrep -i 
'Allowed|esm'
echo 4. Install unattended-upgrades from -proposed suites
cat > setup_proposed.sh &1 | grep unattended-upgrades
echo 5.Run unattended-upgrades to confirm -proposed Allowed origins does find 
esm packages
ssh ubuntu@$VM_IP sudo unattended-upgrades --dry-run --verbose 2>&1 | egrep -i 
'Allowed|esm'
echo 6. Verify apt-cache policy shows matching origins and suites
ssh ubuntu@$VM_IP sudo apt-cache policy | grep -i esm



 Verification output

csmith@uptown:~/src$ ./unattended-up.sh 3.84.44.110
1. Launch AWs Ubuntu PRO Trusty which auto-enables both esm-apps and esm-infra
2. Remove ubuntu-advantage-tools Alllowed-Origins config
The authenticity of host '3.84.44.110 (3.84.44.110)' can't be established.
ECDSA key fingerprint is SHA256:uO/pH0y4oazsq85AdXn33dZEtNRWTBu7y+Of/Kc1XOU.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '3.84.44.110' (ECDSA) to the list of known hosts.
3. Run unattended-upgrades to confirm Allowed origins does not find esm packages
unattended-upgrades 1.1ubuntu1.18.04.7~16.04.4
Allowed origins are: o=Ubuntu,a=xenial, o=Ubuntu,a=xenial-security, 
o=UbuntuESM,a=xenial
4. Install unattended-upgrades from -proposed suites
setup_proposed.sh100%  203 3.5KB/s   00:00
  unattended-upgrades
Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 
unattended-upgrades all 1.1ubuntu1.18.04.7~16.04.6 [42.1 kB]
Preparing to unpack .../unattended-upgrades_1.1ubuntu1.18.04.7~16.04.6_all.deb 
...
Unpacking unattended-upgrades (1.1ubuntu1.18.04.7~16.04.6) over 
(1.1ubuntu1.18.04.7~16.04.4) ...
Setting up unattended-upgrades (1.1ubuntu1.18.04.7~16.04.6) ...
Replacing config file /etc/apt/apt.conf.d/50unattended-upgrades with new version
5.Run unattended-upgrades to confirm -proposed Allowed origins does find esm 
packages
Allowed origins are: o=Ubuntu,a=xenial, o=Ubuntu,a=xenial-security, 
o=UbuntuESMApps,a=xenial-apps-security, o=UbuntuESM,a=xenial-infra-security
/usr/bin/dpkg --status-fd 11 --unpack --auto-deconfigure 
/var/cache/apt/archives/krb5-locales_1.13.2+dfsg-5ubuntu2.1+esm1_all.deb 
/usr/bin/dpkg --status-fd 11 --unpack --auto-deconfigure 
/var/cache/apt/archives/libk5crypto3_1.13.2+dfsg-5ubuntu2.1+esm1_amd64.deb 
/usr/bin/dpkg --status-fd 11 --unpack --auto-deconfigure 
/var/cache/apt/archives/libkrb5support0_1.13.2+dfsg-5ubuntu2.1+esm1_amd64.deb 
/var/cache/apt/archives/libgssapi-krb5-2_1.13.2+dfsg-5ubuntu2.1+esm1_amd64.deb 
/var/cache/apt/archives/libkrb5-3_1.13.2+dfsg-5ubuntu2.1+esm1_amd64.deb 
6. Verify apt-cache policy shows matching origins and suites
 500 https://esm.ubuntu.com/infra/ubuntu xenial-infra-updates/main amd64 
Packages
 release 
v=16.04,o=UbuntuESM,a=xenial-infra-updates,n=xenial,l=UbuntuESM,c=main,b=amd64
 origin esm.ubuntu.com
 500 https://esm.ubuntu.com/infra/ubuntu xenial-infra-security/main amd64 
Packages
 release 
v=16.04,o=UbuntuESM,a=xenial-infra-security,n=xenial,l=UbuntuESM,c=main,b=amd64
 origin esm.ubuntu.com
 500 https://esm.ubuntu.com/apps/ubuntu xenial-apps-updates/main amd64 Packages
 release 
v=16.04,o=UbuntuESMApps,a=xenial-apps-updates,n=xenial,l=UbuntuESMApps,c=main,b=amd64
 origin esm.ubuntu.com
 500 https://esm.ubuntu.com/apps/ubuntu xenial-apps-security/main amd64 Packages
 release 
v=16.04,o=UbuntuESMApps,a=xenial-apps-security,n=xenial,l=UbuntuESMApps,c=main,b=amd64
 origin esm.ubuntu.com


** Tags removed: verification-needed-xenial
** Tags added: verification-dibe-xenial

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESMApps:${distro_codename}-apps-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in 

[Touch-packages] [Bug 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-02-18 Thread Chad Smith
### Bionic validation

1. start with a bionic VM with unattended-upgrades from bionic-updates
2. ua enable ESM-Infra via ubuntu-advantage-tools 
3. /etc/apt/apt.conf.d/51ubuntu-advantage-esm (which delivers Allowed-Origins 
config) 
   "${distro_id}ESMApps:${distro_codename}-apps-security";
   "${distro_id}ESM:${distro_codename}-infra-security";
4. Check whether unattended-upgrades sees bionic esm packages
sudo unattended-upgrades --dry-run --debug 2>&1 | egrep -i 'Allowed|ESM'
5. Upgrade unattended-upgrades to -proposed
6. Check whether unattended-upgrades sees bionic esm packages
sudo unattended-upgrades --dry-run --debug 2>&1 | egrep -i 'Allowed|ESM'


root@test-bionic:~/ubuntu-advantage-client# dpkg-query --show 
unattended-upgrades
unattended-upgrades 1.1ubuntu1.18.04.13

# No esm-infra packages seen by unattended-upgrades dry-run
root@test-bionic:~/ubuntu-advantage-client# sudo unattended-upgrades --dry-run 
--debug 2>&1 | egrep -i 'Allowed|ESM' 
Allowed origins are: o=Ubuntu,a=bionic, o=Ubuntu,a=bionic-security, 
o=UbuntuESM,a=bionic
Checking: krb5-locales ([, ])
Checking: libgssapi-krb5-2 ([, ])
Checking: libk5crypto3 ([, ])
Checking: libkrb5-3 ([, 
])
Checking: libkrb5support0 ([, ])

# upgrade to -proposed
root@test-bionic:~/ubuntu-advantage-client# apt-get install unattended-upgrades
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  libfreetype6
Use 'apt autoremove' to remove it.
Suggested packages:
  bsd-mailx default-mta | mail-transport-agent needrestart
The following packages will be upgraded:
  unattended-upgrades
1 upgraded, 0 newly installed, 0 to remove and 34 not upgraded.
Need to get 41.7 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
unattended-upgrades all 1.1ubuntu1.18.04.14 [41.7 kB]
Fetched 41.7 kB in 1s (65.2 kB/s)   
Preconfiguring packages ...
(Reading database ... 41831 files and directories currently installed.)
Preparing to unpack .../unattended-upgrades_1.1ubuntu1.18.04.14_all.deb ...
Unpacking unattended-upgrades (1.1ubuntu1.18.04.14) over (1.1ubuntu1.18.04.13) 
...
Setting up unattended-upgrades (1.1ubuntu1.18.04.14) ...
Replacing config file /etc/apt/apt.conf.d/50unattended-upgrades with new version
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for systemd (237-3ubuntu10.38) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...

# See esm-infra packages after upgrading to -proposed
root@test-bionic:~/ubuntu-advantage-client# sudo unattended-upgrades --dry-run 
--debug 2>&1 | egrep -i 'Allowed|ESM' 
Allowed origins are: o=Ubuntu,a=bionic, o=Ubuntu,a=bionic-security, 
o=UbuntuESMApps,a=bionic-apps-security, o=UbuntuESM,a=bionic-infra-security
Checking: krb5-locales ([, ])
Checking: libgssapi-krb5-2 ([, ])
Checking: libk5crypto3 ([, ])
Checking: libkrb5-3 ([, 
])
Checking: libkrb5support0 ([, ])
https://esm.ubuntu.com/infra/ubuntu/pool/main/k/krb5/krb5-locales_1.16-2ubuntu0.1+esm1_all.deb'
 ID:0 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/krb5-locales_1.16-2ubuntu0.1+esm1_all.deb)
No conffiles in deb 
/var/cache/apt/archives/krb5-locales_1.16-2ubuntu0.1+esm1_all.deb (There is no 
member named 'conffiles')
https://esm.ubuntu.com/infra/ubuntu/pool/main/k/krb5/libgssapi-krb5-2_1.16-2ubuntu0.1+esm1_amd64.deb'
 ID:0 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/libgssapi-krb5-2_1.16-2ubuntu0.1+esm1_amd64.deb)
No conffiles in deb 
/var/cache/apt/archives/libgssapi-krb5-2_1.16-2ubuntu0.1+esm1_amd64.deb (There 
is no member named 'conffiles')
https://esm.ubuntu.com/infra/ubuntu/pool/main/k/krb5/libkrb5-3_1.16-2ubuntu0.1+esm1_amd64.deb'
 ID:0 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/libkrb5-3_1.16-2ubuntu0.1+esm1_amd64.deb)
No conffiles in deb 
/var/cache/apt/archives/libkrb5-3_1.16-2ubuntu0.1+esm1_amd64.deb (There is no 
member named 'conffiles')
https://esm.ubuntu.com/infra/ubuntu/pool/main/k/krb5/libkrb5support0_1.16-2ubuntu0.1+esm1_amd64.deb'
 ID:0 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/libkrb5support0_1.16-2ubuntu0.1+esm1_amd64.deb)
No conffiles in deb 
/var/cache/apt/archives/libkrb5support0_1.16-2ubuntu0.1+esm1_amd64.deb (There 
is no member named 'conffiles')
https://esm.ubuntu.com/infra/ubuntu/pool/main/k/krb5/libk5crypto3_1.16-2ubuntu0.1+esm1_amd64.deb'
 ID:0 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/libk5crypto3_1.16-2ubuntu0.1+esm1_amd64.deb)
No conffiles in deb 
/var/cache/apt/archives/libk5crypto3_1.16-2ubuntu0.1+esm1_amd64.deb (There is 
no member named 'conffiles')
/usr/bin/dpkg --status-fd 11 --no-triggers --unpack --auto-deconfigure 
/var/cache/apt/archives/krb5-locales_1.16-2ubuntu0.1+esm1_all.deb 
/usr/bin/dpkg --status-fd 11 --no-triggers --unpack --auto-deconfigure 

[Touch-packages] [Bug 1823376] Re: Please add ${distro_id}ESM:${distro_codename}-security to allowed origins (on Ubuntu)

2020-02-18 Thread Chad Smith
I think this bug is replaced by the work here:

https://bugs.launchpad.net/ubuntu/+source/unattended-
upgrades/+bug/1857051

ESM archive names for ESMApps and ESMInfa are now:
  "${distro_id}ESM:${distro_codename}-infra-security";
  "${distro_id}ESMApps:${distro_codename}-apps-security";

The original request in this bug can be dropped as this repo archive is
deprecated:

  "${distro_id}ESM:${distro_codename}-security";

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  New
Status in unattended-upgrades source package in Bionic:
  New

Bug description:
  .

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1823376/+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 1823376] Re: Please add ${distro_id}ESM:${distro_codename}-security to allowed origins (on Ubuntu)

2020-02-18 Thread Chad Smith
I think this bug is replaced by the work here.

archive nmames for ESMApps and ESMInfa are now:
  "${distro_id}ESM:${distro_codename}-infra-security";
  "${distro_id}ESMApps:${distro_codename}-apps-security";

The original request in this bug can be dropped as this repo archive is
deprecated:

  "${distro_id}ESM:${distro_codename}-security";

https://bugs.launchpad.net/ubuntu/+source/unattended-
upgrades/+bug/1857051

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  New
Status in unattended-upgrades source package in Bionic:
  New

Bug description:
  .

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1823376/+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 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-01-28 Thread Chad Smith
Balint,
It looks like this is addressed by: 
https://github.com/mvo5/unattended-upgrades/pull/244 which has now merged. Do 
we know if that branch going to be SRU'd to Trusty, Xenial and Bionic


** Changed in: unattended-upgrades (Ubuntu)
   Status: New => In Progress

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESMApps:${distro_codename}-apps-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  In Progress
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  New
Status in unattended-upgrades source package in Bionic:
  New

Bug description:
  [Impact]

   * Changes to the ESM repo naming and the introduction of the new esm-infra 
and esm-apps suites require an update to unattended-upgrades to ensure the 
security pockets are used.
   * This change will ensure users are actually receiving updates, where as 
today they will not without making manual changes.

  [Test Case]

   * 1) Bionic and Xenial ESM-Apps/ESM-infra with Ubuntu Pro
   * 2) Trusty ESM

  [Regression Potential]

   * This change is ensuring users actually receive security updates when using 
ESM. Therefore, 1) users of ESM-apps on Ubuntu Pro and 2) ESM-infra on Trusty 
will be the only users affected.
   * The possible issue would be if/when users receive actual security updates 
that then regress or cause issues to the system.

  [Other Info]
   
  Previous description:

  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.

  Currently /etc/apt/apt.conf.d/50unattended-upgrades provides:
  Unattended-Upgrade::Allowed-Origins {
  "${distro_id}ESM:${distro_codename}";
  }

  Given that there have been ESM apt pocket renames over the last few
  months, the above ESM allowed-origin should not apply anymore and can
  be dropped or replaced.

  See RT #C122697 and #C121067 for the pocket/suite renames related to
  ESM

  What is needed after the ESM apt pocket/suite renames:

  Support for unattended upgrades for ESM for Infrastructure customers:

  Unattended-Upgrade::Allowed-Origins {
    // Extended Security Maintenance; doesn't necessarily exist for
    // every release and this system may not have it installed, but if
    // available, the policy for updates is such that unattended-upgrades
    // should also install from here by default.
    "${distro_id}ESM:${distro_codename}-infra-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
  };

  === Confirmed proper origin on an attached Trusty instance with ESM-
  infra enabled:

   500 https://esm.ubuntu.com/ubuntu/ trusty-infra-security/main amd64 Packages
   release 
v=14.04,o=UbuntuESM,a=trusty-infra-security,n=trusty,l=UbuntuESM,c=main

  === Confirmed proper origins on Bionic for enabled ESM-infra and ESM-apps on 
an AWS Ubuntu PRO instance:
   500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64

   500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-security,n=bionic,l=UbuntuESMApps,c=main,b=amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051/+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 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-01-17 Thread Chad Smith
** Changed in: unattended-upgrades (Ubuntu)
   Status: Incomplete => New

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESMApps:${distro_codename}-apps-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  New
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  New
Status in unattended-upgrades source package in Bionic:
  New

Bug description:
  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.

  Currently /etc/apt/apt.conf.d/50unattended-upgrades provides:
  Unattended-Upgrade::Allowed-Origins {
  "${distro_id}ESM:${distro_codename}";
  }

  Given that there have been ESM apt pocket renames over the last few
  months, the above ESM allowed-origin should not apply anymore and can
  be dropped or replaced.

  See RT #C122697 and #C121067 for the pocket/suite renames related to
  ESM

  What is needed after the ESM apt pocket/suite renames:

  Support for unattended upgrades for ESM for Infrastructure customers:

  Unattended-Upgrade::Allowed-Origins {
    // Extended Security Maintenance; doesn't necessarily exist for
    // every release and this system may not have it installed, but if
    // available, the policy for updates is such that unattended-upgrades
    // should also install from here by default.
    "${distro_id}ESM:${distro_codename}-infra-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
  };

  === Confirmed proper origin on an attached Trusty instance with ESM-
  infra enabled:

   500 https://esm.ubuntu.com/ubuntu/ trusty-infra-security/main amd64 Packages
   release 
v=14.04,o=UbuntuESM,a=trusty-infra-security,n=trusty,l=UbuntuESM,c=main

  === Confirmed proper origins on Bionic for enabled ESM-infra and ESM-apps on 
an AWS Ubuntu PRO instance:
   500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64

   500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-security,n=bionic,l=UbuntuESMApps,c=main,b=amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051/+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 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESM:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2020-01-16 Thread Chad Smith
** Description changed:

  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.
+ 
+ 
+ Currently /etc/apt/apt.conf.d/50unattended-upgrades provides:
+ Unattended-Upgrade::Allowed-Origins {
+ "${distro_id}ESM:${distro_codename}";
+ }
+ 
+ 
+ Given that there have been ESM apt pocket renames over the last few months, 
the above ESM allowed-origin should not apply anymore and can be dropped or 
replaced.
+ 
+ See RT #C122697 and #C121067 for the pocket/suite renames related to ESM
+ 
+ 
+ What is needed after the ESM apt pocket/suite renames:
+ 
+ Support for unattended upgrades for ESM for Infrastructure customers:
+ 
+ 
+ Unattended-Upgrade::Allowed-Origins {
+   // Extended Security Maintenance; doesn't necessarily exist for
+   // every release and this system may not have it installed, but if
+   // available, the policy for updates is such that unattended-upgrades
+   // should also install from here by default.
+   "${distro_id}ESM:${distro_codename}-infra-security";
+   "${distro_id}ESMApps:${distro_codename}-apps-security";
+ };
+ 
+ 
+ Confirmed proper origin on an attached Trusty instance with ESM-infra enabled:
+ 
+ 
+  500 https://esm.ubuntu.com/ubuntu/ trusty-infra-security/main amd64 Packages
+  release 
v=14.04,o=UbuntuESM,a=trusty-infra-security,n=trusty,l=UbuntuESM,c=main
+ 
+ Confirmed proper origins on Bionic for enabled ESM-infra and ESM-apps on an 
AWS Ubuntu PRO instance:
+  500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
+  release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64
+ 
+  500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 
Packages
+  release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-security,n=bionic,l=UbuntuESMApps,c=main,b=amd64

** Description changed:

  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.
  
- 
  Currently /etc/apt/apt.conf.d/50unattended-upgrades provides:
  Unattended-Upgrade::Allowed-Origins {
- "${distro_id}ESM:${distro_codename}";
+ "${distro_id}ESM:${distro_codename}";
  }
  
- 
- Given that there have been ESM apt pocket renames over the last few months, 
the above ESM allowed-origin should not apply anymore and can be dropped or 
replaced.
+ Given that there have been ESM apt pocket renames over the last few
+ months, the above ESM allowed-origin should not apply anymore and can be
+ dropped or replaced.
  
  See RT #C122697 and #C121067 for the pocket/suite renames related to ESM
- 
  
  What is needed after the ESM apt pocket/suite renames:
  
  Support for unattended upgrades for ESM for Infrastructure customers:
  
- 
  Unattended-Upgrade::Allowed-Origins {
-   // Extended Security Maintenance; doesn't necessarily exist for
-   // every release and this system may not have it installed, but if
-   // available, the policy for updates is such that unattended-upgrades
-   // should also install from here by default.
-   "${distro_id}ESM:${distro_codename}-infra-security";
-   "${distro_id}ESMApps:${distro_codename}-apps-security";
+   // Extended Security Maintenance; doesn't necessarily exist for
+   // every release and this system may not have it installed, but if
+   // available, the policy for updates is such that unattended-upgrades
+   // should also install from here by default.
+   "${distro_id}ESM:${distro_codename}-infra-security";
+   "${distro_id}ESMApps:${distro_codename}-apps-security";
  };
  
+ === Confirmed proper origin on an attached Trusty instance with ESM-
+ infra enabled:
  
- Confirmed proper origin on an attached Trusty instance with ESM-infra enabled:
+  500 https://esm.ubuntu.com/ubuntu/ trusty-infra-security/main amd64 Packages
+  release 
v=14.04,o=UbuntuESM,a=trusty-infra-security,n=trusty,l=UbuntuESM,c=main
  
+ === Confirmed proper origins on Bionic for enabled ESM-infra and ESM-apps on 
an AWS Ubuntu PRO instance:
+  500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
+  release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64
  
-  500 https://esm.ubuntu.com/ubuntu/ trusty-infra-security/main amd64 Packages
-  release 
v=14.04,o=UbuntuESM,a=trusty-infra-security,n=trusty,l=UbuntuESM,c=main
- 
- Confirmed proper origins on Bionic for enabled ESM-infra and ESM-apps on an 
AWS Ubuntu PRO instance:
-  500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
-  release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64
- 
-  500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 
Packages
-  release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-security,n=bionic,l=UbuntuESMApps,c=main,b=amd64
+  500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 
Packages
+  release 

[Touch-packages] [Bug 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESM:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2019-12-19 Thread Chad Smith
** Summary changed:

- Please add ${distro_id}ESM:${distro_codename}-infra-security  and 
t${distro_id}ESM:${distro_codename}-apps-securityo allowed origins (on Ubuntu)
+ Please add ${distro_id}ESM:${distro_codename}-infra-security  and 
${distro_id}ESM:${distro_codename}-apps-security to allowed origins (on Ubuntu)

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESM:${distro_codename}-apps-security to allowed origins
  (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  New
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  New
Status in unattended-upgrades source package in Bionic:
  New

Bug description:
  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051/+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 1823376] Re: Please add ${distro_id}ESM:${distro_codename}-security to allowed origins (on Ubuntu)

2019-12-19 Thread Chad Smith
This bug was fixed (and seems available in Eoan and Focal) but this
feature Unattended upgrades setting was not backported to trusty, xenial
or bionic. Please consider this backport to support ESM
-security origins on trusty, xenial and bionic.

** Also affects: unattended-upgrades (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Trusty)
   Importance: Undecided
   Status: New

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-security to allowed
  origins (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  New
Status in unattended-upgrades source package in Bionic:
  New

Bug description:
  .

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1823376/+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 1857051] [NEW] Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESM:${distro_codename}-apps-security to allowed origins (on Ubuntu)

2019-12-19 Thread Chad Smith
Public bug reported:

ESM -infra-security and -apps-security will need to
participate in unattended upgrades.

** Affects: unattended-upgrades (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: unattended-upgrades (Ubuntu Trusty)
 Importance: Undecided
 Status: New

** Affects: unattended-upgrades (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: unattended-upgrades (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Also affects: unattended-upgrades (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESM:${distro_codename}-apps-security to allowed origins
  (on Ubuntu)

Status in unattended-upgrades package in Ubuntu:
  New
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  New
Status in unattended-upgrades source package in Bionic:
  New

Bug description:
  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051/+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 1855616] Re: apport tries to hit ec2 metadata service if cloud-init is installed

2019-12-08 Thread Chad Smith
I'll have to double check on UEC images and whether cloud-init is
included in those image types, but we should be able to depend on the
following function that that is the case:

def add_cloud_info(report):
# EC2 and Ubuntu Enterprise Cloud instances
try:
 instance_data = json.loads(
subprocess.check_output(['cloud-init', 'query', '--all']).decode())
except subprocess.CalledProcessError as e:
return
report = {}
if instance_data.get('platform') == 'ec2':
ami = instance_data.get('ds', {}).get('meta_data', {}).get('ami_id')
if ami and ami.startswith('ami'):
report['Ec2AMI'] = ami
fields = {
'Ec2AMIManifest': 'ds.meta_data.ami_manifest_path',
'Ec2Kernel': 'ds.dynamic.instance_identity.document.kernelId',
'Ec2Ramdisk':
'ds.dynamic.instance_identity.document.ramdiskId',
'Ec2InstanceType': 'ds.meta_data.instance_type',
'Ec2AvailabilityZone': 'availability_zone'}
for key, path in fields.items():
value = instance_data
for path_part in path.split('.'):
value = value.get(path_part)
if not value:
break
report[key] = value if value else 'unavailable'
else:
add_tag(report, 'uec-images')

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

Title:
  apport tries to hit ec2 metadata service if cloud-init is installed

Status in apport package in Ubuntu:
  New

Bug description:
  This probably made sense in 2012 but in focal all servers are going to
  have cloud-init installed. I *think* apport should consult "< /run
  /cloud-init/instance-data.json jq .v1.platform" but someone from
  server should probably check that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1855616/+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 1835581] Re: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes

2019-08-02 Thread Chad Smith
Manual validate of fix in -proposed systemd on bionic, disco and eoan
(eoan expected broken until followup to systemd-242 SRU is queued).

Azure uses DHCP classess routes and blocks all secondary IP traffic to
their IMDS service or external bound traffic.

Attached are success logs on Azure vms, showing proper handling of
secondary static IPs and dhcp IP as preferred src on default routes for
bionic and disco (and expected failure on eaon) for this SRU.


** Attachment added: "azure-secondary-nic-validation-bionic-disco-eoan.log"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835581/+attachment/5280521/+files/azure-secondary-nic-validation-bionic-disco-eoan.log

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

Title:
  networkd-dhcp4 does not set prefsrc for dhcp-provided classless or
  static routes

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Committed
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [impact]

  the systemd networkd dhcp4 client sets the prefsrc for the default
  route added when a dhcp server provides only the gateway; but if the
  dhcp server provides classless route(s), those are configured instead,
  and the prefsrc is not set for those.

  Normally this is ok, but if the dhcp client system has other
  address(es) configured on the interface using dhcp, then the src for
  packets sent through a classless/static route might not be the same as
  the address provided by the dhcp server.

  If the gateway/router provided in the dhcp classless/static route(s)
  only allows traffic from the address provided to the dhcp client, then
  traffic from the dhcp client may be dropped by the gateway/router.

  [test case]

  set up a dhcp server system (e.g. ubuntu with dnsmasq installed and
  configured) and a dhcp client system.  For example on the dhcp server,
  use this dnsmasq config:

  interface=ens8
  bind-interfaces
  domain=test,10.10.0.0/24
  dhcp-option=42,10.10.0.1
  dhcp-range=test,10.10.0.10,10.10.0.100,1h

  On the dhcp client system, use networkd config such as:

  $ cat /etc/systemd/network/80-ens8.network
  [Match]
  Name=ens8

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6
  Address=10.10.0.5/24

  Reboot the client, or restart networkd, and it should result in:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3580sec preferred_lft 3580sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp src 10.10.0.75 metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5
  10.10.0.1 dev ens8 proto dhcp scope link src 10.10.0.75 metric 1024

  Note that, because networkd completes the static ip configuration
  before the dhcp reply is returned and processed, the static address is
  used for the subnet-local routing.  But for global routing through the
  gateway, the dhcp-provided address is used:

  $ ip r get 1.1.1.1
  1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.75 uid 1000

  Now on the server, add a classless route:

  dhcp-option=121,0.0.0.0/0,10.10.0.1

  and restart dnsmasq on the server.  Then on the client, reboot.  It
  should now have:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3585sec preferred_lft 3585sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5

  Now, the global route will use the static address, not the dhcp-
  provided address:

  $ ip r get 1.1.1.1
  1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.5 uid 1000

  If the router, 10.10.0.1, only will forward traffic sent from the dhcp
  address it provided, 10.10.0.75, then this configuration will result
  in the client being unable to reach anything through the router,
  because all its packets will have a source address of 10.10.0.5, which
  the router would drop/reject.

  [regression potential]

  this only affects dhcp routes provided by a dhcp server using the
  'static' or 'classless' route dhcp options.  Since this behavior is
  currently the default when a system doesn't add static address(es) to
  interfaces that also get dhcp addresses, this is likely not a change
  in behavior for the vast majority of systems.  And any systems that do
  add static 

[Touch-packages] [Bug 1835581] Re: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes

2019-08-02 Thread Chad Smith
Manual validate of fix in -proposed systemd on bionic, disco and eoan
(eoan expected broken until followup to systemd-242 SRU is queued).

Azure uses DHCP classless routes and their backplane security blocks all
secondary IP traffic to either their IMDS service or externally bound
traffic.

Attached are success logs on Azure vms, showing proper handling of
secondary static IPs and dhcp IP as preferred src on default routes for
Bionic and Disco (and expected failure on Eoan) for this SRU.

** Attachment added: "azure-secondary-nic-validation-bionic-disco-eoan.log"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835581/+attachment/5280522/+files/azure-secondary-nic-validation-bionic-disco-eoan.log

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

Title:
  networkd-dhcp4 does not set prefsrc for dhcp-provided classless or
  static routes

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Committed
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [impact]

  the systemd networkd dhcp4 client sets the prefsrc for the default
  route added when a dhcp server provides only the gateway; but if the
  dhcp server provides classless route(s), those are configured instead,
  and the prefsrc is not set for those.

  Normally this is ok, but if the dhcp client system has other
  address(es) configured on the interface using dhcp, then the src for
  packets sent through a classless/static route might not be the same as
  the address provided by the dhcp server.

  If the gateway/router provided in the dhcp classless/static route(s)
  only allows traffic from the address provided to the dhcp client, then
  traffic from the dhcp client may be dropped by the gateway/router.

  [test case]

  set up a dhcp server system (e.g. ubuntu with dnsmasq installed and
  configured) and a dhcp client system.  For example on the dhcp server,
  use this dnsmasq config:

  interface=ens8
  bind-interfaces
  domain=test,10.10.0.0/24
  dhcp-option=42,10.10.0.1
  dhcp-range=test,10.10.0.10,10.10.0.100,1h

  On the dhcp client system, use networkd config such as:

  $ cat /etc/systemd/network/80-ens8.network
  [Match]
  Name=ens8

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6
  Address=10.10.0.5/24

  Reboot the client, or restart networkd, and it should result in:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3580sec preferred_lft 3580sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp src 10.10.0.75 metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5
  10.10.0.1 dev ens8 proto dhcp scope link src 10.10.0.75 metric 1024

  Note that, because networkd completes the static ip configuration
  before the dhcp reply is returned and processed, the static address is
  used for the subnet-local routing.  But for global routing through the
  gateway, the dhcp-provided address is used:

  $ ip r get 1.1.1.1
  1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.75 uid 1000

  Now on the server, add a classless route:

  dhcp-option=121,0.0.0.0/0,10.10.0.1

  and restart dnsmasq on the server.  Then on the client, reboot.  It
  should now have:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3585sec preferred_lft 3585sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5

  Now, the global route will use the static address, not the dhcp-
  provided address:

  $ ip r get 1.1.1.1
  1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.5 uid 1000

  If the router, 10.10.0.1, only will forward traffic sent from the dhcp
  address it provided, 10.10.0.75, then this configuration will result
  in the client being unable to reach anything through the router,
  because all its packets will have a source address of 10.10.0.5, which
  the router would drop/reject.

  [regression potential]

  this only affects dhcp routes provided by a dhcp server using the
  'static' or 'classless' route dhcp options.  Since this behavior is
  currently the default when a system doesn't add static address(es) to
  interfaces that also get dhcp addresses, this is likely not a change
  in behavior for the vast majority of systems.  And 

[Touch-packages] [Bug 1759307] Re: missing dependency on isc-dhcp-client (dhclient)

2018-03-27 Thread Chad Smith
** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  missing dependency on isc-dhcp-client (dhclient)

Status in cloud-init package in Ubuntu:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary
  dhcp ip addresses.  It currently does not identify a dependency on it.

  initramfs-tools uses dhclient in scripts/functions to obtain ipv6 addresses
  (see bug 1621507 for more info).

  This bug was prompted by MP to remove isc-dhcp-client from the ubuntu-minimal 
seed
   
https://code.launchpad.net/~vorlon/ubuntu-seeds/platform.bionic-dhcp-switch/+merge/342013

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1759307/+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 1722564] Re: apport question will not accept multi-character responses

2017-11-09 Thread Chad Smith
** Description changed:

- the newly added cloud-init apport support shows a list of cloud
- providers and asks the user to select one.  There are currently 18
- options.  For any option > 10, apport will just take the '1' that is
- typed as the answer.
+ === Begin SRU Template ===
+ [Impact]
+ Packages which provide apport integration with more than 9 options in a 
choice will not be able to select options numbered >= 10 on the commandline 
using 'ubuntu-bug '
+ 
+ 
+ [Test Case]
+ Overview:
+  1. Update to proposed versions of cloud-init v. 17.1 and apport v. 
+  2. Run 'ubuntu-bug cloud-init' attempt to report a bug on a cloud choice 
greater than 9
+  3. View report and make sure the proper cloud is reported
+ 
+ 
+ Script:
+ if [ ! -f './lxc-proposed-snapshot' ]; then
+   wget 
https://raw.githubusercontent.com/cloud-init/ubuntu-sru/master/bin/lxc-proposed-snapshot;
+   chmod 755 lxc-proposed-snapshot;
+ fi
+ 
+ for release in xenial artful; do
+ ref=$release-proposed;
+ echo "$release START --";
+ lxc-proposed-snapshot --proposed --publish $release $ref;
+ lxc init $ref test-$release;
+ lxc start test-$release;
+ lxc exec test-$release -- apt install apport;
+ lxc exec test-$release -- dpkg-query --show apport;
+ lxc exec test-$release -- ubuntu-bug cloud-init;
+ done
+ 
+ [Regression Potential]
+ Minimal. This bug only affects packages with >9 bug filing options for a 
given choice. Worst case, is bugs filed would incorrectly represent option 1 of 
a selection instead of option 1X.
+ 
+ 
+ === End SRU Template ===
+ 
+ === original description ===
+ the newly added cloud-init apport support shows a list of cloud providers and 
asks the user to select one.  There are currently 18 options.  For any option > 
10, apport will just take the '1' that is typed as the answer.
  
  It should obviously wait for more than one character or a carriage
  return.
  
- 
- *** Please select the cloud vendor or environment in which this instance is 
running
- 
+ *** Please select the cloud vendor or environment in which this instance
+ is running
  
  Choices:
-   1: Amazon - Ec2
-   2: AliYun
-   3: AltCloud
-   4: Azure
-   5: Bigstep
-   6: CloudSigma
-   7: CloudStack
-   8: DigitalOcean
-   9: GCE - Google Compute Engine
-   10: MAAS
-   11: NoCloud
-   12: OpenNebula
-   13: OpenStack
-   14: OVF
-   15: Scaleway
-   16: SmartOS
-   17: VMware
-   18: Other
-   C: Cancel
+   1: Amazon - Ec2
+   2: AliYun
+   3: AltCloud
+   4: Azure
+   5: Bigstep
+   6: CloudSigma
+   7: CloudStack
+   8: DigitalOcean
+   9: GCE - Google Compute Engine
+   10: MAAS
+   11: NoCloud
+   12: OpenNebula
+   13: OpenStack
+   14: OVF
+   15: Scaleway
+   16: SmartOS
+   17: VMware
+   18: Other
+   C: Cancel
  Please choose (1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/C): 1
  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: apport 2.20.7-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu2
  Architecture: amd64
  Date: Tue Oct 10 15:21:48 2017
  PackageArchitecture: all
  ProcEnviron:
-  TERM=xterm-256color
-  PATH=(custom, no user)
-  LANG=C.UTF-8
+  TERM=xterm-256color
+  PATH=(custom, no user)
+  LANG=C.UTF-8
  SourcePackage: apport
  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 apport in Ubuntu.
https://bugs.launchpad.net/bugs/1722564

Title:
  apport question will not accept multi-character responses

Status in Apport:
  Confirmed
Status in apport package in Ubuntu:
  In Progress
Status in apport source package in Xenial:
  New
Status in apport source package in Artful:
  In Progress

Bug description:
  === Begin SRU Template ===
  [Impact]
  Packages which provide apport integration with more than 9 options in a 
choice will not be able to select options numbered >= 10 on the commandline 
using 'ubuntu-bug '

  
  [Test Case]
  Overview:
   1. Update to proposed versions of cloud-init v. 17.1 and apport v. 
   2. Run 'ubuntu-bug cloud-init' attempt to report a bug on a cloud choice 
greater than 9
   3. View report and make sure the proper cloud is reported


  Script:
  if [ ! -f './lxc-proposed-snapshot' ]; then
wget 
https://raw.githubusercontent.com/cloud-init/ubuntu-sru/master/bin/lxc-proposed-snapshot;
chmod 755 lxc-proposed-snapshot;
  fi

  for release in xenial artful; do
  ref=$release-proposed;
  echo "$release START --";
  lxc-proposed-snapshot --proposed --publish $release $ref;
  lxc init $ref test-$release;
  lxc start test-$release;
  lxc exec test-$release -- apt install apport;
  lxc exec test-$release -- dpkg-query --show apport;
  lxc exec test-$release -- ubuntu-bug cloud-init;
  done

  [Regression Potential]
  

[Touch-packages] [Bug 1722564] Re: apport question will not accept multi-character responses

2017-10-24 Thread Chad Smith
Just tested on artful both above and below the prompt choice threshold
of 10 and bug reporting works.  Input of "9" for single digits
choices versus "13" for multi-digit choices both work now for
choice prompts with long lists. Short choice list prompts retain their
single character responses.

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

Title:
  apport question will not accept multi-character responses

Status in Apport:
  Confirmed
Status in apport package in Ubuntu:
  In Progress
Status in apport source package in Artful:
  In Progress

Bug description:
  the newly added cloud-init apport support shows a list of cloud
  providers and asks the user to select one.  There are currently 18
  options.  For any option > 10, apport will just take the '1' that is
  typed as the answer.

  It should obviously wait for more than one character or a carriage
  return.

  
  *** Please select the cloud vendor or environment in which this instance is 
running

  
  Choices:
1: Amazon - Ec2
2: AliYun
3: AltCloud
4: Azure
5: Bigstep
6: CloudSigma
7: CloudStack
8: DigitalOcean
9: GCE - Google Compute Engine
10: MAAS
11: NoCloud
12: OpenNebula
13: OpenStack
14: OVF
15: Scaleway
16: SmartOS
17: VMware
18: Other
C: Cancel
  Please choose (1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/C): 1

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: apport 2.20.7-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu2
  Architecture: amd64
  Date: Tue Oct 10 15:21:48 2017
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1722564/+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 1722564] Re: apport question will not accept multi-character responses

2017-10-24 Thread Chad Smith
Yeah that feels like a premature optomization as that limits your interface 
options significantly (to only 9 valid choices). I'm suprised there haven't 
been any other bugs related to this, but maybe there aren't a lot of cli 
use-cases out there with complex bug-reporting choices.
I've attached a branch that now readlines instance or read(1) for prompts which 
contain a large set of choices (> 10).


This merge proposal a bit more flexible as it'd also permit options where > 99 
choices are presented. I would think that > 99 choices would be a usability 
issues as I can't fathom people reading through 100+ separate options to 
actually choose the one that best applies to them.


I'm not sure the SRU team understood the impact of the branch. Per the pastebin 
that I provided originally, the user wouldn't have to input "3 " they would 
input "3" or "1" or "11".


I've since changes this branch to read until  for all choices if the # 
or choices are > 10. This means that all existing apport use-cases retain the 
optimized 1 character choice selection if their provided choices are <= 9. For 
any lists larger than that (which is currently broken in apport) the user will 
have to hit enter after their choice.

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

Title:
  apport question will not accept multi-character responses

Status in Apport:
  Confirmed
Status in apport package in Ubuntu:
  In Progress
Status in apport source package in Artful:
  In Progress

Bug description:
  the newly added cloud-init apport support shows a list of cloud
  providers and asks the user to select one.  There are currently 18
  options.  For any option > 10, apport will just take the '1' that is
  typed as the answer.

  It should obviously wait for more than one character or a carriage
  return.

  
  *** Please select the cloud vendor or environment in which this instance is 
running

  
  Choices:
1: Amazon - Ec2
2: AliYun
3: AltCloud
4: Azure
5: Bigstep
6: CloudSigma
7: CloudStack
8: DigitalOcean
9: GCE - Google Compute Engine
10: MAAS
11: NoCloud
12: OpenNebula
13: OpenStack
14: OVF
15: Scaleway
16: SmartOS
17: VMware
18: Other
C: Cancel
  Please choose (1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/C): 1

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: apport 2.20.7-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu2
  Architecture: amd64
  Date: Tue Oct 10 15:21:48 2017
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1722564/+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 1722564] Re: apport question will not accept multi-character responses

2017-10-24 Thread Chad Smith
** Branch linked: lp:~chad.smith/apport/add-multichar-response-for-long-
lists

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

Title:
  apport question will not accept multi-character responses

Status in Apport:
  Confirmed
Status in apport package in Ubuntu:
  In Progress
Status in apport source package in Artful:
  In Progress

Bug description:
  the newly added cloud-init apport support shows a list of cloud
  providers and asks the user to select one.  There are currently 18
  options.  For any option > 10, apport will just take the '1' that is
  typed as the answer.

  It should obviously wait for more than one character or a carriage
  return.

  
  *** Please select the cloud vendor or environment in which this instance is 
running

  
  Choices:
1: Amazon - Ec2
2: AliYun
3: AltCloud
4: Azure
5: Bigstep
6: CloudSigma
7: CloudStack
8: DigitalOcean
9: GCE - Google Compute Engine
10: MAAS
11: NoCloud
12: OpenNebula
13: OpenStack
14: OVF
15: Scaleway
16: SmartOS
17: VMware
18: Other
C: Cancel
  Please choose (1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/C): 1

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: apport 2.20.7-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu2
  Architecture: amd64
  Date: Tue Oct 10 15:21:48 2017
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1722564/+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 1722564] Re: apport question will not accept multi-character responses

2017-10-24 Thread Chad Smith
Ahh brian, sorry for this delay here, I forgot to subscribe to the bug.
So those variable changes where actually because I had update apport on
a zesty machine but accidentally diffed against xenial  source. I'll put
up an official upstream apport merge proposal and link it here so we can
proceed with a discussion.

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

Title:
  apport question will not accept multi-character responses

Status in Apport:
  Confirmed
Status in apport package in Ubuntu:
  In Progress
Status in apport source package in Artful:
  In Progress

Bug description:
  the newly added cloud-init apport support shows a list of cloud
  providers and asks the user to select one.  There are currently 18
  options.  For any option > 10, apport will just take the '1' that is
  typed as the answer.

  It should obviously wait for more than one character or a carriage
  return.

  
  *** Please select the cloud vendor or environment in which this instance is 
running

  
  Choices:
1: Amazon - Ec2
2: AliYun
3: AltCloud
4: Azure
5: Bigstep
6: CloudSigma
7: CloudStack
8: DigitalOcean
9: GCE - Google Compute Engine
10: MAAS
11: NoCloud
12: OpenNebula
13: OpenStack
14: OVF
15: Scaleway
16: SmartOS
17: VMware
18: Other
C: Cancel
  Please choose (1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/C): 1

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: apport 2.20.7-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu2
  Architecture: amd64
  Date: Tue Oct 10 15:21:48 2017
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1722564/+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 1722564] Re: apport question will not accept multi-character responses

2017-10-18 Thread Chad Smith
This quick fix worked on my side http://paste.ubuntu.com/25715415/
allows for two char reading if choices> 10

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

Title:
  apport question will not accept multi-character responses

Status in Apport:
  Confirmed
Status in apport package in Ubuntu:
  Triaged

Bug description:
  the newly added cloud-init apport support shows a list of cloud
  providers and asks the user to select one.  There are currently 18
  options.  For any option > 10, apport will just take the '1' that is
  typed as the answer.

  It should obviously wait for more than one character or a carriage
  return.

  
  *** Please select the cloud vendor or environment in which this instance is 
running

  
  Choices:
1: Amazon - Ec2
2: AliYun
3: AltCloud
4: Azure
5: Bigstep
6: CloudSigma
7: CloudStack
8: DigitalOcean
9: GCE - Google Compute Engine
10: MAAS
11: NoCloud
12: OpenNebula
13: OpenStack
14: OVF
15: Scaleway
16: SmartOS
17: VMware
18: Other
C: Cancel
  Please choose (1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/C): 1

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: apport 2.20.7-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu2
  Architecture: amd64
  Date: Tue Oct 10 15:21:48 2017
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1722564/+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 1240757] Re: Bridge not created if bind9 is on

2015-10-16 Thread Chad Smith
Looks like the proper syntax for the listen-on named config is  either


Just tested on MAAS dns service which fails > 75% of the time when brought up 
in a vm due to timing issues.

The proposed  "listen-on { ! 10.0.3.1; };"   cannot be parsed by bind
because ! is supposed to be outside the address list match element.
(per http://www.zytrax.com/books/dns/ch7/address_match_list.html)


I think the fix should be:

listen-on ! { 10.0.3.1; };

With this setting in my maas dns/bind conf, bind comes up without error
and I don't get collisions with lxc ips on the system.

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

Title:
  Bridge not created if bind9 is on

Status in bind9 package in Ubuntu:
  Confirmed
Status in lxc package in Ubuntu:
  Confirmed

Bug description:
  LXC will not create the lxcbr0 bridge if bind9 is on, as it can not
  take the 10.0.3.1 address. If bind9 is stopped, then LXC successfully
  creates the bridge.

  Expected result: LXC will create the bridge, even if bind9 is on.
  --- 
  ApportVersion: 2.9.2-0ubuntu8.3
  Architecture: i386
  DistroRelease: Ubuntu 13.04
  InstallationDate: Installed on 2013-06-29 (110 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release i386 (20130424)
  MarkForUpload: True
  Package: lxc
  PackageArchitecture: i386
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.8.0-31-generic 
root=UUID=4c07e19b-cf33-4cbd-ab6d-fe300398b22b ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 3.8.0-31.46-generic 3.8.13.8
  RelatedPackageVersions:
   bind9utils 1:9.9.2.dfsg.P1-2ubuntu2.1
   apparmor   2.8.0-0ubuntu11
  Tags:  raring
  Uname: Linux 3.8.0-31-generic i686
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  modified.conffile..etc.bind.named.conf.local: [modified]
  mtime.conffile..etc.bind.named.conf.local: 2013-08-01T12:03:20.742316

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1240757/+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 1240757] Re: Bridge not created if bind9 is on

2015-10-16 Thread Chad Smith
hmm, I should've validated this statement above further on deployments.
I am seeing other errors with bind with the above suggestion. I'll debug
more and present results.

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

Title:
  Bridge not created if bind9 is on

Status in bind9 package in Ubuntu:
  Confirmed
Status in lxc package in Ubuntu:
  Confirmed

Bug description:
  LXC will not create the lxcbr0 bridge if bind9 is on, as it can not
  take the 10.0.3.1 address. If bind9 is stopped, then LXC successfully
  creates the bridge.

  Expected result: LXC will create the bridge, even if bind9 is on.
  --- 
  ApportVersion: 2.9.2-0ubuntu8.3
  Architecture: i386
  DistroRelease: Ubuntu 13.04
  InstallationDate: Installed on 2013-06-29 (110 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release i386 (20130424)
  MarkForUpload: True
  Package: lxc
  PackageArchitecture: i386
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.8.0-31-generic 
root=UUID=4c07e19b-cf33-4cbd-ab6d-fe300398b22b ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 3.8.0-31.46-generic 3.8.13.8
  RelatedPackageVersions:
   bind9utils 1:9.9.2.dfsg.P1-2ubuntu2.1
   apparmor   2.8.0-0ubuntu11
  Tags:  raring
  Uname: Linux 3.8.0-31-generic i686
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  modified.conffile..etc.bind.named.conf.local: [modified]
  mtime.conffile..etc.bind.named.conf.local: 2013-08-01T12:03:20.742316

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1240757/+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 1240757] Re: Bridge not created if bind9 is on

2015-10-16 Thread Chad Smith
Ok attempt #2.


Looks like the original clause below didn't match any addresses  so I was 
getting connection refused messages

listen-on { ! 10.0.3.1; };

What I found worked on my end was specifying a secondary address match
list 'any' which we fall through to match any ipv4 address  that is not
10.0.3.1:

listen-on { ! 10.0.3.1; any; };

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

Title:
  Bridge not created if bind9 is on

Status in bind9 package in Ubuntu:
  Confirmed
Status in lxc package in Ubuntu:
  Confirmed

Bug description:
  LXC will not create the lxcbr0 bridge if bind9 is on, as it can not
  take the 10.0.3.1 address. If bind9 is stopped, then LXC successfully
  creates the bridge.

  Expected result: LXC will create the bridge, even if bind9 is on.
  --- 
  ApportVersion: 2.9.2-0ubuntu8.3
  Architecture: i386
  DistroRelease: Ubuntu 13.04
  InstallationDate: Installed on 2013-06-29 (110 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release i386 (20130424)
  MarkForUpload: True
  Package: lxc
  PackageArchitecture: i386
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.8.0-31-generic 
root=UUID=4c07e19b-cf33-4cbd-ab6d-fe300398b22b ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 3.8.0-31.46-generic 3.8.13.8
  RelatedPackageVersions:
   bind9utils 1:9.9.2.dfsg.P1-2ubuntu2.1
   apparmor   2.8.0-0ubuntu11
  Tags:  raring
  Uname: Linux 3.8.0-31-generic i686
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  modified.conffile..etc.bind.named.conf.local: [modified]
  mtime.conffile..etc.bind.named.conf.local: 2013-08-01T12:03:20.742316

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