[Yahoo-eng-team] [Bug 2011454] Re: TypeError: load() missing 1 required positional argument: 'Loader'

[Michael Hudson-Doyle]

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

I think this is a bug in cloud-init, it looks like it is not compatible
with pyyaml 6.

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** This bug has been marked a duplicate of bug 2009746
   dpkg-reconfigure cloud-init: yaml.load errors during MAAS deloyment of 
Ubuntu 23.04(Lunar)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/2011454

Title:
  TypeError: load() missing 1 required positional argument: 'Loader'

Status in cloud-init:
  New
Status in curtin:
  New

Bug description:
  I'm seeing failures deploying lunar to an arm64 server, curtin
  2.1-0ubuntu1~22.04.1, MAAS 3.3:

 Running command ['unshare', '--help'] with allowed return codes [0] 
(capture=True)
  Running command ['unshare', '--fork', '--pid', '--', 'chroot', 
'/tmp/tmp6un94l9v/target', 'lsb_release', '--all'] with allowed return codes 
[0] (capture=True)
  Running command ['unshare', '--fork', '--pid', '--', 'chroot', 
'/tmp/tmp6un94l9v/target', 'dpkg', '--print-architecture'] with allowed return 
codes [0] (capture=True)
  got primary mirror: None
  got security mirror: None
  Apt Mirror info: {'PRIMARY': 'http://ports.ubuntu.com/ubuntu-ports', 
'SECURITY': 'http://ports.ubuntu.com/ubuntu-ports', 'MIRROR': 
'http://ports.ubuntu.com/ubuntu-ports'}
  Applying debconf selections
  Running command ['unshare', '--fork', '--pid', '--', 'chroot', 
'/tmp/tmp6un94l9v/target', 'debconf-set-selections'] with allowed return codes 
[0] (capture=True)
  Running command ['unshare', '--fork', '--pid', '--', 'chroot', 
'/tmp/tmp6un94l9v/target', 'dpkg-query', '--list'] with allowed return codes 
[0] (capture=True)
  unconfiguring cloud-init
  cleaning cloud-init config from: 
['/tmp/tmp6un94l9v/target/etc/cloud/cloud.cfg.d/90_dpkg.cfg']
  Running command ['unshare', '--fork', '--pid', '--', 'chroot', 
'/tmp/tmp6un94l9v/target', 'dpkg-reconfigure', '--frontend=noninteractive', 
'cloud-init'] with allowed return codes [0] (capture=True)
  finish: 
cmd-install/stage-curthooks/builtin/cmd-curthooks/writing-apt-config: FAIL: 
configuring apt configuring apt
  finish: cmd-install/stage-curthooks/builtin/cmd-curthooks: FAIL: 
curtin command curthooks
  Traceback (most recent call last):
File "/curtin/curtin/commands/main.py", line 202, in main
  ret = args.func(args)
^^^
File "/curtin/curtin/commands/curthooks.py", line 1886, in curthooks
  builtin_curthooks(cfg, target, state)
File "/curtin/curtin/commands/curthooks.py", line 1692, in 
builtin_curthooks
  do_apt_config(cfg, target)
File "/curtin/curtin/commands/curthooks.py", line 97, in 
do_apt_config
  apt_config.handle_apt(apt_cfg, target)
File "/curtin/curtin/commands/apt_config.py", line 73, in handle_apt
  apply_debconf_selections(cfg, target)
File "/curtin/curtin/commands/apt_config.py", line 167, in 
apply_debconf_selections
  dpkg_reconfigure(need_reconfig, target=target)
