[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Chad Smith]

Thanks Lukas: +1 on this changeset not degrading early boot install
scenarios  where systemd services are ordered After=systemd-networkd-
wait-online.service

Preliminary testing on Azure platform look good with accelerated networking 
enabled have confirmed dual-nic tests correctly configure the primary network 
devices brought  and blocking systemd-networkd-wait-online awaiting the 
matching hv_netsvc devices.
The tests confirm systemd-networkd-wait-online.service properly awaits the 
individual devices Also, initial cloud-init integration test runs on Azure 
noble w/ netplan.io v.1.0-2ubuntu1 do not seem to expose any regressions for 
our integration tests so far. 

cloud-init Ec2 testing of this same proposed netplan.io package doesn't
show any degradation of behavior in detecting Ec2's IMDS in early boot.

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

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Invalid
Status in netplan.io source package in Noble:
  Fix Committed
Status in systemd source package in Noble:
  Invalid

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2033926] Re: NTP module broken in mantic

[Chad Smith]

Marking the cloud-init task here as invalid as this is a systemd
packaging issue that was resolved in  253.5-1ubuntu4

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

Title:
  NTP module broken in mantic

Status in cloud-init package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  tests/integration_tests/modules/test_ntp_servers.py is failing. With
  this user data:

  #cloud-config
  ntp:
ntp_client: ntp
servers:
- 172.16.15.14
- 172.16.17.18
pools:
- 0.cloud-init.mypool
- 1.cloud-init.mypool
- 172.16.15.15

  The apt install of ntp fails in the logs. If I try to install locally,
  I get:

  root@cloudinit-0901-195800sev1vrx3:~# apt install ntp
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   ntpsec : Conflicts: time-daemon
   systemd-timesyncd : Conflicts: time-daemon
  E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2033926/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2033926] Re: NTP module broken in mantic

[Chad Smith]

Closing this issue as it was a debian/control problem in systemd-
timesyncd that dropped "Provides: time-daemon" from the package
declarations in systemd 253.5-1ubuntu3. This prevented apt resolver in
mantic from properly recognizing the conflicts between systemd-timesyncd
and ntpsec. So the resolver couldn't determine that it had to remote
systemd-timesyncd.


This debian/control issue was fixed in systemd 253.5-1ubuntu4 which is
not yet installed in daily mantic builds for cloudimages in lxc. So,
this results in an inability of apt to resolve those conflicts on the
stale systemd-timesyncd 253.5-1ubuntu3 which is installed in those
images.


To resolve this conflict prior to cloudimage updates:
apt update
apt install systemd-timesyncd


apt install ntp # now works fine and removes systemd-timesyncd automatically 
because of the proper Provides: time-daemon

** Changed in: cloud-init (Ubuntu)
   Status: Triaged => Fix Released

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

** Changed in: systemd (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Status: Fix Released => Invalid

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

Title:
  NTP module broken in mantic

Status in cloud-init package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  tests/integration_tests/modules/test_ntp_servers.py is failing. With
  this user data:

  #cloud-config
  ntp:
ntp_client: ntp
servers:
- 172.16.15.14
- 172.16.17.18
pools:
- 0.cloud-init.mypool
- 1.cloud-init.mypool
- 172.16.15.15

  The apt install of ntp fails in the logs. If I try to install locally,
  I get:

  root@cloudinit-0901-195800sev1vrx3:~# apt install ntp
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   ntpsec : Conflicts: time-daemon
   systemd-timesyncd : Conflicts: time-daemon
  E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2033926/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2030788] Re: "localectl set-x11-keymap" doesn't work in mantic

[Chad Smith]

** Description changed:

  On the raspi arm64 server image, I used to use cloud-init's keyboard
  module to set my keyboard to GB by default. However, on mantic localectl
  (which the keyboard module uses) is now reporting:
  
-   $ localectl set-x11-keymap gb pc105
-   Setting X11 and console keymaps is not supported in Debian
+   $ localectl set-x11-keymap gb pc105
+   Setting X11 and console keymaps is not supported in Debian
  
  So ... how do I get my £ key by default now? Or should this be filed
  against systemd as well?
+ 
+ 
+ === update 
+ cloud-init 23.3 release now writes /etc/default/keyboard directly instead of 
calling: localectl set-x11-keymap. After setting keymap/layout, cloud-init also 
runs: systemctl restart console-setup.
+ 
+ The remaining question is do we want to improve usability of the error
+ message or hints/docs for admins describing how to set up keymap/layout?

** Summary changed:

- "localectl set-x11-keymap" doesn't work in mantic
+ Usability: "localectl set-x11-keymap" doesn't work in mantic

** Changed in: cloud-init (Ubuntu)
 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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2030788

Title:
  Usability: "localectl set-x11-keymap" doesn't work in mantic

Status in cloud-init package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  On the raspi arm64 server image, I used to use cloud-init's keyboard
  module to set my keyboard to GB by default. However, on mantic
  localectl (which the keyboard module uses) is now reporting:

    $ localectl set-x11-keymap gb pc105
    Setting X11 and console keymaps is not supported in Debian

  So ... how do I get my £ key by default now? Or should this be filed
  against systemd as well?

  
  === update 
  cloud-init 23.3 release now writes /etc/default/keyboard directly instead of 
calling: localectl set-x11-keymap. After setting keymap/layout, cloud-init also 
runs: systemctl restart console-setup.

  The remaining question is do we want to improve usability of the error
  message or hints/docs for admins describing how to set up
  keymap/layout?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2030788/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2030788] Re: "localectl set-x11-keymap" doesn't work in mantic

[Chad Smith]

This bug is fix released in cloud-init 23.3-0ubuntu1 in Ubuntu mantic.

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

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

Title:
  "localectl set-x11-keymap" doesn't work in mantic

Status in cloud-init package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  On the raspi arm64 server image, I used to use cloud-init's keyboard
  module to set my keyboard to GB by default. However, on mantic
  localectl (which the keyboard module uses) is now reporting:

$ localectl set-x11-keymap gb pc105
Setting X11 and console keymaps is not supported in Debian

  So ... how do I get my £ key by default now? Or should this be filed
  against systemd as well?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2030788/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

While SRU verification did test lunar. I had forgotten the original
release of 23.1 was already published to lunar containing the cloud-init
changes for apport/general-hooks/cloud-init.py and apport/package-
hooks/cloud-init.py that we are verifying here.


I've marked Lunar task as fix-released since 23.1 already contains this 
published fix. The verification script just stands to validate it works as 
advertised.

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

Title:
  Update ubuntu cloud info

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Focal:
  Fix Committed
Status in cloud-init source package in Jammy:
  Fix Committed
Status in cloud-init source package in Kinetic:
  Fix Committed
Status in apport source package in Lunar:
  New
Status in cloud-init source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]
  Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id

  [ Test Plan ]

  1. Launch LXD container for each series
  2. upgrade to cloud-init from -proposed.
  3. Execute apport-bug cloud-init and view report to assess that correct tags 
are present for LXD datasource.
  4. replace /run/cloud-init/instance-data.json cloud-id content with examples 
from openstack, ec2, configdrive and assert appropriate tags match the platform 
details.

  verification scriptlet (attached):

  #!/bin/bash
  set -ex

  cat > setup_proposed.sh  openstack.json  ec2.json << EOF
  {
    "ds": {
  "imageId": "ami-123",
  "instanceType": "m1.tiny",
  "region": "us-east-1"
    },
    "v1": {
  "cloud_name": "aws",
  "distro": "ubuntu",
  "distro_release": "jammy",
  "distro_version": "22.04",
  "instance_id": "i-06b5687b4d7b8595d",
  "machine": "x86_64",
  "platform": "ec2",
  "python_version": "3.10.4",
  "region": "us-east-2",
  "variant": "ubuntu"
    }
  }
  EOF

  for release in focal jammy kinetic lunar; do
   VM=sru-$release
   lxc launch ubuntu-daily:$release $VM
   while ! lxc exec $VM -- cloud-init status --wait --long; do
  sleep 5
   done
   echo --- 1. Generate current apport report, selecting Openstack as cloud.
   echo --- step through prompts and select 'K' to keep report
   echo --- VERSION OF APPORT ---
   lxc exec $VM -- apport-bug --version
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.orig
   lxc exec $VM rm /tmp/$APPORT_FILE

   lxc file push setup_proposed.sh $VM/
   lxc exec $VM -- bash /setup_proposed.sh | grep cloud-init

   lxc file push openstack.json $VM/run/cloud-init/instance-data.json
   echo --- 2. Generate -proposed apport report which sources openstack 
instance-data.json, selecting Openstack as cloud.
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.openstack-proposed
   lxc exec $VM rm /tmp/$APPORT_FILE

   echo --- 3. Generate -proposed apport report which sources ec2 
instance-data, selecting Ec2 as cloud.
   lxc file push ec2.json $VM/run/cloud-init/instance-data.json
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.ec2-proposed
   lxc exec $VM rm /tmp/$APPORT_FILE

   # redact logs lines for easy diffs
   for file in `ls apport*`; do
   sed -i '1,/logs.tgz/!d' $file
   done
   echo --- 4. Inspect diff tags of orig to openstack-proposed report
   diff -urN apport-$VM.orig apport-$VM.openstack-proposed || true
   echo --- 5. Inspect diff tags of openstack-proposed to ec2-proposed report
   diff -urN apport-$VM.openstack-proposed apport-$VM.ec2-proposed || true

  done

  [ Where problems could occur ]
  apport-bug could traceback on poor logic preventing simple bug filing at 
apport CLI. It could omit tags if unable to process 
cloud-init/instance-data.json. nothing critical to daily performance, uptime or 
security

  [ Other Info ]

  [Original description]

  Issues:
   - Using the presence of cloud-init to flag an image as a cloud image is 
incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images)
   - Using the presence of EC2 metadata source is incorrect as many non-EC2 
clouds provide EC2 metadata. 

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

Updated test script asserting specific cloud-init version 23.2.1 as
lunar was not installing from lunar-proposed by default without apt
install -tlunar-proposed.

also changed test to specifically assert expected
CloudName/PlatformSubplatform or Region  and collect FAILED logs
otherwise


Test verification results:
=
csmith@midtown:~$ ./sru-1724623.sh 
+ cat
+ cat
+ cat
+ rm -f failures
+ for release in focal jammy kinetic lunar
+ VM=sru-focal
+ lxc launch ubuntu-daily:focal sru-focal
Creating sru-focal
Starting sru-focal
+ lxc exec sru-focal -- cloud-init status --wait --long

status: done
boot_status_code: enabled-by-generator
last_update: Thu, 13 Jul 2023 19:31:03 +
detail:
DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]
+ echo --- 1. Generate current apport report, selecting Openstack as cloud.
--- 1. Generate current apport report, selecting Openstack as cloud.
+ echo --- step through prompts and select K to keep report
--- step through prompts and select K to keep report
+ echo --- VERSION OF APPORT ---
--- VERSION OF APPORT ---
+ lxc exec sru-focal -- apport-bug --version
2.20.11
+ lxc exec sru-focal -- apport-bug cloud-init

*** Collecting problem information

The collected information can be sent to the developers to improve the
application. This might take a few minutes.
..
*** Your device details (lshw) may be useful to developers when addressing this 
bug, but gathering it requires admin privileges. Would you like to include this 
info?


What would you like to do? Your options are:
  Y: Yes
  N: No
  C: Cancel
Please choose (Y/N/C): n

*** Is this machine running in a cloud environment?


What would you like to do? Your options are:
  Y: Yes
  N: No
  C: Cancel
Please choose (Y/N/C): y

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


Choices:
  1: AliYun
  2: AltCloud
  3: Amazon - Ec2
  4: Azure
  5: Bigstep
  6: Brightbox
  7: CloudSigma
  8: CloudStack
  9: DigitalOcean
  10: E24Cloud
  11: GCE - Google Compute Engine
  12: Huawei Cloud
  13: Exoscale
  14: Hetzner Cloud
  15: NWCS
  16: IBM - (aka SoftLayer or BlueMix)
  17: LXD
  18: MAAS
  19: NoCloud
  20: OpenNebula
  21: OpenStack
  22: Oracle
  23: OVF
  24: RbxCloud - (HyperOne, Rootbox, Rubikon)
  25: OpenTelekomCloud
  26: SAP Converged Cloud
  27: Scaleway
  28: SmartOS
  29: UpCloud
  30: VMware
  31: Vultr
  32: ZStack
  33: Outscale
  34: Other
  C: Cancel
Please choose 
(1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/C):
 21


*** Your user-data, cloud-config or autoinstall files can optionally  be 
provided from /var/lib/cloud/instance/user-data.txt and could be useful to 
developers when addressing this bug. Do you wish to attach user-data to this 
bug?


What would you like to do? Your options are:
  Y: Yes
  N: No
  C: Cancel
Please choose (Y/N/C): y
...

*** Send problem report to the developers?

After the problem report has been sent, please fill out the form in the
automatically opened web browser.

What would you like to do? Your options are:
  S: Send report (43.7 KB)
  V: View report
  K: Keep report file for sending later or copying to somewhere else
  I: Cancel and ignore future crashes of this program version
  C: Cancel
Please choose (S/V/K/I/C): k
Problem report file: /tmp/apport.cloud-init.svir_fqp.apport
++ lxc exec sru-focal ls /tmp
++ grep apport
+ APPORT_FILE=apport.cloud-init.svir_fqp.apport
+ lxc file pull sru-focal/tmp/apport.cloud-init.svir_fqp.apport 
apport-sru-focal.orig
+ lxc exec sru-focal rm /tmp/apport.cloud-init.svir_fqp.apport
+ lxc file push setup_proposed.sh sru-focal/
+ lxc exec sru-focal -- bash /setup_proposed.sh 
 
+ grep cloud-init
  cloud-init
Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 cloud-init all 
23.2.1-0ubuntu0~20.04.2 [532 kB]
dpkg-preconfigure: unable to re-open stdin: No such file or directory
Preparing to unpack .../cloud-init_23.2.1-0ubuntu0~20.04.2_all.deb ...
Unpacking cloud-init (23.2.1-0ubuntu0~20.04.2) over (23.1.2-0ubuntu0~20.04.2) 
...
Setting up cloud-init (23.2.1-0ubuntu0~20.04.2) ...
++ lxc exec sru-focal -- cloud-init --version
+ VERSION='/usr/bin/cloud-init 23.2.1-0ubuntu0~20.04.2'
+ '[' '/usr/bin/cloud-init ~20.04.2' '!=' '/usr/bin/cloud-init 
23.2.1-0ubuntu0~20.04.2' ']'
+ lxc file push openstack.json sru-focal/run/cloud-init/instance-data.json
+ echo --- 2. Generate -proposed apport report which sources openstack 
instance-data.json, selecting Openstack as cloud.
--- 2. Generate -proposed apport report which sources openstack 
instance-data.json, selecting Openstack as cloud.
+ lxc exec sru-focal -- apport-bug cloud-init

*** Collecting problem information

The collected information can be sent to the developers to improve the
application. This might take a few minutes.
...
*** Your device details (lshw) may be useful to developers 

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

SRU validation Focal, Jammy, Kinetic and Lunar successes.

** Attachment added: "sru-1724623.log"
   
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1724623/+attachment/5684389/+files/sru-1724623.log

** Tags removed: block-proposed-focal regression-proposed verification-needed 
verification-needed-focal verification-needed-jammy verification-needed-kinetic
** Tags added: verification-done verification-done-focal 
verification-done-jammy verification-done-kinetic

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

Title:
  Update ubuntu cloud info

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Focal:
  Fix Committed
Status in cloud-init source package in Jammy:
  Fix Committed
Status in cloud-init source package in Kinetic:
  Fix Committed
Status in apport source package in Lunar:
  New
Status in cloud-init source package in Lunar:
  Fix Committed

Bug description:
  [ Impact ]
  Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id

  [ Test Plan ]

  1. Launch LXD container for each series
  2. upgrade to cloud-init from -proposed.
  3. Execute apport-bug cloud-init and view report to assess that correct tags 
are present for LXD datasource.
  4. replace /run/cloud-init/instance-data.json cloud-id content with examples 