File "/curtin/curtin/commands/apt_config.py", line 133, in 
dpkg_reconfigure
  util.subp(['dpkg-reconfigure', '--frontend=noninteractive'] +
File "/curtin/curtin/util.py", line 275, in subp
  return _subp(*args, **kwargs)
 ^^
File "/curtin/curtin/util.py", line 139, in _subp
  raise ProcessExecutionError(stdout=out, stderr=err,
  curtin.util.ProcessExecutionError: Unexpected error while running 
command.
  Command: ['unshare', '--fork', '--pid', '--', 'chroot', 
'/tmp/tmp6un94l9v/target', 'dpkg-reconfigure', '--frontend=noninteractive', 
'cloud-init']
  Exit code: 1
  Reason: -
  Stdout: ''
  Stderr: Traceback (most recent call last):
File "", line 23, in 
  TypeError: load() missing 1 required positional argument: 
'Loader'
  
  Unexpected error while running command.
  Command: ['unshare', '--fork', '--pid', '--', 'chroot', 
'/tmp/tmp6un94l9v/target', 'dpkg-reconfigure', '--frontend=noninteractive', 
'cloud-init']
  Exit code: 1
  Reason: -
  Stdout: ''
  Stderr: Traceback (most recent call last):
File "", line 23, in 
  TypeError: load() missing 1 required positional argument: 
'Loader'
  
  
  Stderr: ''

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


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : 

[Yahoo-eng-team] [Bug 1872124] Re: Please integrate ubuntu-drivers --gpgpu into Ubuntu Server

[Michael Hudson-Doyle]

The version of subiquity in 22.04.1 supports this now.

** Changed in: subiquity
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1872124

Title:
  Please integrate ubuntu-drivers --gpgpu into Ubuntu Server

Status in cloud-init:
  Incomplete
Status in MAAS:
  Incomplete
Status in subiquity:
  Fix Released
Status in ubuntu-drivers-common package in Ubuntu:
  New
Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  Could subiquity provide an option in the UI to install and execute
  ubuntu-drivers-common on the target? The use case I'm interested in is
  an "on-rails" installation of Nvidia drivers for servers being
  installed for deep learning workloads.

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


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1915460] [NEW] no way to suppress host key info on console

[Michael Hudson-Doyle]

Public bug reported:

cc_keys_to_console does not have any way to prevent the keys being
written to the console (beyond deleting write-ssh-key-fingerprints,
which while actually ok for my use case is gross). I propose adding a
"no_keys_to_console" config option, defaulting to False, that suppresses
the output (modelled on what cc_ssh_authkey_fingerprints does).

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1915460

Title:
  no way to suppress host key info on console

Status in cloud-init:
  New

Bug description:
  cc_keys_to_console does not have any way to prevent the keys being
  written to the console (beyond deleting write-ssh-key-fingerprints,
  which while actually ok for my use case is gross). I propose adding a
  "no_keys_to_console" config option, defaulting to False, that
  suppresses the output (modelled on what cc_ssh_authkey_fingerprints
  does).

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1915077] [NEW] genisoimage may be going away

[Michael Hudson-Doyle]

Public bug reported:

It seems that cdrkit, which is where genisoimage comes from, is dead
upstream and is likely to be removed from debian:
https://lists.debian.org/debian-cloud/2021/02/msg00011.html

Plenty of cloud-init docs and tutorials refer to genisoimage to create
seed ISOs, it may be time to find something else.

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1915077

Title:
  genisoimage may be going away

Status in cloud-init:
  New

Bug description:
  It seems that cdrkit, which is where genisoimage comes from, is dead
  upstream and is likely to be removed from debian:
  https://lists.debian.org/debian-cloud/2021/02/msg00011.html

  Plenty of cloud-init docs and tutorials refer to genisoimage to create
  seed ISOs, it may be time to find something else.

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1869155] Re: When installing with subiquity, the generated network config uses the macaddress keyword on s390x (where MAC addresses are not necessarily stable across reboots)

[Michael Hudson-Doyle]

** Changed in: subiquity
   Status: New => Fix Released

** Changed in: initramfs-tools (Ubuntu)
   Status: New => Fix Released

** Changed in: ubuntu-z-systems
   Status: New => Fix Released

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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1869155

Title:
  When installing with subiquity, the generated network config uses the
  macaddress keyword on s390x (where MAC addresses are not necessarily
  stable across reboots)

Status in cloud-init:
  Invalid
Status in subiquity:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released

Bug description:
  While performing a subiquity focal installation on an s390x LPAR (where the 
LPAR is connected to a VLAN trunk) I saw a section like this:
 match:
  macaddress: 02:28:0b:00:00:53
  So the macaddress keyword is used, but on several s390x machine generation 
MAC addresses are
  not necessarily stable and uniquie across reboots.
  (z14 GA2 and newer system have in between a modified firmware that ensures 
that MAC addresses are stable and uniquire across reboots, but for z14 GA 1 and 
older systems, incl. the z13 that I used this is not the case - and a backport 
of the firmware modification is very unlikely)

  The configuration that I found is this:

  $ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by the datasource. Changes
  # to it will not persist across an instance 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:
  enc600:
  addresses:
  - 10.245.236.26/24
  gateway4: 10.245.236.1
  match:
  macaddress: 02:28:0b:00:00:53
  nameservers:
  addresses:
  - 10.245.236.1
  set-name: enc600
  version: 2

  (This is a spin-off of ticket LP 1868246.)

  It's understood that the initial idea for the MAC addresses was to have a 
unique identifier, but
  I think with the right tooling (ip, ifconfig, ethtool or even the 
network-manager UI) you can even change MAC addresses today on other platforms.

  Nowadays interface names are based on their underlying physical
  device/address (here in this case '600' or to be precise '0600' -
  leading '0' are removed), which makes the interface and it's name
  already quite unique - since it is not possible to have two devices
  (in one system) with the exact same address.

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1869967] Re: subiquity->cloud-init generates netplan yaml telling user not to edit it

[Michael Hudson-Doyle]

** Changed in: subiquity
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1869967

Title:
  subiquity->cloud-init generates netplan yaml telling user not to edit
  it

Status in cloud-init:
  Invalid
Status in subiquity:
  Fix Released

Bug description:
  As seen in , users who install with subiquity end up
  with a /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg that persists
  on the target system, plus an /etc/netplan/50-cloud-init.yaml that
  tells users not to edit it without taking steps to disable cloud-init.

  I don't think this is what we want.  I think a subiquity install
  should unambiguously treat cloud-init as a one-shot at installation,
  and leave the user afterwards with config files that can be directly
  edited without fear of cloud-init interfering; and the yaml files
  generated by cloud-init on subiquity installs should therefore also
  not include this scary language:

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

  But we need to figure out how to fix this between subiquity and cloud-
  init.

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1868246] Re: No network after subiquity LPAR installation on s390x with VLAN

[Michael Hudson-Doyle]

** Changed in: initramfs-tools (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1868246

Title:
  No network after subiquity LPAR installation on s390x with VLAN

Status in cloud-init:
  Invalid
Status in subiquity:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released

Bug description:
  I tried today an subiquity LPAR installation using the latest ISO (March 19) 
that includes the latest 20.03 subiquity.
  The installation itself completed fine, but after the post-install reboot the 
system didn't had a network active - please note that the LPAR is connected to 
a VLAN.

  $ ip a   
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
defaul
  t qlen 1000   
  
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
  
  inet 127.0.0.1/8 scope host lo
  
 valid_lft forever preferred_lft forever
  
  inet6 ::1/128 scope host  
  
 valid_lft forever preferred_lft forever
  
  2: encc000:  mtu 1500 qdisc noop state DOWN group 
default q
  len 1000  
  
  link/ether a2:8d:91:85:12:e3 brd ff:ff:ff:ff:ff:ff
  
  3: enP1p0s0:  mtu 1500 qdisc noop state DOWN group 
default 
  qlen 1000 
  
  link/ether 82:0c:2d:0c:b8:70 brd ff:ff:ff:ff:ff:ff
  
  4: enP1p0s0d1:  mtu 1500 qdisc noop state DOWN group 
defaul
  t qlen 1000   
  
  link/ether 82:0c:2d:0c:b8:71 brd ff:ff:ff:ff:ff:ff
  
  5: enP2p0s0:  mtu 1500 qdisc noop state DOWN group 
default 
  qlen 1000 
  
  link/ether 82:0c:2d:0c:b7:00 brd ff:ff:ff:ff:ff:ff
  
  6: enP2p0s0d1:  mtu 1500 qdisc noop state DOWN group 
defaul
  t qlen 1000   
  
  link/ether 82:0c:2d:0c:b7:01 brd ff:ff:ff:ff:ff:ff   

  Wanting to have a look at the netplan config it turned out that there is no 
yaml file:
  $ ls -l /etc/netplan/
  total 0  

  Adding one manually and applying it worked fine.

  So looks like the installer does not properly generate or copy a
  01-netcfg.yaml to /etc/netplan.

  Please see below the entire steps as well as a compressed file with
  the entire content of /var/log

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1834875] Re: cloud-init growpart race with udev