from openstack, ec2, configdrive and assert appropriate tags match the platform 
details.

  verification scriptlet (attached):

  #!/bin/bash
  set -ex

  cat > setup_proposed.sh  openstack.json  ec2.json << EOF
  {
    "ds": {
  "imageId": "ami-123",
  "instanceType": "m1.tiny",
  "region": "us-east-1"
    },
    "v1": {
  "cloud_name": "aws",
  "distro": "ubuntu",
  "distro_release": "jammy",
  "distro_version": "22.04",
  "instance_id": "i-06b5687b4d7b8595d",
  "machine": "x86_64",
  "platform": "ec2",
  "python_version": "3.10.4",
  "region": "us-east-2",
  "variant": "ubuntu"
    }
  }
  EOF

  for release in focal jammy kinetic lunar; do
   VM=sru-$release
   lxc launch ubuntu-daily:$release $VM
   while ! lxc exec $VM -- cloud-init status --wait --long; do
  sleep 5
   done
   echo --- 1. Generate current apport report, selecting Openstack as cloud.
   echo --- step through prompts and select 'K' to keep report
   echo --- VERSION OF APPORT ---
   lxc exec $VM -- apport-bug --version
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.orig
   lxc exec $VM rm /tmp/$APPORT_FILE

   lxc file push setup_proposed.sh $VM/
   lxc exec $VM -- bash /setup_proposed.sh | grep cloud-init

   lxc file push openstack.json $VM/run/cloud-init/instance-data.json
   echo --- 2. Generate -proposed apport report which sources openstack 
instance-data.json, selecting Openstack as cloud.
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.openstack-proposed
   lxc exec $VM rm /tmp/$APPORT_FILE

   echo --- 3. Generate -proposed apport report which sources ec2 
instance-data, selecting Ec2 as cloud.
   lxc file push ec2.json $VM/run/cloud-init/instance-data.json
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.ec2-proposed
   lxc exec $VM rm /tmp/$APPORT_FILE

   # redact logs lines for easy diffs
   for file in `ls apport*`; do
   sed -i '1,/logs.tgz/!d' $file
   done
   echo --- 4. Inspect diff tags of orig to openstack-proposed report
   diff -urN apport-$VM.orig apport-$VM.openstack-proposed || true
   echo --- 5. Inspect diff tags of openstack-proposed to ec2-proposed report
   diff -urN apport-$VM.openstack-proposed apport-$VM.ec2-proposed || true

  done

  [ Where problems could occur ]
  apport-bug could traceback on poor logic preventing simple bug filing at 
apport CLI. It could omit tags if unable to process 
cloud-init/instance-data.json. nothing critical to daily performance, uptime or 
security

  [ Other Info ]

  [Original description]

  Issues:
   - Using the presence of cloud-init to flag an image as a cloud image is 
incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images)
   - Using the presence of EC2 metadata source 

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

SRU validation Focal, Jammy, Kinetic and Lunar successes.

** Attachment added: "sru-1724623.log"
   
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1724623/+attachment/5684388/+files/sru-1724623.log

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

Title:
  Update ubuntu cloud info

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Focal:
  Fix Committed
Status in cloud-init source package in Jammy:
  Fix Committed
Status in cloud-init source package in Kinetic:
  Fix Committed
Status in apport source package in Lunar:
  New
Status in cloud-init source package in Lunar:
  Fix Committed

Bug description:
  [ Impact ]
  Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id

  [ Test Plan ]

  1. Launch LXD container for each series
  2. upgrade to cloud-init from -proposed.
  3. Execute apport-bug cloud-init and view report to assess that correct tags 
are present for LXD datasource.
  4. replace /run/cloud-init/instance-data.json cloud-id content with examples 
from openstack, ec2, configdrive and assert appropriate tags match the platform 
details.

  verification scriptlet (attached):

  #!/bin/bash
  set -ex

  cat > setup_proposed.sh  openstack.json  ec2.json << EOF
  {
    "ds": {
  "imageId": "ami-123",
  "instanceType": "m1.tiny",
  "region": "us-east-1"
    },
    "v1": {
  "cloud_name": "aws",
  "distro": "ubuntu",
  "distro_release": "jammy",
  "distro_version": "22.04",
  "instance_id": "i-06b5687b4d7b8595d",
  "machine": "x86_64",
  "platform": "ec2",
  "python_version": "3.10.4",
  "region": "us-east-2",
  "variant": "ubuntu"
    }
  }
  EOF

  for release in focal jammy kinetic lunar; do
   VM=sru-$release
   lxc launch ubuntu-daily:$release $VM
   while ! lxc exec $VM -- cloud-init status --wait --long; do
  sleep 5
   done
   echo --- 1. Generate current apport report, selecting Openstack as cloud.
   echo --- step through prompts and select 'K' to keep report
   echo --- VERSION OF APPORT ---
   lxc exec $VM -- apport-bug --version
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.orig
   lxc exec $VM rm /tmp/$APPORT_FILE

   lxc file push setup_proposed.sh $VM/
   lxc exec $VM -- bash /setup_proposed.sh | grep cloud-init

   lxc file push openstack.json $VM/run/cloud-init/instance-data.json
   echo --- 2. Generate -proposed apport report which sources openstack 
instance-data.json, selecting Openstack as cloud.
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.openstack-proposed
   lxc exec $VM rm /tmp/$APPORT_FILE

   echo --- 3. Generate -proposed apport report which sources ec2 
instance-data, selecting Ec2 as cloud.
   lxc file push ec2.json $VM/run/cloud-init/instance-data.json
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.ec2-proposed
   lxc exec $VM rm /tmp/$APPORT_FILE

   # redact logs lines for easy diffs
   for file in `ls apport*`; do
   sed -i '1,/logs.tgz/!d' $file
   done
   echo --- 4. Inspect diff tags of orig to openstack-proposed report
   diff -urN apport-$VM.orig apport-$VM.openstack-proposed || true
   echo --- 5. Inspect diff tags of openstack-proposed to ec2-proposed report
   diff -urN apport-$VM.openstack-proposed apport-$VM.ec2-proposed || true

  done

  [ Where problems could occur ]
  apport-bug could traceback on poor logic preventing simple bug filing at 
apport CLI. It could omit tags if unable to process 
cloud-init/instance-data.json. nothing critical to daily performance, uptime or 
security

  [ Other Info ]

  [Original description]

  Issues:
   - Using the presence of cloud-init to flag an image as a cloud image is 
incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images)
   - Using the presence of EC2 metadata source is incorrect as many non-EC2 
clouds provide EC2 metadata.  Thus we have bugs like bug #1722946 that are 
tagged as an 'ec2-images' bug which are clearly on openstack
   - Marking all bugs that have cloud-init but no EC2 metadata source as an 
'uec-images' bug uses a 

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

SRU validation Focal, Jammy, Kinetic and Lunar successes.

** Attachment added: "sru-1724623.log"
   
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1724623/+attachment/5684387/+files/sru-1724623.log

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

Title:
  Update ubuntu cloud info

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Focal:
  Fix Committed
Status in cloud-init source package in Jammy:
  Fix Committed
Status in cloud-init source package in Kinetic:
  Fix Committed
Status in apport source package in Lunar:
  New
Status in cloud-init source package in Lunar:
  Fix Committed

Bug description:
  [ Impact ]
  Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id

  [ Test Plan ]

  1. Launch LXD container for each series
  2. upgrade to cloud-init from -proposed.
  3. Execute apport-bug cloud-init and view report to assess that correct tags 
are present for LXD datasource.
  4. replace /run/cloud-init/instance-data.json cloud-id content with examples 
from openstack, ec2, configdrive and assert appropriate tags match the platform 
details.

  verification scriptlet (attached):

  #!/bin/bash
  set -ex

  cat > setup_proposed.sh  openstack.json  ec2.json << EOF
  {
    "ds": {
  "imageId": "ami-123",
  "instanceType": "m1.tiny",
  "region": "us-east-1"
    },
    "v1": {
  "cloud_name": "aws",
  "distro": "ubuntu",
  "distro_release": "jammy",
  "distro_version": "22.04",
  "instance_id": "i-06b5687b4d7b8595d",
  "machine": "x86_64",
  "platform": "ec2",
  "python_version": "3.10.4",
  "region": "us-east-2",
  "variant": "ubuntu"
    }
  }
  EOF

  for release in focal jammy kinetic lunar; do
   VM=sru-$release
   lxc launch ubuntu-daily:$release $VM
   while ! lxc exec $VM -- cloud-init status --wait --long; do
  sleep 5
   done
   echo --- 1. Generate current apport report, selecting Openstack as cloud.
   echo --- step through prompts and select 'K' to keep report
   echo --- VERSION OF APPORT ---
   lxc exec $VM -- apport-bug --version
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.orig
   lxc exec $VM rm /tmp/$APPORT_FILE

   lxc file push setup_proposed.sh $VM/
   lxc exec $VM -- bash /setup_proposed.sh | grep cloud-init

   lxc file push openstack.json $VM/run/cloud-init/instance-data.json
   echo --- 2. Generate -proposed apport report which sources openstack 
instance-data.json, selecting Openstack as cloud.
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.openstack-proposed
   lxc exec $VM rm /tmp/$APPORT_FILE

   echo --- 3. Generate -proposed apport report which sources ec2 
instance-data, selecting Ec2 as cloud.
   lxc file push ec2.json $VM/run/cloud-init/instance-data.json
   lxc exec $VM -- apport-bug cloud-init
   APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
   lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.ec2-proposed
   lxc exec $VM rm /tmp/$APPORT_FILE

   # redact logs lines for easy diffs
   for file in `ls apport*`; do
   sed -i '1,/logs.tgz/!d' $file
   done
   echo --- 4. Inspect diff tags of orig to openstack-proposed report
   diff -urN apport-$VM.orig apport-$VM.openstack-proposed || true
   echo --- 5. Inspect diff tags of openstack-proposed to ec2-proposed report
   diff -urN apport-$VM.openstack-proposed apport-$VM.ec2-proposed || true

  done

  [ Where problems could occur ]
  apport-bug could traceback on poor logic preventing simple bug filing at 
apport CLI. It could omit tags if unable to process 
cloud-init/instance-data.json. nothing critical to daily performance, uptime or 
security

  [ Other Info ]

  [Original description]

  Issues:
   - Using the presence of cloud-init to flag an image as a cloud image is 
incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images)
   - Using the presence of EC2 metadata source is incorrect as many non-EC2 
clouds provide EC2 metadata.  Thus we have bugs like bug #1722946 that are 
tagged as an 'ec2-images' bug which are clearly on openstack
   - Marking all bugs that have cloud-init but no EC2 metadata source as an 
'uec-images' bug uses a 

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

** Changed in: cloud-init (Ubuntu Lunar)
   Status: New => Fix Committed

** Description changed:

  [ Impact ]
  Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id
  
  [ Test Plan ]
  
  1. Launch LXD container for each series
  2. upgrade to cloud-init from -proposed.
  3. Execute apport-bug cloud-init and view report to assess that correct tags 
are present for LXD datasource.
  4. replace /run/cloud-init/instance-data.json cloud-id content with examples 
from openstack, ec2, configdrive and assert appropriate tags match the platform 
details.
  
  verification scriptlet (attached):
  
  #!/bin/bash
  set -ex
  
  cat > setup_proposed.sh  openstack.json  ec2.json << EOF
  {
-   "ds": {
- "imageId": "ami-123",
- "instanceType": "m1.tiny",
- "region": "us-east-1"
-   },
-   "v1": {
- "cloud_name": "aws",
- "distro": "ubuntu",
- "distro_release": "jammy",
- "distro_version": "22.04",
- "instance_id": "i-06b5687b4d7b8595d",
- "machine": "x86_64",
- "platform": "ec2",
- "python_version": "3.10.4",
- "region": "us-east-2",
- "variant": "ubuntu"
-   }
+   "ds": {
+ "imageId": "ami-123",
+ "instanceType": "m1.tiny",
+ "region": "us-east-1"
+   },
+   "v1": {
+ "cloud_name": "aws",
+ "distro": "ubuntu",
+ "distro_release": "jammy",
+ "distro_version": "22.04",
+ "instance_id": "i-06b5687b4d7b8595d",
+ "machine": "x86_64",
+ "platform": "ec2",
+ "python_version": "3.10.4",
+ "region": "us-east-2",
+ "variant": "ubuntu"
+   }
  }
  EOF
  
  for release in focal jammy kinetic lunar; do
-  VM=sru-$release
-  lxc launch ubuntu-daily:$release $VM
-  while ! lxc exec $VM -- cloud-init status --wait --long; do
- sleep 5
-  done
-  echo --- 1. Generate current apport report, selecting Openstack as cloud.
-  echo --- step through prompts and select 'K' to keep report
-  lxc exec $VM -- apport-bug cloud-init
-  APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
-  lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.orig
-  lxc exec $VM rm /tmp/$APPORT_FILE
+  VM=sru-$release
+  lxc launch ubuntu-daily:$release $VM
+  while ! lxc exec $VM -- cloud-init status --wait --long; do
+ sleep 5
+  done
+  echo --- 1. Generate current apport report, selecting Openstack as cloud.
+  echo --- step through prompts and select 'K' to keep report
+  echo --- VERSION OF APPORT ---
+  lxc exec $VM -- apport-bug --version
+  lxc exec $VM -- apport-bug cloud-init
+  APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
+  lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.orig
+  lxc exec $VM rm /tmp/$APPORT_FILE
  
-  lxc file push setup_proposed.sh $VM/
-  lxc exec $VM -- bash /setup_proposed.sh | grep cloud-init
+  lxc file push setup_proposed.sh $VM/
+  lxc exec $VM -- bash /setup_proposed.sh | grep cloud-init
  
-  lxc file push openstack.json $VM/run/cloud-init/instance-data.json
-  echo --- 2. Generate -proposed apport report which sources openstack 
instance-data.json, selecting Openstack as cloud.
-  lxc exec $VM -- apport-bug cloud-init
-  APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
-  lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.openstack-proposed
-  lxc exec $VM rm /tmp/$APPORT_FILE
+  lxc file push openstack.json $VM/run/cloud-init/instance-data.json
+  echo --- 2. Generate -proposed apport report which sources openstack 
instance-data.json, selecting Openstack as cloud.
+  lxc exec $VM -- apport-bug cloud-init
+  APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
+  lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.openstack-proposed
+  lxc exec $VM rm /tmp/$APPORT_FILE
  
-  echo --- 3. Generate -proposed apport report which sources ec2 
instance-data, selecting Ec2 as cloud.
-  lxc file push ec2.json $VM/run/cloud-init/instance-data.json
-  lxc exec $VM -- apport-bug cloud-init
-  APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
-  lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.ec2-proposed
-  lxc exec $VM rm /tmp/$APPORT_FILE
+  echo --- 3. Generate -proposed apport report which sources ec2 
instance-data, selecting Ec2 as cloud.
+  lxc file push ec2.json $VM/run/cloud-init/instance-data.json
+  lxc exec $VM -- apport-bug cloud-init
+  APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
+  lxc file pull 

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

SUCCESSFUL verification on Jammy, Kinetic and Lunar.  No tracebacks, all
expected CloudArchitecture, CloudName, CloudPlatform and CloudRegion are
present when expected for openstack or ec2/aws. No missing apport report
keys from orig to -proposed.

Long logs of test run below Jammy/Kinetic/Lunar:
$ bash ./sru-2025376-verification.sh 
+ cat
+ cat
+ cat
+ for release in jammy kinetic lunar
+ VM=sru-jammy
+ lxc launch ubuntu-daily:jammy sru-jammy
Creating sru-jammy
Starting sru-jammy
+ lxc exec sru-jammy -- cloud-init status --wait --long

status: done
boot_status_code: enabled-by-generator
last_update: Thu, 29 Jun 2023 19:44:00 +
detail:
DataSourceLXD
+ echo --- 1. Generate current apport report, selecting Openstack as cloud.
--- 1. Generate current apport report, selecting Openstack as cloud.
+ echo --- step through prompts and select K to keep report
--- step through prompts and select K to keep report
+ lxc exec sru-jammy -- apport-bug cloud-init

*** Collecting problem information

The collected information can be sent to the developers to improve the
application. This might take a few minutes.
..
*** Your device details (lshw) may be useful to developers when addressing this 
bug, but gathering it requires admin privileges. Would you like to include this 
info?


What would you like to do? Your options are:
  Y: Yes
  N: No
  C: Cancel
Please choose (Y/N/C): n
.
*** Is this machine running in a cloud environment?


What would you like to do? Your options are:
  Y: Yes
  N: No
  C: Cancel
Please choose (Y/N/C): y

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


Choices:
  1: AliYun
  2: AltCloud
  3: Amazon - Ec2
  4: Azure
  5: Bigstep
  6: Brightbox
  7: CloudSigma
  8: CloudStack
  9: DigitalOcean
  10: E24Cloud
  11: GCE - Google Compute Engine
  12: Huawei Cloud
  13: Exoscale
  14: Hetzner Cloud
  15: NWCS
  16: IBM - (aka SoftLayer or BlueMix)
  17: LXD
  18: MAAS
  19: NoCloud
  20: OpenNebula
  21: OpenStack
  22: Oracle
  23: OVF
  24: RbxCloud - (HyperOne, Rootbox, Rubikon)
  25: OpenTelekomCloud
  26: SAP Converged Cloud
  27: Scaleway
  28: SmartOS
  29: UpCloud
  30: VMware
  31: Vultr
  32: ZStack
  33: Outscale
  34: Other
  C: Cancel
Please choose 
(1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/C):
 21


*** Your user-data, cloud-config or autoinstall files can optionally  be 
provided from /var/lib/cloud/instance/user-data.txt and could be useful to 
developers when addressing this bug. Do you wish to attach user-data to this 
bug?


What would you like to do? Your options are:
  Y: Yes
  N: No
  C: Cancel
Please choose (Y/N/C): y
...

*** Send problem report to the developers?

After the problem report has been sent, please fill out the form in the
automatically opened web browser.

What would you like to do? Your options are:
  S: Send report (66.5 KB)
  V: View report
  K: Keep report file for sending later or copying to somewhere else
  I: Cancel and ignore future crashes of this program version
  C: Cancel
Please choose (S/V/K/I/C): k
Problem report file: /tmp/apport.cloud-init.5fl06mv5.apport
++ lxc exec sru-jammy ls /tmp
++ grep apport
+ APPORT_FILE=apport.cloud-init.5fl06mv5.apport
+ lxc file pull sru-jammy/tmp/apport.cloud-init.5fl06mv5.apport 
apport-sru-jammy.orig
+ lxc exec sru-jammy rm /tmp/apport.cloud-init.5fl06mv5.apport
+ lxc file push setup_proposed.sh sru-jammy/
+ lxc exec sru-jammy -- bash /setup_proposed.sh
+ grep cloud-init
  cloud-init
Get:1 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 cloud-init all 
23.2-0ubuntu0~22.04.1 [533 kB]
dpkg-preconfigure: unable to re-open stdin: No such file or directory
Preparing to unpack .../cloud-init_23.2-0ubuntu0~22.04.1_all.deb ...
Unpacking cloud-init (23.2-0ubuntu0~22.04.1) over (23.1.2-0ubuntu0~22.04.1) ...
Setting up cloud-init (23.2-0ubuntu0~22.04.1) ...
+ lxc file push openstack.json sru-jammy/run/cloud-init/instance-data.json
+ echo --- 2. Generate -proposed apport report which sources openstack 
instance-data.json, selecting Openstack as cloud.
--- 2. Generate -proposed apport report which sources openstack 
instance-data.json, selecting Openstack as cloud.
+ lxc exec sru-jammy -- apport-bug cloud-init

*** Collecting problem information

The collected information can be sent to the developers to improve the
application. This might take a few minutes.

*** Your device details (lshw) may be useful to developers when addressing this 
bug, but gathering it requires admin privileges. Would you like to include this 
info?


What would you like to do? Your options are:
  Y: Yes
  N: No
  C: Cancel
Please choose (Y/N/C): n

*** Your user-data, cloud-config or autoinstall files can optionally  be
provided from /var/lib/cloud/instance/user-data.txt and could be useful
to developers when addressing this bug. Do you wish to attach user-data
to this bug?


What would you like to do? Your 

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

SRU Verification script

** Description changed:

  [ Impact ]
  Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id
  
  [ Test Plan ]
  
  1. Launch LXD container for each series
  2. upgrade to cloud-init from -proposed.
  3. Execute apport-bug cloud-init and view report to assess that correct tags 
are present for LXD datasource.
  4. replace /run/cloud-init/instance-data.json cloud-id content with examples 
from openstack, ec2, configdrive and assert appropriate tags match the platform 
details.
- 5. Assert no stray uec-images or invalid ec2-images tags on openstack.
  
- scriptlet TBD:
+ verification scriptlet (attached):
+ 
+ #!/bin/bash
+ set -ex
+ 
+ cat > setup_proposed.sh  openstack.json  ec2.json << EOF
  {
-   "v1": {
- "cloud_name": "aws",
- "distro": "ubuntu",
- "distro_release": "jammy",
- "distro_version": "22.04",
- "instance_id": "i-06b5687b4d7b8595d",
- "machine": "x86_64",
- "platform": "ec2",
- "python_version": "3.10.4",
- "region": "us-east-2",
- "variant": "ubuntu"
-   }
+   "ds": {
+ "imageId": "ami-123",
+ "instanceType": "m1.tiny",
+ "region": "us-east-1"
+   },
+   "v1": {
+ "cloud_name": "aws",
+ "distro": "ubuntu",
+ "distro_release": "jammy",
+ "distro_version": "22.04",
+ "instance_id": "i-06b5687b4d7b8595d",
+ "machine": "x86_64",
+ "platform": "ec2",
+ "python_version": "3.10.4",
+ "region": "us-east-2",
+ "variant": "ubuntu"
+   }
  }
  EOF
  
  for release in focal jammy kinetic lunar; do
-  lxc launch ubuntu-daily:$release sru-$release
-  lxc exec sru-f -- cloud-init status --wait --long
-  lxc exec sru-f -- apport-bug cloud-init
-  # step through prompts and select view/save report
-  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
- CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion, 
CloudSubPlatform
+  VM=sru-$release
+  lxc launch ubuntu-daily:$release $VM
+  while ! lxc exec $VM -- cloud-init status --wait --long; do
+ sleep 5
+  done
+  echo --- 1. Generate current apport report, selecting Openstack as cloud.
+  echo --- step through prompts and select 'K' to keep report
+  lxc exec $VM -- apport-bug cloud-init
+  APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
+  lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.orig
+  lxc exec $VM rm /tmp/$APPORT_FILE
  
-  echo ### validate openstack apport-bug
-  lxc file push openstack.json dev-$release/run/cloud-init/instance-data.json
-  lxc exec sru-f -- apport-bug cloud-init
-  # step through prompts and select view/save report
-  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
- CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion,
+  lxc file push setup_proposed.sh $VM/
+  lxc exec $VM -- bash /setup_proposed.sh | grep cloud-init
  
-  echo ### validate ec2 apport-bug
-  lxc file push ec2.json dev-$release/run/cloud-init/instance-data.json
-  lxc exec sru-f -- apport-bug cloud-init
-  # step through prompts and select view/save report
-  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
- CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion,
+  lxc file push openstack.json $VM/run/cloud-init/instance-data.json
+  echo --- 2. Generate -proposed apport report which sources openstack 
instance-data.json, selecting Openstack as cloud.
+  lxc exec $VM -- apport-bug cloud-init
+  APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
+  lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.openstack-proposed
+  lxc exec $VM rm /tmp/$APPORT_FILE
+ 
+  echo --- 3. Generate -proposed apport report which sources ec2 
instance-data, selecting Ec2 as cloud.
+  lxc file push ec2.json $VM/run/cloud-init/instance-data.json
+  lxc exec $VM -- apport-bug cloud-init
+  APPORT_FILE=$(lxc exec $VM ls /tmp | grep apport)
+  lxc file pull $VM/tmp/$APPORT_FILE apport-$VM.ec2-proposed
+  lxc exec $VM rm /tmp/$APPORT_FILE
+ 
+  # redact logs lines for easy diffs
+  for file in `ls apport*`; do
+  sed -i '1,/logs.tgz/!d' $file
+  done
+  echo --- 4. Inspect diff tags of orig to openstack-proposed report
+  diff -urN apport-$VM.orig apport-$VM.openstack-proposed || 

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

Filed a bug tracking focal-proposed regression 
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2025376

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

Title:
  Update ubuntu cloud info

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Focal:
  Fix Committed
Status in cloud-init source package in Jammy:
  Fix Committed
Status in cloud-init source package in Kinetic:
  Fix Committed

Bug description:
  [ Impact ]
  Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id

  [ Test Plan ]

  1. Launch LXD container for each series
  2. upgrade to cloud-init from -proposed.
  3. Execute apport-bug cloud-init and view report to assess that correct tags 
are present for LXD datasource.
  4. replace /run/cloud-init/instance-data.json cloud-id content with examples 
from openstack, ec2, configdrive and assert appropriate tags match the platform 
details.
  5. Assert no stray uec-images or invalid ec2-images tags on openstack.

  scriptlet TBD:

  cat > openstack.json  ec2.json << EOF
  {
    "v1": {
  "cloud_name": "aws",
  "distro": "ubuntu",
  "distro_release": "jammy",
  "distro_version": "22.04",
  "instance_id": "i-06b5687b4d7b8595d",
  "machine": "x86_64",
  "platform": "ec2",
  "python_version": "3.10.4",
  "region": "us-east-2",
  "variant": "ubuntu"
    }
  }
  EOF

  for release in focal jammy kinetic lunar; do
   lxc launch ubuntu-daily:$release sru-$release
   lxc exec sru-f -- cloud-init status --wait --long
   lxc exec sru-f -- apport-bug cloud-init
   # step through prompts and select view/save report
   # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
  CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion, 
CloudSubPlatform

   echo ### validate openstack apport-bug
   lxc file push openstack.json dev-$release/run/cloud-init/instance-data.json
   lxc exec sru-f -- apport-bug cloud-init
   # step through prompts and select view/save report
   # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
  CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion,

   echo ### validate ec2 apport-bug
   lxc file push ec2.json dev-$release/run/cloud-init/instance-data.json
   lxc exec sru-f -- apport-bug cloud-init
   # step through prompts and select view/save report
   # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
  CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion,

  done

  [ Where problems could occur ]
  apport-bug could traceback on poor logic preventing simple bug filing at CLI. 
It could omit tags if unable to process cloud-init/instance-data.json. nothing 
critical to daily performance, uptime or security

  [ Other Info ]

  [Original description]

  Issues:
   - Using the presence of cloud-init to flag an image as a cloud image is 
incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images)
   - Using the presence of EC2 metadata source is incorrect as many non-EC2 
clouds provide EC2 metadata.  Thus we have bugs like bug #1722946 that are 
tagged as an 'ec2-images' bug which are clearly on openstack
   - Marking all bugs that have cloud-init but no EC2 metadata source as an 
'uec-images' bug uses a name that no longer has meaning.

  Solution:
   - If cloud-init is present, check for /etc/cloud/build.info to indicate an 
Ubuntu cloud images, tag as 'cloud-images'.  Pull the build_name and serial 
from that file into the bug comments.
   - If cloud-init is present, check for the presence of 
/run/cloud-init/cloud.cfg.  Parse this yaml to determine the datasource type.  
Add the datasource used to the bug comment.

  I have filed bug #1724626 to ask cloud-init development to surface
  more information from ds-identify to help ID the cloud so that we can
  better tag/annotate the bug.  There may also be some info we can get
  to indicate the image ID on more clouds than just AWS.  At a minimum I
  would like to see dsidentify make the EC2 platform it found available
  for consumers in cloud.cfg.  This would allow us to identify AWS EC2
  from look-alike datasources so that we can tag a bug as ec2-images for
  bug really on AWS and add EC2 specific fields to the
  description/attachments.

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


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

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

Regression discovered for focal-proposed due to type annotations not
being parsed on python 3.8. this resulted in tracebacks from python when
importing cloud-init's apport/general-hooks module:


..ERROR: hook /usr/share/apport/general-hooks/cloud-init.py crashed:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport/report.py", line 226, in _run_hook
exec(compile(fd.read(), hook, 'exec'), symb)
  File "/usr/share/apport/general-hooks/cloud-init.py", line 7, in 
def _get_azure_data(ds_data) -> dict[str, str]:
TypeError: 'type' object is not subscriptable


** Tags removed: verification-needed-focal
** Tags added: block-proposed-focal regression-proposed 
verification-failed-focal

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

Title:
  Update ubuntu cloud info

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Focal:
  Fix Committed
Status in cloud-init source package in Jammy:
  Fix Committed
Status in cloud-init source package in Kinetic:
  Fix Committed

Bug description:
  [ Impact ]
  Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id

  [ Test Plan ]

  1. Launch LXD container for each series
  2. upgrade to cloud-init from -proposed.
  3. Execute apport-bug cloud-init and view report to assess that correct tags 
are present for LXD datasource.
  4. replace /run/cloud-init/instance-data.json cloud-id content with examples 
from openstack, ec2, configdrive and assert appropriate tags match the platform 
details.
  5. Assert no stray uec-images or invalid ec2-images tags on openstack.

  scriptlet TBD:

  cat > openstack.json  ec2.json << EOF
  {
    "v1": {
  "cloud_name": "aws",
  "distro": "ubuntu",
  "distro_release": "jammy",
  "distro_version": "22.04",
  "instance_id": "i-06b5687b4d7b8595d",
  "machine": "x86_64",
  "platform": "ec2",
  "python_version": "3.10.4",
  "region": "us-east-2",
  "variant": "ubuntu"
    }
  }
  EOF

  for release in focal jammy kinetic lunar; do
   lxc launch ubuntu-daily:$release sru-$release
   lxc exec sru-f -- cloud-init status --wait --long
   lxc exec sru-f -- apport-bug cloud-init
   # step through prompts and select view/save report
   # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
  CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion, 
CloudSubPlatform

   echo ### validate openstack apport-bug
   lxc file push openstack.json dev-$release/run/cloud-init/instance-data.json
   lxc exec sru-f -- apport-bug cloud-init
   # step through prompts and select view/save report
   # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
  CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion,

   echo ### validate ec2 apport-bug
   lxc file push ec2.json dev-$release/run/cloud-init/instance-data.json
   lxc exec sru-f -- apport-bug cloud-init
   # step through prompts and select view/save report
   # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
  CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion,

  done

  [ Where problems could occur ]
  apport-bug could traceback on poor logic preventing simple bug filing at CLI. 
It could omit tags if unable to process cloud-init/instance-data.json. nothing 
critical to daily performance, uptime or security

  [ Other Info ]

  [Original description]

  Issues:
   - Using the presence of cloud-init to flag an image as a cloud image is 
incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images)
   - Using the presence of EC2 metadata source is incorrect as many non-EC2 
clouds provide EC2 metadata.  Thus we have bugs like bug #1722946 that are 
tagged as an 'ec2-images' bug which are clearly on openstack
   - Marking all bugs that have cloud-init but no EC2 metadata source as an 
'uec-images' bug uses a name that no longer has meaning.

  Solution:
   - If cloud-init is present, check for /etc/cloud/build.info to indicate an 
Ubuntu cloud images, tag as 'cloud-images'.  Pull the build_name and serial 
from that file into the bug comments.
   - If cloud-init is present, check for the presence of 
/run/cloud-init/cloud.cfg.  Parse this yaml to determine the datasource type.  
Add the datasource used to the bug comment.

  I have filed bug #1724626 to ask cloud-init development to surface
  more information from ds-identify to help ID the cloud so that we can
  

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

** Description changed:

- [ Impact ] 
- Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id 
+ [ Impact ]
+ Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id
  
  [ Test Plan ]
  
  1. Launch LXD container for each series
  2. upgrade to cloud-init from -proposed.
  3. Execute apport-bug cloud-init and view report to assess that correct tags 
are present for LXD datasource.
  4. replace /run/cloud-init/instance-data.json cloud-id content with examples 
from openstack, ec2, configdrive and assert appropriate tags match the platform 
details.
  5. Assert no stray uec-images or invalid ec2-images tags on openstack.
  
- 
  scriptlet TBD:
- 
  
  cat > openstack.json  ec2.son << EOF
+ cat > ec2.json << EOF
  {
-   "v1": {
- "cloud_name": "aws",
- "distro": "ubuntu",
- "distro_release": "jammy",
- "distro_version": "22.04",
- "instance_id": "i-06b5687b4d7b8595d",
- "machine": "x86_64",
- "platform": "ec2",
- "python_version": "3.10.4",
- "region": "us-east-2",
- "variant": "ubuntu"
-   }
+   "v1": {
+ "cloud_name": "aws",
+ "distro": "ubuntu",
+ "distro_release": "jammy",
+ "distro_version": "22.04",
+ "instance_id": "i-06b5687b4d7b8595d",
+ "machine": "x86_64",
+ "platform": "ec2",
+ "python_version": "3.10.4",
+ "region": "us-east-2",
+ "variant": "ubuntu"
+   }
  }
  EOF
  
+ for release in focal jammy kinetic lunar; do
+  lxc launch ubuntu-daily:$release sru-$release
+  lxc exec sru-f -- cloud-init status --wait --long
+  lxc exec sru-f -- apport-bug cloud-init
+  # step through prompts and select view/save report
+  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
+ CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion, 
CloudSubPlatform
  
- for release in focal jammy kinetic lunar; do
-  lxc launch ubuntu-daily:$release sru-$release
-  lxc exec sru-f -- cloud-init status --wait --long
-  lxc exec sru-f -- apport-bug cloud-init
-  # step through prompts and select view/save report
-  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
- CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion, 
CloudSubPlatform
+  echo ### validate openstack apport-bug
+  lxc file push openstack.json dev-$release/run/cloud-init/instance-data.json
+  lxc exec sru-f -- apport-bug cloud-init
+  # step through prompts and select view/save report
+  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
+ CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion,
  
-  echo ### validate openstack apport-bug
-  lxc file push openstack.json dev-$release/run/cloud-init/instance-data,json
-  lxc exec sru-f -- apport-bug cloud-init
-  # step through prompts and select view/save report
-  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
- CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion, 
+  echo ### validate ec2 apport-bug
+  lxc file push ec2.json dev-$release/run/cloud-init/instance-data.json
+  lxc exec sru-f -- apport-bug cloud-init
+  # step through prompts and select view/save report
+  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
+ CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion,
  
-  echo ### validate ec2 apport-bug
-  lxc file push ec2.json dev-$release/run/cloud-init/instance-data,json
-  lxc exec sru-f -- apport-bug cloud-init
-  # step through prompts and select view/save report
-  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
- CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion, 
- 
- 
- done 
- 
+ done
  
  [ Where problems could occur ]
  apport-bug could traceback on poor logic preventing simple bug filing at CLI. 
It could omit tags if unable to process cloud-init/instance-data.json. nothing 
critical to daily performance, uptime or security
  
  [ Other Info ]
-  
- 
  
  [Original description]
  
  Issues:
   - Using the presence of cloud-init to flag an image as a cloud image is 
incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images)
   - Using the presence 

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Chad Smith]

** Description changed:

- add_cloud_info() in data/general-hooks/ubuntu.py needs an overhaul.
+ [ Impact ] 
+ Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id 
+ 
+ [ Test Plan ]
+ 
+ 1. Launch LXD container for each series
+ 2. upgrade to cloud-init from -proposed.
+ 3. Execute apport-bug cloud-init and view report to assess that correct tags 
are present for LXD datasource.
+ 4. replace /run/cloud-init/instance-data.json cloud-id content with examples 
from openstack, ec2, configdrive and assert appropriate tags match the platform 
details.
+ 5. Assert no stray uec-images or invalid ec2-images tags on openstack.
+ 
+ 
+ scriptlet TBD:
+ 
+ 
+ cat > openstack.json  ec2.son << EOF
+ {
+   "v1": {
+ "cloud_name": "aws",
+ "distro": "ubuntu",
+ "distro_release": "jammy",
+ "distro_version": "22.04",
+ "instance_id": "i-06b5687b4d7b8595d",
+ "machine": "x86_64",
+ "platform": "ec2",
+ "python_version": "3.10.4",
+ "region": "us-east-2",
+ "variant": "ubuntu"
+   }
+ }
+ EOF
+ 
+ 
+ for release in focal jammy kinetic lunar; do
+  lxc launch ubuntu-daily:$release sru-$release
+  lxc exec sru-f -- cloud-init status --wait --long
+  lxc exec sru-f -- apport-bug cloud-init
+  # step through prompts and select view/save report
+  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
+ CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion, 
CloudSubPlatform
+ 
+  echo ### validate openstack apport-bug
+  lxc file push openstack.json dev-$release/run/cloud-init/instance-data,json
+  lxc exec sru-f -- apport-bug cloud-init
+  # step through prompts and select view/save report
+  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
+ CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion, 
+ 
+  echo ### validate ec2 apport-bug
+  lxc file push ec2.json dev-$release/run/cloud-init/instance-data,json
+  lxc exec sru-f -- apport-bug cloud-init
+  # step through prompts and select view/save report
+  # inspect tags to assert cloud platform is proper tags where value is 
non-empty/null
+ CloudID, CloudName, CloudArchitecture CloudPlatform, CloudRegion, 
+ 
+ 
+ done 
+ 
+ 
+ [ Where problems could occur ]
+ apport-bug could traceback on poor logic preventing simple bug filing at CLI. 
It could omit tags if unable to process cloud-init/instance-data.json. nothing 
critical to daily performance, uptime or security
+ 
+ [ Other Info ]
+  
+ 
+ 
+ [Original description]
  
  Issues:
   - Using the presence of cloud-init to flag an image as a cloud image is 
incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images)
   - Using the presence of EC2 metadata source is incorrect as many non-EC2 
clouds provide EC2 metadata.  Thus we have bugs like bug #1722946 that are 
tagged as an 'ec2-images' bug which are clearly on openstack
   - Marking all bugs that have cloud-init but no EC2 metadata source as an 
'uec-images' bug uses a name that no longer has meaning.
  
  Solution:
   - If cloud-init is present, check for /etc/cloud/build.info to indicate an 
Ubuntu cloud images, tag as 'cloud-images'.  Pull the build_name and serial 
from that file into the bug comments.
   - If cloud-init is present, check for the presence of 
/run/cloud-init/cloud.cfg.  Parse this yaml to determine the datasource type.  
Add the datasource used to the bug comment.
  
  I have filed bug #1724626 to ask cloud-init development to surface more
  information from ds-identify to help ID the cloud so that we can better
  tag/annotate the bug.  There may also be some info we can get to
  indicate the image ID on more clouds than just AWS.  At a minimum I
  would like to see dsidentify make the EC2 platform it found available
  for consumers in cloud.cfg.  This would allow us to identify AWS EC2
  from look-alike datasources so that we can tag a bug as ec2-images for
  bug really on AWS and add EC2 specific fields to the
  description/attachments.

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

Title:
  Update ubuntu cloud info

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  [ Impact ] 
  Apport reported bug add invalid bug tags such as `uec-images` which no longer 
has meaning or `ec2-images` on openstack. Since cloud-init is installed in all 
these images and detects the correct datasource, leverage cloud-init's 
instance-data.json or cloud-id 

  [ Test Plan ]

  1. Launch LXD container 

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

Closing the cloud-init task here as invalid because we have livecd-
rootfs overlay config files allow for cloud-init.service to get ordered
After=NetworkManager.service which solves the immediate DNS issues in
early boot. Long-term cloud-init will need to spec out options to prefer
ordering after NetworkManager versus systemd-networkd at systemd
generator timeframe because ordering After=NetworkManager is
incompatible with cloud-init's default Before=sysinit.target.

We'll take that long-term work as a separate bug for cloud-init
https://bugs.launchpad.net/cloud-init/+bug/2015949 to discern how best
to position upstream cloud-init.service files to cope with service
ordering conflicts to prefer NetworkManager.service over systemd-
networkd.


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

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  Fix Released
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

I can confirm success manually launching images via kvm in virt-manager
that live desktop image builds as of 20230403 images in
`/cdrom/.disk/info` have the proper systemd service ordering which
places cloud-init.service `After=NetworkManager.service NetworkManager-
wait-online.service`. Which allows cloud-init to resolve DNS on Ubuntu
ISOs where NetworkManager is the primary network backend.


We also found a secondary bug not related to the specific NetworkManager DNS 
issue, once cloud-init renders initial network config to detect the datasource, 
it writes direct network configuration to 
/etc/NetworkManager/systemc-connections. If networking changes are provided in 
autoinstall.network, ubuntu-desktop-installer(via subiquity) writes that 
network config to /etc/netplan/00-installer.yaml and invokes 'netplan apply'. 
This results in collisions in NetworkManager configuration as netplan isn't 
aware of cloud-init's direct config of in 
/etc/NetworkManager/system-connections/cloud-init-.nmconnection.

https://bugs.launchpad.net/cloud-init/+bug/2015605

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  In Progress
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

I can now confirm successful autoinstall runs with FQDN in kernel
commandline in Desktop live installer ISOs dated 20230403. This allows
cloud-init.service to be ordered `After=NetworkManager.service
NetworkManager-wait-online.service` which ensures devices and resolved
are both 'up' and active by the time cloud-init tries to download remote
user-data/meta-data from a seedurl.


$ cat /var/log/installer/media-info   # also found in /cdrom/.disk/info in 
ephemeral environment
Ubuntu 23.04 "Lunar Lobster" - Daily amd64 (20230403)


$ # installer version of the snap
2023-04-03 15:42:37,497 INFO subiquity:163 Starting Subiquity server revision 
907 of snap /snap/ubuntu-desktop-installer/907


Presence of the correct systemd service ordering for cloud-init.service in 
Desktop live installer builds dated 20230403 placing cloud-init.service 
`After=NetworkManager.service NetworkManager-wait-online.service` guarantee 
that network is up before cloud-init datasource discovery runs which also 
implies systemd-resolved has started and has adequate connectivity to source 
FQDNs on any NetworkManager discovered NICs.

ubuntu@ubuntu:~$ systemctl show -p After,Before cloud-init.service --no-pager
Before=sshd-keygen.service cloud-config.target network-online.target 
sshd.service shutdown.target systemd-user-sessions.service
After=cloud-init-local.service NetworkManager.service system.slice 
networking.service systemd-journald.socket systemd-networkd-wait-online.service 
NetworkManager-wait-online.service

This allows cloud-init to download remote user-data from an FQDN
provided to the live desktop installer via the kernel parameter:
`ds=nocloud-net;s=http://YOUR-DOMAIN/'

So, FQDN lookup seems to be resolved by the systemd service ordering
after NetworkManager is up and functional.


There may be a secondary issue to file related to environments with nameservers 
being specifically provided for pxe-based installs after cloud-init properly 
downloads remote user-data from a remote FQDN but ordering of systemd network 
configuration seems to alleviate the DNS resolution aspect pointed to in this 
bug.

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  In Progress
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

jsonschema 2.6.0 is now dropped from latest ubuntu-desktop-snap version
0+get.98600e08 in stable channel as of a couple hours ago per this
issue/fix[1]. This resolves issues with curtin Tracebacks on
jsonschema.validate(). Additionally cloud-init has a PR in progress[2]
to avoid registering a strict draft4 schema with
additionalProperties=False. The cloud-init fix is now unnecessary given
the changes already published in ubuntu-desktop-installer to drop
jsonschema 2.6.0 from the snap.


[1] drop duplicate python dependencies from site-packages
https://github.com/canonical/ubuntu-desktop-installer/issues/1714

[2] https://github.com/canonical/cloud-init/pull/2098


** Bug watch added: github.com/canonical/ubuntu-desktop-installer/issues #1714
   https://github.com/canonical/ubuntu-desktop-installer/issues/1714

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  In Progress
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in livecd-rootfs package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2002445] Re: udev NIC renaming race with mlx5_core driver

[Chad Smith]

Kinetic success for proposed launches, rename race seen and properly handled 
without delaying boot time due to systemd-networkd-wait-online.target.

 *** 251.4-1ubuntu7.3 500   
500 http://archive.ubuntu.com/ubuntu kinetic-proposed/main amd64 
Packages
100 /var/lib/dpkg/status   
...
- Test run complete: 100 attempted -
Successes without rename race: 81   
Successes with rename race and preserved altname: 19
Failures due to network delay: 0
Failures due to no altnames persisted: 81   
===

** Attachment added: "sru-systemd-kinetic.log"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2002445/+attachment/5657411/+files/sru-systemd-kinetic.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/2002445

Title:
  udev NIC renaming race with mlx5_core driver

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Committed
Status in systemd source package in Lunar:
  Fix Released

Bug description:
  [Impact]
  On systems with mellanox NICs, udev's NIC renaming races with the mlx5_core 
driver's own configuration of subordinate interfaces. When the kernel wins this 
race, the device cannot be renamed as udev has attempted, and this causes 
systemd-network-online.target to timeout waiting for links to be configured. 
This ultimately results in boot being delayed by about 2 minutes.

  [Test Plan]
  Repeated launches of Standard_D8ds_v5 instance types will generally hit this 
race around 1 in 10 runs. Create a vm snapshot with updated systemd from 
ppa:enr0n/systemd-245. Launch 100 Standard_D8ds_v5 instances with updated 
systemd. Assert not failure in cloud-init status and no 2 minute delay in 
network-online.target.

  To check for failure symptom:
    - Assert that network-online.target isn't the longest pole from 
systemd-analyze blame.

  To assert success condition during net rename busy race:
    - assert when "eth1" is still the primary device name, that two altnames 
are listed (preserving the altname due to the primary NIC rename being hit).

  Sample script uses pycloudlib to create modified base image for test
  and launches 100 VMs of type Standard_D8ds_v5, counting both successes
  and any failures seen.

  #!/usr/bin/env python3
  # This file is part of pycloudlib. See LICENSE file for license information.
  """Basic examples of various lifecycle with an Azure instance."""

  import json
  import logging
  import os
  import sys
  from enum import Enum

  import pycloudlib

  LOG = logging.getLogger()

  base_cfg = """#cloud-config
  ssh-import-id: [chad.smith, enr0n, falcojr, holmanb, aciba]
  """

  #source: "deb [allow-insecure=yes] 
https://ppa.launchpadcontent.net/enr0n/systemd-245/ubuntu focal main"
  # - apt install systemd udev -y --allow-unauthenticated

  apt_cfg = """
  # Add developer PPA
  apt:
   sources:
 systemd-testing:
   source: {source}
  # upgrade systemd after cloud-init is nearly done
  runcmd:
   - apt install systemd udev -y --allow-unauthenticated
  """

  debug_systemd_cfg = """
  # Create systemd-udev debug override.conf in base image
  write_files:
  - path: /etc/systemd/system/systemd-networkd.service.d/override.conf
owner: root:root
defer: {defer}
content: |
  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug
  
  - path: /etc/systemd/system/systemd-udevd.service.d/override.conf
owner: root:root
defer: {defer}
content: |
  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug
  LogRateLimitIntervalSec=0
  """

  cloud_config = base_cfg + apt_cfg + debug_systemd_cfg
  cloud_config2 = base_cfg + debug_systemd_cfg

  
  class BootCondition(Enum):
  SUCCESS_WITHOUT_RENAME_RACE = "network bringup success without rename 
race"
  SUCCESS_WITH_RENAME_RACE = "network bringup success rename race condition"
  ERROR_NETWORK_TIMEOUT = "error: timeout on systemd-networkd-wait-online"

  
  def batch_launch_vm(
  client, instance_type, image_id, user_data, instance_count=5
  ):
  instances = []
  while len(instances) < instance_count:
  instances.append(
  client.launch(
  image_id=image_id,
  instance_type=instance_type,
  user_data=user_data,
  )
  )
  return instances

  
  def get_boot_condition(test_idx, instance):
  blame = instance.execute("systemd-analyze blame").splitlines()
  try:
  LOG.info(

[Touch-packages] [Bug 2002445] Re: udev NIC renaming race with mlx5_core driver

[Chad Smith]

Jammy success for proposed launches, rename race  seen and properly
handled without delaying boot time due to systemd-networkd-wait-
online.target.


 *** 249.11-0ubuntu3.9 500  
500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages 
100 /var/lib/dpkg/status


- Test run complete: 100 attempted -
Successes without rename race: 93   
Successes with rename race and preserved altname: 7 
Failures due to network delay: 0
Failures due to no altnames persisted: 93   
===  


** Attachment added: "sru-systemd-jammy.log"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2002445/+attachment/5657410/+files/sru-systemd-jammy.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/2002445

Title:
  udev NIC renaming race with mlx5_core driver

Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Committed
Status in systemd source package in Lunar:
  Fix Committed

Bug description:
  [Impact]
  On systems with mellanox NICs, udev's NIC renaming races with the mlx5_core 
driver's own configuration of subordinate interfaces. When the kernel wins this 
race, the device cannot be renamed as udev has attempted, and this causes 
systemd-network-online.target to timeout waiting for links to be configured. 
This ultimately results in boot being delayed by about 2 minutes.

  [Test Plan]
  Repeated launches of Standard_D8ds_v5 instance types will generally hit this 
race around 1 in 10 runs. Create a vm snapshot with updated systemd from 
ppa:enr0n/systemd-245. Launch 100 Standard_D8ds_v5 instances with updated 
systemd. Assert not failure in cloud-init status and no 2 minute delay in 
network-online.target.

  To check for failure symptom:
    - Assert that network-online.target isn't the longest pole from 
systemd-analyze blame.

  To assert success condition during net rename busy race:
    - assert when "eth1" is still the primary device name, that two altnames 
are listed (preserving the altname due to the primary NIC rename being hit).

  Sample script uses pycloudlib to create modified base image for test
  and launches 100 VMs of type Standard_D8ds_v5, counting both successes
  and any failures seen.

  #!/usr/bin/env python3
  # This file is part of pycloudlib. See LICENSE file for license information.
  """Basic examples of various lifecycle with an Azure instance."""

  import json
  import logging
  import os
  import sys
  from enum import Enum

  import pycloudlib

  LOG = logging.getLogger()

  base_cfg = """#cloud-config
  ssh-import-id: [chad.smith, enr0n, falcojr, holmanb, aciba]
  """

  #source: "deb [allow-insecure=yes] 
https://ppa.launchpadcontent.net/enr0n/systemd-245/ubuntu focal main"
  # - apt install systemd udev -y --allow-unauthenticated

  apt_cfg = """
  # Add developer PPA
  apt:
   sources:
 systemd-testing:
   source: {source}
  # upgrade systemd after cloud-init is nearly done
  runcmd:
   - apt install systemd udev -y --allow-unauthenticated
  """

  debug_systemd_cfg = """
  # Create systemd-udev debug override.conf in base image
  write_files:
  - path: /etc/systemd/system/systemd-networkd.service.d/override.conf
owner: root:root
defer: {defer}
content: |
  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug
  
  - path: /etc/systemd/system/systemd-udevd.service.d/override.conf
owner: root:root
defer: {defer}
content: |
  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug
  LogRateLimitIntervalSec=0
  """

  cloud_config = base_cfg + apt_cfg + debug_systemd_cfg
  cloud_config2 = base_cfg + debug_systemd_cfg

  
  class BootCondition(Enum):
  SUCCESS_WITHOUT_RENAME_RACE = "network bringup success without rename 
race"
  SUCCESS_WITH_RENAME_RACE = "network bringup success rename race condition"
  ERROR_NETWORK_TIMEOUT = "error: timeout on systemd-networkd-wait-online"

  
  def batch_launch_vm(
  client, instance_type, image_id, user_data, instance_count=5
  ):
  instances = []
  while len(instances) < instance_count:
  instances.append(
  client.launch(
  image_id=image_id,
  instance_type=instance_type,
  user_data=user_data,
  )
  )
  return instances

  
  def get_boot_condition(test_idx, instance):
  blame = instance.execute("systemd-analyze blame").splitlines()
  try:
  LOG.info(
  

[Touch-packages] [Bug 2002445] Re: udev NIC renaming race with mlx5_core driver

[Chad Smith]

Test script referenced in the bug description
https://paste.ubuntu.com/p/Xkc7bSZ8fB/


** Description changed:

  [Impact]
  On systems with mellanox NICs, udev's NIC renaming races with the mlx5_core 
driver's own configuration of subordinate interfaces. When the kernel wins this 
race, the device cannot be renamed as udev has attempted, and this causes 
systemd-network-online.target to timeout waiting for links to be configured. 
This ultimately results in boot being delayed by about 2 minutes.
  
  [Test Plan]
  Repeated launches of Standard_D8ds_v5 instance types will generally hit this 
race around 1 in 10 runs. Create a vm snapshot with updated systemd from 
ppa:enr0n/systemd-245. Launch 100 Standard_D8ds_v5 instances with updated 
systemd. Assert not failure in cloud-init status and no 2 minute delay in 
network-online.target.
  
  To check for failure symptom:
    - Assert that network-online.target isn't the longest pole from 
systemd-analyze blame.
  
  To assert success condition during net rename busy race:
-   - assert when "eth1" is still the primary device name, that two altnames 
are listed (preserving the altname due to the primary NIC rename being hit.
+   - assert when "eth1" is still the primary device name, that two altnames 
are listed (preserving the altname due to the primary NIC rename being hit).
  
  Sample script uses pycloudlib to create modified base image for test and
  launches 100 VMs of type Standard_D8ds_v5, counting both successes and
  any failures seen.
  
  #!/usr/bin/env python3
  # This file is part of pycloudlib. See LICENSE file for license information.
  """Basic examples of various lifecycle with an Azure instance."""
  
+ import json
  import logging
- import json
+ import os
+ import sys
+ from enum import Enum
  
  import pycloudlib
+ 
  LOG = logging.getLogger()
  
  base_cfg = """#cloud-config
- ssh-import-id: [chad.smith, enr0n]
+ ssh-import-id: [chad.smith, enr0n, falcojr, holmanb, aciba]
  """
+ 
+ #source: "deb [allow-insecure=yes] 
https://ppa.launchpadcontent.net/enr0n/systemd-245/ubuntu focal main"
+ # - apt install systemd udev -y --allow-unauthenticated
  
  apt_cfg = """
  # Add developer PPA
  apt:
-  sources:
-    systemd-testing:
-  source: "deb [allow-insecure=yes] 
https://ppa.launchpadcontent.net/enr0n/systemd-245/ubuntu focal main"
+  sources:
+systemd-testing:
+  source: {source}
  # upgrade systemd after cloud-init is nearly done
  runcmd:
-  - apt install systemd udev -y --allow-unauthenticated
+  - apt install systemd udev -y --allow-unauthenticated
  """
  
  debug_systemd_cfg = """
  # Create systemd-udev debug override.conf in base image
  write_files:
  - path: /etc/systemd/system/systemd-networkd.service.d/override.conf
-   owner: root:root
-   defer: {defer}
-   content: |
- [Service]
- Environment=SYSTEMD_LOG_LEVEL=debug
- 
+   owner: root:root
+   defer: {defer}
+   content: |
+ [Service]
+ Environment=SYSTEMD_LOG_LEVEL=debug
+ 
  - path: /etc/systemd/system/systemd-udevd.service.d/override.conf
-   owner: root:root
-   defer: {defer}
-   content: |
- [Service]
- Environment=SYSTEMD_LOG_LEVEL=debug
- LogRateLimitIntervalSec=0
+   owner: root:root
+   defer: {defer}
+   content: |
+ [Service]
+ Environment=SYSTEMD_LOG_LEVEL=debug
+ LogRateLimitIntervalSec=0
  """
  
  cloud_config = base_cfg + apt_cfg + debug_systemd_cfg
  cloud_config2 = base_cfg + debug_systemd_cfg
  
- def debug_systemd_image_launch_overlake_v5_with_snapshot():
- """Test overlake v5 timeouts
- 
- test procedure:
- - Launch base focal image
- - enable ppa:enr0n/systemd-245 and systemd/udev debugging
- - cloud-init clean --logs && deconfigure waalinux agent before shutdown
- - snapshot a base image
- - launch v5 system from snapshot
- - check systemd-analyze for expected timeout
- """
- client = pycloudlib.Azure(tag="azure")
- 
- image_id = client.daily_image(release="focal")
- pub_path = "/home/ubuntu/.ssh/id_rsa.pub"
- priv_path = "/home/ubuntu/.ssh/id_rsa"
- 
- client.use_key(pub_path, priv_path)
- 
- base_instance = client.launch(
- image_id=image_id,
- instance_type="Standard_DS1_v2",
- user_data=cloud_config.format(defer="true"),
- )
- 
- LOG.info(f"base instance: ssh ubuntu@{base_instance.ip}")
- base_instance.wait()
- LOG.info(base_instance.execute("apt cache policy systemd"))
- snapshotted_image_id = client.snapshot(base_instance)
- 
- reproducer = False
- tries = 0
- success_count_with_race = 0
- success_count_no_race = 0
- failure_count_network_delay = 0
- failure_count_no_altnames = 0
- TEST_SUMMARY_TMPL = """
- - Test run complete: {tries} attempted -
- Successes without rename race: {success_count_no_race}
- Successes with rename race and preserved altname: 
{success_count_with_race}
- Failures due to network delay: 

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

** Changed in: cloud-init
   Status: Triaged => In Progress

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  In Progress
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

PR up for discussion on this ordering change in livecd
https://code.launchpad.net/~chad.smith/livecd-rootfs/+git/livecd-
rootfs/+merge/439586

** 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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2008952

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  Triaged
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

Short-term proposal update:
   Looks like we can't get away with suppplemental systemd drop-ins in 
/etc/systemd/system/cloud-init.service.d by themselves in livecd-roots because 
we need to remove the "Before=sysinit.target" from the default shipped 
cloud-init.service config. Systemd drop-ins are used only to augment or add 
configuration, we need to replace the entire [Unit] definition in 
/lib/systemd/system/cloud-init.service in order to remove the 
Before=sysinit.target because it will still conflict with 
NetworkManager.service ordering on After=dbus.service

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  Triaged
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

Short-term solution here will likely be for livecd-rootfs to augment
cloud-init.service which drops `Before=sysinit.target` and adds an
`After=NetworkManager-wait-online.service`. This is quite a bit like
what redhat and derivatives have done for a while. Redhat and
derivitatives have an `After=NetworkManager.service` for cloud-
init.service config and no `Before=sysinit.target`. Suse injects an
`After=dbus.service` which also puts it at the same boot timeframe as
NetworkManager-based environments.[1]


It does mean that cloud-init datasource gets detected a couple seconds later in 
boot, meaning that any service depending on 
`/run/cloud-init/instance-data.json` will also get delayed a couple of seconds, 
but doesn't delay overall boot process.


Long-term solution may be to see if we can improve NetworkManager dependency on 
dbus.service so that it could support late-bind interaction once dbus.socket 
comes online.


References:
[1] upstream suse/redhat cloud-init.service configuration NetworkManager/dbus 
ordering 
https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init.service.tmpl#L19-L27

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  Triaged
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

While retries on DNS resolution failures does not work for cloud-
init.service for environments running NetworkManager.service (desktop
live ISOs), I have found that the retries work where systemd-networkd is
bringing up network config (server live ISOs). This is because cloud-
init.service is After=systemd-network-wait-online.service which provides
systemd-resolved with viable network interfaces which are up and
providing access to functional DNS configuration.

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  Triaged
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

This issue with NetworkManager.service and systemd is reminiscent of the
related feature request against systemd-networkd
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636912 that also
points out the ordering issues.

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  Triaged
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

TLDR: My earlier suggestion to retry in cloud-init.service while
awaiting DNS is not viable when thinking about NetworkManager.
NetworkManager.service is After=sysinit.target due to After=dbus.service
and cloud-init.service is Before=sysinit.target. NetworkManager is the
only service bringing up the primary NIC in desktop images which gives
cloud-init access to a functional DNS. Unless we can move
NetworkManager.service before sysinit.target, I don't think we don't
think we can leverage DNS.


In review of a KVM live desktop boot in which cloud-init.service defines 
After=systemd-resolved.service We can see that cloud-init.service still blocks 
start of NetworkManager (due to After=sysinit.target) and DNS is not active 
until enp1s0 is actually brought up by NetworkManager.


Here are snippets of the journalctl logs on a local KVM boot where we can see 
systemd-resolved coming up, then cloud-init.service with 30 retries and finally 
NetworkManager.service starting after cloud-init.service failed to download the 
metadata due to DNS resolution errors:

1. systemd-resolved "starts" @22:14:42.302181, which unblocks cloud-init.service
2. cloud-init.service @22:14:42.690949 (which emits that enp1s0's link is not 
actually up yet so no viable DNS at that time)
3. NetworkManager.service starting @22:15:16.012686up only after 
cloud-init.service finishes 30 seconds of retries @22:15:16.012686
4. systemd-resolved finally getting a viable DNS route through enp1s0 
@22:15:19.630090 ubuntu systemd-resolved[1136]: enp1s0: Bus client set DNS 
server list to: 192.168.122.1
5. Network manager finally sees enp1s0 device activated @22:15:19.632846
6. NetworkManager-wait-online.service finally gets to CONNECTED status 
@22:15:19.637543


--- journalctl -b 0 -o short-precise | egrep 
'enp1s0|resolved|NetworkManager|ci-info'
Mar 14 22:14:39.167190 ubuntu kernel: virtio_net virtio0 enp1s0: renamed from 
eth0
Mar 14 22:14:41.451373 ubuntu systemd[1]: Starting systemd-resolved.service - 
Network Name Resolution...
Mar 14 22:14:42.253268 ubuntu systemd-resolved[1136]: Positive Trust Anchors:
Mar 14 22:14:42.253583 ubuntu systemd-resolved[1136]: . IN DS 20326 8 2 
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Mar 14 22:14:42.253685 ubuntu systemd-resolved[1136]: Negative trust anchors: 
home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 
18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 
22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 
26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 
30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp 
home internal intranet lan local private test
Mar 14 22:14:42.300435 ubuntu systemd-resolved[1136]: Using system hostname 
'ubuntu'.
Mar 14 22:14:42.302181 ubuntu systemd[1]: Started systemd-resolved.service - 
Network Name Resolution.
### cloud-init noticing enp1s0 has no link
Mar 14 22:14:42.690949 ubuntu cloud-init[1341]: ci-info: | enp1s0 | False | 
. | . |   .   | 52:54:00:5b:ba:d5 |
Mar 14 22:15:16.012686 ubuntu systemd[1]: Starting NetworkManager.service - 
Network Manager...
Mar 14 22:15:16.285604 ubuntu NetworkManager[1546]:   [1678832116.2854] 
NetworkManager (version 1.40.12) is starting... 
(boot:1f3e11ab-fea1-4f3e-a6ef-fb9d48b0c4d6)
Mar 14 22:15:16.285972 ubuntu NetworkManager[1546]:   [1678832116.2859] 
Read config: /etc/NetworkManager/NetworkManager.conf (lib: 
10-dns-resolved.conf, 20-connectivity-ubuntu.conf, no-mac-addr-change.conf) 
(run: 10-globally-managed-devices.conf) (etc: default-wifi-powersave-on.conf)
Mar 14 22:15:16.302542 ubuntu systemd[1]: Started NetworkManager.service - 
Network Manager.
Mar 14 22:15:16.303605 ubuntu NetworkManager[1546]:   [1678832116.3035] 
bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
Mar 14 22:15:16.316514 ubuntu systemd[1]: Starting 
NetworkManager-wait-online.service - Network Manager Wait Online...
Mar 14 22:15:16.354249 ubuntu NetworkManager[1546]:   [1678832116.3542] 
manager[0x5629cd53f000]: monitoring kernel firmware directory '/lib/firmware'.
Mar 14 22:15:16.354423 ubuntu NetworkManager[1546]:   [1678832116.3544] 
monitoring ifupdown state file '/run/network/ifstate'.
Mar 14 22:15:16.356985 ubuntu dbus-daemon[1490]: [system] Activating via 
systemd: service name='org.freedesktop.hostname1' 
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.14' (uid=0 
pid=1546 comm="/usr/sbin/NetworkManager --no-daemon" label="unconfined")
Mar 14 22:15:16.527848 ubuntu NetworkManager[1546]:   [1678832116.5278] 
hostname: hostname: using hostnamed
Mar 14 22:15:16.527869 ubuntu NetworkManager[1546]:   [1678832116.5278] 
hostname: static hostname changed from (none) to "ubuntu"
Mar 14 22:15:16.528346 ubuntu NetworkManager[1546]:   [1678832116.5283] 
dns-mgr: init: dns=systemd-resolved rc-manager=unmanaged (auto), 
plugin=systemd-resolved
Mar 14 

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

I can confirm Dan's validation that After=systemd-resolved.service doesn't buy 
us anything here because, although systemd-resolved.service is up, 
NetworkManager.service && NetworkManager-wait-online.service don't finish 
bringing link up for related network devices until After=dbus.service 
timeframe. So blocking on systemd-resolved.service tells us only that the 
service is running, not that it provides useful DNS lookups.


Since dbus.service is After=sysinit.target and sysinit.target is 
After=cloud-init.service we have an ordering cycle for NetworkManager that 
doesn't exist for systemd-networkd controlled environments.  Any attempts to 
include After=NetworkManager-wait-online.service in cloud-init.service 
definition result in ordering cycles. Even if we try to add 
DefaultDependecies=no to both NetworkManager.service and 
NetworkManager-wait-online.service to prevent them from pulling in 
`After=sysinit.target` for ordering.


NetworkManager images (desktop) differ from cloud-init's systemd-networkd 
managed images (server) because systemd-networkd-wait-online.service doesn't 
have a strict After=dbus.service config systemd-networkd can poll for dbus 
availability and use it once it's available. But, it doesn't seem 
NetworkManager has that facility though I haven't dug deeply into NM yet.

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  Triaged
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

I'm also going back to the tabular network state printed out by in
cloud-init.service shows: that the primary network interface is still
down at this point in boot, which it shouldn't be. cloud-init should be
waiting on the presence of link up before starting it's cloud-
init.service (network boot stage). I'm working on the hypothesis that we
are missing an `After=NetworkManager-wait-online.service` which wasn't
present in cloud-init because it didn't have to cope with non systemd-
networkd managed devices in ubuntu-server installs.

ci-info: | enp0s31f6 | False | . | . | . | 6c:24:08:9e:54:e6 |


Running a couple of tests in a manifactured Desktop Live iso installer now to 
confirm

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  Triaged
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data

[Chad Smith]

Thank you all for your attention on this bug.


Sorry my earlier comment on this bug was ill-informed and incorrect. I'm able 
to reproduce this as well through the server installer qemu/kvm based installs 
as well so I can confirm as well that this isn't/wasn't NetworkManager and 
systemd-networkd related.

Also, I am concerned with cloud-init.service being ordered specifically
after sytemd-resolved.service on all deployments as we will be affecting
all boots and delaying them on the systemd-resolved setup of DNS when
only specific use-cases such NoCloudNet with an FQDN as kernel cmdline
directive may need that service to be active.

Some other datasources like GCP do rely on DNS resolution of the
instance metadata service (GCP), but cloud-images inject a config into
/etc/hosts to resolve that locally in absence of active DNS in early
boot. Ec2 does also define instance-data:8773 as a potential fallback
IMDS definition, but both IPv4 and IPv6 endpoints are defined earlier in
the search order, so we never get back to that DNS lookup in all
practical deployments.


We may be able to avoid the cost of a strict `After=systemd-resolved.service` 
clause in cloud-init.service if we can add the following logic to nocloud by 
adding sensible retries in the NoCloud datasource.

 1. Check if seed URLs `netloc` is an ip address. If IP, no retries on
failure.

 2a. When seed URL is non-IP, retry on specific 'network resolution
error' URLError raised and retry X times for that failure mode

 - or -

 2b . When seed URL is non-IP, invoke socket.getaddrinfo to validate DNS
resolution prior to attempting to download metadata, if not resolvable,
retry only as long as systemd.resolved.services isn't yet active.


These retry approaches should allow us to avoid impacting typical boots on most 
systems, yet still support DNS-based needs for datasource detection in early 
boot if FQDN is used for IMDS.

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

Title:
  DNS failure while trying to fetch user-data

Status in cloud-init:
  Triaged
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In testing netboot + autoinstall of the new ubuntu desktop subiquity
  based installer for 23.04 I found cloud-init is failing to retrieve
  user-data because it can't resolved the hostname in the URL.  This
  same configuration does work for 22.04 based subiquity, so seems a
  regression.

  From the ipxe config:

  imgargs vmlinuz initrd=initrd \
   ip=dhcp \
   iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso 
\
   fsck.mode=skip \
   layerfs-path=minimal.standard.live.squashfs \
   autoinstall \
   'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \

  That fails, but if we replace boot.linuxgroove.com with the IP it
  works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2002445] Re: udev NIC renaming race with mlx5_core driver

[Chad Smith]

** Description changed:

  [Impact]
  On systems with mellanox NICs, udev's NIC renaming races with the mlx5_core 
driver's own configuration of subordinate interfaces. When the kernel wins this 
race, the device cannot be renamed as udev has attempted, and this causes 
systemd-network-online.target to timeout waiting for links to be configured. 
This ultimately results in boot being delayed by about 2 minutes.
  
  [Test Plan]
  Repeated launches of Standard_D8ds_v5 instance types will generally hit this 
race around 1 in 10 runs. Create a vm snapshot with updated systemd from 
ppa:enr0n/systemd-245. Launch 100 Standard_D8ds_v5 instances with updated 
systemd. Assert not failure in cloud-init status and no 2 minute delay in 
network-online.target.
  
  To check for failure symptom:
    - Assert that network-online.target isn't the longest pole from 
systemd-analyze blame.
  
  To assert success condition during net rename busy race:
    - assert when "eth1" is still the primary device name, that two altnames 
are listed (preserving the altname due to the primary NIC rename being hit.
  
  Sample script uses pycloudlib to create modified base image for test and
  launches 100 VMs of type Standard_D8ds_v5, counting both successes and
  any failures seen.
  
+ 
  #!/usr/bin/env python3
- 
+ # This file is part of pycloudlib. See LICENSE file for license information.
  """Basic examples of various lifecycle with an Azure instance."""
  
  import logging
  import json
  
  import pycloudlib
  LOG = logging.getLogger()
  
  base_cfg = """#cloud-config
  ssh-import-id: [chad.smith, enr0n]
  """
  
  apt_cfg = """
  # Add developer PPA
  apt:
-  sources:
-    systemd-testing:
-  source: "deb [allow-insecure=yes] 
https://ppa.launchpadcontent.net/enr0n/systemd-245/ubuntu focal main"
+  sources:
+systemd-testing:
+  source: "deb [allow-insecure=yes] 
https://ppa.launchpadcontent.net/enr0n/systemd-245/ubuntu focal main"
  # upgrade systemd after cloud-init is nearly done
  runcmd:
-  - apt install systemd udev -y --allow-unauthenticated
+  - apt install systemd udev -y --allow-unauthenticated
  """
  
  debug_systemd_cfg = """
  # Create systemd-udev debug override.conf in base image
  write_files:
  - path: /etc/systemd/system/systemd-networkd.service.d/override.conf
-   owner: root:root
-   defer: {defer}
-   content: |
- [Service]
- Environment=SYSTEMD_LOG_LEVEL=debug
- 
+   owner: root:root
+   defer: {defer}
+   content: |
+ [Service]
+ Environment=SYSTEMD_LOG_LEVEL=debug
+ 
  - path: /etc/systemd/system/systemd-udevd.service.d/override.conf
-   owner: root:root
-   defer: {defer}
-   content: |
- [Service]
- Environment=SYSTEMD_LOG_LEVEL=debug
- LogRateLimitIntervalSec=0
+   owner: root:root
+   defer: {defer}
+   content: |
+ [Service]
+ Environment=SYSTEMD_LOG_LEVEL=debug
+ LogRateLimitIntervalSec=0
  """
  
  cloud_config = base_cfg + apt_cfg + debug_systemd_cfg
  cloud_config2 = base_cfg + debug_systemd_cfg
  
+ 
  def debug_systemd_image_launch_overlake_v5_with_snapshot():
- """Test overlake v5 timeouts
+ """Test overlake v5 timeouts
+ 
+ test procedure:
+ - Launch base focal image
+ - enable ppa:enr0n/systemd-245 and systemd/udev debugging
+ - cloud-init clean --logs && deconfigure waalinux agent before shutdown
+ - snapshot a base image
+ - launch v5 system from snapshot
+ - check systemd-analyze for expected timeout
+ """
+ client = pycloudlib.Azure(tag="azure")
  
- test procedure:
- - Launch base focal image
- - enable ppa:enr0n/systemd-245 and systemd/udev debugging
- - cloud-init clean --logs && deconfigure waalinux agent before shutdown
- - snapshot a base image
- - launch v5 system from snapshot
- - check systemd-analyze for expected timeout
- """
- client = pycloudlib.Azure(tag="azure")
+ image_id = client.daily_image(release="focal")
+ pub_path = "/home/ubuntu/.ssh/id_rsa.pub"
+ priv_path = "/home/ubuntu/.ssh/id_rsa"
  
- image_id = client.daily_image(release="focal")
- pub_path = "/home/ubuntu/.ssh/id_rsa.pub"
- priv_path = "/home/ubuntu/.ssh/id_rsa"
+ client.use_key(pub_path, priv_path)
  
- client.use_key(pub_path, priv_path)
+ base_instance = client.launch(
+ image_id=image_id,
+ instance_type="Standard_DS1_v2",
+ user_data=cloud_config.format(defer="true"),
+ )
  
- base_instance = client.launch(
- image_id=image_id,
- instance_type="Standard_DS1_v2",
- user_data=cloud_config.format(defer="true"),
- )
+ LOG.info(f"base instance: ssh ubuntu@{base_instance.ip}")
+ base_instance.wait()
+ LOG.info(base_instance.execute("apt cache policy systemd"))
+ snapshotted_image_id = client.snapshot(base_instance)
  
- LOG.info(f"base instance: ssh ubuntu@{base_instance.ip}")
- base_instance.wait()
- LOG.info(base_instance.execute("apt cache 

[Touch-packages] [Bug 2002445] Re: udev NIC renaming race with mlx5_core driver

[Chad Smith]

** Description changed:

  [Impact]
  On systems with mellanox NICs, udev's NIC renaming races with the mlx5_core 
driver's own configuration of subordinate interfaces. When the kernel wins this 
race, the device cannot be renamed as udev has attempted, and this causes 
systemd-network-online.target to timeout waiting for links to be configured. 
This ultimately results in boot being delayed by about 2 minutes.
  
  [Test Plan]
- Since this is a race condition, we need to boot many instances before we see 
the issue. The Ubuntu Server team will help coordinate the testing at scale to 
confirm the fix.
+ Repeated launches of Standard_D8ds_v5 instance types will generally hit this 
race around 1 in 10 runs. Create a vm snapshot with updated systemd from 
ppa:enr0n/systemd-245. Launch 100 Standard_D8ds_v5 instances with updated 
systemd. Assert not failure in cloud-init status and no 2 minute delay in 
network-online.target.
+ 
+ 
+ To check for failure symptom:
+   - Assert that network-online.target isn't the longest pole from 
systemd-analyze blame. 
+ 
+ To assert success condition during net rename busy race:
+   - assert when "eth1" is still the primary device name, that two altnames 
are listed (preserving the altname due to the primary NIC rename being hit.
+ 
+ 
+ Sample script uses pycloudlib to create modified base image for test and
+ launches 100 VMs of type Standard_D8ds_v5, counting both successes and
+ any failures seen.
+ 
+ #!/usr/bin/env python3
+ 
+ 
+ """Basic examples of various lifecycle with an Azure instance."""
+ 
+ import logging
+ import json
+ 
+ import pycloudlib
+ LOG = logging.getLogger()
+ 
+ base_cfg = """#cloud-config
+ ssh-import-id: [chad.smith, enr0n]
+ """
+ 
+ apt_cfg = """
+ # Add developer PPA
+ apt:
+  sources:
+systemd-testing:
+  source: "deb [allow-insecure=yes] 
https://ppa.launchpadcontent.net/enr0n/systemd-245/ubuntu focal main"
+ # upgrade systemd after cloud-init is nearly done
+ runcmd:
+  - apt install systemd udev -y --allow-unauthenticated
+ """
+ 
+ debug_systemd_cfg = """
+ # Create systemd-udev debug override.conf in base image
+ write_files:
+ - path: /etc/systemd/system/systemd-networkd.service.d/override.conf
+   owner: root:root
+   defer: {defer}
+   content: |
+ [Service]
+ Environment=SYSTEMD_LOG_LEVEL=debug
+ 
+ - path: /etc/systemd/system/systemd-udevd.service.d/override.conf
+   owner: root:root
+   defer: {defer}
+   content: |
+ [Service]
+ Environment=SYSTEMD_LOG_LEVEL=debug
+ LogRateLimitIntervalSec=0
+ """
+ 
+ cloud_config = base_cfg + apt_cfg + debug_systemd_cfg
+ cloud_config2 = base_cfg + debug_systemd_cfg
+ 
+ 
+ def debug_systemd_image_launch_overlake_v5_with_snapshot():
+ """Test overlake v5 timeouts
+ 
+ test procedure:
+ - Launch base focal image
+ - enable ppa:enr0n/systemd-245 and systemd/udev debugging
+ - cloud-init clean --logs && deconfigure waalinux agent before shutdown
+ - snapshot a base image
+ - launch v5 system from snapshot
+ - check systemd-analyze for expected timeout
+ """
+ client = pycloudlib.Azure(tag="azure")
+ 
+ image_id = client.daily_image(release="focal")
+ pub_path = "/home/ubuntu/.ssh/id_rsa.pub"
+ priv_path = "/home/ubuntu/.ssh/id_rsa"
+ 
+ client.use_key(pub_path, priv_path)
+ 
+ base_instance = client.launch(
+ image_id=image_id,
+ instance_type="Standard_DS1_v2",
+ user_data=cloud_config.format(defer="true"),
+ )
+ 
+ LOG.info(f"base instance: ssh ubuntu@{base_instance.ip}")
+ base_instance.wait()
+ LOG.info(base_instance.execute("apt cache policy systemd"))
+ snapshotted_image_id = client.snapshot(base_instance)
+ 
+ reproducer = False
+ tries = 0
+ success_count_with_race = 0
+ success_count_no_race = 0
+ failure_count_network_delay = 0
+ failure_count_no_altnames = 0
+ TEST_SUMMARY_TMPL = """
+ - Test run complete: {tries} attempted -
+ Successes without rename race: {success_count_no_race}
+ Successes with rename race and preserved altname: 
{success_count_with_race_persist_altname}
+ Failures due to network delay: {failure_count_network_delay}
+ Failures due to no altnames persisted: {failure_count_no_altnames}
+ ===
+ """
+ while tries < 10 and not reproducer:
+ tries += 1
+ new_instance = client.launch(
+ image_id=snapshotted_image_id,
+ instance_type="Standard_D8ds_v5",
+ user_data=cloud_config.format(defer="false"),
+ )
+ # breadcrumb for us pycloudlib/Azure  will reuse available IPs
+ new_instance.wait()
+ blame = new_instance.execute("systemd-analyze blame").splitlines()
+ LOG.info(f"--- Attempt {tries} ssh ubuntu@{new_instance.ip} Blame: 
{blame[0]}")
+ ip_addr = json.loads(new_instance.execute("ip -j addr").stdout)
+ for d in ip_addr:
+   

[Touch-packages] [Bug 1997124] Re: Netplan/Systemd/Cloud-init/Dbus Race

[Chad Smith]

The dbus race that is happening here is due to `networkctl reconfigure`[1] 
being run by netplan apply, failing to talk to dbus, and restarting 
systemd_networkd[2] at that point in time when systemd_network may actually be 
coming up and is in an indeterminate state.
 

[1] https://github.com/canonical/netplan/blob/main/netplan/cli/utils.py#L116
[2] 
https://github.com/canonical/netplan/blob/main/netplan/cli/commands/apply.py#L277

I'm guessing the restart here from netplan apply is what's triggering
the occasional failure case where not all network config is applied
(like IP addresses) in systemd-networkd. It doesn't happen all the time
but it's racy as systemd-networkd is mid startup and we're restarting it
again via netplan apply.

After discussion with waldi (Bastian Blank) in Debian land about the systemd 
dependency chain, it seems my suggestion about about adding dbus.socket to 
cloud-init.service will actually introduce an ordering cycle because 
dbus.socket is 
  After=sysinit.target, yet cloud-init.service is Before=sysinit.target.


So, trying to shoehorn cloud-init into the dependency chain After=dbus.socket 
is impossible for systemd to schedule.


Maybe, we'd want one of the following instead:
 1. `netplan apply` provide an option to avoid falling back to `networkctl 
reconfigure` and exit non-zero so cloud-init can do something better, or retry 
where necessary
 2.  `netplan apply` can defer or block/retry until dbus.socket/service is 
ready allowing this only to affect cases where netplan apply is called 
 3. cloud-init to defer calling netplan apply on systemd-networkd environments 
until later boot stage (cloud-config.service) which comes after sysinit.target 
(and therefore can expect dbus.socket to be started at that point in boot.


I'll add netplan here to see if there are thoughts or counter suggestions here.

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

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

Title:
  Netplan/Systemd/Cloud-init/Dbus Race

Status in cloud-init:
  In Progress
Status in netplan:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Cloud-init is seeing intermittent failures while running `netplan
  apply`, which appears to be caused by a missing resource at the time
  of call.

  The symptom in cloud-init logs looks like:

  Running ['netplan', 'apply'] resulted in stderr output: Failed to
  connect system bus: No such file or directory

  I think that this error[1] is likely caused by cloud-init running
  netplan apply too early in boot process (before dbus is active).

  Today I stumbled upon this error which was hit in MAAS[2]. We have
  also hit it intermittently during tests (we didn't have a reproducer).

  Realizing that this may not be a cloud-init error, but possibly a
  dependency bug between dbus/systemd we decided to file this bug for
  broader visibility to other projects.

  I will follow up this initial report with some comments from our
  discussion earlier.

  [1] https://github.com/canonical/netplan/blob/main/src/dbus.c#L801
  [2] 
https://discourse.maas.io/t/latest-ubuntu-20-04-image-causing-netplan-error/5970

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1997124/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1959054] Re: debhelper restarts services marked --no-restart-on-upgrade

[Chad Smith]

Note related bug if a package were to use debhelper-compat 10 vs 9 on
focal.

In Focal, debhelper-compat 10 will incorrectly introduce ignore the
params

dh_systemd_start --no-restart-on-upgrade --no-start


And will still inject which will restart all services across package upgrade 
with something like the following pseudo script:
  
deb-systemd-invoke try-restart 

Moral of the story, don't shift your debian/compat version on stable
releases or bad things could happen.

See: LP: #1999159

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

Title:
  debhelper restarts services marked --no-restart-on-upgrade

Status in debconf package in Ubuntu:
  Fix Released
Status in debhelper package in Ubuntu:
  Fix Released
Status in docker.io package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Fix Released
Status in debconf source package in Jammy:
  Fix Released
Status in debhelper source package in Jammy:
  Fix Released
Status in docker.io source package in Jammy:
  Fix Released
Status in libvirt source package in Jammy:
  Fix Released
Status in debconf package in Debian:
  Fix Released
Status in debhelper package in Debian:
  Fix Released

Bug description:
  Debian bug #994204 (https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=994204) describes a flaw in debhelper that
  results in the postinst being generated in such a fashion that
  services marked --no-stop-on-upgrade (or its deprecated alias --no-
  restart-on-upgrade), restart anyway.

  Please note: this is nothing to do with the --no-restart-after-upgrade
  flag (which is, somewhat confusingly IMO, unrelated).

  I've confirmed that the flaw appears to be present in the jammy
  version of debhelper (though not impish) and that packages generated
  with it appear to contain the flawed postinst (I first encountered
  this whilst working on the open-iscsi merge), though I haven't yet
  managed to test that the flaw exhibits itself on upgrade (though I'd
  say from the presence of the flaw in the postinst, that it's a
  reasonable inference that it will).

  In dbus (the merge of which I'm currently working on), Debian has
  worked around this but given I've now run into two affected packages
  (open-iscsi and dbus), only one of which has a work-around, I'd much
  rather we got debhelper fixed up and rebuilt affected packages?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1959054/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1997124] Re: Netplan/Systemd/Cloud-init/Dbus Race

[Chad Smith]

Confirmed that we need dbus.socket in cloud-init.service as the
dependency chain doesn't explicitly define that ordering dependency.
We'll need this for netplan apply to work without a race

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

Title:
  Netplan/Systemd/Cloud-init/Dbus Race

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

Bug description:
  Cloud-init is seeing intermittent failures while running `netplan
  apply`, which appears to be caused by a missing resource at the time
  of call.

  The symptom in cloud-init logs looks like:

  Running ['netplan', 'apply'] resulted in stderr output: Failed to
  connect system bus: No such file or directory

  I think that this error[1] is likely caused by cloud-init running
  netplan apply too early in boot process (before dbus is active).

  Today I stumbled upon this error which was hit in MAAS[2]. We have
  also hit it intermittently during tests (we didn't have a reproducer).

  Realizing that this may not be a cloud-init error, but possibly a
  dependency bug between dbus/systemd we decided to file this bug for
  broader visibility to other projects.

  I will follow up this initial report with some comments from our
  discussion earlier.

  [1] https://github.com/canonical/netplan/blob/main/src/dbus.c#L801
  [2] 
https://discourse.maas.io/t/latest-ubuntu-20-04-image-causing-netplan-error/5970

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1997124/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1953525] [NEW] debian control should express a package dependency on ubuntu-advantage-tools

[Chad Smith]

Public bug reported:

./softwareproperties/gtk/utils.py relies on presence of ua command
delivered by ubuntu-advantage-tools. This deb should probably express at
least a Recommends on ubuntu-advantage-tools.

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  debian control should express a package dependency on ubuntu-
  advantage-tools

Status in software-properties package in Ubuntu:
  New

Bug description:
  ./softwareproperties/gtk/utils.py relies on presence of ua command
  delivered by ubuntu-advantage-tools. This deb should probably express
  at least a Recommends on ubuntu-advantage-tools.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1953525/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-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

[Chad Smith]

# Success testing on Bionic Desktop installer
1. Validate current behavior from bionic-updates
csmith@downtown:~$ IP=`uvt-kvm ip ubuntu18.04`
csmith@downtown:~$ ssh csmith@$IP
Welcome to Ubuntu 18.04.6 LTS (GNU/Linux 5.4.0-84-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management: https://landscape.canonical.com
 * Support:https://ubuntu.com/advantage

8 updates can be applied immediately.
8 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable

New release '20.04.3 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Your Hardware Enablement Stack (HWE) is supported until April 2023.
Last login: Thu Nov 18 14:29:55 2021 from 192.168.122.1
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ cat > setup_proposed.sh < #!/bin/bash
> mirror=http://archive.ubuntu.com/ubuntu
> echo deb \$mirror \$(lsb_release -sc)-proposed main | tee 
> /etc/apt/sources.list.d/proposed.list
> apt-get update -q
> apt-get install -qy software-properties-gtk software-properties-common 
> python3-software-properties
> EOF
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ lsb_release -sc
bionic
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ apt policy software-properties-gtk
software-properties-gtk:
  Installed: 0.96.24.32.14
  Candidate: 0.96.24.32.14
  Version table:
 *** 0.96.24.32.14 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main i386 
Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main i386 Packages
100 /var/lib/dpkg/status
 0.96.24.32.1 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
500 http://us.archive.ubuntu.com/ubuntu bionic/main i386 Packages
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ [ -f 
/var/lib/ubuntu-advantage-tools/status.json ] && echo "status.json PRESENT" || 
echo "status.json ABSENT"
status.json ABSENT
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ software-properties-gtk 
# no error messages
# Updates tab on Bionic does not currently report any ESM, support expiry info

2. Install -proposed software-properties, click Updates tab show the correct 
expiry for Bionic on unattached
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ sudo bash ./setup_proposed.sh
deb http://archive.ubuntu.com/ubuntu bionic-proposed main
Hit:1 http://us.archive.ubuntu.com/ubuntu bionic InRelease
Get:2 http://us.archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:3 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Get:4 http://archive.ubuntu.com/ubuntu bionic-proposed InRelease [242 kB]
Get:5 http://us.archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Get:6 http://us.archive.ubuntu.com/ubuntu bionic-updates/main i386 Packages 
[1,378 kB]
Get:7 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 
[2,303 kB]
Get:8 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages [114 
kB]
Get:9 http://archive.ubuntu.com/ubuntu bionic-proposed/main i386 Packages [80.6 
kB]
Get:10 http://archive.ubuntu.com/ubuntu bionic-proposed/main Translation-en 
[27.8 kB]
Get:11 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 DEP-11 
Metadata [6,340 B]
Get:12 http://archive.ubuntu.com/ubuntu bionic-proposed/main DEP-11 48x48 Icons 
[6,671 B]
Get:13 http://archive.ubuntu.com/ubuntu bionic-proposed/main DEP-11 64x64 Icons 
[10.2 kB]
Fetched 4,421 kB in 2s (2,845 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be upgraded:
  python3-software-properties software-properties-common
  software-properties-gtk
3 upgraded, 0 newly installed, 0 to remove and 26 not upgraded.
Need to get 98.7 kB of archives.
After this operation, 14.3 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
software-properties-common all 0.96.24.32.18 [10.1 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
software-properties-gtk all 0.96.24.32.18 [64.9 kB]
Get:3 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
python3-software-properties all 0.96.24.32.18 [23.8 kB]
Fetched 98.7 kB in 1s (152 kB/s)
(Reading database ... 130245 files and directories currently installed.)
Preparing to unpack .../software-properties-common_0.96.24.32.18_all.deb ...
Unpacking software-properties-common (0.96.24.32.18) over (0.96.24.32.14) ...
Preparing to unpack .../software-properties-gtk_0.96.24.32.18_all.deb ...
Unpacking software-properties-gtk (0.96.24.32.18) over (0.96.24.32.14) ...
Preparing to unpack .../python3-software-properties_0.96.24.32.18_all.deb ...
Unpacking python3-software-properties (0.96.24.32.18) over (0.96.24.32.14) ...
Setting up python3-software-properties (0.96.24.32.18) ...
Setting up 

[Touch-packages] [Bug 1939732] Re: report availability of Ubuntu Advantage ESM services on unattached machines

[Chad Smith]

# Success testing on Bionic Desktop installer
1. Validate current behavior from bionic-updates
csmith@downtown:~$ IP=`uvt-kvm ip ubuntu18.04`
csmith@downtown:~$ ssh csmith@$IP
Welcome to Ubuntu 18.04.6 LTS (GNU/Linux 5.4.0-84-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management: https://landscape.canonical.com
 * Support:https://ubuntu.com/advantage

8 updates can be applied immediately.
8 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable

New release '20.04.3 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Your Hardware Enablement Stack (HWE) is supported until April 2023.
Last login: Thu Nov 18 14:29:55 2021 from 192.168.122.1
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ cat > setup_proposed.sh < #!/bin/bash
> mirror=http://archive.ubuntu.com/ubuntu
> echo deb \$mirror \$(lsb_release -sc)-proposed main | tee 
> /etc/apt/sources.list.d/proposed.list
> apt-get update -q
> apt-get install -qy software-properties-gtk software-properties-common 
> python3-software-properties
> EOF
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ lsb_release -sc
bionic
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ apt policy software-properties-gtk
software-properties-gtk:
  Installed: 0.96.24.32.14
  Candidate: 0.96.24.32.14
  Version table:
 *** 0.96.24.32.14 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main i386 
Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main i386 Packages
100 /var/lib/dpkg/status
 0.96.24.32.1 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
500 http://us.archive.ubuntu.com/ubuntu bionic/main i386 Packages
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ [ -f 
/var/lib/ubuntu-advantage-tools/status.json ] && echo "status.json PRESENT" || 
echo "status.json ABSENT"
status.json ABSENT
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ software-properties-gtk 
# no error messages
# Updates tab on Bionic does not currently report any ESM, support expiry info

2. Install -proposed software-properties, click Updates tab show the correct 
expiry for Bionic on unattached
csmith@csmith-Standard-PC-Q35-ICH9-2009:~$ sudo bash ./setup_proposed.sh
deb http://archive.ubuntu.com/ubuntu bionic-proposed main
Hit:1 http://us.archive.ubuntu.com/ubuntu bionic InRelease
Get:2 http://us.archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:3 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Get:4 http://archive.ubuntu.com/ubuntu bionic-proposed InRelease [242 kB]
Get:5 http://us.archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Get:6 http://us.archive.ubuntu.com/ubuntu bionic-updates/main i386 Packages 
[1,378 kB]
Get:7 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 
[2,303 kB]
Get:8 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages [114 
kB]
Get:9 http://archive.ubuntu.com/ubuntu bionic-proposed/main i386 Packages [80.6 
kB]
Get:10 http://archive.ubuntu.com/ubuntu bionic-proposed/main Translation-en 
[27.8 kB]
Get:11 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 DEP-11 
Metadata [6,340 B]
Get:12 http://archive.ubuntu.com/ubuntu bionic-proposed/main DEP-11 48x48 Icons 
[6,671 B]
Get:13 http://archive.ubuntu.com/ubuntu bionic-proposed/main DEP-11 64x64 Icons 
[10.2 kB]
Fetched 4,421 kB in 2s (2,845 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be upgraded:
  python3-software-properties software-properties-common
  software-properties-gtk
3 upgraded, 0 newly installed, 0 to remove and 26 not upgraded.
Need to get 98.7 kB of archives.
After this operation, 14.3 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
software-properties-common all 0.96.24.32.18 [10.1 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
software-properties-gtk all 0.96.24.32.18 [64.9 kB]
Get:3 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
python3-software-properties all 0.96.24.32.18 [23.8 kB]
Fetched 98.7 kB in 1s (152 kB/s)
(Reading database ... 130245 files and directories currently installed.)
Preparing to unpack .../software-properties-common_0.96.24.32.18_all.deb ...
Unpacking software-properties-common (0.96.24.32.18) over (0.96.24.32.14) ...
Preparing to unpack .../software-properties-gtk_0.96.24.32.18_all.deb ...
Unpacking software-properties-gtk (0.96.24.32.18) over (0.96.24.32.14) ...
Preparing to unpack .../python3-software-properties_0.96.24.32.18_all.deb ...
Unpacking python3-software-properties (0.96.24.32.18) over (0.96.24.32.14) ...
Setting up python3-software-properties (0.96.24.32.18) ...
Setting up 

[Touch-packages] [Bug 1939732] Re: report availability of Ubuntu Advantage ESM services on unattached machines

[Chad Smith]

** Changed in: software-properties (Ubuntu Bionic)
   Status: New => Fix Committed

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

Title:
  report availability of Ubuntu Advantage ESM services on unattached
  machines

Status in software-properties package in Ubuntu:
  Fix Released
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed
Status in software-properties source package in Impish:
  Fix Committed

Bug description:
  [Impact]

    * Error messages emitted to software-properties-gtk console "[Errno 2] No 
such file or directory: '/var/lib/ubuntu-advantage/status.json'" due to 
incorrect expectation that status.json file is written when non-root runs `ua 
status`
    * This logic results in multiple `ua status` calls which each result in a 
network-egress to https://contracts.canonical.com on unattached machines which 
could result in delays in rendering  the GTK dialogs while awaiting a response.

  [Test Case]
  1. Install latest version of software-properties-gtk from -proposed
  cat > setup_proposed.sh 

[Touch-packages] [Bug 1939732] Re: report availability of Ubuntu Advantage ESM services on unattached machines

[Chad Smith]

** Also affects: software-properties (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 software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1939732

Title:
  report availability of Ubuntu Advantage ESM services on unattached
  machines

Status in software-properties package in Ubuntu:
  Fix Committed
Status in software-properties source package in Bionic:
  New
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed
Status in software-properties source package in Impish:
  Fix Committed

Bug description:
  [Impact]

    * Error messages emitted to software-properties-gtk console "[Errno 2] No 
such file or directory: '/var/lib/ubuntu-advantage/status.json'" due to 
incorrect expectation that status.json file is written when non-root runs `ua 
status`
    * This logic results in multiple `ua status` calls which each result in a 
network-egress to https://contracts.canonical.com on unattached machines which 
could result in delays in rendering  the GTK dialogs while awaiting a response.

  [Test Case]
  1. Install latest version of software-properties-gtk from -proposed
  cat > setup_proposed.sh 

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

[Chad Smith]

I think there was an omission on the latest bionic upload it doesn't
contain the fixes that were added for focal, hirsute and impish.

I've put up a PR that cherry-picks those fixes into the bionic branch
that would need review and upload before I can validate and set
verification-done-bionic on this bug.

bionic upstream PR.
https://code.launchpad.net/~chad.smith/software-properties/+git/software-properties/+merge/411393

-- 
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:
  Fix Released
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed
Status in software-properties source package in Impish:
  Fix Committed

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

[Chad Smith]

# Hirsute desktop results: SUCCESS non-LTS has neither ESM-Infra nor ESM-Apps 
support or availability.
# so 1. it will not expose "Extend..." links to provide ESM information in 
Updates tab
# and 2. When attached no ESM information will be represented in Updates tab

1. # install proposed

$ cat > setup_proposed.sh 

[Touch-packages] [Bug 1939732] Re: report availability of Ubuntu Advantage ESM services on unattached machines

[Chad Smith]

# Hirsute desktop results: SUCCESS non-LTS has neither ESM-Infra nor ESM-Apps 
support or availability.
# so 1. it will not expose "Extend..." links to provide ESM information in 
Updates tab
# and 2. When attached no ESM information will be represented in Updates tab

1. # install proposed

$ cat > setup_proposed.sh 

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

[Chad Smith]

@brian-murray the verification-done-impish tag may be unnecessary here
by me. My above verification on impish may have just been supplemental
as 0.99.13 already had released which provided ESM awareness on Impish.
That said, I revalidated this because the current 0.99.13.1 also touched
that same logic and I wanted to confirm no regression.

-- 
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:
  Fix Released
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed
Status in software-properties source package in Impish:
  Fix Committed

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

[Chad Smith]

# Impish desktop results: SUCCESS non-LTS has neither ESM-Infra nor ESM-Apps 
support or availability.
# so  1. it will not expose "Extend..." links to provide ESM information in 
Updates tab
# and 2. When attached no ESM information will be represented in Updates tab


1. # install proposed

$ cat > setup_proposed.sh  Fix Committed

** Changed in: software-properties (Ubuntu Impish)
   Importance: Undecided => High

** Changed in: software-properties (Ubuntu Impish)
 Assignee: (unassigned) => Robert Ancell (robert-ancell)

-- 
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:
  Fix Released
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed
Status in software-properties source package in Impish:
  Fix Committed

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 

[Touch-packages] [Bug 1939732] Re: report availability of Ubuntu Advantage ESM services on unattached machines

[Chad Smith]

# Impish desktop results: SUCCESS  
# Note non-LTS doesn't have ESM-infra of ESM-Apps support/availability so no 
Extend... link should be present on Updates tab

1. # install proposed

$ cat > setup_proposed.sh  setup_proposed.sh 

[Touch-packages] [Bug 1939732] Re: report availability of Ubuntu Advantage ESM services on unattached machines

[Chad Smith]

# Focal desktop results: SUCCESS

1. # install proposed

$ cat > setup_proposed.sh  setup_proposed.sh 

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

[Chad Smith]

# Focal desktop results: SUCCESS

1. # install proposed

$ cat > setup_proposed.sh 

[Touch-packages] [Bug 1939732] Re: report availability of Ubuntu Advantage ESM services on unattached machines

[Chad Smith]

** Description changed:

  [Impact]
  
    * Error messages emitted to software-properties-gtk console "[Errno 2] No 
such file or directory: '/var/lib/ubuntu-advantage/status.json'" due to 
incorrect expectation that status.json file is written when non-root runs `ua 
status`
    * This logic results in multiple `ua status` calls which each result in a 
network-egress to https://contracts.canonical.com on unattached machines which 
could result in delays in rendering  the GTK dialogs while awaiting a response.
  
  [Test Case]
  1. Install latest version of software-properties-gtk from -proposed
  cat > setup_proposed.sh  setup_proposed.sh 

[Touch-packages] [Bug 1939732] Re: report availability of Ubuntu Advantage ESM services on unattached machines

[Chad Smith]

** Description changed:

  [Impact]
  
    * Error messages emitted to software-properties-gtk console "[Errno 2] No 
such file or directory: '/var/lib/ubuntu-advantage/status.json'" due to 
incorrect expectation that status.json file is written when non-root runs `ua 
status`
    * This logic results in multiple `ua status` calls which each result in a 
network-egress to https://contracts.canonical.com on unattached machines which 
could result in delays in rendering  the GTK dialogs while awaiting a response.
  
  [Test Case]
  1. Install latest version of software-properties-gtk from -proposed
  cat > setup_proposed.sh  setup_proposed.sh 

[Touch-packages] [Bug 1939732] Re: report availability of Ubuntu Advantage ESM services on unattached machines

[Chad Smith]

** Description changed:

  [Impact]
  
-   * Error messages emitted to software-properties-gtk console "[Errno 2] No 
such file or directory: '/var/lib/ubuntu-advantage/status.json'" due to 
incorrect expectation that status.json file is written when non-root runs `ua 
status`
-   * This logic results in multiple `ua status` calls which each result in a 
network-egress to https://contracts.canonical.com on unattached machines which 
could result in delays in rendering  the GTK dialogs while awaiting a response.
- 
+   * Error messages emitted to software-properties-gtk console "[Errno 2] No 
such file or directory: '/var/lib/ubuntu-advantage/status.json'" due to 
incorrect expectation that status.json file is written when non-root runs `ua 
status`
+   * This logic results in multiple `ua status` calls which each result in a 
network-egress to https://contracts.canonical.com on unattached machines which 
could result in delays in rendering  the GTK dialogs while awaiting a response.
  
  [Test Case]
- 1. Install latest version of Ubuntu advantage from -proposed
- cat > setup_proposed.sh  setup_proposed.sh 

[Touch-packages] [Bug 1939732] Re: report availability of Ubuntu Advantage ESM services on unattached machines

[Chad Smith]

** Description changed:

+ [Impact]
+ 
+   * Error messages emitted to software-properties-gtk console "[Errno 2] No 
such file or directory: '/var/lib/ubuntu-advantage/status.json'" due to 
incorrect expectation that status.json file is written when non-root runs `ua 
status`
+   * This logic results in multiple `ua status` calls which each result in a 
network-egress to https://contracts.canonical.com on unattached machines which 
could result in delays in rendering  the GTK dialogs while awaiting a response.
+ 
+ 
+ [Test Case]
+ 1. Install latest version of Ubuntu advantage from -proposed
+ cat > setup_proposed.sh  setup_proposed.sh 

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

[Chad Smith]

I'm hesitant for your to revert on the focal branches as I don't have
context on if there is tooling that consumes those branches directly in
the project. I don't think it's too much for me to get you and/or Robert
a patch for this now. Today is good for me and I'll push a couple PRs
for you and Robert to review.

-- 
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:
  Fix Released
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed

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

[Chad Smith]

@robert, looks like we should reject this queued upload and put up a
separate set of uploads. Recommending reject here and we can work this &
next week to get you MRs to support current best-practices for
interacting with ua status.json.

-- 
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:
  Fix Released
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed

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

[Chad Smith]

Thank you for this submission. I was awaiting feedback on this bug to
determine if you'd like to solve the outstanding issue that Extend...
links aren't presented on the software-properties-gtk UI for unattached
machines (and/or) dropping the error messages from the console. But, as
you mentioned error console messaging isn't presented to the UI so this
is a non-issue that we can remedy in future uploads.


That said, I also discovered that changes in ubuntu-advantage-tools 27.2
which have already SRU'd into xenial, bionic, focal and render this
current logic broken.


I've filed LP: #1939732 to capture upcoming features needed in the UI to better 
inform about Extending your support if desired on Bionic/Focal etc.

LP 1939732 could be fixed by this diff:

--- /usr/lib/python3/dist-packages/softwareproperties/gtk/utils.py.old  
2021-08-12 13:56:59.695413561 -0600
+++ /usr/lib/python3/dist-packages/softwareproperties/gtk/utils.py  
2021-08-12 14:12:28.597659801 -0600
@@ -26,6 +26,7 @@
 gi.require_version("Gtk", "3.0")
 from gi.repository import Gio, Gtk
 import json
+import os
 import subprocess
 
 import logging
@@ -79,24 +80,20 @@
 # which has already run `ua status`. Calling ua status directly on
 # network disconnected machines will raise a TimeoutException trying to
 # access contracts.canonical.com/v1/resources.
-try:
-# Success writes UA_STATUS_JSON
-result = subprocess.run(['ua', 'status', '--format=json'], 
stdout=subprocess.PIPE)
-except Exception as e:
-print("Failed to call ubuntu advantage client:\n%s" % e)
-return {}
-if result.returncode != 0:
-print("Ubuntu advantage client returned code %d" % result.returncode)
-return {}
-
-try:
-status_file = open(UA_STATUS_JSON, "r")
-except Exception as e:
-print("No ua status file written:\n%s" % e)
-return {}
-
-with status_file as stream:
-status_json = stream.read()
+if os.path.exists(UA_STATUS_JSON):
+with open(UA_STATUS_JSON) as stream:
+   status_json = stream.read()
+else:
+try:
+# Success writes UA_STATUS_JSON
+result = subprocess.run(['ua', 'status', '--format=json'], 
stdout=subprocess.PIPE)
+except Exception as e:
+print("Failed to call ubuntu advantage client:\n%s" % e)
+return {}
+if result.returncode != 0:
+print("Ubuntu advantage client returned code %d" % 
result.returncode)
+return {}
+status_json = result.stdout
 try:
 status = json.loads(status_json)
 except json.JSONDecodeError as e:



 The UX "updates" tab no longer can correctly determine that the machine is 
attached because a new field "available" has been published in status.json. 


Current utils.py:get_ua_service_status relies on a now incorrect check:

if service.get("available"):  # then we are not attached
if service["available"] == "yes":
 available = True
 service_status = "disabled"  # Disabled since unattached

Since ua status output on attach machines now provides "available":
"yes" in version 27.2 it broke the assumption that "available" keys
represented a detached system.

This 2nd issue could be fixed by this diff

--- /usr/lib/python3/dist-packages/softwareproperties/gtk/utils.py.old  
2021-08-12 13:56:59.695413561 -0600
+++ /usr/lib/python3/dist-packages/softwareproperties/gtk/utils.py  
2021-08-12 13:57:13.951629355 -0600
@@ -123,7 +123,7 @@
 service_status = "n/a"
 for service in status.get("services", []):
 if service.get("name") == service_name:
-if service.get("available"):  # then we are not attached
+if status.get("attached", False) == False:  # we are not attached
 if service["available"] == "yes":
  available = True
  service_status = "disabled"  # Disabled since unattached



the third issue is that the contract expiry date format of v 27.2 doesn't 
conform to software-properties-gtk expectations: with the above patches, we 
still see issues with ability to decode the expiry string in the console

unconverted data remains: +00:00 (<--- added print of the exception msg)
Unable to determine UA contract expiry


this patch would be needed to suport expiry datestring formatting for ua-tools 
27.2 in bionic focal etc
--- 
/usr/lib/python3/dist-packages/softwareproperties/gtk/SoftwarePropertiesGtk.py.old
  2021-08-12 14:43:33.570530853 -0600
+++ 
/usr/lib/python3/dist-packages/softwareproperties/gtk/SoftwarePropertiesGtk.py  
2021-08-12 14:43:50.594751621 -0600
@@ -394,8 +394,11 @@
 # gives software properties dialogs a chance to interact about
 # renewals if needed.
 try:
+# Ignore timezone to simplify formatting python < 3.7
+# 3.7+ 

[Touch-packages] [Bug 1939732] [NEW] report availability of Ubuntu Advantage ESM services on unattached machines

[Chad Smith]

Public bug reported:

Release: bionic/focal
Version: 0.96.24.32 (bionic)

Issue:
Software & Updates GTK UI doesn't report availability of UBuntu Advantage ESM 
Infra or ESM Apps services on unattached machines

Steps to repropduce:

Launch software-properties-gtk from the commandline.
See unexpected errors on the terminal

 No ua status file written:
[Errno 2] No such file or directory: '/var/lib/ubuntu-advantage/status.json'


Navigation to the "Updates" tab
See only:
Basic Security Maintenance
04/26/2023

Expected results:
See no error messages on terminal
See a link to the right of Basic Security Maintenance on the "Updates" tab that 
points to ESM info
Basic Security Maintenance  Extend...(links to  
ubuntu.com/security/esm)

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  report availability of Ubuntu Advantage ESM services on unattached
  machines

Status in software-properties package in Ubuntu:
  New

Bug description:
  Release: bionic/focal
  Version: 0.96.24.32 (bionic)

  Issue:
  Software & Updates GTK UI doesn't report availability of UBuntu Advantage ESM 
Infra or ESM Apps services on unattached machines

  Steps to repropduce:

  Launch software-properties-gtk from the commandline.
  See unexpected errors on the terminal

   No ua status file written:
  [Errno 2] No such file or directory: '/var/lib/ubuntu-advantage/status.json'

  
  Navigation to the "Updates" tab
  See only:
  Basic Security Maintenance
  04/26/2023

  Expected results:
  See no error messages on terminal
  See a link to the right of Basic Security Maintenance on the "Updates" tab 
that points to ESM info
  Basic Security Maintenance  Extend...(links to  
ubuntu.com/security/esm)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1939732/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-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

[Chad Smith]

>> Is there a reason why the ua client doesn't do this itself
internally, i.e. it gives you fresh json or returns the cached copy if
it can't do the update?

Currently the only "time" during which ubuntu-advantage-tools (UA
client) could perform the logic to exec 'sudo ua status' is during
postinst at package install upgrade time. UA client can not perform that
status setup during package install for the same timeout reasons you
mentioned.  It is a potentially long operation. If run during a package
install it could delay or prevent other package upgrades if it hits a
timeout and/or error. That said, we are working on instrumenting a
systemd timer service that can run config change/setup operations out of
band of typical APT package installs. So, this case could be handled by
that timer-based service.  This SRU does represent.

This changeset as-is does represent an improvement to existing cases
because the Software properties UX demonstrates awareness of ESM (and
contract expiry information) properly for attached machines, or
unattached machines where `sudo ua status` has been run.

Subsequent releases of software-properties will now be able to take
advantage of reading "ua status --format=json" output directly as non-
root (due to a bug-fix released in 27.2.1). The non-root user will not
have to rely anymore on that json file if absent as the --format=json
output will render the same JSON dict that would be present on disk for
the root user. This is a fix that is under verification in the -proposed
queue now for ua-tools and was not available at the time of this
original software-properties PR. I'm ok with this approach as-is knowing
that we can significantly improve the behavior once ubuntu-advantage-
tools 27.2.1 is released to X B F and H

-- 
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:
  Fix Released
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed

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

[Chad Smith]

miniamlly as in the patch above, I think we probably need a pre-flight
check of os.path.exists( UA_STATUS_JSON) so we don't emit those Errno
messages due to failed file opens

-- 
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:
  Fix Released
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed

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

[Chad Smith]

Ultimately if we decide to go with #2 here's a patch that I think would
limit both the time cost of a remote uRL query and the noisy logging:

--- /usr/lib/python3/dist-packages/softwareproperties/gtk/utils.py  
2021-06-10 23:20:22.0 -0600
+++ /usr/lib/python3/dist-packages/softwareproperties/gtk/utils.py.new  
2021-07-14 15:32:54.559693094 -0600
@@ -26,6 +26,7 @@
 gi.require_version("Gtk", "3.0")
 from gi.repository import Gio, Gtk
 import json
+import os
 import subprocess
 
 import logging
@@ -76,23 +77,12 @@
 def get_ua_status():
 """Return a dict of all UA status information or empty dict on error."""
 # status.json will exist on any attached system or any unattached system
-# which has already run `ua status`. Calling ua status directly on
-# network disconnected machines will raise a TimeoutException trying to
-# access contracts.canonical.com/v1/resources.
-try:
-# Success writes UA_STATUS_JSON
-result = subprocess.run(['ua', 'status', '--format=json'], 
stdout=subprocess.PIPE)
-except Exception as e:
-print("Failed to call ubuntu advantage client:\n%s" % e)
+# which has already run `sudo ua status`.
+if not os.path.exists(UA_STATUS_JSON):
 return {}
-if result.returncode != 0:
-print("Ubuntu advantage client returned code %d" % result.returncode)
-return {}
-
 try:
 status_file = open(UA_STATUS_JSON, "r")
 except Exception as e:
-print("No ua status file written:\n%s" % e)
 return {}
 
 with status_file as stream:

-- 
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:
  Fix Released
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed

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

[Chad Smith]

Ultimately if we decide to go with #2 here's a patch that I think would
limit both the time cost of a remote uRL query and the noisy logging:


--- /usr/lib/python3/dist-packages/softwareproperties/gtk/utils.py  
2021-06-10 23:20:22.0 -0600
+++ /usr/lib/python3/dist-packages/softwareproperties/gtk/utils.py.new  
2021-07-14 15:19:14.485004311 -0600
@@ -76,23 +76,10 @@
 def get_ua_status():
 """Return a dict of all UA status information or empty dict on error."""
 # status.json will exist on any attached system or any unattached system
-# which has already run `ua status`. Calling ua status directly on
-# network disconnected machines will raise a TimeoutException trying to
-# access contracts.canonical.com/v1/resources.
-try:
-# Success writes UA_STATUS_JSON
-result = subprocess.run(['ua', 'status', '--format=json'], 
stdout=subprocess.PIPE)
-except Exception as e:
-print("Failed to call ubuntu advantage client:\n%s" % e)
-return {}
-if result.returncode != 0:
-print("Ubuntu advantage client returned code %d" % result.returncode)
-return {}
-
+# which has already run `sudo ua status`.
 try:
 status_file = open(UA_STATUS_JSON, "r")
 except Exception as e:
-print("No ua status file written:\n%s" % e)
 return {}
 
 with status_file as stream:

-- 
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:
  Fix Released
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed

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

[Chad Smith]

Also per #2 above, if we were to drop the `ua status` call from
utils.py:get_ua_status() that would also mitigate the perceived "time
cost" corradoventu mentioned because `ua status` does reach out to the
internet to contracts.canonical.com to check service availability for
your running distro/kernel/platform. If we don't make that `ua status`
commandline call, and rely on presence/absence of /var/lib/ubuntu-
advantage/status.json then we can avoid the round trip to an external
URL to fill in these service details.

-- 
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:
  Fix Released
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed

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

[Chad Smith]

@robert-ancell and @corradoventu those errors are due to running
software-properties-gtk as non-root user on a system that is not
attached to any ubuntu-advantage services.

 The /var/lib/ubuntu-advantage/status.json file is only created by a
root user via an `sudo ua status` or `sudo ua attach ` call. The
absence of the file means that the system is not attached to any valid
Ubuntu Advantage services, and the logic in
softwareproperties/gtk/util.py will still correctly return an empty
representation for ubuntu-advantage services as an empty dict {} and the
UX dialogs properly direct folks to how to activate ESM in this case.


I mistakenly thought software-properties-gtk is invoked as root user in order 
to install/update packages. Given that it is invoked as non-root user we can do 
one of two things:
   1. keep the current implementation which would print messages about missing 
status.json files knowing that the UX dialogs still behave correctly.
OR
   2. drop the subp call to 'ua' 'status' from utils.py:get_ua_status() because 
they will never emit the /var/lib/ubuntu-advantage/status.json artifact and 
also drop the printed messages about No ua status file written as that really 
only means you are non-root and on an unattached machine.

-- 
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:
  Fix Released
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  Fix Committed
Status in software-properties source package in Focal:
  Fix Committed
Status in software-properties source package in Hirsute:
  Fix Committed

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 1732522] Re: [2.3] Ephemeral boot environment does not renew DHCP leases

[Chad Smith]

** Changed in: cloud-init
   Status: Incomplete => Invalid

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

Title:
  [2.3] Ephemeral boot environment does not renew DHCP leases

Status in cloud-init:
  Invalid
Status in MAAS:
  Fix Released
Status in cloud-initramfs-tools package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  I started commissioning+hardware testing on a machine, and while the
  machine was testing (for 2hrs+) i noticed that the IP address had
  disappeared. The machine has the MAC of  00:25:90:4c:e7:9e and IP of
  192.168.0.211 from the dynamic range.

  Checking the MAAS server, I noticed that the IP/MAC was in the ARP
  table:

  andreserl@maas:/var/lib/maas/dhcp$ arp -a | grep 211
  192-168-9-211.maas (192.168.9.211) at 00:25:90:4c:e7:9e [ether] on bond-lan

  Checking the leases file has the following:
  http://pastebin.ubuntu.com/25969442/

  Then I checked a couple areas of MAAS:
   - Device discovery, the machine wasn't there.
   - Subnet details page, the machine wasn't there (e.g. as observed)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1732522/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

[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

[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