[Michael Hudson-Doyle]

** No longer affects: linux-azure (Ubuntu)

** No longer affects: systemd (Ubuntu)

** Also affects: cloud-utils (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: cloud-initramfs-tools (Ubuntu Eoan)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  Fix Committed
Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in cloud-utils package in Ubuntu:
  Fix Released
Status in cloud-initramfs-tools source package in Eoan:
  New
Status in cloud-utils source package in Eoan:
  New

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1869155] Re: When installing with subiquity, the generated network config uses the macaddress keyword on s390x (where MAC addresses are not necessarily stable across reboots)

[Michael Hudson-Doyle]

Pretty sure it's initramfs-tools that is putting the mac addresses in
the netplan. That probably needs to grow a little platform-dependent
behaviour around this.

** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1869155

Title:
  When installing with subiquity, the generated network config uses the
  macaddress keyword on s390x (where MAC addresses are not necessarily
  stable across reboots)

Status in cloud-init:
  Incomplete
Status in subiquity:
  New
Status in Ubuntu on IBM z Systems:
  New
Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  While performing a subiquity focal installation on an s390x LPAR (where the 
LPAR is connected to a VLAN trunk) I saw a section like this:
 match:
  macaddress: 02:28:0b:00:00:53
  So the macaddress keyword is used, but on several s390x machine generation 
MAC addresses are
  not necessarily stable and uniquie across reboots.
  (z14 GA2 and newer system have in between a modified firmware that ensures 
that MAC addresses are stable and uniquire across reboots, but for z14 GA 1 and 
older systems, incl. the z13 that I used this is not the case - and a backport 
of the firmware modification is very unlikely)

  The configuration that I found is this:

  $ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by the datasource. Changes
  # to it will not persist across an instance 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:
  enc600:
  addresses:
  - 10.245.236.26/24
  gateway4: 10.245.236.1
  match:
  macaddress: 02:28:0b:00:00:53
  nameservers:
  addresses:
  - 10.245.236.1
  set-name: enc600
  version: 2

  (This is a spin-off of ticket LP 1868246.)

  It's understood that the initial idea for the MAC addresses was to have a 
unique identifier, but
  I think with the right tooling (ip, ifconfig, ethtool or even the 
network-manager UI) you can even change MAC addresses today on other platforms.

  Nowadays interface names are based on their underlying physical
  device/address (here in this case '600' or to be precise '0600' -
  leading '0' are removed), which makes the interface and it's name
  already quite unique - since it is not possible to have two devices
  (in one system) with the exact same address.

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1808072] [NEW] there is a window between user being created and ssh_pwauth being honoured

[Michael Hudson-Doyle]

Public bug reported:

I booted an instance locally and managed to log in over ssh using a
password despite ssh_pwauth being false. Turns out that this was because
the user was created around two minutes before sshd_config was updated.

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1808072

Title:
  there is a window between user being created and ssh_pwauth being
  honoured

Status in cloud-init:
  New

Bug description:
  I booted an instance locally and managed to log in over ssh using a
  password despite ssh_pwauth being false. Turns out that this was
  because the user was created around two minutes before sshd_config was
  updated.

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1739516] [NEW] networking comes up before hostname is set

[Michael Hudson-Doyle]

Public bug reported:

When boot with libvirt a disk image that has been installed with
subiquity which has the workaround for bug 1737630 applied, i.e.
networkd starts automatically, I cannot ping the VM by hostname from the
host.

I think this is because the networking has come up before the hostname
is set, so the hostname is not sent along with the DHCP request to
libvirt's dnsmasq and so that dnsmasq cannot answer lookups for the
hostname. If I run "netplan apply" on the vm, enough things are
apparently restarted that DHCP happens again and I can ping the vm by
hostname from the host.

I'm not completely sure I have diagnosed this correctly and certainly
don't know how to fix it.

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1739516

Title:
  networking comes up before hostname is set

Status in cloud-init:
  New

Bug description:
  When boot with libvirt a disk image that has been installed with
  subiquity which has the workaround for bug 1737630 applied, i.e.
  networkd starts automatically, I cannot ping the VM by hostname from
  the host.

  I think this is because the networking has come up before the hostname
  is set, so the hostname is not sent along with the DHCP request to
  libvirt's dnsmasq and so that dnsmasq cannot answer lookups for the
  hostname. If I run "netplan apply" on the vm, enough things are
  apparently restarted that DHCP happens again and I can ping the vm by
  hostname from the host.

  I'm not completely sure I have diagnosed this correctly and certainly
  don't know how to fix it.

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1737630] [NEW] cloud-init's netplan rendering does not do anything that starts networkd

[Michael Hudson-Doyle]

Public bug reported:

Currently if an instance ends up using cloud-init's netplan support with
the networkd backed, networkd is never started and so networking doesn't
come up. The fix is probably to call "netplan apply" rather than
"netplan generate".

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1737630

Title:
  cloud-init's netplan rendering does not do anything that starts
  networkd

Status in cloud-init:
  New

Bug description:
  Currently if an instance ends up using cloud-init's netplan support
  with the networkd backed, networkd is never started and so networking
  doesn't come up. The fix is probably to call "netplan apply" rather
  than "netplan generate".

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1726651] [NEW] any netplan config for wifi devices should not be world readable

[Michael Hudson-Doyle]

Public bug reported:

Currently, as near as I can tell, curtin writes netplan config to a
world readable file in /etc/cloud/ and cloud-init writes it to a world
readable file in /etc/netplan. But if there are any wpa2 psks in the
config they should be put in a 0600 file.

This doesn't really make any sense for actual clouds, but subiquity
should be able to get this right.

One way to do this would be for cloud-init to check through the provided
config and put wifis in a separate file or another would be for there to
be a way to direct cloud-init to write different parts of the netplan
config to different files and a way to set the modes of those files
(neither of which appears to be possible today), and for curtin to make
use of that. I don't really care :)

** Affects: cloud-init
 Importance: Undecided
 Status: New

** Affects: curtin
 Importance: Undecided
 Status: New

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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1726651

Title:
  any netplan config for wifi devices should not be world readable

Status in cloud-init:
  New
Status in curtin:
  New

Bug description:
  Currently, as near as I can tell, curtin writes netplan config to a
  world readable file in /etc/cloud/ and cloud-init writes it to a world
  readable file in /etc/netplan. But if there are any wpa2 psks in the
  config they should be put in a 0600 file.

  This doesn't really make any sense for actual clouds, but subiquity
  should be able to get this right.

  One way to do this would be for cloud-init to check through the
  provided config and put wifis in a separate file or another would be
  for there to be a way to direct cloud-init to write different parts of
  the netplan config to different files and a way to set the modes of
  those files (neither of which appears to be possible today), and for
  curtin to make use of that. I don't really care :)

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1414218] Re: Remove extraneous trace in linux/dhcp.py

[Michael Hudson-Doyle]

I've uploaded the patch to the trusty-proposed queue. Not sure how to
handle the cloud-archive stuff!

** Also affects: neutron (Ubuntu Trusty)
   Importance: Undecided
   Status: New

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

** Changed in: neutron (Ubuntu Trusty)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1414218

Title:
  Remove extraneous trace in linux/dhcp.py

Status in Ubuntu Cloud Archive:
  Confirmed
Status in neutron:
  Fix Released
Status in neutron juno series:
  Fix Released
Status in neutron package in Ubuntu:
  Fix Released
Status in neutron source package in Trusty:
  In Progress

Bug description:
  [Impact]

  The debug tracepoint in Dnsmasq._output_hosts_file is extraneous and
  causes unnecessary performance overhead when creating lots (> 1000)
  ports at one time.

  The trace point is unnecessary since the data is being written to disk
  and the file can be examined in a worst case scenario. The added
  performance overhead is an order of magnitude in difference (~.5
  seconds versus ~.05 seconds at 1500 ports).

  [Test Case]

  1. Deploy OpenStack using neutron for networking
  2. Create 1500 ports
  3. Observe the performance degradation for each port creation.

  [Regression Potential]

  Minimal. This code has been running in stable/juno, stable/kilo, and
  above for awhile.

  [Other Questions]

  This is likely to occur in OpenStack deployments which have large
  networks deployed. The degradation is gradual, but the performance
  becomes unacceptable with large enough networks.

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp