[Yahoo-eng-team] [Bug 1767166] Re: IBMCloud datasource does not recognize provisioning in debug mode.
** Changed in: cloud-init (Ubuntu)
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/1767166
Title:
IBMCloud datasource does not recognize provisioning in debug mode.
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Status in cloud-init source package in Artful:
Fix Released
Status in cloud-init source package in Bionic:
Fix Released
Status in cloud-init source package in Cosmic:
Fix Committed
Bug description:
=== Begin SRU Template ===
[Impact]
Cloud-init is disabled in the provisioning state. If provisioning
artifacts are left around after debug mode, cloud-init remains disabled
and doesn't properly configure the instance.
This issue only affects images that are being tested by IBM before official
publication. Once officially published, the images will have a 'production'
tag, and bug does not reproduce.
As such, it is believed that a regular end user is not really able to
produce.
[Test Case]
cat > sethostname.yaml < /run/runcmd-ran.txt']
EOF
VM_IP=`launch-softlayer --pubkey-file ~/.ssh/id_rsa.pub -u
sethostname.yaml -i os:xenial | awk '/primary ip/{printf "root@%s",
$3}'`
ssh root@$VM_IP -- dpkg-query --show cloud-init;
ssh root@$VM_IP -- cloud-init status --long;
ssh root@$VM_IP -- cloud-init analyze show;
ssh root@$VM_IP -- sh -c '
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 cloud-init';
ssh root@$VM_IP -- DEBUG_LEVEL=2 DI_LOG=stderr
/usr/lib/cloud-init/ds-identify --force 2>&1 | grep provision
ssh root@$VM_IP -- cloud-init clean --logs --reboot;
ssh root@$VM_IP -- egrep 'provisioning|swinstall' /var/log/cloud-init.log
ssh root@$VM_IP -- grep provision /run/cloud-init/ds-identify.log
[Regression Potential]
Regression will still be limited to softlayer instances as code changes are
limited to softlayer datasource detection in ds-identify and
DataSourceIBMCloud.
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=44a44ae18
This bug is currently fixed in bionic-proposed version
(18.2-27-g6ef92c98-0ubuntu1~18.04.1) and
cloud-init trunk, so first upload to ubuntu 'cc' will have it fixed.
=== End SRU Template ===
When IBMCloud deploys from a template, artifacts from the
provisioning stage are normally cleaned up. Cloud-init relied'
on that behavior to determine the provisioning boot from the subsequent
post-provisioning boot.
However, when testing, the provisioning stage will leave artifacts
in place (/root/provisioningConfiguration.cfg). This caused cloud-init
to permenantly believe that it was in the provisioning stage.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1767166/+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 1956788] Re: system_cfg not read on Oracle datasource
This bug is believed to be fixed in cloud-init in version 23.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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1956788 Title: system_cfg not read on Oracle datasource Status in cloud-init: Fix Released Bug description: In https://github.com/canonical/cloud- init/commit/2c52e6e88b19f5db8d55eb7280ee27703e05d75f , the order of reading network config was changed for Oracle due to initramfs needing to take lower precedence than the datasource. However, this also bumped system_cfg to a lower precedence than ds, which means that any network configuration specified in /etc/cloud will not be applied. system_cfg should instead be moved above ds so network configuration in /etc/cloud takes precedence. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1956788/+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 2008888] Re: RuntimeError: duplicate mac found! both 'wwan1' and 'wwan0'
This bug is believed to be fixed in cloud-init in version 23.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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/200 Title: RuntimeError: duplicate mac found! both 'wwan1' and 'wwan0' Status in cloud-init: Fix Released Bug description: Hi This bug is a variant of https://bugs.launchpad.net/cloud-init/+bug/1997922. I got this error only when PXE booting a target with a modem that has dual interface support, and using ubuntu-22.04.2-live-server-amd64.iso or ubuntu-22.04.1-live-server-amd64.iso. After a manual installation, the target boots fine without this error. Detected modems that cause this error: Quectel EG25 Quectel RM510Q-GLHA Sierra Wireless MC7455 Failure in cloud-init prevent automatic installation of targets in our production. Tested solution: After studying the info in bug 1997922, I downloaded https://github.com/canonical/cloud-init/blob/main/cloudinit/net/__init__.py and changed line 1043 to: if driver == "mscc_felix" or driver == "fsl_enetc" or driver == "qmi_wwan": Then created a customized version of ubuntu-22.04.2-live-server- amd64.iso and tested in our production line, and now everything works fine. Logs: cat > get_driver.py < ../../devices/pci:00/:00:15.0/usb2/2-1/2-1:1.4/net/wwan0 qmi_wwan wwan1 lrwxrwxrwx 1 root root 0 Mar 1 08:11 /sys/class/net/wwan1 -> ../../devices/pci:00/:00:15.0/usb1/1-4/1-4:1.4/net/wwan1 qmi_wwan eno1 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno1 -> ../../devices/pci:00/:00:09.0/:02:00.0/net/eno1 igb eno2 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno2 -> ../../devices/pci:00/:00:0a.0/:03:00.0/net/eno2 igb eno3 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno3 -> ../../devices/pci:00/:00:0b.0/:04:00.0/net/eno3 igb eno4 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno4 -> ../../devices/pci:00/:00:0c.0/:05:00.0/net/eno4 igb eno5 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno5 -> ../../devices/pci:00/:00:16.0/:0a:00.0/net/eno5 ixgbe eno6 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno6 -> ../../devices/pci:00/:00:16.0/:0a:00.1/net/eno6 ixgbe Please let me know if you want more info or help for testing a final solution To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/200/+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 2011291] Re: After Cloud-Init is completed, an error is reported when the sshd service is restarted.
This bug is believed to be fixed in cloud-init in version 23.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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/2011291 Title: After Cloud-Init is completed, an error is reported when the sshd service is restarted. Status in cloud-init: Fix Released Bug description: I tested this issue on multiple versions, I found that cloud-init 21.4 is ok, cloud-init 22.2 and 23.1 is not ok. The following error information is displayed for the sshd service: Mar 11 17:17:53 openEuler sshd[2232]: @@@ Mar 11 17:17:53 openEuler sshd[2232]: @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ Mar 11 17:17:53 openEuler sshd[2232]: @@@ Mar 11 17:17:53 openEuler sshd[2232]: Permissions 0640 for '/etc/ssh/ssh_host_rsa_key' are too open. Mar 11 17:17:53 openEuler sshd[2232]: It is required that your private key files are NOT accessible by others. Mar 11 17:17:53 openEuler sshd[2232]: This private key will be ignored. Mar 11 17:17:53 openEuler sshd[2232]: Unable to load host key "/etc/ssh/ssh_host_rsa_key": bad permissions Mar 11 17:17:53 openEuler sshd[2232]: Unable to load host key: /etc/ssh/ssh_host_rsa_key Mar 11 17:17:53 openEuler sshd[2232]: @@@ Mar 11 17:17:53 openEuler sshd[2232]: @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ Mar 11 17:17:53 openEuler sshd[2232]: @@@ Mar 11 17:17:53 openEuler sshd[2232]: Permissions 0640 for '/etc/ssh/ssh_host_ed25519_key' are too open. Mar 11 17:17:53 openEuler sshd[2232]: It is required that your private key files are NOT accessible by others. Mar 11 17:17:53 openEuler sshd[2232]: This private key will be ignored. Mar 11 17:17:53 openEuler sshd[2232]: Unable to load host key "/etc/ssh/ssh_host_ed25519_key": bad permissions Mar 11 17:17:53 openEuler sshd[2232]: Unable to load host key: /etc/ssh/ssh_host_ed25519_key Mar 11 17:17:53 openEuler sshd[2232]: sshd: no hostkeys available -- exiting. At the same time, I found that the key file permission generated by the sshd service is 0o400, But the file permission generated by cloud- init cc_ssh is 0o644 (publibc key) and 0o640 (private key). Should cloud-init be consistent with sshd? [root@openEuler ~]# cd /etc/ssh/ [root@openEuler ssh]# ll ssh_host_* -r. 1 root ssh_keys480 Mar 11 15:57 ssh_host_ecdsa_key -r. 1 root root162 Mar 11 15:57 ssh_host_ecdsa_key.pub -r. 1 root ssh_keys387 Mar 11 15:57 ssh_host_ed25519_key -r. 1 root root 82 Mar 11 15:57 ssh_host_ed25519_key.pub -r. 1 root ssh_keys 2578 Mar 11 15:57 ssh_host_rsa_key -r. 1 root root554 Mar 11 15:57 ssh_host_rsa_key.pub After Cloud-Init is completed： [root@openEuler ssh]# ll ssh_host_* -rw-r-. 1 root ssh_keys 1381 Mar 11 17:17 ssh_host_dsa_key -rw-r--r--. 1 root root 604 Mar 11 17:17 ssh_host_dsa_key.pub -rw-r-. 1 root ssh_keys 505 Mar 11 17:17 ssh_host_ecdsa_key -rw-r--r--. 1 root root 176 Mar 11 17:17 ssh_host_ecdsa_key.pub -rw-r-. 1 root ssh_keys 411 Mar 11 17:17 ssh_host_ed25519_key -rw-r--r--. 1 root root 96 Mar 11 17:17 ssh_host_ed25519_key.pub -rw-r-. 1 root ssh_keys 2602 Mar 11 17:17 ssh_host_rsa_key -rw-r--r--. 1 root root 568 Mar 11 17:17 ssh_host_rsa_key.pub To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2011291/+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 2016350] Re: Growpart fails on FreeBSD with MBR/Slices
This bug is believed to be fixed in cloud-init in version 23.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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/2016350 Title: Growpart fails on FreeBSD with MBR/Slices Status in cloud-init: Fix Released Bug description: A VM with slices and/or MBR will have a slice named /dev/da0s1a and makes growpart fail on its partition detection; Traceback (most recent call last): File "/usr/local/lib/python3.9/site-packages/cloudinit/config/modules.py", line 246, in _run_modules ran, _r = cc.run( File "/usr/local/lib/python3.9/site-packages/cloudinit/cloud.py", line 67, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/local/lib/python3.9/site-packages/cloudinit/helpers.py", line 185, in run results = functor(*args) File "/usr/local/lib/python3.9/site-packages/cloudinit/config/cc_growpart.py", line 613, in handle resized = util.log_time( File "/usr/local/lib/python3.9/site-packages/cloudinit/util.py", line 2721, in log_time ret = func(*args, **kwargs) File "/usr/local/lib/python3.9/site-packages/cloudinit/config/cc_growpart.py", line 526, in resize_devices (disk, ptnum) = device_part_info(blockdev) File "/usr/local/lib/python3.9/site-packages/cloudinit/config/cc_growpart.py", line 273, in device_part_info return (m.group(1), m.group(2)) AttributeError: 'NoneType' object has no attribute 'group' It seems the regex needs to be modified to support MBR disks, if we want to support them. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2016350/+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 1917626] Re: Publish jsonschema with documention
Sorry for delay here, this is fix released and published to schema- store.org as of this upstream commit https://github.com/canonical/cloud- init/commit/53e1ccf83ca737f80f98300cf00d5c026bd9464d ** Changed in: cloud-init Status: In Progress => 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/1917626 Title: Publish jsonschema with documention Status in cloud-init: Fix Released Bug description: Hey there, I saw that you folks already use jsonschema so I would like to propose to publish together with the docs so IDEs can validate cloudinit files without calling an external service or code. This is really helpful when you are writing cloud-init files because your schemas are quite rich and have good documentation in them. I thought of using already existing tox doc to do it but it won't have the dependencies necessary to dump the schemas, do you suggest something there? To make it work locally, I just generated the schema offline with the following command: python -c 'import json; from cloudinit.config.schema import get_schema; print(json.dumps(get_schema(), indent=4))' But if that was online it could be added to https://www.schemastore.org/ which seems to be a central location for a bunch of schemas. Thank you in advance! To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1917626/+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 2008952] Re: DNS failure while trying to fetch user-data
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 Yahoo! Engineering Team, which is subscribed to cloud-init. 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/~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 2015949] [NEW] Ubuntu: cloud-init.service order After=NetworkManager.service not possible with Before=sysinit.target
Public bug reported: In Ubuntu packaging of systemd cloud-init.service file, cloud- init.service declares ordering as After=systemd-networkd-wait- online.target[1] and Before=sysinit.target[2]. The desktop live installer ISO prefers using NetworkManager as the primary network backend and cloud-init must order After=NetworkManager.service in these cases to avoid DNS-related bugs during datasource discovery and downloading user-data such as LP: #2008952. Short-term fix is to provide an override for cloud-init.service in the livecd-rootfs project[3] Long-term need is to provide a mechanism at systemd-generator timeframe to order cloud-init.service After=NetworkManager.service. Since NetworkManager.service is After=sysinit.target due to After=dbus.service ordering, cloud-init.service would have to drop it's Before=sysinit.target declarations in order to avoid systemd ordering cycles. [1] https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init.service.tmpl#L11 [2] https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init.service.tmpl#L33 [3] livecd-rootfs cloud-init.service overrides https://code.launchpad.net/~chad.smith/livecd-rootfs/+git/livecd-rootfs/+merge/439586 ** Affects: cloud-init Importance: Medium Status: New ** Changed in: cloud-init Importance: Undecided => Medium -- 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/2015949 Title: Ubuntu: cloud-init.service order After=NetworkManager.service not possible with Before=sysinit.target Status in cloud-init: New Bug description: In Ubuntu packaging of systemd cloud-init.service file, cloud- init.service declares ordering as After=systemd-networkd-wait- online.target[1] and Before=sysinit.target[2]. The desktop live installer ISO prefers using NetworkManager as the primary network backend and cloud-init must order After=NetworkManager.service in these cases to avoid DNS-related bugs during datasource discovery and downloading user-data such as LP: #2008952. Short-term fix is to provide an override for cloud-init.service in the livecd-rootfs project[3] Long-term need is to provide a mechanism at systemd-generator timeframe to order cloud-init.service After=NetworkManager.service. Since NetworkManager.service is After=sysinit.target due to After=dbus.service ordering, cloud-init.service would have to drop it's Before=sysinit.target declarations in order to avoid systemd ordering cycles. [1] https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init.service.tmpl#L11 [2] https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init.service.tmpl#L33 [3] livecd-rootfs cloud-init.service overrides https://code.launchpad.net/~chad.smith/livecd-rootfs/+git/livecd-rootfs/+merge/439586 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2015949/+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 2015605] Re: desktop live installer: cloud-init/ubuntu-desktop-installer network config naming collisions
Marking invalid for cloud-init as this cloud-init task was added during triage to inform the project of external config changes in place in livecd-rootfs related to cloud-init behavior on Desktop live installer images. ** Changed in: cloud-init Status: New => 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/2015605 Title: desktop live installer: cloud-init/ubuntu-desktop-installer network config naming collisions Status in cloud-init: Invalid Status in livecd-rootfs package in Ubuntu: Fix Released Bug description: Seen on live desktop isos build date: $ cat /cdrom/.disk/info Ubuntu 23.04 "Lunar Lobster" - Dail amd64 (20230407) $ snap list ubuntu-desktop-installer Name Version Rev Tracking Publisher Notes ubuntu-desktop-installer 0+git.f46d534e 922 latest/stable/… canonical✓ classic Desktop live installer prefers NetworkManager backend for network config due to a netplan config file /etc/netplan/01-network-manager.yaml which contains: network: version: 2 renderer: NetworkManager livecd-rootfs configures cloud-init to write directly to /etc/NetworkManager/system-connections when discovering network due to a config snippet at /etc/cloud/cloud.cfg.d/99-installer-use-networkmanager.cfg which sets cloud-init to write directly to /etc/NetworkManager/system-connections with this config: # Automatically generated by installer build process system_info: network: renderers: ['network-manager'] activators: ['network-manager'] - This tells cloud-init to write out /etc/NetworkManager/system-connections/cloud-init-enp1s0.nmconnection directly. Later Ubuntu-desktop-installer(subiquity) starts, it may set network config and write it to /etc/netplan/00-installer.yaml and trigger a 'netplan apply'. If there is a non-empty netplan config at this time, subiquity writes out /etc/netplan/00-installer.yaml and renames any other existing netplan yaml files to /etc/netplan/*.yaml.dist-subiquity. Then subiquity(ubuntu-desktop-installer) invokes netplan apply to render all applicable network config to the ephemeral (installer) environment. When netplan is rendering to `backend: NetworkManager` instead of the default networkd and it'll write /etc/NetworkManager/netplan-*.nmconnection files with connection names scoped under `netplan-`. Cloud-init's rendered connections are scoped under `cloudinit-`. This results in a split brain problem where cloudinit's configuration and netplan's configuration are not aware of each other and netplan isn't aware of any pre-existing /etc/NetworkManager artifacts. We then have conflicting nm connections being defined and named for the same underlying network interfaces. This results in inability to run: nmcli load /etc/NetworkManager/system-connections/cloud-init-enp1s0.nmconnection with errors such as "unknown connection" or "ipv4.gateway: gateway cannot be set if there are no addresses configured" Ideally we probably want both cloud-init and subiquity to be configuring network in netplan config files so that any merged network config is well known by netplan and results in a single source of truth for network config. This may mean dropping the overrides provided by livecd-roots setting cloud-init to render directly to network-manager. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2015605/+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 2015605] [NEW] desktop live installer: cloud-init/ubuntu-desktop-installer network config naming collisions
Public bug reported: Seen on live desktop isos build date: Desktop live installer prefers NetworkManager backend for network config due to a netplan config file /etc/netplan/01-network-manager.yaml which contains: network: version: 2 renderer: NetworkManager livecd-rootfs configures cloud-init to write directly to /etc/NetworkManager/system-connections when discovering network due to a config snippet at /etc/cloud/cloud.cfg.d/99-installer-use-networkmanager.cfg which sets cloud-init to write directly to /etc/NetworkManager/system-connections with this config: # Automatically generated by installer build process system_info: network: renderers: ['network-manager'] activators: ['network-manager'] - This tells cloud-init to write out /etc/NetworkManager/system-connections/cloud-init-enp1s0.nmconnection directly. Later Ubuntu-desktop-installer(subiquity) starts, it may set network config and write it to /etc/netplan/00-installer.yaml and trigger a 'netplan apply'. If there is a non-empty netplan config at this time, subiquity writes out /etc/netplan/00-installer.yaml and renames any other existing netplan yaml files to /etc/netplan/*.yaml.dist-subiquity. Then subiquity(ubuntu-desktop-installer) invokes netplan apply to render all applicable network config to the ephemeral (installer) environment. When netplan is rendering to `backend: NetworkManager` instead of the default networkd and it'll write /etc/NetworkManager/netplan-*.nmconnection files with connection names scoped under `netplan-`. Cloud-init's rendered connections are scoped under `cloudinit-`. This results in a split brain problem where cloudinit's configuration and netplan's configuration are not aware of each other and netplan isn't aware of any pre-existing /etc/NetworkManager artifacts. We then have conflicting nm connections being defined and named for the same underlying network interfaces. This results in inability to run: nmcli load /etc/NetworkManager/system- connections/cloud-init-enp1s0.nmconnection with errors such as "unknown connection" or "ipv4.gateway: gateway cannot be set if there are no addresses configured" Ideally we probably want both cloud-init and subiquity to be configuring network in netplan config files so that any merged network config is well known by netplan and results in a single source of truth for network config. This may mean dropping the overrides provided by livecd-roots setting cloud-init to render directly to network-manager. ** Affects: cloud-init Importance: Undecided Status: New ** Affects: livecd-rootfs (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/2015605 Title: desktop live installer: cloud-init/ubuntu-desktop-installer network config naming collisions Status in cloud-init: New Status in livecd-rootfs package in Ubuntu: New Bug description: Seen on live desktop isos build date: Desktop live installer prefers NetworkManager backend for network config due to a netplan config file /etc/netplan/01-network-manager.yaml which contains: network: version: 2 renderer: NetworkManager livecd-rootfs configures cloud-init to write directly to /etc/NetworkManager/system-connections when discovering network due to a config snippet at /etc/cloud/cloud.cfg.d/99-installer-use-networkmanager.cfg which sets cloud-init to write directly to /etc/NetworkManager/system-connections with this config: # Automatically generated by installer build process system_info: network: renderers: ['network-manager'] activators: ['network-manager'] - This tells cloud-init to write out /etc/NetworkManager/system-connections/cloud-init-enp1s0.nmconnection directly. Later Ubuntu-desktop-installer(subiquity) starts, it may set network config and write it to /etc/netplan/00-installer.yaml and trigger a 'netplan apply'. If there is a non-empty netplan config at this time, subiquity writes out /etc/netplan/00-installer.yaml and renames any other existing netplan yaml files to /etc/netplan/*.yaml.dist-subiquity. Then subiquity(ubuntu-desktop-installer) invokes netplan apply to render all applicable network config to the ephemeral (installer) environment. When netplan is rendering to `backend: NetworkManager` instead of the default networkd and it'll write /etc/NetworkManager/netplan-*.nmconnection files with connection names scoped under `netplan-`. Cloud-init's rendered connections are scoped under `cloudinit-`. This results in a split brain problem where cloudinit's configuration and netplan's configuration are not aware of each other and netplan isn't aware of any pre-existing /etc/NetworkManager artifacts. We then have conflicting nm connections being defined and named for the same underlying network
[Yahoo-eng-team] [Bug 2012377] Re: Launchpad branding (logo) out of date
Thanks for noting this inconsistency, I've updated branding logo now to align w/ RTD ** Changed in: cloud-init 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/2012377 Title: Launchpad branding (logo) out of date Status in cloud-init: Fix Released Bug description: Compare current logo on Launchpad: https://launchpadlibrarian.net/139952952/logo-64x64.png with the one on cloud-init readthedocs - https://cloudinit.readthedocs.io/en/latest/_static/logo-dark-mode.png To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2012377/+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 2009746] [NEW] dpkg-reconfigure cloud-init: yaml.load errors during MAAS deloyment of Ubuntu 23.04(Lunar)
Public bug reported: Affects cloud-init 23.1.1 Lunar MAAS deployed Ubuntu 23.04 (Lunar) machines invoke `dpkg-reconfigure cloud-init` which results in an exit 1 with the following traceback as seen in curtin logs: Running command ['unshare', '--fork', '--pid', '--', 'chroot', '/tmp/tmpwr8y_4f8/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/tmpwr8y_4f8/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' Ubuntu 23.04 Lunar has published PyYAML 6.0.1[1] which finally changed the signature on yaml.load to require a Loader= parameter. This traceback is due to a stale call to yaml.load() in cloud-init.postinst[2] that should have migrated to yaml.safe_load. In Jammy and and earlier, PyYAML was still emitting deprecation warning messages to stderr, but those warnings are silenced automatically by any invocation to `dpkg-reconfigure --frontend=noninteractive cloud-init`. So none of the warnings showed up in curtin or MAAS, until we got an explicit non-zero exit code. References: [1] Pyyaml 6.0.1 commit sync'd to lunar https://git.launchpad.net/ubuntu/+source/pyyaml/commit/?id=5308dbefbe5dc7ce4a19adbfdb4c4e08a798217d [2] yaml.load failure on Lunar: https://github.com/canonical/cloud-init/blob/ubuntu/devel/debian/cloud-init.postinst#L41 ** Affects: cloud-init Importance: High Assignee: Chad Smith (chad.smith) Status: Triaged ** Affects: maas (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init Importance: Undecided => High ** Changed in: cloud-init Status: New => Triaged ** Changed in: cloud-init Assignee: (unassigned) => Chad Smith (chad.smith) ** Also affects: maas (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/2009746 Title: dpkg-reconfigure cloud-init: yaml.load errors during MAAS deloyment of Ubuntu 23.04(Lunar) Status in cloud-init: Triaged Status in maas package in Ubuntu: New Bug description: Affects cloud-init 23.1.1 Lunar MAAS deployed Ubuntu 23.04 (Lunar) machines invoke `dpkg-reconfigure cloud-init` which results in an exit 1 with the following traceback as seen in curtin logs: Running command ['unshare', '--fork', '--pid', '--', 'chroot', '/tmp/tmpwr8y_4f8/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 "
[Yahoo-eng-team] [Bug 2008952] Re: DNS failure while trying to fetch user-data
journalctl on a failed laptop is showwing a lot of throttling logs from NetworkManager such as : stat change: unavilable -> disconnected (reason 'carrier changed', sys-iface-state: 'managed') This makes be believe that networkd and NetworkManager are attempting to grab management of the NIC multiple times throughout boot thereby rendering the network and carrier down. I see cloud-init reflecting the 'down' carrier state of en0s31f6 in the 'init' timeframe too by Cloud-init v. 23.1.1-0ubuntu1 running 'init' at Tue, 07 Mar 2023 03:17:56 +. Up 62.47 seconds. ci-info: +Net device info+ ci-info: +---+---+---+---+---+---+ ci-info: | Device | Up | Address |Mask | Scope | Hw-Address | ci-info: +---+---+---+---+---+---+ ci-info: | enp0s31f6 | False | . | . | . | 6c:24:08:9e:54:e6 | ci-info: | lo| True | 127.0.0.1 | 255.0.0.0 | host | . | ci-info: | lo| True | ::1/128 | . | host | . | ci-info: | wlp0s20f3 | False | . | . | . | 38:7a:0e:2d:d0:bb | ci-info: +---+---+---+---+---+---+ 2. The second interesting configuration 'error' to be aware of is that netplan doesn't like the 644 permissions on the rendered /etc/netplan/01-network-manager-all.yaml. ** (process:2015): WARNING **: 03:18:08.594: Permissions for /etc/netplan/01-network-manager-all.yaml are too open. Netplan configuration should NOT be accessible by others. Full log paste: https://dpaste.com/APGZH46PN ** Also affects: subiquity 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/2008952 Title: DNS failure while trying to fetch user-data Status in cloud-init: Triaged Status in subiquity: 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/~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 2008727] Re: [Lunar/Desktop] 5 min boot delay on bare metal due cloud-init-local.service
Upstream commit landed to avoid this automatically suggesting that OpenStack datasource may be applicable by default on Bare metal. This is probably not the majority of cases for bare metal openstack detection for bare metal should only be active if it is explicitly set by either kernel cmdline by providing ci.ds=OpenStack parameter or in the image itself with a file in /etc/cloud/cloud.cfg.d/90-somename.cfg containing a explicitly: datasource_list: [OpenStack]. Related upstream commit. https://github.com/canonical/cloud-init/commit/d1ffbea556a06105d1ade88b4143ad43f53692c4 This is released to Lunar now as 23.1.1 and will make it back to Bionic, Focal, Jammy, Kinetic in our next SRU in a week or two. ** Summary changed: - [Lunar/Desktop] 5 min boot delay due cloud-init-local.service + [Lunar/Desktop] 5 min boot delay on bare metal due cloud-init-local.service ** Changed in: cloud-init 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/2008727 Title: [Lunar/Desktop] 5 min boot delay on bare metal due cloud-init- local.service Status in cloud-init: Fix Released Bug description: I run lunar for a while now (upgraded from Jammy through `do-release-upgrade -d`) and since I do some Subiquity development often, I do have cloud-init setup, for a while as well. Friday 24th, after a regular `apt update && apt upgrade` my laptop boot time increased by surprising 5 min, at a first glance it appears to be due cloud-init-local.service waiting for network activity in the Ethernet port, which I rarely use. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2008727/+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 2007400] Re: eatmydata enabled by default results in apt packages not correctly installed
Marking invalid as it seems this is unrelated to cloud-init. Please re- open if this surfaces again. ** Changed in: cloud-init Status: Triaged => 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/2007400 Title: eatmydata enabled by default results in apt packages not correctly installed Status in cloud-init: Invalid Bug description: I'm using LXD 5.0 (LTS) on Ubuntu 22.04 to launch containers and virtual machines. I am using cloud-init in LXD's user.user-data field to install some apt packages when the container or VM is launched. For example, I have the following cloud-config section: package_update: true packages: - openssh-server The server is launched as follows: lxc launch images:ubuntu/jammy/desktop myhostname --vm However, when the server is launched, the apt package is listed as successfully installed, but there are no files associated with it: util.py[DEBUG]: apt-install [eatmydata apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install openssh-server ... took 25.031 seconds handlers.py[DEBUG]: finish: modules-final/config-package-update-upgrade-install: SUCCESS: config-package-update-upgrade-install ran successfully Yet "dpkg -L openssh-server" shows: Package 'openssh-server' does not contain any files (!) This results in an unusable system. I don't know what "eatmydata" is or why it is enabled by default, but does indeed appear to be eating this data and resulting in an unusable server. It looks like there's a sparsely documented option called apt_get_wrapper which seems to let you disable "eatmydata": https://cloudinit.readthedocs.io/en/18.5/topics/examples.html?highlight=eatmydata#additional-apt-configuration I configured this to disable "eatmydata" and sure enough, I am now able to successfully create a virtual machine. Is it possible to better document the use of eatmydata in cloud-init, and moreover maybe consider disabling it by default so you have to opt-in to get the performance benefits it provide (while accepting the risk of possible data corruption)? Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2007400/+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 2006052] Re: cloud init prefixes password hash with exclamation mark
Hiya windowsguy, One thing we hope to see here with your attached tar/zipped logs from `cloud-init collect-logs` is whether cloud-init is actually making a call to passwd -l or usermod --lock in logs. I'll mark this bug as 'Incomplete' status. Please set it back to 'New' when you have had a change to attach the full cloud-init.log (or tgz from cloud-init collect-logs). NOTE: when using cloud-init collect-logs it'll capture your user-data in /run/cloud-init/instance-data-sensitive.json which does contain your password in this case, so make sure you redact any specific password or hash listed if attaching that tarfile. ** Changed in: cloud-init Status: Invalid => Incomplete -- 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/2006052 Title: cloud init prefixes password hash with exclamation mark Status in cloud-init: Incomplete Bug description: Host OS is Ubuntu 22.04 LTS. Guest info: - Ubuntu 22.04 LTS KVM guest: https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64-disk-kvm.img (also tried with https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-disk-kvm.img) - cloud-init package: 22.4.2-0ubuntu0~22.04.1 I use this to configure password for the Ubuntu user: users: - name: ubuntu gecos: Ubuntu User sudo: ALL=(ALL) NOPASSWD:ALL shell: /bin/bash groups: sudo lock_passwd: false # mkpasswd --method=SHA-512 --rounds=4096 -S "1234asdf" passwd: $6$rounds=4096$1234asdf$3Ym7weobJp/ORkJML66e54IyCEOGKM8C1zfQj4NRngDgJJGdEJn3O9rocWy0uVc84PbEvSnzji3a54X5FOb230 While provisioning is still running, I can log in as root (configured separately) and observe the hash in /etc/shadow is identical to this (as expected). Also 'ubuntu' can login. After provisioning is complete and the VM reboots, I cannot login as 'ubuntu'. I log in as root and find that now a '!' was prefixed to password hash in /etc/shadow: ubuntu:!$6$rounds=4096$1 If I remove that '!', I can login as the ubuntu user. I tried surrounding the password with single and double quotes, no difference. Initially it's provisioned correctly, so it's something that injects that '!' after that. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2006052/+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 1997124] Re: Netplan/Systemd/Cloud-init/Dbus Race
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 Yahoo! Engineering Team, which is subscribed to cloud-init. 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/~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 2001737] Re: Jammy's cloud-init doesn't work on lxd 4.0
work in progress pull request which will resolve this problem. Needs unit tests and then cloud-init can support jammy launches from LXD 4.0 hosts. https://github.com/canonical/cloud-init/pull/1948 ** Changed in: cloud-init Status: Triaged => Won't Fix ** Changed in: cloud-init Status: Won't Fix => In Progress -- 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/2001737 Title: Jammy's cloud-init doesn't work on lxd 4.0 Status in cloud-init: In Progress Bug description: When trying to boot a Jammy container on a host that uses lxd/4.0 the cloud-init there fails to work properly. The result is, that a ssh key for authentication isn't inserted in the host, denying ssh access. Upgrading to lxd/5.0 does works around this issue, which provides a newer interface, but isn't a solution as lxd/4.0 is an LTS of only a few years old. For a complete log see: https://pastebin.canonical.com/p/X9GN5GH8wv/ To reproduce, install the lxd 4.0/stable snap on a machine, configure it to inject a ssh key, and try to launch an jammy container there. One won't be able to ssh into the container. An extensive thread about this can be found at: https://chat.canonical.com/canonical/pl/c1erobjybt8jzbgxguowxrddrc To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2001737/+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 1998998] [NEW] azure: /run/cloud-init/cloud-id broken symlink across reboot.
Public bug reported:
cloud-init 22.4.2
On Azure, datasource details change across reboot cloud-init incorrectly
removes /run/cloud-init/cloud-id-azure symlink.
2022-12-07 04:14:17,920 - util.py[DEBUG]: Creating symbolic link from
'/run/cloud-init/cloud-id' => '/run/cloud-init/cloud-id-azure'
2022-12-07 04:14:17,920 - util.py[DEBUG]: Attempting to remove
/run/cloud-init/cloud-id-azure
# FRESH LAUNCH
ubuntu@test-focal:~$ ls -l /run/cloud-init/cloud-id
lrwxrwxrwx 1 root root 30 Dec 7 04:10 /run/cloud-init/cloud-id ->
/run/cloud-init/cloud-id-azure
ubuntu@test-focal:~$ grep cloud-id /var/log/cloud-init.log
2022-12-07 04:10:34,734 - util.py[DEBUG]: Writing to
/run/cloud-init/cloud-id-azure - wb: [644] 6 bytes
2022-12-07 04:10:34,735 - util.py[DEBUG]: Creating symbolic link from
'/run/cloud-init/cloud-id' => '/run/cloud-init/cloud-id-azure'
# ACROSS REBOOT
ubuntu@test-focal:~$ ls -l /run/cloud-init/cloud-id
lrwxrwxrwx 1 root root 30 Dec 7 04:14 /run/cloud-init/cloud-id ->
/run/cloud-init/cloud-id-azure
2022-12-07 04:14:17,920 - util.py[DEBUG]: Writing to
/run/cloud-init/cloud-id-azure - wb: [644] 6 bytes
2022-12-07 04:14:17,920 - util.py[DEBUG]: Creating symbolic link from
'/run/cloud-init/cloud-id' => '/run/cloud-init/cloud-id-azure'
2022-12-07 04:14:17,920 - util.py[DEBUG]: Attempting to remove
/run/cloud-init/cloud-id-azure
It looks like the symlink cleanup logic introduced in
https://github.com/canonical/cloud-
init/commit/217ef6ba6c52788f4363b998b6da08863fea5cd9 (which was
released in cloud-init v. 21.4) doesn't do a proper comparison of
previous-datasource to current datasource
Debug logs added to
https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/__init__.py#L443
shows that we are comparing the incorrect source file
/root/cloud-init/cloud-id versus actually comparing the cloud-specific symlink
name /run/cloud-init/cloud-id-, resulting in a removal of the
cloud-specific link name across reboot.
2022-12-07 04:25:58,162 - __init__.py[WARNING]: previous_cloud_id_file
/run/cloud-init/cloud-id-azure != cloud_id_file /run/cloud-init/cloud-id
Likely all we need is a correction in logic like the following:
diff --git a/cloudinit/sources/__init__.py b/cloudinit/sources/__init__.py
index 85e094ac5..3fb08ead2 100644
--- a/cloudinit/sources/__init__.py
+++ b/cloudinit/sources/__init__.py
@@ -439,8 +439,9 @@ class DataSource(CloudInitPickleMixin,
metaclass=abc.ABCMeta):
prev_cloud_id_file = os.path.realpath(cloud_id_file)
else:
prev_cloud_id_file = cloud_id_file
-util.sym_link(f"{cloud_id_file}-{cloud_id}", cloud_id_file, force=True)
-if prev_cloud_id_file != cloud_id_file:
+new_cloud_id_file = f"{cloud_id_file}-{cloud_id}"
+util.sym_link(new_cloud_id_file, cloud_id_file, force=True)
+if prev_cloud_id_file != new_cloud_id_file:
util.del_file(prev_cloud_id_file)
write_json(json_sensitive_file, processed_data, mode=0o600)
json_file = self.paths.get_runpath("instance_data")
** Affects: cloud-init
Importance: High
Status: Triaged
** Tags: bitesize
** Changed in: cloud-init
Status: New => Triaged
** Changed in: cloud-init
Importance: Undecided => High
** Tags added: bitesize
--
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/1998998
Title:
azure: /run/cloud-init/cloud-id broken symlink across reboot.
Status in cloud-init:
Triaged
Bug description:
cloud-init 22.4.2
On Azure, datasource details change across reboot cloud-init
incorrectly removes /run/cloud-init/cloud-id-azure symlink.
2022-12-07 04:14:17,920 - util.py[DEBUG]: Creating symbolic link from
'/run/cloud-init/cloud-id' => '/run/cloud-init/cloud-id-azure'
2022-12-07 04:14:17,920 - util.py[DEBUG]: Attempting to remove
/run/cloud-init/cloud-id-azure
# FRESH LAUNCH
ubuntu@test-focal:~$ ls -l /run/cloud-init/cloud-id
lrwxrwxrwx 1 root root 30 Dec 7 04:10 /run/cloud-init/cloud-id ->
/run/cloud-init/cloud-id-azure
ubuntu@test-focal:~$ grep cloud-id /var/log/cloud-init.log
2022-12-07 04:10:34,734 - util.py[DEBUG]: Writing to
/run/cloud-init/cloud-id-azure - wb: [644] 6 bytes
2022-12-07 04:10:34,735 - util.py[DEBUG]: Creating symbolic link from
'/run/cloud-init/cloud-id' => '/run/cloud-init/cloud-id-azure'
# ACROSS REBOOT
ubuntu@test-focal:~$ ls -l /run/cloud-init/cloud-id
lrwxrwxrwx 1 root root 30 Dec 7 04:14 /run/cloud-init/cloud-id ->
/run/cloud-init/cloud-id-azure
2022-12-07 04:14:17,920 - util.py[DEBUG]: Writing to
/run/cloud-init/cloud-id-azure - wb: [644] 6 bytes
2022-12-07 04:14:17,920 - util.py[DEBUG]: Creating symbolic link from
'/run/cloud-init/cloud-id' => '/run/cloud-init/cloud-id-azure'
2022-12-07 04:14:17,920 - util.py[DEBUG]: Attempting to remove
/run/cloud-init/cloud-id-azure
It looks
[Yahoo-eng-team] [Bug 1844191] Re: azure advanced networking sometimes triggers duplicate mac detection
Upstream PR landed with a fix for this issue allowing cloud-init to ignore
duplicate macs as seen on mellanox subordinate devices.
https://github.com/canonical/cloud-init/pull/1853.
We have also released this into Ubuntu Lunar 23.04 as cloud-init version
22.4-0ubuntu4.
Our plan is also to queue this up as soon as possible for our next SRU
(Stable release update).
Marking this as Fix released as it will be in the next cloud images build for
23.04.
We will create separate bug tasks on this bug for bionic, focal, jammy and
kinetic when we start the SRU release process for this bug.
In the meantime, https://code.launchpad.net/~cloud-init-
dev/+archive/ubuntu/daily has development builds containing this fix
for those looking to validate this behavior before an official SRU
release to Bionic, Focal, jammy and Kinetic.
** Changed in: cloud-init
Status: Confirmed => 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/1844191
Title:
azure advanced networking sometimes triggers duplicate mac detection
Status in cloud-init:
Fix Released
Bug description:
Hi, we're still being affected by this on Azure with
19.2-24-ge7881d5c-0ubuntu1~18.04.1 - using PACKER to build from image:
BuildSource : Marketplace/Canonical/UbuntuServer/18.04-DAILY-LTS
Here is the packer config:
"provisioners": [
{
"type": "shell",
"inline": [
"while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo
'Waiting for cloud-init...'; sleep 1; done"
]
},
{
"type": "ansible",
"playbook_file": "{{user `ansible_playbook`}}",
"user": "packer",
"extra_arguments": [ "--extra-vars", "codeVersion={{user
`code_version`}} managed_image_name={{user `managed_image_name`}}" ]
},
{
"type": "shell",
"execute_command": "chmod +x {{ .Path }}; {{ .Vars }} sudo -E sh
'{{ .Path }}'",
"inline_shebang": "/bin/sh -x",
"inline": [ "/usr/sbin/waagent -force -deprovision+user && export
HISTSIZE=0 && sync" ]
}]
Here is the playbook:
---
- hosts: all
remote_user: ubuntu
become: yes
become_method: sudo
become_user: root
environment:
DEBIAN_FRONTEND: noninteractive
Note: we are applying `enableAcceleratedNetworking: true` to the NIC,
anecdotally we think this is related.
Usually our playbook has more in it (obviously) but Azure kept
pointing fingers at us that our image was causing the problem, so I
ran this test simply deploying a blank deprovisioned image via our
same process.
And here's what happens on the serial console log:
[ 20.337603] sh[910]: + [ -e /var/lib/cloud/instance/obj.pkl ]
[ 20.343177] sh[910]: + echo cleaning persistent cloud-init object
[ 20.349027] [ OK ] Started Network Time Synchronization.
[ OK ] Reached target System Time Synchronized.
sh[910]: cleaning persistent cloud-init object
[ 20.361066] sh[910]: + rm /var/lib/cloud/instance/obj.pkl
[ 20.412333] sh[910]: + exit 0
[ 34.282291] cloud-init[938]: Cloud-init v.
19.2-24-ge7881d5c-0ubuntu1~18.04.1 running 'init-local' at Mon, 16 Sep 2019
18:02:23 +. Up 32.02 seconds.
[ 34.288809] cloud-init[938]: 2019-09-16 18:02:25,262 - util.py[WARNING]:
failed stage init-local
[ 34.423057] cloud-init[938]: failed run of stage init-local
[ 34.437716] cloud-init[938]:
[ 34.441088] cloud-init[938]: Traceback (most recent call last):
[ 34.443719] cloud-init[938]: File
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 653, in
status_wrapper
[ 34.448072] cloud-init[938]: ret = functor(name, args)
[ 34.450532] cloud-init[938]: File
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 362, in main_init
[ 34.454849] cloud-init[938]:
init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
[ 34.458725] cloud-init[938]: File
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 697, in
apply_network_config
[ 34.463421] cloud-init[938]: net.wait_for_physdevs(netcfg)
[ 34.466051] cloud-init[938]: File
"/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 344, in
wait_for_physdevs
[ 34.470673] cloud-init[938]: present_macs =
get_interfaces_by_mac().keys()
[ 34.473964] cloud-init[938]: File
"/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 633, in
get_interfaces_by_mac
[ 34.479325] cloud-init[938]: (name, ret[mac], mac))
[ 34.481838] cloud-init[938]: RuntimeError: duplicate mac found! both
'eth0' and 'enP1s1' have mac '00:0d:3a:7c:f7:3f'
[ 34.486614] cloud-init[938]:
[Yahoo-eng-team] [Bug 1996781] Re: text/plain encoding for write_files unsupported?
Marking this as Fix released as I think it should already be in official 22.2 releases. If it still persists in 22.2 or later please feel free to reopen the bug. ** Changed in: cloud-init 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/1996781 Title: text/plain encoding for write_files unsupported? Status in cloud-init: Fix Released Bug description: OpenStack RockyLinux 8 instance failed to boot properly. Console log showed: ``` [ 103.927922] cloud-init[852]: Cloud-init v. 22.1-5.el8 running 'init' at Wed, 16 Nov 2022 14:45:47 +. Up 103.64 seconds. [ 103.974747] cloud-init[852]: 2022-11-16 14:45:47,803 - schema.py[WARNING]: Invalid cloud-config provided: [ 103.978215] cloud-init[852]: write_files.0.encoding: 'text/plain' is not one of ['gz', 'gzip', 'gz+base64', 'gzip+base64', 'gz+b64', 'gzip+b64', 'b64', 'base64'] [ 103.982366] cloud-init[852]: write_files.0.encoding: 'text/plain' is not one of ['gz', 'gzip', 'gz+base64', 'gzip+base64', 'gz+b64', 'gzip+b64', 'b64', 'base64'] ``` But the [docs](https://cloudinit.readthedocs.io/en/22.1_a/topics/modules.html#write- files) for this version so that text/plain IS an accepted encoding. This worked before the release of RockyLinux 8.7 so I'm assuming this is a newer version of cloud-init and there's a regression? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1996781/+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 1993503] Re: grub_dpkg writes wrong device into debconf
Thanks for the detailed discussions here @danielky. I think I agree with your last statement in comment #3 > Detecting the raid-setup and the right disks might be out of scope for > cc_grub_dpkg, so why not just skip setting the "grub-pc/install_devices" item > if it is already set in debconf and there is no "grub-pc/install_devices" > given in cc_grub_dpkg config? In the case of the live installer, subiquity (via curtin) ends up setting grub debconf selections. I do think cloud-init's cc_grub_dpkg::fetcg_idevs function[1] could probably grow awareness of debconf selections as that should be honored with precedence above local discovery using grub probe. I'll set this to triaged and confirm with the team tomorrow that this is a reasonable approach/consensus for cloud-init. As for the subiquity aspect of this bug, I agree is seems like providing either: grub_dpkg: enabled: false -- or -- # reflecting the specific devices that were chosen during auto install would make the most sense to ensure the system boots properly configured and cloud-init does not overwrite values setup by the installer (via curtin) grub_dpkg: grub-pc/install_devices: ** Changed in: cloud-init Status: Invalid => Triaged ** Changed in: cloud-init Importance: Undecided => Medium -- 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/1993503 Title: grub_dpkg writes wrong device into debconf Status in cloud-init: Triaged Status in subiquity: New Bug description: After auto-installing ubuntu 22.04 onto a LV on a mdraid 1 with two disks cc_grub_dpkg overrides the correct `grub-pc/install_devices` debconf entry with a false one on first boot: ``` ~# debconf-show grub-pc | grep grub-pc/install_devices: * grub-pc/install_devices: /dev/disk/by-id/dm-name-vg0-lv_root ``` This breaks grub updates. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1993503/+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 1488891] Re: WALinuxAgentShim fails to handle escaped characters in dhclient.eth0.leases
This was fixed as of 0.7.6-444-g41900b72f ** Changed in: cloud-init Status: In Progress => 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/1488891 Title: WALinuxAgentShim fails to handle escaped characters in dhclient.eth0.leases Status in cloud-init: Fix Released Bug description: For example, a line of option unknown-245 "dH\"l"; in dhclient.eth0.leases should yield an IP address of 100.72.34.108 but instead causes an exception: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py", line 249, in get_data fabric_data = metadata_func() File "/usr/lib/python3/dist-packages/cloudinit/sources/helpers/azure.py", line 289, in get_metadata_from_fabric shim = WALinuxAgentShim() File "/usr/lib/python3/dist-packages/cloudinit/sources/helpers/azure.py", line 210, in __init__ self.endpoint = self.find_endpoint() File "/usr/lib/python3/dist-packages/cloudinit/sources/helpers/azure.py", line 237, in find_endpoint endpoint_ip_address = socket.inet_ntoa(value) OSError: packed IP wrong length for inet_ntoa To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1488891/+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 1992711] [NEW] cloud-init reporting does not report boot stage start; finish events for init-local, init-network, modules-config, modules-final
Public bug reported:
cloud-init 22.3 reporting configuration doesn't report paired
start/finish event_types for all of cloud-init's boot stages.
Expected behavior:
cloud-init boot stages (init-local, init-network, config-modules and
config-final) to emit both event_type start and finish to represent entry and
exit of each boot stage and result "SUCCESS" or "FAILURE".
Results seen:
Only intermittently see init-network finish events, otherwise strictly event
children within the named scope of init-local/*, init-network/*,
modules-config/* and modules-final/* publish both start and finish events.
# desired init-network event only seen sometimes.
{"name": "init-network", "description": "searching for network datasources",
"event_type": "finish", "origin": "cloudinit", "timestamp": 1665613954.3995728,
"result": "SUCCESS"}
Test Procedure:
# terminal 1 on LXC host setup simple http server to log POST
name:event_type tuples
cat > report_server.py << EOF
#!/usr/bin/env python3
from http.server import BaseHTTPRequestHandler, HTTPServer
import logging
import json
class S(BaseHTTPRequestHandler):
def _set_response(self):
self.send_response(200)
self.send_header('Content-type', 'text/plain')
self.end_headers()
def do_POST(self):
content_length = int(self.headers['Content-Length'])
post_data = self.rfile.read(content_length)
json_data = json.loads(post_data.decode('utf-8'))
msg = f"{json_data['name']}:{json_data['event_type']}"
logging.info(msg)
self._set_response()
def run(server_class=HTTPServer, handler_class=S, port=8080):
logging.basicConfig(level=logging.INFO)
server_address = ('', port)
httpd = server_class(server_address, handler_class)
logging.info('Starting httpd...\n')
try:
httpd.serve_forever()
except KeyboardInterrupt:
pass
httpd.server_close()
logging.info('Stopping httpd...\n')
if __name__ == '__main__':
from sys import argv
if len(argv) == 2:
run(port=int(argv[1]))
else:
run()
EOF
python3 report_server.py 2> /dev/null
Terminal 2
# Setup LXC container with a reporting configuration which will talk to the LXC
host
cat > 99-reporting.cfg
[Yahoo-eng-team] [Bug 1991677] [NEW] docs: better documentation of dsmode=local vs dsmode=net
Public bug reported: Per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1991261 there is confusion about the impact of dsmode=net vs local on cloud-init runtime. This is a request for improved/conspicous general datasoiurce documentation of dsmode settings and the impact to cloud-init configuration. The only current doc references we have pointing to dsmode behavior are at specific datasources: 1. https://cloudinit.readthedocs.io/en/latest/topics/datasources/opennebula.html?highlight=dsmode#datasource-configuration 2. https://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html?highlight=dsmode#keys-and-values ** 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/1991677 Title: docs: better documentation of dsmode=local vs dsmode=net Status in cloud-init: New Bug description: Per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1991261 there is confusion about the impact of dsmode=net vs local on cloud- init runtime. This is a request for improved/conspicous general datasoiurce documentation of dsmode settings and the impact to cloud-init configuration. The only current doc references we have pointing to dsmode behavior are at specific datasources: 1. https://cloudinit.readthedocs.io/en/latest/topics/datasources/opennebula.html?highlight=dsmode#datasource-configuration 2. https://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html?highlight=dsmode#keys-and-values To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1991677/+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 1991421] Re: cloud-init bug At Linode
Thanks for filing a bug against cloud-init. Please update the report with details which describe what feature you would like to see. ** Changed in: cloud-init Status: New => 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/1991421 Title: cloud-init bug At Linode Status in cloud-init: Invalid Bug description: A new feature in cloud-init identified possible datasources for this system as To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1991421/+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 1986551] Re: Current kinetic ISO images not installable on s390x
Fix released into Ubuntu Kinetic 22.10 as cloud-init version 22.3-13-g70ce6442-0ubuntu1~22.10.1 ** Changed in: cloud-init 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/1986551 Title: Current kinetic ISO images not installable on s390x Status in cloud-init: Fix Released Status in subiquity: New Status in Ubuntu on IBM z Systems: New Bug description: While wanting to install an kinetic/22.10 system on s390x for testing new and updated packages I found that the current daily ISO image for s390x is not installable - not on LPAR nor on z/VM - not interactively using subiquity, not non-interactively using autoinstall. I had the image from August 2nd and the installation ended at the console with these messages (please ignore the weird special characters): ... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mTime & Date Service Ý0m. connecting... - \ | waiting for cloud-init... - It is possible to connect to the installer over the network, which might allow the use of a more capable terminal and can offer more languages than can be rendered in the Linux console. Unfortunately this system seems to have no global IP addresses at this time. Starting Ý0;1;39mTime & Date Service Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mTime & Date Service Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mWait until snapd is fully seeded Ý0m. Starting Ý0;1;39mApply the settings specified in cloud-config Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mSubiquity, the installer for Ubuntu Server hvc0 Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mSubiquity, the ins er for Ubuntu Server t tysclp0 Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mLogin Prompts Ý0m. Stopping Ý0;1;39mOpenBSD Secure Shell server Ý0m... Ý Ý0;32m OK Ý0m¨ Stopped Ý0;1;39mOpenBSD Secure Shell server Ý0m. Starting Ý0;1;39mOpenBSD Secure Shell server Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mOpenBSD Secure Shell server Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mApply the settings specified in cloud-con ig Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mMulti-User System Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mGraphical Interface Ý0m. Starting Ý0;1;39mExecute cloud user/final scripts Ý0m... Starting Ý0;1;39mRecord Runlevel Change in UTMP Ý0m... Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mRecord Runlevel Change in UTMP Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mExecute cloud user/final scripts Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mCloud-init target Ý0m. ... Then updated to the latest ISO from today (Aug 15th), I got the same: ... Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mHolds Snappy daemon refresh Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mService for snap application lxd.activate Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39msnap.lxd.hook.conf -4b29-8a88-87b80c6b731 8.scope Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39msnap.subiquity.hoo -4a63-9355-e4654a5890c 1.scope Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mService for snap a on subiquity.subiquity -server Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mService for snap a n subiquity.subiquity- service Ý0m. Starting Ý0;1;39mTime & Date Service Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mTime & Date Service Ý0m. connecting... - \ | waiting for cloud-init... - \ It is possible to connect to the installer over the network, which might allow the use of a more capable terminal and can offer more languages than can be rendered in the Linux console. Unfortunately this system seems to have no global IP addresses at this time. ... Unfortunately I am not able to get any logs at that (very early) stage of the installation. On top I did a 22.04.1 installation on the same systems, using the same data (IP etc) which worked fine. (I kept one of the systems in that stage for now ...) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1986551/+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 1986781] Re: [Ubuntu 22.04]cloud-init failed to complete after 10 minutes of waiting was shown during Installation via iDRAC Virtual Console
Please set the bug status back to "New" when further comments have been added to make sure our team gets alerted about the updated comments so we can respond more quickly. ** Also affects: subiquity Importance: Undecided Status: New ** Changed in: subiquity Status: New => Incomplete -- 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/1986781 Title: [Ubuntu 22.04]cloud-init failed to complete after 10 minutes of waiting was shown during Installation via iDRAC Virtual Console Status in cloud-init: Incomplete Status in subiquity: Incomplete Bug description: Description: On Dell EMC PowerEdge system when Install Ubuntu 22.04 via iDRAC Virtual Console, cloud-init failed to complete after 10 minutes of waiting. Steps to Reproduce: 1. Login to iDRAC and Launch Virtual Console. 2. Connect to Virtual Media and Map ubuntu 22.04 iso file using Map CD/DVD option. 3. Try Installing Ubuntu server. 4. "cloud-init" failed to complete after 10 minutes of waiting was shown during Installation. Expected Results :- Installation should be successful. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1986781/+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 1986947] [NEW] cc_grub_dpkg: race condition on dpkg-set-selections lock
Public bug reported: Intermittent failure found during jenkins test runs: We probably want a couple quick retries if lock is held. https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_grub_dpkg.py#L155 '2022-08-18 06:54:21,464 - handlers.py[DEBUG]: start: ' 'modules-config/config-grub-dpkg: running config-grub-dpkg with frequency ' 'once-per-instance\n' '2022-08-18 06:54:21,464 - util.py[DEBUG]: Writing to ' '/var/lib/cloud/instances/32493477-976f-924a-b363-1ddcabc724d9/sem/config_grub_dpkg ' '- wb: [644] 25 bytes\n' '2022-08-18 06:54:21,464 - helpers.py[DEBUG]: Running config-grub-dpkg using ' 'lock ()\n" "2022-08-18 06:54:21,464 - subp.py[DEBUG]: Running command ['grub-probe', " "'-t', 'disk', '/boot'] with allowed return codes [0] (shell=False, " 'capture=True)\n' "2022-08-18 06:54:21,710 - subp.py[DEBUG]: Running command ['udevadm', " "'info', '--root', '--query=symlink', '/dev/sda'] with allowed return codes " '[0] (shell=False, capture=True)\n' '2022-08-18 06:54:21,713 - cc_grub_dpkg.py[DEBUG]: considering these device ' 'symlinks: ' '/dev/disk/azure/root,/dev/disk/by-id/scsi-36002248026fe88a16909c01e11d36751,/dev/disk/by-id/wwn-0x6002248026fe88a16909c01e11d36751,/dev/disk/by-path/acpi-VMBUS:01-scsi-0:0:0:0,/dev/disk/cloud/azure_root\n' '2022-08-18 06:54:21,714 - cc_grub_dpkg.py[DEBUG]: filtered to these ' 'disk/by-id symlinks: ' '/dev/disk/by-id/scsi-36002248026fe88a16909c01e11d36751,/dev/disk/by-id/wwn-0x6002248026fe88a16909c01e11d36751\n' '2022-08-18 06:54:21,714 - cc_grub_dpkg.py[DEBUG]: selected ' '/dev/disk/by-id/scsi-36002248026fe88a16909c01e11d36751\n' '2022-08-18 06:54:21,714 - cc_grub_dpkg.py[DEBUG]: Setting grub ' 'debconf-set-selections with ' "'/dev/disk/by-id/scsi-36002248026fe88a16909c01e11d36751','false'\n" '2022-08-18 06:54:21,714 - subp.py[DEBUG]: Running command ' "['debconf-set-selections'] with allowed return codes [0] (shell=False, " 'capture=True)\n' '2022-08-18 06:54:21,817 - util.py[WARNING]: Failed to run ' 'debconf-set-selections for grub-dpkg\n' '2022-08-18 06:54:21,823 - util.py[DEBUG]: Failed to run ' 'debconf-set-selections for grub-dpkg\n' 'Traceback (most recent call last):\n' ' File "/usr/lib/python3/dist-packages/cloudinit/config/cc_grub_dpkg.py", ' 'line 155, in handle\n' 'subp.subp(["debconf-set-selections"], dconf_sel)\n' ' File "/usr/lib/python3/dist-packages/cloudinit/subp.py", line 336, in ' 'subp\n' 'stdout=out, stderr=err, exit_code=rc, cmd=args\n' 'cloudinit.subp.ProcessExecutionError: Unexpected error while running ' 'command.\n' "Command: ['debconf-set-selections']\n" 'Exit code: 1\n' 'Reason: -\n' 'Stdout: \n' 'Stderr: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked ' 'by another process: Resource temporarily unavailable\n' ** Affects: cloud-init Importance: Medium Status: Triaged ** Tags: bitesize ** Changed in: cloud-init Importance: Undecided => Medium ** Tags added: bitesize -- 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/1986947 Title: cc_grub_dpkg: race condition on dpkg-set-selections lock Status in cloud-init: Triaged Bug description: Intermittent failure found during jenkins test runs: We probably want a couple quick retries if lock is held. https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_grub_dpkg.py#L155 '2022-08-18 06:54:21,464 - handlers.py[DEBUG]: start: ' 'modules-config/config-grub-dpkg: running config-grub-dpkg with frequency ' 'once-per-instance\n' '2022-08-18 06:54:21,464 - util.py[DEBUG]: Writing to ' '/var/lib/cloud/instances/32493477-976f-924a-b363-1ddcabc724d9/sem/config_grub_dpkg ' '- wb: [644] 25 bytes\n' '2022-08-18 06:54:21,464 - helpers.py[DEBUG]: Running config-grub-dpkg using ' 'lock ()\n" "2022-08-18 06:54:21,464 - subp.py[DEBUG]: Running command ['grub-probe', " "'-t', 'disk', '/boot'] with allowed return codes [0] (shell=False, " 'capture=True)\n' "2022-08-18 06:54:21,710 - subp.py[DEBUG]: Running command ['udevadm', " "'info', '--root', '--query=symlink', '/dev/sda'] with allowed return codes " '[0] (shell=False, capture=True)\n' '2022-08-18 06:54:21,713 - cc_grub_dpkg.py[DEBUG]: considering these device ' 'symlinks: ' '/dev/disk/azure/root,/dev/disk/by-id/scsi-36002248026fe88a16909c01e11d36751,/dev/disk/by-id/wwn-0x6002248026fe88a16909c01e11d36751,/dev/disk/by-path/acpi-VMBUS:01-scsi-0:0:0:0,/dev/disk/cloud/azure_root\n' '2022-08-18 06:54:21,714 - cc_grub_dpkg.py[DEBUG]: filtered to these ' 'disk/by-id symlinks: ' '/dev/disk/by-id/scsi-36002248026fe88a16909c01e11d36751,/dev/disk/by-id/wwn-0x6002248026fe88a16909c01e11d36751\n' '2022-08-18 06:54:21,714 - cc_grub_dpkg.py[DEBUG]: selected ' '/dev/disk/by-id/scsi-36002248026fe88a16909c01e11d36751\n' '2022-08-18 06:54:21,714 -
[Yahoo-eng-team] [Bug 1982857] [NEW] cloud-init does not provide configurable network activator priority overrides
Public bug reported: cloud-init has two interactions with network backplanes 1. to write (or render) network configuration to the approapriate config files for the network system: systemd, netplan, network-manager, ENI, freebsd, netbsd, openbsd. This is done via cloudinit.net.renderers discovery[1] 2. optionally to bring up the network configuration via "network activation" for datasources discovered only in init boot stage after network is already up[2] /etc/cloud/cloud.cfg allows system_info:network:renderers to configure overrides for default renderers, but not for activators. The two discovery/mechanisms don't know about each other and have separate logic to determine which is applicable on the given system. Cloud-init should either: - Expose system_info: network: activators discovery priorty/order configuration in /etc/cloud/cloud.cfg* -- OR -- - make activators aware of customized/overridden renderers priority from cloud.cfg and honor that priority order when discovering activators to use. Without this feature, overridden network: renderer priority order to set network-manager as default renderer will result in cloud-init writing /etc/NetworkManager/system-connections/cloud- init-.nmconnection but then trying to run `netplan apply` for a non-existent configuration on ubuntu Desktop installs. References: [1] network renderers discovery: https://github.com/canonical/cloud-init/blob/main/cloudinit/net/renderers.py#L67 [2] network activators discovery: https://github.com/canonical/cloud-init/blob/main/cloudinit/net/activators.py#L279 [3] renderer overrides honored: https://github.com/canonical/cloud-init/blob/main/cloudinit/distros/__init__.py#L122-L126 [4] No activator overrides: https://github.com/canonical/cloud-init/blob/main/cloudinit/distros/__init__.py#L246 ** Affects: cloud-init Importance: Undecided Status: Triaged ** Affects: subiquity Importance: Undecided Status: New ** Tags: bitesize ** Description changed: cloud-init has two interactions with network backplanes 1. to write (or render) network configuration to the approapriate config files for the network system: systemd, netplan, network-manager, ENI, freebsd, netbsd, openbsd. This is done via cloudinit.net.renderers discovery[1] 2. optionally to bring up the network configuration via "network activation" for datasources discovered only in init boot stage after network is already up[2] - /etc/cloud/cloud.cfg allows system_info:network:renderers to configure overrides for default renderers, but not for activators. The two discovery/mechanisms don't know about each other and have separate logic to determine which is applicable on the given system. + Cloud-init should either: + - Expose system_info: network: activators discovery priorty/order configuration in /etc/cloud/cloud.cfg* - Cloud-init should either: - - Expose system_info: network: activators discovery priorty/order configuration in /etc/cloud/cloud.cfg* + -- OR -- - -- OR -- - - - make activators aware of customized/overridden renderers priority + - make activators aware of customized/overridden renderers priority from cloud.cfg and honor that priority order when discovering activators to use. - - Without this feature, overridden network: renderer priority order to set network-manager as default renderer will result in cloud-init writing /etc/NetworkManager/system-connections/cloud-init-.nmconnection but then trying to run `netplan apply` for a non-existent configuration on ubuntu Desktop installs. - + Without this feature, overridden network: renderer priority order to set + network-manager as default renderer will result in cloud-init writing + /etc/NetworkManager/system-connections/cloud- + init-.nmconnection but then trying to run `netplan apply` for + a non-existent configuration on ubuntu Desktop installs. References: [1] network renderers discovery: https://github.com/canonical/cloud-init/blob/main/cloudinit/net/renderers.py#L67 - [2] network activators discovery: + [2] network activators discovery: https://github.com/canonical/cloud-init/blob/main/cloudinit/net/activators.py#L279 ** Tags added: bitesize ** Description changed: cloud-init has two interactions with network backplanes 1. to write (or render) network configuration to the approapriate config files for the network system: systemd, netplan, network-manager, ENI, freebsd, netbsd, openbsd. This is done via cloudinit.net.renderers discovery[1] 2. optionally to bring up the network configuration via "network activation" for datasources discovered only in init boot stage after network is already up[2] /etc/cloud/cloud.cfg allows system_info:network:renderers to configure overrides for default renderers, but not for activators. The two discovery/mechanisms don't know about each other and have separate logic to determine which is applicable on the given system.
[Yahoo-eng-team] [Bug 1981646] Re: network v2: do not render world-readable netplan when wifi or auth config contains sensitive passwords
Alternative solution to this could be if netplan.io grows a new root- only directory option that defines a schema for storing sensitive information like credentials. Not sure if this is something netplan.io would plan to grow or not. Tagging netplan.io on this bug as an FYI `wishlist` in case future feature work goes this direction. The features that may be nice from netplan frm a usability standpoint: 1. documented policy that suggests chmod 600 on any netplan YAML 2. Instrumented policy in `netplan generate` or `netplan apply` that warns about world-readable files consumed which happen to contain security-related keys. 3. Ideally, sensitive YAML content root-only files wouldn't live in with world-readable content in /etc/netplan/* files. Possibly define a sensitive/security/credentials subdirectory/schema that could contain the security bits. This is probably not the bug to file against netplan.io as it contains multiple feature request, but I wanted to track the sentiment in case that effort is becomes something desireable for netplan (and thereby affecting how cloud-init should write out sensitive files). ** Also affects: netplan 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/1981646 Title: network v2: do not render world-readable netplan when wifi or auth config contains sensitive passwords Status in cloud-init: Triaged Status in netplan: New Bug description: https://netplan.io/reference/ supports wifi password and auto client- key-password keys which should generally not be world-readable. But, when rendering passthrough V2 network configuration, cloud-init emits a single /etc/netplan/50-cloud-init.yaml file that is world readable. If network v2 config contains sensitive password keys it may make sense for cloud-init to either: 1. Make /etc/netplan/50-cloud-init.yaml only root-readable - OR - 2. Write a world-readable /etc/netplan/50-cloud-init.yaml containing all keys except wifis and auth and a root-readable /etc/netplan/50-cloud-init-sensitive.yaml which would contain any security sensitive config content. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1981646/+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 1643688] Re: Azure should set hostname during init-local
I believe this bug/feature has been fixed in cloud-init as of cloud-init version 18.1 Azure specifically sets hostname during init-local timeframe based on this commit https://github.com/canonical/cloud- init/commit/133ad2cb327ad17b7b81319fac8f9f14577c04df which addressed this related bug https://bugs.launchpad.net/cloud- init/+bug/1746455. If this still is a problem please feel free to re-open this bug or open a new bug descibing this issue in current cloud-init version 22.2. ** Changed in: cloud-init 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/1643688 Title: Azure should set hostname during init-local Status in cloud-init: Fix Released Bug description: The Azure data-source currently considers itself a networked one, as at least part of the information is read via network. In consequence the hostname is only known after network is already setup and a ifdown/ifup cycle is initiated to update the network view of the hostname. This cycle leads to a massive delay in boot time, at least if ipv6 setup is requested. Please split hostname setup out of the normal networked init run. The information via the ovf file is known pretty early and without network. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1643688/+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 1981646] [NEW] network v2: do not render world-readable netplan when wifi or auth config contains sensitive passwords
Public bug reported: https://netplan.io/reference/ supports wifi password and auto client- key-password keys which should generally not be world-readable. But, when rendering passthrough V2 network configuration, cloud-init emits a single /etc/netplan/50-cloud-init.yaml file that is world readable. If network v2 config contains sensitive password keys it may make sense for cloud-init to either: 1. Make /etc/netplan/50-cloud-init.yaml only root-readable - OR - 2. Write a world-readable /etc/netplan/50-cloud-init.yaml containing all keys except wifis and auth and a root-readable /etc/netplan/50-cloud-init-sensitive.yaml which would contain any security sensitive config content. ** Affects: cloud-init Importance: Low 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/1981646 Title: network v2: do not render world-readable netplan when wifi or auth config contains sensitive passwords Status in cloud-init: New Bug description: https://netplan.io/reference/ supports wifi password and auto client- key-password keys which should generally not be world-readable. But, when rendering passthrough V2 network configuration, cloud-init emits a single /etc/netplan/50-cloud-init.yaml file that is world readable. If network v2 config contains sensitive password keys it may make sense for cloud-init to either: 1. Make /etc/netplan/50-cloud-init.yaml only root-readable - OR - 2. Write a world-readable /etc/netplan/50-cloud-init.yaml containing all keys except wifis and auth and a root-readable /etc/netplan/50-cloud-init-sensitive.yaml which would contain any security sensitive config content. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1981646/+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 1976564] [NEW] cloud-config: cloud_dir setting not honored globalling by cloud-init
Public bug reported: Changes to /etc/cloud/cloud.cfg system_info: paths: cloud_dir setting is not honored globally in cloud-init. Some paths continue to hardcode /var/lib/cloud paths to certain operations. Affects cloud-init version 22.2 [Test Plan] cat > 95-custom-cloud-dir.cfg < '../../var/lib/cloud/data/result.json' # Expect to find no files in /var/lib/cloud lxc exec dev-x find /var/lib/cloud /var/lib/cloud /var/lib/cloud/data /var/lib/cloud/data/status.json [ Possible hardcoded paths to resolve] - cloudinit/util.py:fetch_ssl_details - cloudinit/sources/DataSourceBigstep.py - cloudinit/sources/DataSourceAzure.py - cloudinit/cmd/main.py:status_wrapper - cloudinit/cmd/devel/logs.py - ** Affects: cloud-init Importance: High Status: Triaged ** Changed in: cloud-init Status: New => Triaged ** Changed in: cloud-init Importance: Undecided => High -- 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/1976564 Title: cloud-config: cloud_dir setting not honored globalling by cloud-init Status in cloud-init: Triaged Bug description: Changes to /etc/cloud/cloud.cfg system_info: paths: cloud_dir setting is not honored globally in cloud-init. Some paths continue to hardcode /var/lib/cloud paths to certain operations. Affects cloud-init version 22.2 [Test Plan] cat > 95-custom-cloud-dir.cfg < '../../var/lib/cloud/data/result.json' # Expect to find no files in /var/lib/cloud lxc exec dev-x find /var/lib/cloud /var/lib/cloud /var/lib/cloud/data /var/lib/cloud/data/status.json [ Possible hardcoded paths to resolve] - cloudinit/util.py:fetch_ssl_details - cloudinit/sources/DataSourceBigstep.py - cloudinit/sources/DataSourceAzure.py - cloudinit/cmd/main.py:status_wrapper - cloudinit/cmd/devel/logs.py - To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1976564/+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 1974053] Re: Release 22.2
** Changed in: cloud-init Status: New => Fix Released ** Changed in: cloud-init Assignee: (unassigned) => Brett Holman (holmanb) -- 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/1974053 Title: Release 22.2 Status in cloud-init: Fix Released Bug description: Summary: Release 22.2 Further information: == Release Notes == Cloud-init release 22.2 is now available The 22.2 release: * spanned about 3 months * had 28 contributors from 31 domains * fixed 1 Launchpad issues Highlights: - Add native NetworkManager support - Various schema improvements: - Implemented userdata schema definitions for all modules - moved `cloud-init devel schema` command to `cloud-init schema` - Add LXD tutorial - Shave ~8ms off generator runtime - Allow growpart to resize encrypted partitions - Add support for dual stack IPv6/IPv4 IMDS to Ec2 - Drop vestigial support for upstart == Changelog == - Fix test due to caplog incompatibility (#1461) [Alberto Contreras] - Align rhel custom files with upstream (#1431) [Emanuele Giuseppe Esposito] - cc_write_files: Improve schema. (#1460) [Alberto Contreras] - cli: Redact files with permission errors in commands (#1440) [Alberto Contreras] (LP: #1953430) - Improve cc_set_passwords. (#1456) [Alberto Contreras] - testing: make fake cloud-init wait actually wait (#1459) - Scaleway: Fix network configuration for netplan 0.102 and later (#1455) [Maxime Corbin] - Fix 'ephmeral' typos in disk names(#1452) [Mike Hucka] - schema: version schema-cloud-config-v1.json (#1424) - cc_modules: set default meta frequency value when no config available (#1457) - Log generic warning on non-systemd systems. (#1450) [Alberto Contreras] - cc_snap.maybe_install_squashfuse no longer needed in Bionic++. (#1448) [Alberto Contreras] - Drop support of *-sk keys in cc_ssh (#1451) [Alberto Contreras] - testing: Fix console_log tests (#1437) - tests: cc_set_passoword update for systemd, non-systemd distros (#1449) - Fix bug in url_helper/dual_stack() logging (#1426) - schema: render schema paths from _CustomSafeLoaderWithMarks (#1391) (GH: SC-929) - testing: Make integration tests kinetic friendly (#1441) - Handle error if SSH service no present. (#1422) [Alberto Contreras] (GH: #1969526) - Fix network-manager activator availability and order (#1438) - sources/azure: remove reprovisioning marker (#1414) [Chris Patterson] - upstart: drop vestigial support for upstart (#1421) - testing: Ensure NoCloud detected in test (#1439) - Update .github-cla-signers kallioli [Kevin Allioli] - Consistently strip top-level network key (#1417) (GH: #1906187) - testing: Fix LXD VM metadata test (#1430) - testing: Add NoCloud setup for NoCloud test (#1425) - Update linters and adapt code for compatibility (#1434) [Paride Legovini] - run-container: add support for LXD VMs (#1428) [Paride Legovini] - integration-reqs: bump pycloudlib pinned commit (#1427) [Paride Legovini] - Fix NoCloud docs (#1423) - Docs fixes (#1406) - docs: Add docs for module creation (#1415) - Remove cheetah from templater (#1416) - tests: verify_ordered_items fallback to re.escape if needed (#1420) - Misc module cleanup (#1418) - docs: Fix doc warnings and enable errors (#1419) [Alberto Contreras] (GH: #1876341) - Refactor cloudinit.sources.NetworkConfigSource to enum (#1413) [Alberto Contreras] (GH: #1874875) - Don't fail if IB and Ethernet devices 'collide' (#1411) - Use cc_* module meta defintion over hardcoded vars (SC-888) (#1385) - Fix cc_rsyslog.py initialization (#1404) [Alberto Contreras] - Promote cloud-init schema from devel to top level subcommand (#1402) - mypy: disable missing imports warning for httpretty (#1412) [Chris Patterson] - users: error when home should not be created AND ssh keys provided [Jeffrey 'jf' Lim] - Allow growpart to resize encrypted partitions (#1316) - Fix typo in integration_test.rst (#1405) [Alberto Contreras] - cloudinit.net refactor: apply_network_config_names (#1388) [Alberto Contreras] (GH: #1884602) - tests/azure: add fixtures for hardcoded paths (markers and data_dir) (#1399) [Chris Patterson] - testing: Add responses workaround for focal/impish (#1403) - cc_ssh_import_id: fix is_key_in_nested_dict to avoid early False - Fix ds-identify not detecting NoCloud seed in config (#1381) (GH: #1876375) - sources/azure: retry dhcp for failed processes (#1401) [Chris Patterson] - Move notes about refactorization out of CONTRIBUTING.rst (#1389) - Shave ~8ms off generator runtime (#1387) - Fix provisioning dhcp timeout to 20 minutes (#1394) [Chris Patterson] - schema: module example strict testing fix seed_random -
[Yahoo-eng-team] [Bug 1969526] [NEW] cc-ssh: traceback when openssh-server absent
Public bug reported:
In minimal cloud images without openssh-server, cloud-init will get the
following traceback.
2022-04-19 20:42:32,593 - stages.py[DEBUG]: Running module set-passwords
() with
frequency once-per-instance
2022-04-19 20:42:32,593 - handlers.py[DEBUG]: start:
modules-config/config-set-passwords: running config-set-passwords with
frequency once-per-instance
2022-04-19 20:42:32,593 - util.py[DEBUG]: Writing to
/var/lib/cloud/instances/rocky-8/sem/config_set_passwords - wb: [644] 24 bytes
2022-04-19 20:42:32,593 - helpers.py[DEBUG]: Running config-set-passwords using
lock ()
2022-04-19 20:42:32,594 - ssh_util.py[DEBUG]: line 1: option
PasswordAuthentication added with no
2022-04-19 20:42:32,594 - util.py[DEBUG]: Writing to /etc/ssh/sshd_config - wb:
[644] 26 bytes
2022-04-19 20:42:32,594 - subp.py[DEBUG]: Running command ['service', 'sshd',
'restart'] with allowed return codes [0] (shell=False, capture=True)
2022-04-19 20:42:32,620 - handlers.py[DEBUG]: finish:
modules-config/config-set-passwords: FAIL: running config-set-passwords with
frequency once-per-instance
2022-04-19 20:42:32,621 - util.py[WARNING]: Running module set-passwords
() failed
2022-04-19 20:42:32,621 - util.py[DEBUG]: Running module set-passwords () failed
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/cloudinit/stages.py", line 876, in
_run_modules
freq=freq)
File "/usr/lib/python3.6/site-packages/cloudinit/cloud.py", line 54, in run
return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3.6/site-packages/cloudinit/helpers.py", line 185, in run
results = functor(*args)
File "/usr/lib/python3.6/site-packages/cloudinit/config/cc_set_passwords.py",
line 234, in handle
service_name=cloud.distro.get_option('ssh_svcname', 'ssh'))
File "/usr/lib/python3.6/site-packages/cloudinit/config/cc_set_passwords.py",
line 131, in handle_ssh_pwauth
subp.subp(cmd)
File "/usr/lib/python3.6/site-packages/cloudinit/subp.py", line 295, in subp
cmd=args)
cloudinit.subp.ProcessExecutionError: Unexpected error while running command.
Command: ['service', 'sshd', 'restart']
Exit code: 5
Reason: -
Stdout:
Stderr: Redirecting to /bin/systemctl restart sshd.service
Failed to restart sshd.service: Unit sshd.service not found.
While one could argue that cloud images without openssh-server might
have limited utility, there are use cases for slim apps/micro-services
that may not rely on this stack and cloud-init should probably cope
better in the face of this missing dependency.
While working this issue, let's add a Suggests: openssh-server to
debian/control for Deb-based systems.
** Affects: cloud-init
Importance: Low
Status: Triaged
** Tags: bitesize
** Changed in: cloud-init
Importance: Undecided => Low
--
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/1969526
Title:
cc-ssh: traceback when openssh-server absent
Status in cloud-init:
Triaged
Bug description:
In minimal cloud images without openssh-server, cloud-init will get
the following traceback.
2022-04-19 20:42:32,593 - stages.py[DEBUG]: Running module set-passwords
() with
frequency once-per-instance
2022-04-19 20:42:32,593 - handlers.py[DEBUG]: start:
modules-config/config-set-passwords: running config-set-passwords with
frequency once-per-instance
2022-04-19 20:42:32,593 - util.py[DEBUG]: Writing to
/var/lib/cloud/instances/rocky-8/sem/config_set_passwords - wb: [644] 24 bytes
2022-04-19 20:42:32,593 - helpers.py[DEBUG]: Running config-set-passwords
using lock ()
2022-04-19 20:42:32,594 - ssh_util.py[DEBUG]: line 1: option
PasswordAuthentication added with no
2022-04-19 20:42:32,594 - util.py[DEBUG]: Writing to /etc/ssh/sshd_config -
wb: [644] 26 bytes
2022-04-19 20:42:32,594 - subp.py[DEBUG]: Running command ['service', 'sshd',
'restart'] with allowed return codes [0] (shell=False, capture=True)
2022-04-19 20:42:32,620 - handlers.py[DEBUG]: finish:
modules-config/config-set-passwords: FAIL: running config-set-passwords with
frequency once-per-instance
2022-04-19 20:42:32,621 - util.py[WARNING]: Running module set-passwords
() failed
2022-04-19 20:42:32,621 - util.py[DEBUG]: Running module set-passwords
() failed
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/cloudinit/stages.py", line 876, in
_run_modules
freq=freq)
File "/usr/lib/python3.6/site-packages/cloudinit/cloud.py", line 54, in run
return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3.6/site-packages/cloudinit/helpers.py", line 185, in
run
results = functor(*args)
File
"/usr/lib/python3.6/site-packages/cloudinit/config/cc_set_passwords.py", line
234, in handle
service_name=cloud.distro.get_option('ssh_svcname', 'ssh'))
File
[Yahoo-eng-team] [Bug 1968789] [NEW] docs: update rtd documentation for nocloud
Public bug reported: Update "read the docs" content at doc/rtd/topics/datasources/altcloud.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceAltCloud.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst Specifically, these docs need to also include discussion of seed directory setup in /var/lib/cloud/seed/*. ** Affects: cloud-init Importance: Undecided Status: Triaged ** Tags: bitesize ** Tags added: bitesize ** Changed in: cloud-init Status: New => Triaged -- 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/1968789 Title: docs: update rtd documentation for nocloud Status in cloud-init: Triaged Bug description: Update "read the docs" content at doc/rtd/topics/datasources/altcloud.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceAltCloud.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst Specifically, these docs need to also include discussion of seed directory setup in /var/lib/cloud/seed/*. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1968789/+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 1858893] Re: schema: add jsonschema definition to cc_emit_upstart
Dropping cc_emit_upstart config module due to no longer having Ubuntu Trusty support in cloud-init upstream. Marking WONTFIX ** Changed in: cloud-init Status: Triaged => Won't Fix -- 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/1858893 Title: schema: add jsonschema definition to cc_emit_upstart Status in cloud-init: Won't Fix Bug description: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_emit_upstart.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858893/+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 1858886] Re: schema: add jsonschema definition to cc_byobu
Upstream fix committed in https://github.com/canonical/cloud-init/commit/af7eb1deab12c7208853c5d18b55228e0ba29c4d published as cloud-init 22.1 ** Changed in: cloud-init 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/1858886 Title: schema: add jsonschema definition to cc_byobu Status in cloud-init: Fix Released Bug description: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_byobu.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858886/+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 1858889] Re: schema: add jsonschema definition to cc_debug
Upstream fix committed in https://github.com/canonical/cloud-init/commit/af7eb1deab12c7208853c5d18b55228e0ba29c4d published as cloud-init 22.1 ** Changed in: cloud-init 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/1858889 Title: schema: add jsonschema definition to cc_debug Status in cloud-init: Fix Released Bug description: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_debug.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858889/+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 1858891] Re: schema: add jsonschema definition to cc_disable_ec2_metadata
Upstream fix committed in https://github.com/canonical/cloud-init/commit/af7eb1deab12c7208853c5d18b55228e0ba29c4d published as cloud-init 22.1 ** Changed in: cloud-init 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/1858891 Title: schema: add jsonschema definition to cc_disable_ec2_metadata Status in cloud-init: Fix Released Bug description: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_disable_ec2_metadata.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858891/+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 1858887] Re: schema: add jsonschema definition to cc_ca_certs
Upstream fix committed in https://github.com/canonical/cloud-init/commit/af7eb1deab12c7208853c5d18b55228e0ba29c4d published as cloud-init 22.1 ** Changed in: cloud-init 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/1858887 Title: schema: add jsonschema definition to cc_ca_certs Status in cloud-init: Fix Released Bug description: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_ca_certs.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858887/+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 1858892] Re: schema: add jsonschema definition to cc_disk_setup
Upstream fix committed in https://github.com/canonical/cloud-init/commit/af7eb1deab12c7208853c5d18b55228e0ba29c4d published as cloud-init 22.1 ** Changed in: cloud-init 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/1858892 Title: schema: add jsonschema definition to cc_disk_setup Status in cloud-init: Fix Released Bug description: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_disk_setup.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858892/+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 1858885] Re: schema: add jsonschema definition to cc_apt_pipelining
upstream commit added that resolves this issue. https://github.com/canonical/cloud-init/commit/4ba6fd283674df1ef25300d91c6d2061910744be fix published in version 21.4 ** Changed in: cloud-init 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/1858885 Title: schema: add jsonschema definition to cc_apt_pipelining Status in cloud-init: Fix Released Bug description: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_apt_pipelining.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858885/+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 1966085] Re: cloud-init status --wait never returns if datasource not found
Fix released to Jammy [ubuntu/jammy-proposed] cloud-init 22.1-14-g2e17a0d6-0ubuntu1~22.04.4 (Accepted) ** Changed in: cloud-init (Ubuntu Jammy) Status: In Progress => Fix Released ** Changed in: cloud-init 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/1966085 Title: cloud-init status --wait never returns if datasource not found Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: In Progress Status in cloud-init source package in Focal: In Progress Status in cloud-init source package in Impish: In Progress Status in cloud-init source package in Jammy: Fix Released Bug description: Calling "cloud-init status --wait" never returns if ds-identify cannot find a datasource. In https://github.com/canonical/cloud-init/pull/1162, we modified status checks to wait until we get an "enabled" or "disabled" file from ds-identiy. ds-identify never outputs a "disabled" file, so "status --wait" will wait indefinitely if no datasource is found. A simple reproduction is to change "ret=1" on this line: https://github.com/canonical/cloud-init/blob/main/tools/ds-identify#L1866 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1966085/+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 1966085] Re: cloud-init status --wait never returns if datasource not found
** Also affects: cloud-init (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Jammy) Importance: High Status: Triaged ** Also affects: cloud-init (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu Bionic) Status: New => In Progress ** Changed in: cloud-init (Ubuntu Focal) Status: New => In Progress ** Changed in: cloud-init (Ubuntu Impish) Status: New => In Progress ** Changed in: cloud-init (Ubuntu Jammy) Status: Triaged => In Progress ** Changed in: cloud-init Assignee: (unassigned) => James Falcon (falcojr) -- 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/1966085 Title: cloud-init status --wait never returns if datasource not found Status in cloud-init: Triaged Status in cloud-init package in Ubuntu: In Progress Status in cloud-init source package in Bionic: In Progress Status in cloud-init source package in Focal: In Progress Status in cloud-init source package in Impish: In Progress Status in cloud-init source package in Jammy: In Progress Bug description: Calling "cloud-init status --wait" never returns if ds-identify cannot find a datasource. In https://github.com/canonical/cloud-init/pull/1162, we modified status checks to wait until we get an "enabled" or "disabled" file from ds-identiy. ds-identify never outputs a "disabled" file, so "status --wait" will wait indefinitely if no datasource is found. A simple reproduction is to change "ret=1" on this line: https://github.com/canonical/cloud-init/blob/main/tools/ds-identify#L1866 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1966085/+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 1956788] Re: system_cfg not read on Oracle datasource
This fix in Jammy 22.1-14-g2e17a0d6-0ubuntu1~22.04.1 also had an unintended side-effect where network would not get rendered due and newly launched instnaces on Jammy were unreachable due to cloud-init networking being configured as disabled in Oracle images /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg. This commit is being reverted for this release so it can be refactored to avoid the side-effect. https://github.com/canonical/cloud-init/pull/1326 ** Changed in: cloud-init Status: Fix Released => New ** Changed in: cloud-init Status: New => In Progress -- 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/1956788 Title: system_cfg not read on Oracle datasource Status in cloud-init: In Progress Bug description: In https://github.com/canonical/cloud- init/commit/2c52e6e88b19f5db8d55eb7280ee27703e05d75f , the order of reading network config was changed for Oracle due to initramfs needing to take lower precedence than the datasource. However, this also bumped system_cfg to a lower precedence than ds, which means that any network configuration specified in /etc/cloud will not be applied. system_cfg should instead be moved above ds so network configuration in /etc/cloud takes precedence. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1956788/+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 1779386] Re: test smoser bug for lp-attach [please ignore]
** Changed in: cloud-init Status: New => 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/1779386 Title: test smoser bug for lp-attach [please ignore] Status in cloud-init: Invalid Bug description: I couldn't figure out how to login to launchpad staging, so i'm using this. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1779386/+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 1960545] Re: Clean and init again doesn't re-run "write-files"
I'll make this bug as invalid for now because this is cloud-init working as desired and I expect the only thing you were missing was a subsequent call to `cloud-init init` to see write-files run. If this is closed in error, please feel free to set state back to 'New' above. ** Changed in: cloud-init Status: New => 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/1960545 Title: Clean and init again doesn't re-run "write-files" Status in cloud-init: Invalid Bug description: Hi community, I am trying to re-apply the new version of uc20 gadget snap manually. After googling, cloud-init scripts can rerun with "cloud-init clean && cloud-init init --local". However the rerun doesn't seem to work for the updates in "write-files" of the new version. The new contents are applied in the files. Is there another command I should run? Regards, Hao To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1960545/+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 1953430] [NEW] cloud-init query traceback on root read-only etc/cloud/cloud.cfg.d/ files
Public bug reported:
If any files are root read-only in /etc/cloud/cloud.cfg.d cloud-init query
tracebacks for non-root user
cloud-init version: 21.4
Reproducible on Jammy Desktop installer images
csmith@csmith-Standard-PC-i440FX-PIIX-1996:~$ cloud-init query --all
Traceback (most recent call last):
File "/usr/bin/cloud-init", line 33, in
sys.exit(load_entry_point('cloud-init==21.4', 'console_scripts',
'cloud-init')())
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 927, in main
retval = util.log_time(
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2472, in
log_time
ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/query.py", line 109, in
handle_args
paths = read_cfg_paths()
File "/usr/lib/python3/dist-packages/cloudinit/cmd/devel/__init__.py", line
22, in read_cfg_paths
init.read_cfg()
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 229, in
read_cfg
self._cfg = self._read_cfg(extra_fns)
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 237, in
_read_cfg
base_cfg=fetch_base_config())
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 1049, in
fetch_base_config
util.read_conf_with_confd(CLOUD_CONFIG),
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 950, in
read_conf_with_confd
confd_cfg = read_conf_d(confd)
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 925, in
read_conf_d
cfgs.append(read_conf(os.path.join(confd, fn)))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 271, in
read_conf
return load_yaml(load_file(fname), default={})
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1361, in
load_file
with open(fname, 'rb') as ifh:
PermissionError: [Errno 13] Permission denied:
'/etc/cloud/cloud.cfg.d/99-installer.cfg'
# works fine for root user
csmith@csmith-Standard-PC-i440FX-PIIX-1996:~$ sudo cloud-init query --all
[sudo] password for csmith:
{
"_beta_keys": [
"subplatform"
],
"availability_zone": null,
"base64_encoded_keys": [],
"cloud_name": "none",
"distro": "ubuntu",
"distro_release": "jammy",
"distro_version": "22.04",
"ds": {
"_doc": "EXPERIMENTAL: The structure and format of content scoped under the
'ds' key may change in subsequent releases of cloud-init.",
"meta_data": {
"instance_id": "fd598361-12e8-41e0-a7eb-7c9f2d7d3b41"
}
},
"instance_id": "iid-datasource-none",
"kernel_release": "5.13.0-19-generic",
"local_hostname": "csmith-Standard-PC-i440FX-PIIX-1996",
"machine": "x86_64",
"merged_cfg": {
"_doc": "Merged cloud-init system config from /etc/cloud/cloud.cfg and
/etc/cloud/cloud.cfg.d/",
"_log": [
"[loggers]\nkeys=root,cloudinit\n\n[handlers]\nkeys=consoleHandler,cloudLogHandler\n\n[formatters]\nkeys=simpleFormatter,arg0Formatter\n\n[logger_root]\nlevel=DEBUG\nhandlers=consoleHandler,cloudLogHandler\n\n[logger_cloudinit]\nlevel=DEBUG\nqualname=cloudinit\nhandlers=\npropagate=1\n\n[handler_consoleHandler]\nclass=StreamHandler\nlevel=WARNING\nformatter=arg0Formatter\nargs=(sys.stderr,)\n\n[formatter_arg0Formatter]\nformat=%(asctime)s
- %(filename)s[%(levelname)s]:
%(message)s\n\n[formatter_simpleFormatter]\nformat=[CLOUDINIT]
%(filename)s[%(levelname)s]: %(message)s\n",
"[handler_cloudLogHandler]\nclass=FileHandler\nlevel=DEBUG\nformatter=arg0Formatter\nargs=('/var/log/cloud-init.log',
'a', 'UTF-8')\n",
"[handler_cloudLogHandler]\nclass=handlers.SysLogHandler\nlevel=DEBUG\nformatter=simpleFormatter\nargs=(\"/dev/log\",
handlers.SysLogHandler.LOG_USER)\n"
],
"apt": {
"preserve_sources_list": true
},
"cloud_config_modules": [
"emit_upstart",
"snap",
"ssh-import-id",
"locale",
"set-passwords",
"grub-dpkg",
"apt-pipelining",
"apt-configure",
"ubuntu-advantage",
"ntp",
"timezone",
"disable-ec2-metadata",
"runcmd",
"byobu"
],
"cloud_final_modules": [
"package-update-upgrade-install",
"fan",
"landscape",
"lxd",
"ubuntu-drivers",
"write-files-deferred",
"puppet",
"chef",
"mcollective",
"salt-minion",
"reset_rmc",
"refresh_rmc_and_interface",
"rightscale_userdata",
"scripts-vendor",
"scripts-per-once",
"scripts-per-boot",
"scripts-per-instance",
"scripts-user",
"ssh-authkey-fingerprints",
"keys-to-console",
"install-hotplug",
"phone-home",
"final-message",
"power-state-change"
],
"cloud_init_modules": [
"migrator",
"seed_random",
"bootcmd",
"write-files",
"growpart",
"resizefs",
"disk_setup",
"mounts",
"set_hostname",
"update_hostname",
"update_etc_hosts",
"ca-certs",
"rsyslog",
"users-groups",
"ssh"
],
"datasource": {
"None": {
"metadata": {
"instance_id": "fd598361-12e8-41e0-a7eb-7c9f2d7d3b41"
},
"userdata_raw": "#cloud-config\ngrowpart:\n mode: 'off'\nlocale:
en_US.UTF-8\npreserve_hostname:
[Yahoo-eng-team] [Bug 1952721] Re: passwd: insert a blank space in /etc/shadow
Thank you for filing a bug and making Ubuntu and cloud-init better. The reason you are unable to login as jpcozar is because the default behavior of cloud-init is to lock password logins and prefer key-based login for ssh. What you'll need is to both allow password-based ssh logins with "ssh_pwauth: true" and make sure the password is unlocked for jpcozar with "lock_passwd: false". the complete userdata below: #cloud-config ssh_pwauth: true users: - default - name: jpcozar groups: sudo shell: /bin/bash sudo: ALL=(ALL) NOPASSWD:ALL passwd: $6$ZE4Us0phF$/gVyOLzLIKI6uxCjYmkNnLxmtyZcicmZ8pXFTMM0P9TG14egqPDVm066uacHsuFw9vH1/i2fx5vTWpD/C//qc. ** Changed in: cloud-init Status: New => 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/1952721 Title: passwd: insert a blank space in /etc/shadow Status in cloud-init: Invalid Bug description: Hello, I am using multipass 1.8.0.+win with a config file called cloud-init.yaml. I create my own user and insert the hash password of my user like that: users: - default - name: jpcozar groups: sudo shell: /bin/bash sudo: ALL=(ALL) NOPASSWD:ALL passwd: $6$ZE4Us0phF$/gVyOLzLIKI6uxCjYmkNnLxmtyZcicmZ8pXFTMM0P9TG14egqPDVm066uacHsuFw9vH1/i2fx5vTWpD/C//qc. Once multipass has created the virtual machine, I can't login with user/passwd. If I check /etc/shadow, it inserts a blank space after ":" so I can't login. jpcozar: $6$ZE4Us0phF$/gVyOLzLIKI6uxCjYmkNnLxmtyZcicmZ8pXFTMM0P9TG14egqPDVm066uacHsuFw9vH1/i2fx5vTWpD/C//qc.:18961:0:9:7::: If I delete, such space, I can login jpcozar:$6$ZE4Us0phF$/gVyOLzLIKI6uxCjYmkNnLxmtyZcicmZ8pXFTMM0P9TG14egqPDVm066uacHsuFw9vH1/i2fx5vTWpD/C//qc.:18961:0:9:7::: I have tried other options in cloud-init.yaml like passwd:$6$ZE4Us0phF$/gVyOLzLIKI6uxCjYmkNnLxmtyZcicmZ8pXFTMM0P9TG14egqPDVm066uacHsuFw9vH1/i2fx5vTWpD/C//qc. and it returns syntax error or passwd: "$6$ZE4Us0phF$/gVyOLzLIKI6uxCjYmkNnLxmtyZcicmZ8pXFTMM0P9TG14egqPDVm066uacHsuFw9vH1/i2fx5vTWpD/C//qc." and it generates such blank spaces. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1952721/+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 1943275] [NEW] docs: cc_users_groups: add more explicit docs on impact of omission of "- default" user on a system
Public bug reported: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#users- and-groups should have a more visible note explaing the affect of omitting "- default" as this is a fairly frequent accidental side-effect for user-config containing "users:" directives. ** Affects: cloud-init Importance: Low Status: New ** Tags: docs -- 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/1943275 Title: docs: cc_users_groups: add more explicit docs on impact of omission of "- default" user on a system Status in cloud-init: New Bug description: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#users- and-groups should have a more visible note explaing the affect of omitting "- default" as this is a fairly frequent accidental side- effect for user-config containing "users:" directives. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1943275/+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 1940233] Re: cloud-init in impish makes /home/ubuntu/.ssh root.root
** Also affects: cloud-init (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Impish) Importance: Critical Status: Fix Committed ** Also affects: cloud-init (Ubuntu Bionic) 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/1940233 Title: cloud-init in impish makes /home/ubuntu/.ssh root.root Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Committed Status in cloud-init source package in Bionic: New Status in cloud-init source package in Focal: New Status in cloud-init source package in Hirsute: New Status in cloud-init source package in Impish: Fix Committed Bug description: Hi, I got to this by my systems complaining to be unable to do ssh-keygen after deployment. Example: $ uvt-kvm ssh --insecure impish-kvm 'ssh-keygen -b 2048 -t rsa -f ~/.ssh/id_rsa -q -N '\'''\''' Saving key "/home/ubuntu/.ssh/id_rsa" failed: Permission denied I found that is due to permissions after guest spawning: /home/ubuntu/.ssh changed Old: drwx-- 2 ubuntu ubuntu 4096 Aug 17 08:20 .ssh/ New: drwxr-xr-x 2 root root 4096 Aug 17 08:17 .ssh/ That beaks later things like ssh-keygen. uvt-kvm only does instruct cloud-init to place a key. This uses ssh_authorized_keys from https://cloudinit.readthedocs.io/en/latest/topics/modules.html?highlight=ssh_authorized_keys#authorized-keys Checked a few guests: I've seen this on - impish x86 - impish s390x I've not seen this on - bionic - focal - impish You might say - wait a minute impish in both lists. But it is the date: Bad com.ubuntu.cloud.daily:server:21.10:amd64 20210815 cloud-init 21.2-69-g65607405-0ubuntu1 Good com.ubuntu.cloud.daily:server:21.10:amd64 20210706 cloud-init 21.2-3-g899bfaa9-0ubuntu2 And either this cloud-init version is broken or the underlying new impish image. I mounted the underlying cloud-image (without customization by cloud-init) and found that /home is empty (true for all those images). So to me that seems to be an issue in the new cloud-init that now is in those images. Steps to reproduce # if your host has no keys to push to the guest run ssh-keygen # sync the latest broken images $ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=impish # spawn guest $ uvt-kvm create --password=ubuntu i release=impish arch=amd64 label=daily # wait for it and check the permissions $ uvt-kvm wait i $ uvt-kvm ssh i "ls -laF /home/ubuntu/" drwxr-xr-x 2 root root 4096 Aug 17 08:17 .ssh/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1940233/+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 1936229] Re: selinux cloud-init-hotplugd.socket not having permissions to fifo sockets
** Changed in: centos Status: New => 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/1936229 Title: selinux cloud-init-hotplugd.socket not having permissions to fifo sockets Status in cloud-init: New Status in CentOS: Invalid Bug description: Initial cloud-init-hotplugd.socket has some undesirable interactions with an enforcing SElinux system when trying to listen on a FIFO socket. Deploying on rocky linux 8.4 we can see SELinux errors preventing the cloud-init-hotplugd.socket from starting from journalctl -b 0: systemd[1]: cloud-init-hotplugd.socket: Failed to listen on sockets: Permission denied systemd[1]: cloud-init-hotplugd.socket: Failed with result 'resources'. systemd[1]: Failed to listen on cloud-init hotplug hook socket. ... setroubleshoot[772]: SELinux is preventing systemd from add_name access on the directory hook-hotplug-cmd. For complete SELinux messages run: sealert -l 8969a264-6637-489a-a329-0aafc0b8ee3a setroubleshoot[772]: SELinux is preventing systemd from add_name access on the directory hook-hotplug-cmd. * Plugin catchall (100. confidence) suggests ** If you believe that systemd should be allowed add_name access on the hook-hotplug-cmd directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'systemd' --raw | audit2allow -M my-systemd # semodule -X 300 -i my-systemd.pp [rocky@ip-172-31-3-239 ~]$ sestatus SELinux status: enabled SELinuxfs mount:/sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 [rocky@ip-172-31-3-239 ~]$ systemctl status cloud-init-hotplugd.socket ● cloud-init-hotplugd.socket - cloud-init hotplug hook socket Loaded: loaded (/usr/lib/systemd/system/cloud-init-hotplugd.socket; enabled; vendor preset: disabled) Active: failed (Result: resources) Listen: /run/cloud-init/hook-hotplug-cmd (FIFO) Jul 14 03:39:49 ip-172-31-3-239.us-east-2.compute.internal systemd[1]: cloud-init-hotplugd.socket: Failed to listen on sockets: Permission denied Jul 14 03:39:49 ip-172-31-3-239.us-east-2.compute.internal systemd[1]: cloud-init-hotplugd.socket: Failed with result 'resources'. Jul 14 03:39:49 ip-172-31-3-239.us-east-2.compute.internal systemd[1]: Failed to listen on cloud-init hotplug hook socket. [rocky@ip-172-31-3-239 ~]$ systemctl status cloud-init-hotplugd.service ● cloud-init-hotplugd.service - cloud-init hotplug hook daemon Loaded: loaded (/usr/lib/systemd/system/cloud-init-hotplugd.service; static; vendor preset: disabled) Active: inactive (dead) When setting selinux to permissive, we can see no errors from the systemd services [rocky@ip-172-31-3-239 ~]$ sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config [rocky@ip-172-31-3-239 ~]$ sudo cloud-init clean --logs --reboot [rocky@ip-172-31-3-239 ~]$ sestatus SELinux status: enabled SELinuxfs mount:/sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 [rocky@ip-172-31-3-239 ~]$ systemctl status cloud-init-hotplugd.socket ● cloud-init-hotplugd.socket - cloud-init hotplug hook socket Loaded: loaded (/usr/lib/systemd/system/cloud-init-hotplugd.socket; enabled; vendor preset: disabled) Active:
[Yahoo-eng-team] [Bug 1936229] Re: selinux cloud-init-hotplugd.socket not having permissions to fifo sockets
** Also affects: centos 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/1936229 Title: selinux cloud-init-hotplugd.socket not having permissions to fifo sockets Status in cloud-init: New Status in CentOS: New Bug description: Initial cloud-init-hotplugd.socket has some undesirable interactions with an enforcing SElinux system when trying to listen on a FIFO socket. Deploying on rocky linux 8.4 we can see SELinux errors preventing the cloud-init-hotplugd.socket from starting from journalctl -b 0: systemd[1]: cloud-init-hotplugd.socket: Failed to listen on sockets: Permission denied systemd[1]: cloud-init-hotplugd.socket: Failed with result 'resources'. systemd[1]: Failed to listen on cloud-init hotplug hook socket. ... setroubleshoot[772]: SELinux is preventing systemd from add_name access on the directory hook-hotplug-cmd. For complete SELinux messages run: sealert -l 8969a264-6637-489a-a329-0aafc0b8ee3a setroubleshoot[772]: SELinux is preventing systemd from add_name access on the directory hook-hotplug-cmd. * Plugin catchall (100. confidence) suggests ** If you believe that systemd should be allowed add_name access on the hook-hotplug-cmd directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'systemd' --raw | audit2allow -M my-systemd # semodule -X 300 -i my-systemd.pp [rocky@ip-172-31-3-239 ~]$ sestatus SELinux status: enabled SELinuxfs mount:/sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 [rocky@ip-172-31-3-239 ~]$ systemctl status cloud-init-hotplugd.socket ● cloud-init-hotplugd.socket - cloud-init hotplug hook socket Loaded: loaded (/usr/lib/systemd/system/cloud-init-hotplugd.socket; enabled; vendor preset: disabled) Active: failed (Result: resources) Listen: /run/cloud-init/hook-hotplug-cmd (FIFO) Jul 14 03:39:49 ip-172-31-3-239.us-east-2.compute.internal systemd[1]: cloud-init-hotplugd.socket: Failed to listen on sockets: Permission denied Jul 14 03:39:49 ip-172-31-3-239.us-east-2.compute.internal systemd[1]: cloud-init-hotplugd.socket: Failed with result 'resources'. Jul 14 03:39:49 ip-172-31-3-239.us-east-2.compute.internal systemd[1]: Failed to listen on cloud-init hotplug hook socket. [rocky@ip-172-31-3-239 ~]$ systemctl status cloud-init-hotplugd.service ● cloud-init-hotplugd.service - cloud-init hotplug hook daemon Loaded: loaded (/usr/lib/systemd/system/cloud-init-hotplugd.service; static; vendor preset: disabled) Active: inactive (dead) When setting selinux to permissive, we can see no errors from the systemd services [rocky@ip-172-31-3-239 ~]$ sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config [rocky@ip-172-31-3-239 ~]$ sudo cloud-init clean --logs --reboot [rocky@ip-172-31-3-239 ~]$ sestatus SELinux status: enabled SELinuxfs mount:/sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 [rocky@ip-172-31-3-239 ~]$ systemctl status cloud-init-hotplugd.socket ● cloud-init-hotplugd.socket - cloud-init hotplug hook socket Loaded: loaded (/usr/lib/systemd/system/cloud-init-hotplugd.socket; enabled; vendor preset: disabled)
[Yahoo-eng-team] [Bug 1936229] [NEW] selinux cloud-init-hotplugd.socket not having permissions to fifo sockets
Public bug reported: Initial cloud-init-hotplugd.socket has some undesirable interactions with an enforcing SElinux system when trying to listen on a FIFO socket. Deploying on rocky linux 8.4 we can see SELinux errors preventing the cloud-init-hotplugd.socket from starting from journalctl -b 0: systemd[1]: cloud-init-hotplugd.socket: Failed to listen on sockets: Permission denied systemd[1]: cloud-init-hotplugd.socket: Failed with result 'resources'. systemd[1]: Failed to listen on cloud-init hotplug hook socket. ... setroubleshoot[772]: SELinux is preventing systemd from add_name access on the directory hook-hotplug-cmd. For complete SELinux messages run: sealert -l 8969a264-6637-489a-a329-0aafc0b8ee3a setroubleshoot[772]: SELinux is preventing systemd from add_name access on the directory hook-hotplug-cmd. * Plugin catchall (100. confidence) suggests ** If you believe that systemd should be allowed add_name access on the hook-hotplug-cmd directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'systemd' --raw | audit2allow -M my-systemd # semodule -X 300 -i my-systemd.pp [rocky@ip-172-31-3-239 ~]$ sestatus SELinux status: enabled SELinuxfs mount:/sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 [rocky@ip-172-31-3-239 ~]$ systemctl status cloud-init-hotplugd.socket ● cloud-init-hotplugd.socket - cloud-init hotplug hook socket Loaded: loaded (/usr/lib/systemd/system/cloud-init-hotplugd.socket; enabled; vendor preset: disabled) Active: failed (Result: resources) Listen: /run/cloud-init/hook-hotplug-cmd (FIFO) Jul 14 03:39:49 ip-172-31-3-239.us-east-2.compute.internal systemd[1]: cloud-init-hotplugd.socket: Failed to listen on sockets: Permission denied Jul 14 03:39:49 ip-172-31-3-239.us-east-2.compute.internal systemd[1]: cloud-init-hotplugd.socket: Failed with result 'resources'. Jul 14 03:39:49 ip-172-31-3-239.us-east-2.compute.internal systemd[1]: Failed to listen on cloud-init hotplug hook socket. [rocky@ip-172-31-3-239 ~]$ systemctl status cloud-init-hotplugd.service ● cloud-init-hotplugd.service - cloud-init hotplug hook daemon Loaded: loaded (/usr/lib/systemd/system/cloud-init-hotplugd.service; static; vendor preset: disabled) Active: inactive (dead) When setting selinux to permissive, we can see no errors from the systemd services [rocky@ip-172-31-3-239 ~]$ sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config [rocky@ip-172-31-3-239 ~]$ sudo cloud-init clean --logs --reboot [rocky@ip-172-31-3-239 ~]$ sestatus SELinux status: enabled SELinuxfs mount:/sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 [rocky@ip-172-31-3-239 ~]$ systemctl status cloud-init-hotplugd.socket ● cloud-init-hotplugd.socket - cloud-init hotplug hook socket Loaded: loaded (/usr/lib/systemd/system/cloud-init-hotplugd.socket; enabled; vendor preset: disabled) Active: active (listening) since Wed 2021-07-14 03:53:19 UTC; 1min 16s ago Listen: /run/cloud-init/hook-hotplug-cmd (FIFO) Tasks: 0 (limit: 4797) Memory: 0B CGroup: /system.slice/cloud-init-hotplugd.socket Jul 14 03:53:19 ip-172-31-3-239.us-east-2.compute.internal systemd[1]: Listening on cloud-init hotplug hook socket. Attempting to generate a selinux policy for this systemd.socket I get the following: [rocky@ip-172-31-3-239 ~]$ sudo ausearch -c 'systemd' --raw | audit2allow -m
[Yahoo-eng-team] [Bug 1935857] [NEW] cc_ssh: parse_ssh_config_map does not take into account user-specific Match section overrides
Public bug reported: cloud-init 21.2 User-specific Match sections can be provided in /etc/ssh/sshd_config to override global ssh config default settings such as AuthorizedKeysFile. cloud-init's parsing of sshd_config in ssh_util[1] is simplistic and treats each line in the sshd_config file as simple key/value pairs. Any Match sections defined below a global AuthorizedKeysFile setting will be overridden to the line containing an AuthorizedKeysFile definition, even if that definition should only be scoped to a specific user Match. Here is an example adding a specific Match section which should only apply non-default AuthorizedKeysFile to the "custom" user, and how cloud-init incorrectly represents that content. $ cat sshd_bad_parse.yaml
[Yahoo-eng-team] [Bug 1732522] Re: [2.3] Ephemeral boot environment does not renew DHCP leases
** 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/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/~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 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
** Changed in: cloud-init (Ubuntu Hirsute)
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/1910835
Title:
Azure IMDS publicKeys contain \r\n which prevents ssh access to vms
using cloud-generated ssh keys.
Status in cloud-init:
Confirmed
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Committed
Status in cloud-init source package in Bionic:
Fix Committed
Status in cloud-init source package in Focal:
Fix Committed
Status in cloud-init source package in Groovy:
Fix Committed
Status in cloud-init source package in Hirsute:
Fix Released
Bug description:
== Begin SRU Template ==
[Impact]
The previous version of cloud-init used OpenSSL to process the SSH keys
provided by the Azure platform. cloud-init 20.4 replaced that code with a more
efficient implementation, but one which did not use OpenSSL: this meant that
users passing certificates to instances, or users generating SSH keys in
Azure's web UI (which inserts \r\n sequences into the public key content), were
regressed: their certificates and malformed SSH keys were no longer handled, so
they could fail to gain access to newly-launched instances.
This release is only a single functional cherry-pick which solely
affects Azure platform. It is a critical bug we wish to release as
soon as possible
* Azure: cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
The functional changeset here introduces a raise KeyError exception
which forces cloud-init to revert to previous released logic of the
previous cloud-init public release 20.3.
[Test Case]
As this is a single commit backport, the cloud-init SRU exception need
not apply. An upstream integration test has been written for this
issue (https://github.com/canonical/cloud-
init/blob/master/tests/integration_tests/bugs/test_lp1910835.py).
A full run of the upstream test suite on Azure will therefore
regression test the update generally and test this issue specifically:
a log of a test run for each suite will be attached.
[Regression Potential]
The proposed change only modifies code paths used on Azure,
specifically to revert to a previous behaviour: users unaffected by
the bug should see no change (their keys will get to their instance
via a different route), and users affected by the bug would have been
unable to access their instances before (so cannot be relying on this
behaviour in a way which we could break by fixing it).
[Discussion]
This should only affect public Azure VM launched which use Azure to
--generate-ssh-keys either from the dashboard or from the `az cli`
Any other cloud-platform is not affected by this change.
== End SRU Template ==
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
== Original Description ==
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing
to generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines
when it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without
processing the string, resulting in an invalid keyline:
ssh-rsa B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d
k/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R^M
9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW^M
lkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq^M
4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7^M
[Yahoo-eng-team] [Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Hirsute)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Groovy)
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/1910835
Title:
Azure IMDS publicKeys contain \r\n which prevents ssh access to vms
using cloud-generated ssh keys.
Status in cloud-init:
Confirmed
Status in cloud-init package in Ubuntu:
New
Status in cloud-init source package in Xenial:
New
Status in cloud-init source package in Bionic:
New
Status in cloud-init source package in Focal:
New
Status in cloud-init source package in Groovy:
New
Status in cloud-init source package in Hirsute:
New
Bug description:
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing
to generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines
when it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without processing
the string, resulting in an invalid keyline:
ssh-rsa B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d
k/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R^M
9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW^M
lkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq^M
4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7^M
6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu^M
iKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht^M
6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9^M
S2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU= generated-by-azure
this prevents ssh from actually reading the right key from azure:
$ ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys
If we strip the CRLF (^M) characters and reparse with ssh-keygenm we
see the proper key registered:
$ ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys
3072 SHA256:PQ9EKxTKONJKFC2N56UpL6+Oc/cujfA9HpsF5VW2QDI generated-by-azure
(RSA)
If cloud-init (or IMDS) were to strip those \r\n characters from each
line ssh
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1910835/+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 1910835] [NEW] Auzre IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
Public bug reported:
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing to
generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines when
it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without processing
the string, resulting in an invalid keyline:
ssh-rsa B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d
k/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R^M
9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW^M
lkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq^M
4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7^M
6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu^M
iKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht^M
6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9^M
S2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU= generated-by-azure
this prevents ssh from actually reading the right key from azure:
$ ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys
If we strip the CRLF (^M) characters and reparse with ssh-keygenm we see
the proper key registered:
$ ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys
3072 SHA256:PQ9EKxTKONJKFC2N56UpL6+Oc/cujfA9HpsF5VW2QDI generated-by-azure (RSA)
If cloud-init (or IMDS) were to strip those \r\n characters from each
line ssh
** Affects: cloud-init
Importance: Critical
Status: Confirmed
--
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/1910835
Title:
Auzre IMDS publicKeys contain \r\n which prevents ssh access to vms
using cloud-generated ssh keys.
Status in cloud-init:
Confirmed
Bug description:
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing
to generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines
when it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without processing
the string, resulting in an invalid keyline:
ssh-rsa B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d
k/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R^M
9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW^M
lkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq^M
4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7^M
6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu^M
iKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht^M
[Yahoo-eng-team] [Bug 1788915] Re: sysconfig renders vlan with TYPE=Ethernet
This bug is believed to be fixed in cloud-init in version 20.4. 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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1788915 Title: sysconfig renders vlan with TYPE=Ethernet Status in cloud-init: Fix Released Bug description: Distribution: Fedora 28 Cloud provider: None Network content of /etc/cloud/cloud.cfg.d/99_datasource.cfg (omitting users, etc.): network: version: 1 config: - type: physical name: lan1 mac_address: 0c:c4:7a:db:dc:b0 - type: vlan name: lan1.100 vlan_link: lan1 vlan_id: 100 subnets: - type: static address: 192.168.0.2/24 gateway: 192.168.0.1 dns_nameservers: - 8.8.8.8 - 8.8.4.4 - type: vlan name: lan1.3900 vlan_link: lan1 vlan_id: 3900 subnets: - type: static address: 10.1.0.2/16 gateway: I am unable to attach logs (no network connection). $ cloud-init --version /usr/bin/cloud-init 17.1 The sysconfig renderer leaves the configured "kind" set to the default (ethernet), which results in a config file with "TYPE=Ethernet", which is incorrect and results in the VLAN interface not being created. $ cat ifcfg-lan1.100 # Created by cloud-init on instance boot automatically, do not edit. # BOOTPROTO=none DEFROUTE=yes DEVICE=lan1.100 GATEWAY=192.168.0.1 IPADDR=192.168.0.2 NETMASK=255.255.255.0 ONBOOT=yes PHYSDEV=lan1 TYPE=Ethernet USERCTL=no VLAN=yes $ ifup lan1.100 Error: Connection activation failed: No suitable device found for this connection. Removing the offending "TYPE=Ethernet" line from the config file resolves the problem (as does changing it to "TYPE=Vlan"). I altered my configuration to use version 2 of the network configuration data with identical results (problem is in renderer). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1788915/+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 1776958] Re: error creating lxdbr0.
This bug is believed to be fixed in cloud-init in version 20.4. 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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1776958 Title: error creating lxdbr0. Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: $ cat > my.yaml <) failed cloudinit.util.ProcessExecutionError: Unexpected error while running command. Stderr: Error: The network already exists To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1776958/+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 1813396] Re: gpg called without no-tty
This bug is believed to be fixed in cloud-init in version 20.4. 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: Confirmed => 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/1813396
Title:
gpg called without no-tty
Status in cloud-init:
Fix Released
Bug description:
I am running cloud-init on a libvirt/virsh with this image:
https://cdimage.debian.org/cdimage/openstack/archive/9.6.5-20190122/debian-9.6.5-20190122
-openstack-amd64.qcow2
the relevant lines are:
apt:
sources:
docker:
source: 'deb [arch=amd64] https://download.docker.com/linux/debian
stretch stable'
keyserver: keyserver.ubuntu.com
keyid: 0EBFCD88
sorry for not attaching any bugs, but the triggered command just does
not find "/dev/tty")
The gpg wrapper should have the "no-tty" argument for receiving key at least
on debian systems.
Otherwise cloudinit fails when specifying key-ids on debian cloudimages (with
manually added dirmngr and apt-transport-https, it is quite a mess on the
openstack debian images...)
I would naively propose the following patch:
diff --git a/cloudinit/gpg.py b/cloudinit/gpg.py
index 7fe17a2..21d598e 100644
--- a/cloudinit/gpg.py
+++ b/cloudinit/gpg.py
@@ -42,7 +42,7 @@ def recv_key(key, keyserver, retries=(1, 1)):
@param retries: an iterable of sleep lengths for retries.
Use None to indicate no retries."""
LOG.debug("Importing key '%s' from keyserver '%s'", key, keyserver)
-cmd = ["gpg", "--keyserver=%s" % keyserver, "--recv-keys", key]
+cmd = ["gpg", "--no-tty", "--keyserver=%s" % keyserver, "--recv-keys",
key]
if retries is None:
retries = []
trynum = 0
BR
Till
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1813396/+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 1897915] Re: ntp service on centos is ntp.service, but cloud-init uses nptd.service
This bug is believed to be fixed in cloud-init in version 20.4. 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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1897915 Title: ntp service on centos is ntp.service, but cloud-init uses nptd.service Status in cloud-init: Fix Released Bug description: The ntp (client) service file installed by the centos 7 'ntp' package is named 'ntpd' (note the d), but cloud-init's cc_ntp module identifies that 'service_name' as 'ntp'. See below on centos 7. For centos 8, there is no 'ntp' package that I see, it seems to have been replaced by chrony. [root@cent71 ~]# rpm -ql ntp | grep systemd /usr/lib/systemd/ntp-units.d/60-ntpd.list /usr/lib/systemd/system/ntpd.service [root@cent71 ~]# systemctl status ntp.service Unit ntp.service could not be found. [root@cent71 ~]# systemctl cat ntp.service No files found for ntp.service. [root@cent71 ~]# systemctl cat ntpd.service # /usr/lib/systemd/system/ntpd.service [Unit] Description=Network Time Service After=syslog.target ntpdate.service sntp.service [Service] Type=forking EnvironmentFile=-/etc/sysconfig/ntpd ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS PrivateTmp=true [Install] WantedBy=multi-user.target To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1897915/+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 1885527] Re: cloud-init regenerating ssh-keys
This bug is believed to be fixed in cloud-init in version 20.4. 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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1885527 Title: cloud-init regenerating ssh-keys Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: In Progress Bug description: Hi, I made some experiments with virtual machines with Ubuntu-20.04 at a german cloud provider (Hetzner), who uses cloud-init to initialize machines with a basic setup such as ip and ssh access. During my installation tests I had to reboot the virtual machines several times after installing or removing packages. Occassionally (not always) I noticed that the ssh host keys have changed, ssh complained. After accepting the new host keys (insecure!) I found, that all key files in /etc/ssh had fresh mod times, i.e. were freshly regenerated. This reminds me to a bug I had reported about cloud-init some time ago, where I could not change the host name permanently, because cloud-init reset it to it's initial configuration at every boot time (highly dangerous, because it seemed to reset passwords to their original state as well. Although cloud-init is intended to do an initial configuration for the first boot only, it seems to remain on the system and – even worse: occasionally – change configurations. I've never understood what's the purpose of cloud-init remaining active once after the machine is up and running. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1885527/+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 1826608] Re: sysconfig rendering ignores vlan name
This bug is believed to be fixed in cloud-init in version 20.4. 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: In Progress => 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/1826608 Title: sysconfig rendering ignores vlan name Status in cloud-init: Fix Released Bug description: sysconfig rendering currently just does not pay attention to the vlan device's name. Instead it attempts to set the name to the backing device with .* stripped from the end. Here is an example of current master output. The 'PHYSDEV' entry should be 'eth0', not 'infra'. $ cat my2.yaml version: 2 ethernets: eth0: addresses: ["192.10.1.2/24"] match: macaddress: "00:16:3e:60:7c:df" vlans: infra0: id: 1001 link: eth0 addresses: ["10.0.1.2/16"] $ tox-venv py3 python3 -m cloudinit.cmd.main devel net-convert \ --mac en0,00:16:3e:60:7c:df \ --network-data=my2.yaml --kind=yaml \ --distro=centos --output-kind=sysconfig \ --directory=out.test $ cat out.test/etc/sysconfig/network-scripts/ifcfg-eth0 # Created by cloud-init on instance boot automatically, do not edit. # BOOTPROTO=none DEVICE=eth0 HWADDR=00:16:3e:60:7c:df IPADDR=192.10.1.2 NETMASK=255.255.255.0 NM_CONTROLLED=no ONBOOT=yes STARTMODE=auto TYPE=Ethernet USERCTL=no $ cat out.test/etc/sysconfig/network-scripts/ifcfg-infra0 # Created by cloud-init on instance boot automatically, do not edit. # BOOTPROTO=none DEVICE=infra0 IPADDR=10.0.1.2 NETMASK=255.255.0.0 NM_CONTROLLED=no ONBOOT=yes PHYSDEV=infra STARTMODE=auto TYPE=Ethernet USERCTL=no VLAN=yes To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1826608/+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 1895976] Re: Fail to get http openstack metadata if the Linux instance runs on Hyper-V
This bug is believed to be fixed in cloud-init in version 20.4. 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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1895976 Title: Fail to get http openstack metadata if the Linux instance runs on Hyper-V Status in cloud-init: Fix Released Status in compute-hyperv: New Status in OpenStack Compute (nova): In Progress Status in os-win: Fix Committed Bug description: Because of the commit that introduced platform checks for enabling / using http openstack metadata (https://github.com/canonical/cloud- init/commit/1efa8a0a030794cec68197100f31a856d0d264ab), cloud-init on Linux machines will stop loading http metadata when running on "unsupported" platforms / hypervisors like Hyper-V, XEN, OracleCloud, VMware, OpenTelekomCloud - leading to a whole suite of bug reports and fixes to a non-issue. Let's try to solve this problem once for all the upcoming platforms / hypervisors by adding a configuration option on the metadata level: perform_platform_check or check_if_platform_is_supported (suggestions are welcome for the naming). The value of the config option should be true in order to maintain backwards compatibility. When set to true, cloud-init will check if the platform is supported. No one would like to patch well-working OpenStack environments for this kind of issues and it is always easier to control / build the images you use on private OpenStack. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1895976/+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 1895979] Re: New cloud-init config modules for PowerVM Hypervisor based VMs
This bug is believed to be fixed in cloud-init in version 20.4. 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: In Progress => 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/1895979 Title: New cloud-init config modules for PowerVM Hypervisor based VMs Status in cloud-init: Fix Released Bug description: Linux Virtual Machines deployed (with ppcle architecture), using IBM PowerVM[1] Hypervisor on IBM Power System hosts, need an additional component (referred to as RMC - Remote Management Console) to be installed and successfully running on the VM. This RMC module/service must be installed and functioning on a ppcle VM, for the PowerVM Hypervisor to be able to communicate / manage these Virtual Machines. When a VM boots, there are some basic set of steps(generation of unique RMC node id; subsequent restart of the RMC service etc), that must be performed on a ppcle VM, to ensure that the communication of the VM and PowerVM Hypervisor is intact. RMC has to be active on the VM for the hypervisor to be able to perform many operations successfully. Thus a healthy RMC is a prerequisite for a PowerVM hypervisor based VM. To enable the healthy functioning of RMC services on ppcle Linux based VMs, there are couple of cloud-init config modules that we have been maintaining downstream. As part of this LP bug, we would like to upstream it, so that it benefits the larger community who is using PowerVM based VMs. References: [1] https://developer.ibm.com/depmodels/cloud/articles/cl-hypervisorcompare-powervm/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1895979/+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 1897099] Re: create_swap do not fallback to dd when fallocate fails
This bug is believed to be fixed in cloud-init in version 20.4. 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: In Progress => 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/1897099
Title:
create_swap do not fallback to dd when fallocate fails
Status in cloud-init:
Fix Released
Bug description:
Name: cloud-init
Version : 20.2-1
Code in questioning: cloudinit/config/cc_mounts.py
try:
create_swap(fname, size, "fallocate")
except util.ProcessExecutionError as e:
LOG.warning(errmsg, fname, size, "dd", e)
LOG.warning("Will attempt with dd.")
create_swap(fname, size, "dd")
as there is a kernel bug in latest's linux versions, fallocate creates swap
images with holes.
The workaround is to move fallocate (make create_swap function to fail) so
that cloud-init will fallback to dd.
Used bootcmd (or cloud-boothook) to rename (move) fallocate binary from my
system but according the the logs, it didnt fallback to dd as it should.
Probably the error was not ProcessExecutionError
Logs:
/var/log/cloud-init-output.log:2020-09-24 09:13:16,470 -
cc_mounts.py[WARNING]: Failed to create swapfile '/swapfile' of size 2048MB via
fallocate: Unexpected
error while running command.
/var/log/cloud-init-output.log:Command: ['fallocate', '-l', '2048M',
'/swapfile']
/var/log/cloud-init-output.log:Reason: [Errno 2] No such file or directory:
b'fallocate'
/var/log/cloud-init-output.log:2020-09-24 09:13:16,479 -
cc_mounts.py[WARNING]: failed to setup swap: [Errno 2] No such file or
directory: '/swapfile'
/var/log/cloud-init-output.log:chmod: cannot access '/usr/bin/fallocate': No
such file or directory
/var/log/cloud-init.log:2020-09-24 09:13:16,460 - cc_mounts.py[DEBUG]:
Attempting to determine the real name of swap
/var/log/cloud-init.log:2020-09-24 09:13:16,460 - cc_mounts.py[DEBUG]:
changed default device swap => None
/var/log/cloud-init.log:2020-09-24 09:13:16,460 - cc_mounts.py[DEBUG]:
Ignoring nonexistent default named mount swap
/var/log/cloud-init.log:2020-09-24 09:13:16,461 - cc_mounts.py[DEBUG]:
suggest 2048.0 MB swap for 1983.953125 MB memory with '9030.296875 MB' disk
given max=2048.0 MB [max=2048.0 MB]'
/var/log/cloud-init.log:2020-09-24 09:13:16,461 - cc_mounts.py[DEBUG]:
Creating swapfile in '/swapfile' on fstype 'ext4' using 'fallocate'
/var/log/cloud-init.log:2020-09-24 09:13:16,461 - util.py[DEBUG]: Running
command ['fallocate', '-l', '2048M', '/swapfile'] with allowed return codes [0]
(she
ll=False, capture=True)
/var/log/cloud-init.log:2020-09-24 09:13:16,470 - cc_mounts.py[WARNING]:
Failed to create swapfile '/swapfile' of size 2048MB via fallocate: Unexpected
error while running command.
/var/log/cloud-init.log:Command: ['fallocate', '-l', '2048M', '/swapfile']
/var/log/cloud-init.log:Reason: [Errno 2] No such file or directory:
b'fallocate'
/var/log/cloud-init.log:2020-09-24 09:13:16,479 - util.py[DEBUG]: Attempting
to remove /swapfile
/var/log/cloud-init.log:2020-09-24 09:13:16,479 - util.py[DEBUG]: Setting up
swap file took 0.019 seconds
/var/log/cloud-init.log:2020-09-24 09:13:16,479 - cc_mounts.py[WARNING]:
failed to setup swap: [Errno 2] No such file or directory: '/swapfile'
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1897099/+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 1898997] Re: MAAS cannot deploy/boot if OVS bridge is configured on a single PXE NIC
This bug is believed to be fixed in cloud-init in version 20.4. 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 Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1898997
Title:
MAAS cannot deploy/boot if OVS bridge is configured on a single PXE
NIC
Status in cloud-init:
Fix Released
Status in netplan:
Fix Released
Status in netplan.io package in Ubuntu:
Fix Released
Status in netplan.io source package in Focal:
Fix Released
Status in netplan.io source package in Groovy:
Fix Released
Bug description:
Problem description:
If we try to deploy a single-NIC machine via MAAS, configuring an Open
vSwitch bridge as the primary/PXE interface, the machine will install and boot
Ubuntu 20.04 but it cannot finish the whole configuration (e.g. copying of SSH
keys) and cannot be accessed/controlled via MAAS. It ends up in a "Failed"
state.
This is because systemd-network-wait-online.service fails (for some
reason), before netplan can fully setup and configure the OVS bridge.
Because of broken networking cloud-init cannot complete its final
stages, like setup of SSH keys or signaling its state back to MAAS. If
we wait a little longer the OVS bridge will actually come online and
networking is working – SSH not being setup and MAAS state still
"Failed", though.
Steps to reproduce:
* Setup a (virtual) MAAS system, e.g. inside a LXD container using a KVM
host, as described here:
https://discourse.maas.io/t/setting-up-a-flexible-virtual-maas-test-environment/142
* Install & setup maas[-cli] snap from 2.9/beta channel (instead of the
deb/PPA from the discourse post)
* Configure netplan PPA+key for testing via "Settings" -> "Package repos":
https://launchpad.net/~slyon/+archive/ubuntu/ovs
* Prepare curtin preseed in /var/snap/maas/current/preseeds/curtin_userdata,
inside the LXD container (so you can access the broken machine afterwards):
==
#cloud-config
debconf_selections:
maas: |
{{for line in str(curtin_preseed).splitlines()}}
{{line}}
{{endfor}}
late_commands:
maas: [wget, '--no-proxy', '{{node_disable_pxe_url}}', '--post-data',
'{{node_disable_pxe_data}}', '-O', '/dev/null']
90_create_user: ["curtin", "in-target", "--", "sh", "-c", "sudo useradd
test -g 0 -G sudo"]
92_set_user_password: ["curtin", "in-target", "--", "sh", "-c", "echo
'test:test' | sudo chpasswd"]
94_cat: ["curtin", "in-target", "--", "sh", "-c", "cat /etc/passwd"]
98_cloud_init: ["curtin", "in-target", "--", "apt-get", "-y", "install",
"cloud-init"]
==
* Compose a new virtual machine via MAAS' "KVM" menu, named e.g. "test1"
* Watch it being commissioned via MAAS' "Machines" menu
* Once it's ready select your machine (e.g. "test1.maas") -> Network
* Select the single network interface (e.g. "ens4") -> Create bridge
* Choose "Bridge type: Open vSwitch (ovs)", Select "Subnet" and "IP mode",
save.
* Deploy machine to Ubuntu 20.04 via "Take action" button
The machine will install the OS and boot, but will end up in a
"Failed" state inside MAAS due to network/OVS not being setup
correctly. MAAS/SSH has no control over it. You can access the
(broken) machine via serial console from the KVM-host (i.e. LXD
container) via "virsh console test1" using the "test:test"
credentials.
=== SRU/Focal/netplan.io ===
[Impact]
This update contains bug-fixes and packaging improvements and we would like
to make sure all of our supported customers have access to these improvements.
The notable ones are:
* Setup OVS early in network-pre.target to avoid delays (LP:
#1898997)
See the changelog entry below for a full list of changes and bugs.
[Test Case]
The following development and SRU process was followed:
https://wiki.ubuntu.com/NetplanUpdates
Netplan contains an extensive integration test suite that is ran using
the SRU package for each releases. This test suite's results are available
here:
http://autopkgtest.ubuntu.com/packages/n/netplan.io
A successful run is required before the proposed netplan package
can be let into -updates.
The netplan team will be in charge of attaching the artifacts and console
output of the appropriate run to the bug. Netplan team members will not
mark ‘verification-done’ until this has happened.
[Regression Potential]
In order to mitigate the regression potential, the results of the
aforementioned integration tests are attached to this bug.
Focal:
https://git.launchpad.net/~slyon/+git/files/tree/LP1898997/focal_amd64.log
https://git.launchpad.net/~slyon/+git/files/tree/LP1898997/focal_arm64.log
https://git.launchpad.net/~slyon/+git/files/tree/LP1898997/focal_armhf.log
[Yahoo-eng-team] [Bug 1900837] Re: cloud-init resets permissions on log file after reboot
This bug is believed to be fixed in cloud-init in version 20.4. 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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1900837 Title: cloud-init resets permissions on log file after reboot Status in cloud-init: Fix Released Bug description: In attempting to apply CIS security guidelines onto an Ubuntu system it was found that changing the log files in /var/log to 640, that on a reboot cloud-init would reset the permissions to 644. As long as cloud-init can write to the file it should be ok to alter the permissions without issue. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1900837/+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 1901958] Re: FreeBSD fix fs related bugs
This bug is believed to be fixed in cloud-init in version 20.4. 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: In Progress => 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/1901958
Title:
FreeBSD fix fs related bugs
Status in cloud-init:
Fix Released
Bug description:
1) FreeBSD not support vfat use msdosfs
Original report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250496
"Feel free to submit upstream if you have signed the CLA. I do not want to
sign it."
2) if fs have trim: (-t) or MAC multilabel: (-l) flag, resize FS fail.
https://www.freebsd.org/cgi/man.cgi?query=tunefs=8
2020-10-28 17:15:07,015 - handlers.py[DEBUG]: finish:
init-network/config-resizefs: FAIL: running config-resizefs with frequency
always
...
File
"/usr/local/lib/python3.7/site-packages/cloudinit/config/cc_resizefs.py", line
114, in _can_skip_resize_ufs
optlist, _args = getopt.getopt(newfs_cmd[1:], opt_value)
File "/usr/local/lib/python3.7/getopt.py", line 95, in getopt
opts, args = do_shorts(opts, args[0][1:], shortopts, args[1:])
File "/usr/local/lib/python3.7/getopt.py", line 195, in do_shorts
if short_has_arg(opt, shortopts):
File "/usr/local/lib/python3.7/getopt.py", line 211, in short_has_arg
raise GetoptError(_('option -%s not recognized') % opt, opt)
getopt.GetoptError: option -t not recognized
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1901958/+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 1905440] Re: Release 20.4
This bug is believed to be fixed in cloud-init in version 20.4. 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: In Progress => 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/1905440 Title: Release 20.4 Status in cloud-init: Fix Released Bug description: == Release Notes == Cloud-init release 20.4 is now available The 20.4 release: * spanned about 3 months * had 29 contributors from 31 domains * fixed 14 Launchpad issues Highlights: - Azure ability to hot-attach NICs to preprovisioned VMs before reprovisioning - Additional Azure failure handling - Add NoCloud seed from vendordata - Ability to blacklist network interfaces based on driver - New IBM PowerVM specific RMC module - Allow OVS bridge as primary interface - add cli "--system" param to allow validating system user-data - Support configuring SSH host certificates - New integration testing framework == Changelog == - tox: avoid tox testenv subsvars for xenial support (#684) - Ensure proper root permissions in integration tests (#664) [James Falcon] - LXD VM support in integration tests (#678) [James Falcon] - Integration test for fallocate falling back to dd (#681) [James Falcon] - .travis.yml: correctly integration test the built .deb (#683) - Ability to hot-attach NICs to preprovisioned VMs before reprovisioning (#613) [aswinrajamannar] - Support configuring SSH host certificates. (#660) [Jonathan Lung] - add integration test for LP: #1900837 (#679) - cc_resizefs on FreeBSD: Fix _can_skip_ufs_resize (#655) [Mina Galić] (LP: #1901958, #1901958) - DataSourceAzure: push dmesg log to KVP (#670) [Anh Vo] - Make mount in place for tests work (#667) [James Falcon] - integration_tests: restore emission of settings to log (#657) - DataSourceAzure: update password for defuser if exists (#671) [Anh Vo] - tox.ini: only select "ci" marked tests for CI runs (#677) - Azure helper: Increase Azure Endpoint HTTP retries (#619) [Johnson Shi] - DataSourceAzure: send failure signal on Azure datasource failure (#594) [Johnson Shi] - test_persistence: simplify VersionIsPoppedFromState (#674) - only run a subset of integration tests in CI (#672) - cli: add --system param to allow validating system user-data on a machine (#575) - test_persistence: add VersionIsPoppedFromState test (#673) - introduce an upgrade framework and related testing (#659) - add --no-tty option to gpg (#669) [Till Riedel] (LP: #1813396) - Pin pycloudlib to a working commit (#666) [James Falcon] - DataSourceOpenNebula: exclude SRANDOM from context output (#665) - cloud_tests: add hirsute release definition (#662) - split integration and cloud_tests requirements (#652) - faq.rst: add warning to answer that suggests running `clean` (#661) - Fix stacktrace in DataSourceRbxCloud if no metadata disk is found (#632) [Scott Moser] - Make wakeonlan Network Config v2 setting actually work (#626) [dermotbradley] - HACKING.md: unify network-refactoring namespace (#658) [Mina Galić] - replace usage of dmidecode with kenv on FreeBSD (#621) [Mina Galić] - Prevent timeout on travis integration tests. (#651) [James Falcon] - azure: enable pushing the log to KVP from the last pushed byte (#614) [Moustafa Moustafa] - Fix launch_kwargs bug in integration tests (#654) [James Falcon] - split read_fs_info into linux & freebsd parts (#625) [Mina Galić] - PULL_REQUEST_TEMPLATE.md: expand commit message section (#642) - Make some language improvements in growpart documentation (#649) [Shane Frasier] - Revert ".travis.yml: use a known-working version of lxd (#643)" (#650) - Fix not sourcing default 50-cloud-init ENI file on Debian (#598) [WebSpider] - remove unnecessary reboot from gpart resize (#646) [Mina Galić] - cloudinit: move dmi functions out of util (#622) [Scott Moser] - integration_tests: various launch improvements (#638) - test_lp1886531: don't assume /etc/fstab exists (#639) - Remove Ubuntu restriction from PR template (#648) [James Falcon] - util: fix mounting of vfat on *BSD (#637) [Mina Galić] - conftest: improve docstring for disable_subp_usage (#644) - doc: add example query commands to debug Jinja templates (#645) - Correct documentation and testcase data for some user-data YAML (#618) [dermotbradley] - Hetzner: Fix instance_id / SMBIOS serial comparison (#640) [Markus Schade] - .travis.yml: use a known-working version of lxd (#643) - tools/build-on-freebsd: fix comment explaining purpose of the script (#635) [Mina Galić] - Hetzner: initialize instance_id from system-serial-number (#630) [Markus Schade] (LP: #1885527)
[Yahoo-eng-team] [Bug 1889938] [NEW] cmd: cloud-init query fails for juju units with UnicodeDecodeError
Public bug reported: sudo cloud-init query --all fails on juju deployed units with the following trace: On some platforms (juju deployed instances and various openstack platforms), user-data is compressed when provided to the instance. When deploying juju units in ec2 regions, user-data provided to the instance is gzip compressed. The cloud-init query command attempts to load, decode and read raw userdata content from /var/lib/cloud/instance/user-data.txt. In cases where the user-data is gzip compressed, decoding fails. Instead of reading raw user-data from /var/lib/cloud/instance/user-data.txt, cloud-init query command should read the already decompressed/decoded data /var/lib/cloud/instance/user-data.txt.i if present. ** Affects: cloud-init Importance: Medium Status: Triaged ** Changed in: cloud-init Status: New => Triaged ** Changed in: cloud-init Importance: Undecided => Medium -- 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/1889938 Title: cmd: cloud-init query fails for juju units with UnicodeDecodeError Status in cloud-init: Triaged Bug description: sudo cloud-init query --all fails on juju deployed units with the following trace: On some platforms (juju deployed instances and various openstack platforms), user-data is compressed when provided to the instance. When deploying juju units in ec2 regions, user-data provided to the instance is gzip compressed. The cloud-init query command attempts to load, decode and read raw userdata content from /var/lib/cloud/instance/user-data.txt. In cases where the user-data is gzip compressed, decoding fails. Instead of reading raw user-data from /var/lib/cloud/instance/user-data.txt, cloud-init query command should read the already decompressed/decoded data /var/lib/cloud/instance/user-data.txt.i if present. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1889938/+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 1885598] [NEW] schema: tracecback when using schema --annotate on single line dicts
Public bug reported: Annotate doesn't handle r-value dicts that begin on the same line as the l-value key. Given the following example invalid cloudconfig (providing an int for a string value in chef), we get a traceback when trying to annotate the invalid user-data. cat > invalid-chef-traceback.yaml < invalid-chef.yaml < return_value = main(sys.argv) File "/home/csmith/src/cloud-init/cloudinit/cmd/main.py", line 891, in main retval = util.log_time( File "/home/csmith/src/cloud-init/cloudinit/util.py", line 2285, in log_time ret = func(*args, **kwargs) File "/home/csmith/src/cloud-init/cloudinit/config/schema.py", line 444, in handle_schema_args validate_cloudconfig_file( File "/home/csmith/src/cloud-init/cloudinit/config/schema.py", line 219, in validate_cloudconfig_file print(annotated_cloudconfig_file( File "/home/csmith/src/cloud-init/cloudinit/config/schema.py", line 151, in annotated_cloudconfig_file errors_by_line[schemapaths[path]].append(msg) KeyError: 'chef.install_type' ** Affects: cloud-init Importance: Undecided Status: Confirmed ** Changed in: cloud-init Status: New => Triaged ** Changed in: cloud-init Status: Triaged => Confirmed -- 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/1885598 Title: schema: tracecback when using schema --annotate on single line dicts Status in cloud-init: Confirmed Bug description: Annotate doesn't handle r-value dicts that begin on the same line as the l-value key. Given the following example invalid cloudconfig (providing an int for a string value in chef), we get a traceback when trying to annotate the invalid user-data. cat > invalid-chef-traceback.yaml < invalid-chef.yaml < return_value = main(sys.argv) File "/home/csmith/src/cloud-init/cloudinit/cmd/main.py", line 891, in main retval = util.log_time( File "/home/csmith/src/cloud-init/cloudinit/util.py", line 2285, in log_time ret = func(*args, **kwargs) File "/home/csmith/src/cloud-init/cloudinit/config/schema.py", line 444, in handle_schema_args validate_cloudconfig_file( File "/home/csmith/src/cloud-init/cloudinit/config/schema.py", line 219, in validate_cloudconfig_file print(annotated_cloudconfig_file( File "/home/csmith/src/cloud-init/cloudinit/config/schema.py", line 151, in annotated_cloudconfig_file errors_by_line[schemapaths[path]].append(msg) KeyError: 'chef.install_type' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1885598/+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 1882907] Re: Cloud-init fails to rename device if mac address in the new config contains only numbers
Thank you for the bug Asaf and making cloud-init better.
It seems like your nocloud network-config YAML file exposed to your vm in the
file
"Read 120 bytes from /run/cloud-init/tmp/tmpb_430skf//network-config"
... represents the mac_address value as an integer.
2020-06-10 06:56:30,126 - stages.py[DEBUG]: applying net config names
for {'version': 1, 'config': [{'type': 'physical', 'name': 'eth0',
'mac_address': 41120542311, 'subnets': [{'type': 'dhcp'}]}]}
https://cloudinit.readthedocs.io/en/latest/topics/network-config-
format-v1.html
cloud-init suggests in network config docs above that mac_address values
should be colon-delimited values such as 04:11:20:54:23:11. Also, the
network-config file is read as yaml, any integer-only values present in
yaml will be interpreted as an int instead of strings. To ensure yaml
sees an integer value as a string you would need either single quotes or
double quotes around a value.
Since this network-config does not conform to cloud-init's documeted
network config v1 for mac_address, I don't believe we will be addressing
this feature request upstream as most tooling generally sees and
represents mac addresses as colon-delimited values for readability
instead of a squashed string of 12 hex-digits.
Again thanks for the report, please feel free to reopen if we are
missing a significant use-case here that should be better handled.
** Changed in: cloud-init
Status: New => Won't Fix
--
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/1882907
Title:
Cloud-init fails to rename device if mac address in the new config
contains only numbers
Status in cloud-init:
Won't Fix
Bug description:
On CentOS8, Cloud-init fails to rename device if the new mac address
config contains only numbers.
rpm -qa | grep cloud-init
cloud-init-18.5-7.el8_1.1.noarch
journalctl -u cloud-init
-- Logs begin at Tue 2020-06-02 08:42:02 UTC, end at Tue 2020-06-02 09:04:00
UTC. --
Jun 02 08:42:28 sa-engine.asrachmani.com systemd[1]: Starting Initial
cloud-init job (metadata service crawler)...
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: Cloud-init v. 18.5
running 'init' at Tue, 02 Jun 2020 08:42:29 +. Up 36.72 seconds.
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info:
+++Net device info+++
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info:
++--+---+---+---+---+
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info: | Device
| Up | Address |Mask | Scope | Hw-Address|
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info:
++--+---+---+---+---+
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info: | enp1s0
| True | . | . | . | 52:52:52:52:51:51 |
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info: | lo
| True | 127.0.0.1 | 255.0.0.0 | host | . |
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info: | lo
| True | ::1/128 | . | host | . |
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info:
++--+---+---+---+---+
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info:
+++Route IPv6 info+++
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info:
+---+-+-+---+---+
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info: | Route |
Destination | Gateway | Interface | Flags |
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info:
+---+-+-+---+---+
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info: | 2 |
ff00::/8 |:: | enp1s0 | U |
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: ci-info:
+---+-+-+---+---+
Jun 02 08:42:29 sa-engine.asrachmani.com cloud-init[1345]: 2020-06-02
08:42:29,933 - stages.py[WARNING]: Failed to rename devices: 'int' object has
no attribute 'lower'
Jun 02 08:42:30 sa-engine.asrachmani.com useradd[1638]: new group:
name=cloud-user, GID=1002
Jun 02 08:42:30 sa-engine.asrachmani.com useradd[1638]: new user:
name=cloud-user, UID=1001, GID=1002, home=/home/cloud-user, shell=/bin/bash
Jun 02 08:42:30 sa-engine.asrachmani.com useradd[1638]: add 'cloud-user' to
group 'adm'
Jun 02 08:42:30 sa-engine.asrachmani.com useradd[1638]: add 'cloud-user' to
group 'wheel'
Jun 02 08:42:30 sa-engine.asrachmani.com useradd[1638]: add 'cloud-user' to
group 'systemd-journal'
Jun 02 08:42:30 sa-engine.asrachmani.com useradd[1638]: add 'cloud-user' to
shadow group
[Yahoo-eng-team] [Bug 1868232] Re: underscores should be stripped from hostnames generated for apt config
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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1868232 Title: underscores should be stripped from hostnames generated for apt config Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Committed Status in cloud-init source package in Focal: Fix Committed Bug description: In a ticket filed in the Ubuntu RT instance we were made aware of an issue where if a cloud is configured with an “_” in the region name, cloud-init will generate an apt configuration that also includes that “_” in the name. So for example if the region name is zone_01, apt will be configured to use zone_01.clouds.archive.ubuntu.com. On Friday March 13th we deployed some new archive servers on 18.04 using Apache 2.4.29-1ubuntu4.13. This version of apache has more strict protocol options than previous versions, per https://httpd.apache.org/docs/2.4/mod/core.html#httpprotocoloptions and the result is that a request to zone_01.clouds.archive.ubuntu.com returns a 400 Bad Request. Could cloud-init be updated to remove non-permitted characters including “_” per https://tools.ietf.org/html/rfc3986#section-3.2.2 ? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1868232/+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 1870370] Re: cloud-init doesn't support NFS in mounts
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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1870370 Title: cloud-init doesn't support NFS in mounts Status in cloud-init: Fix Released Bug description: When trying to mount filesystems that use NFS or EFS (AWS Elastic File System - Amazon's implementation of NFSv4.1), cloud-init will not allow valid NFS mountpoints to added to the fstab. In the event that you try, you'll see mounts configuration is [['fs-10e8d4db:/', '/opt/jenkins_workspace', 'efs', 'defaults,_netdev', 0, 0]] followed by "Attempting to determine the real name of fs-10e8d4ab:/" followed by "Ignorming nonexistant named mount fs-10e8d4ab:/" The problem is that sanitize_devname doesn't understand network mount points. I have a PR in progress to fix the problem. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1870370/+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 1873910] Re: Nightly CI builds are failing because due to missing get_interfaces_by_mac mocking
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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1873910 Title: Nightly CI builds are failing because due to missing get_interfaces_by_mac mocking Status in cloud-init: Fix Released Bug description: get_interfaces_by_mac is currently errorring on the system that runs cloud-init's nightly CI. This indicates missing mocking in the following tests: FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_context_devname FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_emptycontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_nonecontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_withdefaultvalue FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_withdefaultvalue_emptycontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_gateway FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_gateway6 FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6 FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_dual FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_prefix FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_prefix_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_ula FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_mask FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_mask_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_mtu FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_nameservers FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_network FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_network_emptystring FAILED cloudinit/sources/tests/test_oracle.py::TestDataSourceOracle::test_network_cmdline FAILED cloudinit/sources/tests/test_oracle.py::TestDataSourceOracle::test_network_fallback (Sourced from https://jenkins.ubuntu.com/server/job/cloud-init-ci- nightly/712/.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1873910/+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 1872836] Re: Swap file creation broken due to incorrect format specifiers
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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1872836 Title: Swap file creation broken due to incorrect format specifiers Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: Swap file creation currently fails with the following error: cc_mounts.py[WARNING]: failed to setup swap: %d format: a number is required, not str This appears to be fallout from changes from this commit: https://github.com/canonical/cloud-init/commit/6603706 https://github.com/canonical/cloud-init/pull/70 It appears several '%d' format specifiers are being incorrectly paired with a string type variable instead of number type variable. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872836/+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 1868327] Re: RuntimeError: dictionary keys changed during iteration
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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1868327 Title: RuntimeError: dictionary keys changed during iteration Status in cloud-init: Fix Released Bug description: Forwarded from https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=954276 This appears to be a python 3.8 incompatibility. | 2020-03-19 14:31:48,840 - util.py[DEBUG]: Running module disk_setup () failed | Traceback (most recent call last): | File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 848, in _run_modules | ran, _r = cc.run(run_name, mod.handle, func_args, | 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 185, in run | results = functor(*args) | File "/usr/lib/python3/dist-packages/cloudinit/config/cc_disk_setup.py", line 129, in handle | update_disk_setup_devices(disk_setup, cloud.device_name_to_device) | File "/usr/lib/python3/dist-packages/cloudinit/config/cc_disk_setup.py", line 166, in update_disk_setup_devices | for origname in disk_setup.keys(): | RuntimeError: dictionary keys changed during iteration I've attached a small patch that implements a minimal fix for this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1868327/+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 1867029] Re: Package ifupdown breaks network configuration by cloud-init
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 Yahoo! Engineering Team, which is subscribed to cloud-init. 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/~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 1875470] Re: DataSourceNoCloudNet claims to support ftp but does not
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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1875470 Title: DataSourceNoCloudNet claims to support ftp but does not Status in cloud-init: Fix Released Bug description: nocloud-net data source clearly states that ftp:// is supported, but it seems there is zero code to actually handle ftp requests. cloud provider: none kernel cmdline: ds=nocloud-net;s=ftp://192.168.0.123/foo To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1875470/+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 1875951] Re: Release 20.2
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 Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1875951 Title: Release 20.2 Status in cloud-init: Fix Released Bug description: == Release Notes == Cloud-init release 20.2 is now available The 20.2 release: * spanned about 9 weeks * had 20 contributors from 20 domains * fixed 14 Launchpad issues Highlights: New cloud platforms: SAP Converged Cloud New distributions: OpenBSD and NetBSD Ubuntu Focal prioritize netplan over /etc/network/interfaces if both exist Add Support for NFS/EFS mounts Ec2: Render full networking configuration on all attached NICs Add support for apt mirrors for hyphenated cloud regions Expose cloud-init 'merged_cfg' and 'sys_info keys' for use in #cloud-config templates and `cloud-init query` == Changelog == - doc/format: reference make-mime.py instead of an inline script (#334) - Add docs about creating parent folders (#330) [Adrian Wilkins] - DataSourceNoCloud/OVF: drop claim to support FTP (#333) (LP: #1875470) - schema: ignore spurious pylint error (#332) - schema: add json schema for write_files module (#152) - BSD: find_devs_with_ refactoring (#298) [Gonéri Le Bouder] - nocloud: drop work around for Linux 2.6 (#324) [Gonéri Le Bouder] - cloudinit: drop dependencies on unittest2 and contextlib2 (#322) - distros: handle a potential mirror filtering error case (#328) - log: remove unnecessary import fallback logic (#327) - .travis.yml: don't run integration test on ubuntu/* branches (#321) - More unit test documentation (#314) - conftest: introduce disable_subp_usage autouse fixture (#304) - YAML align indent sizes for docs readability (#323) [Tak Nishigori] - network_state: add missing space to log message (#325) - tests: add missing mocks for get_interfaces_by_mac (#326) (LP: #1873910) - test_mounts: expand happy path test for both happy paths (#319) - cc_mounts: fix incorrect format specifiers (#316) (LP: #1872836) - swap file "size" being used before checked if str (#315) [Eduardo Otubo] - HACKING.rst: add pytest version gotchas section (#311) - docs: Add steps to re-run cloud-id and cloud-init (#313) [Joshua Powers] - readme: OpenBSD is now supported (#309) [Gonéri Le Bouder] - net: ignore 'renderer' key in netplan config (#306) (LP: #1870421) - Add support for NFS/EFS mounts (#300) [Andrew Beresford] (LP: #1870370) - openbsd: set_passwd should not unlock user (#289) [Gonéri Le Bouder] - tools/.github-cla-signers: add beezly as CLA signer (#301) - util: remove unnecessary lru_cache import fallback (#299) - HACKING.rst: reorganise/update CLA signature info (#297) - distros: drop leading/trailing hyphens from mirror URL labels (#296) - HACKING.rst: add note about variable annotations (#295) - CiTestCase: stop using and remove sys_exit helper (#283) - distros: replace invalid characters in mirror URLs with hyphens (#291) (LP: #1868232) - rbxcloud: gracefully handle arping errors (#262) [Adam Dobrawy] - Fix cloud-init ignoring some misdeclared mimetypes in user-data. [Kurt Garloff] - net: ubuntu focal prioritize netplan over eni even if both present (#267) (LP: #1867029) - cloudinit: refactor util.is_ipv4 to net.is_ipv4_address (#292) - net/cmdline: replace type comments with annotations (#294) - HACKING.rst: add Type Annotations design section (#293) - net: introduce is_ip_address function (#288) - CiTestCase: remove now-unneeded parse_and_read helper method (#286) - .travis.yml: allow 30 minutes of inactivity in cloud tests (#287) - sources/tests/test_init: drop use of deprecated inspect.getargspec (#285) - setup.py: drop NIH check_output implementation (#282) - Identify SAP Converged Cloud as OpenStack [Silvio Knizek] - add Openbsd support (#147) [Gonéri Le Bouder] - HACKING.rst: add examples of the two test class types (#278) - VMWware: support to update guest info gc status if enabled (#261) [xiaofengw-vmware] - Add lp-to-git mapping for kgarloff (#279) - set_passwords: avoid chpasswd on BSD (#268) [Gonéri Le Bouder] - HACKING.rst: add Unit Testing design section (#277) - util: read_cc_from_cmdline handle urlencoded yaml content (#275) - distros/tests/test_init: add tests for _get_package_mirror_info (#272) - HACKING.rst: add links to new Code Review Process doc (#276) - freebsd: ensure package update works (#273) [Gonéri Le
[Yahoo-eng-team] [Bug 1876414] [NEW] testing: add unittest performing schema validation of example cloud-config in doc/ *.txt
Public bug reported: We have 47-ish documentation examples of useful cloud-config in doc/examples/*txt. We need to ensure each cloud-config example contains the necessary #cloud-config header and add a unit tests which will run cloudinit.config.schema:validate_cloudconfig_schema over all those examples to make sure none or our doc suggestions raise SchemaValidationErrors. ** Affects: cloud-init Importance: Undecided Status: Triaged ** Tags: bitesize -- 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/1876414 Title: testing: add unittest performing schema validation of example cloud- config in doc/ *.txt Status in cloud-init: Triaged Bug description: We have 47-ish documentation examples of useful cloud-config in doc/examples/*txt. We need to ensure each cloud-config example contains the necessary #cloud-config header and add a unit tests which will run cloudinit.config.schema:validate_cloudconfig_schema over all those examples to make sure none or our doc suggestions raise SchemaValidationErrors. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1876414/+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 1876412] [NEW] testing: add unittest coverage for config module json schema examples
Public bug reported: As we implement jsonschema definitions in cloud config modules (cloudinit.config.cc_*.py) we need a unittest which will automatically run schema validation on cc_*.py modules. Add a unittest to tests/unittests/test_handler/test_schema.py that will discover all config modules which contain a 'schema' dictionary defined and run all schema['examples'] through cloudinit.config.schema:validate_cloudconfig_schema to ensure no SchemaValidationErrors are raised by our module documentation. ** Affects: cloud-init Importance: Medium Status: New ** Tags: bitesize -- 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/1876412 Title: testing: add unittest coverage for config module json schema examples Status in cloud-init: New Bug description: As we implement jsonschema definitions in cloud config modules (cloudinit.config.cc_*.py) we need a unittest which will automatically run schema validation on cc_*.py modules. Add a unittest to tests/unittests/test_handler/test_schema.py that will discover all config modules which contain a 'schema' dictionary defined and run all schema['examples'] through cloudinit.config.schema:validate_cloudconfig_schema to ensure no SchemaValidationErrors are raised by our module documentation. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1876412/+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 1875951] [NEW] Release 20.2
Public bug reported: == Release Notes == Cloud-init release 20.2 is now available The 20.2 release: * spanned about 9 weeks * had 20 contributors from 20 domains * fixed 14 Launchpad issues Highlights: == Changelog == - doc/format: reference make-mime.py instead of an inline script (#334) - Add docs about creating parent folders (#330) [Adrian Wilkins] - DataSourceNoCloud/OVF: drop claim to support FTP (#333) (LP: #1875470) - schema: ignore spurious pylint error (#332) - schema: add json schema for write_files module (#152) - BSD: find_devs_with_ refactoring (#298) [Gonéri Le Bouder] - nocloud: drop work around for Linux 2.6 (#324) [Gonéri Le Bouder] - cloudinit: drop dependencies on unittest2 and contextlib2 (#322) - distros: handle a potential mirror filtering error case (#328) - log: remove unnecessary import fallback logic (#327) - .travis.yml: don't run integration test on ubuntu/* branches (#321) - More unit test documentation (#314) - conftest: introduce disable_subp_usage autouse fixture (#304) - YAML align indent sizes for docs readability (#323) [Tak Nishigori] - network_state: add missing space to log message (#325) - tests: add missing mocks for get_interfaces_by_mac (#326) (LP: #1873910) - test_mounts: expand happy path test for both happy paths (#319) - cc_mounts: fix incorrect format specifiers (#316) (LP: #1872836) - swap file "size" being used before checked if str (#315) [Eduardo Otubo] - HACKING.rst: add pytest version gotchas section (#311) - docs: Add steps to re-run cloud-id and cloud-init (#313) [Joshua Powers] - readme: OpenBSD is now supported (#309) [Gonéri Le Bouder] - net: ignore 'renderer' key in netplan config (#306) (LP: #1870421) - Add support for NFS/EFS mounts (#300) [Andrew Beresford] (LP: #1870370) - openbsd: set_passwd should not unlock user (#289) [Gonéri Le Bouder] - tools/.github-cla-signers: add beezly as CLA signer (#301) - util: remove unnecessary lru_cache import fallback (#299) - HACKING.rst: reorganise/update CLA signature info (#297) - distros: drop leading/trailing hyphens from mirror URL labels (#296) - HACKING.rst: add note about variable annotations (#295) - CiTestCase: stop using and remove sys_exit helper (#283) - distros: replace invalid characters in mirror URLs with hyphens (#291) (LP: #1868232) - rbxcloud: gracefully handle arping errors (#262) [Adam Dobrawy] - Fix cloud-init ignoring some misdeclared mimetypes in user-data. [Kurt Garloff] - net: ubuntu focal prioritize netplan over eni even if both present (#267) (LP: #1867029) - cloudinit: refactor util.is_ipv4 to net.is_ipv4_address (#292) - net/cmdline: replace type comments with annotations (#294) - HACKING.rst: add Type Annotations design section (#293) - net: introduce is_ip_address function (#288) - CiTestCase: remove now-unneeded parse_and_read helper method (#286) - .travis.yml: allow 30 minutes of inactivity in cloud tests (#287) - sources/tests/test_init: drop use of deprecated inspect.getargspec (#285) - setup.py: drop NIH check_output implementation (#282) - Identify SAP Converged Cloud as OpenStack [Silvio Knizek] - add Openbsd support (#147) [Gonéri Le Bouder] - HACKING.rst: add examples of the two test class types (#278) - VMWware: support to update guest info gc status if enabled (#261) [xiaofengw-vmware] - Add lp-to-git mapping for kgarloff (#279) - set_passwords: avoid chpasswd on BSD (#268) [Gonéri Le Bouder] - HACKING.rst: add Unit Testing design section (#277) - util: read_cc_from_cmdline handle urlencoded yaml content (#275) - distros/tests/test_init: add tests for _get_package_mirror_info (#272) - HACKING.rst: add links to new Code Review Process doc (#276) - freebsd: ensure package update works (#273) [Gonéri Le Bouder] - doc: introduce Code Review Process documentation (#160) - tools: use python3 (#274) - cc_disk_setup: fix RuntimeError (#270) (LP: #1868327) - cc_apt_configure/util: combine search_for_mirror implementations (#271) - bsd: boottime does not depend on the libc soname (#269) [Gonéri Le Bouder] - test_oracle,DataSourceOracle: sort imports (#266) - DataSourceOracle: update .network_config docstring (#257) - cloudinit/tests: remove unneeded with_logs configuration (#263) - .travis.yml: drop stale comment (#255) - .gitignore: add more common directories (#258) - ec2: render network on all NICs and add secondary IPs as static (#114) (LP: #1866930) - ec2 json validation: fix the reference to the 'merged_cfg' key (#256) [Paride Legovini] - releases.yaml: quote the Ubuntu version numbers (#254) [Paride Legovini] - cloudinit: remove six from packaging/tooling (#253) - util/netbsd: drop six usage (#252) - workflows: introduce stale pull request workflow (#125) - cc_resolv_conf: introduce tests and stabilise output across Python versions (#251) - fix minor issue with resolv_conf template (#144) [andreaf74] - doc: CloudInit also support NetBSD (#250) [Gonéri Le
[Yahoo-eng-team] [Bug 1868232] Re: underscores should be stripped from hostnames generated for apt config
** Changed in: cloud-init Status: In Progress => Fix Committed ** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu) Status: New => Fix Committed ** Also affects: cloud-init (Ubuntu Focal) Importance: Undecided Status: Fix Committed -- 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/1868232 Title: underscores should be stripped from hostnames generated for apt config Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Committed Status in cloud-init source package in Focal: Fix Committed Bug description: In a ticket filed in the Ubuntu RT instance we were made aware of an issue where if a cloud is configured with an “_” in the region name, cloud-init will generate an apt configuration that also includes that “_” in the name. So for example if the region name is zone_01, apt will be configured to use zone_01.clouds.archive.ubuntu.com. On Friday March 13th we deployed some new archive servers on 18.04 using Apache 2.4.29-1ubuntu4.13. This version of apache has more strict protocol options than previous versions, per https://httpd.apache.org/docs/2.4/mod/core.html#httpprotocoloptions and the result is that a request to zone_01.clouds.archive.ubuntu.com returns a 400 Bad Request. Could cloud-init be updated to remove non-permitted characters including “_” per https://tools.ietf.org/html/rfc3986#section-3.2.2 ? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1868232/+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 1867197] [NEW] ec2: add support for rendering public IP addresses in network config
Public bug reported:
cloud-init 20.1 currently renders only local ip address information in
the network configuration emitted for attached NICs.
Ec2 instances can be launched and configured with multiple public IP
addresses
https://aws.amazon.com/blogs/aws/multiple-ip-addresses-for-ec2
-instances-in-a-virtual-private-cloud/
Ec2 IMDS network data exposes public IPv4 addresses in the following metadata
keys:
* network.interfaces.macs..public-ipv4s = "18.218.219.181"
* and an association of public ip to the private IPs allocated via the key
"ipv4-associations": {
"18.218.219.181": "172.31.44.13"
 },
Cloud-init should render known public ipv4 address configuration on the node to
avoid network round trips for local services that may connect with the VMs
known public IP
** 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/1867197
Title:
ec2: add support for rendering public IP addresses in network config
Status in cloud-init:
New
Bug description:
cloud-init 20.1 currently renders only local ip address information in
the network configuration emitted for attached NICs.
Ec2 instances can be launched and configured with multiple public IP
addresses
https://aws.amazon.com/blogs/aws/multiple-ip-addresses-for-ec2
-instances-in-a-virtual-private-cloud/
Ec2 IMDS network data exposes public IPv4 addresses in the following metadata
keys:
* network.interfaces.macs..public-ipv4s = "18.218.219.181"
* and an association of public ip to the private IPs allocated via the key
"ipv4-associations": {
"18.218.219.181": "172.31.44.13"
 },
Cloud-init should render known public ipv4 address configuration on the node
to avoid network round trips for local services that may connect with the VMs
known public IP
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1867197/+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 1865882] Re: EC2: token requests 400 due to redacted headers
A version of cloud-init containing this fix was published to Ubuntu
Focal (20.04) cloud-init 20.1-9-g1f860e5a-0ubuntu1.
If this is still a problem for you, please re-open this bug or submit a
new bug with related context.
** Changed in: cloud-init
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/1865882
Title:
EC2: token requests 400 due to redacted headers
Status in cloud-init:
Fix Released
Bug description:
On Focal EC2 cloud, Cloud-init v.20.1-5-g67c8e53c-0ubuntu1 recently
redacted header values from logs for security, but the redact
operation was operating on the source headers dictionary. Ec2 API
token requests are mangled with a 'REDACTED' value as a result and
cloud-init can no longer obtain a valid IMDSv2 token and falls back to
IMDSv2 after 2 minutes of failed retries.
Commit introducing the regression:
https://github.com/canonical/cloud-
init/commit/87cd040ed8fe7195cbb357ed3bbf53cd2a81436c#diff-
a779470bb47168497ada0a33f7990b01R284
Error logs of interest
2020-03-03 13:27:47,839 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/latest/api/token (400, 341b) after 1 attempts
2020-03-03 13:27:47,839 - DataSourceEc2.py[WARNING]: Calling
'http://169.254.169.254/latest/api/token' failed [0/1s]: bad status code [400]
2020-03-03 13:27:47,847 - url_helper.py[DEBUG]: Please wait 1 seconds while
we wait to try again
2020-03-03 13:27:48,848 - DataSourceEc2.py[DEBUG]: Refreshing Ec2 metadata
API token
2020-03-03 13:27:48,848 - url_helper.py[DEBUG]: [0/1] open
'http://None/latest/api/token' with {'url': 'http://None/latest/api/token',
'allow_redirects': True, 'method': 'PUT', 'headers': {'User-Agent':
'Cloud-Init/20.1-5-g67c8e53c-0ubuntu1', 'X-aws-ec2-metadata-token-ttl-seconds':
'REDACTED'}} configuration
2020-03-03 13:27:48,849 - DataSourceEc2.py[WARNING]: Unable to get API token:
None/latest/api/token raised exception HTTPConnectionPool(host='none',
port=80): Max retries exceeded with url: /latest/api/token (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution'))
2020-03-03 13:27:48,850 - url_helper.py[DEBUG]: [0/1] open
'http://169.254.169.254/2009-04-04/meta-data/instance-id' with {'url':
'http://169.254.169.254/2009-04-04/meta-data/instance-id', 'allow_redirects':
True, 'method': 'GET', 'timeout': 50.0, 'headers': {'User-Agent':
'Cloud-Init/20.1-5-g67c8e53c-0ubuntu1'}} configuration
2020-03-03 13:27:48,869 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/2009-04-04/meta-data/instance-id (200, 19b) after 1
attempts
2020-03-03 13:27:48,869 - DataSourceEc2.py[DEBUG]: Using metadata source:
'http://169.254.169.254'
2020-03-03 13:27:48,869 - DataSourceEc2.py[DEBUG]: Refreshing Ec2 metadata
API token
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1865882/+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 1865947] Re: Write redacted metadata to /run/cloud-init/instance-data.json
A version of cloud-init containing this fix was published to Ubuntu Focal (20.04) cloud-init 20.1-9-g1f860e5a-0ubuntu1. If this is still a problem for you, please re-open this bug or submit a new bug with related context. ** Changed in: cloud-init 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/1865947 Title: Write redacted metadata to /run/cloud-init/instance-data.json Status in cloud-init: Fix Released Bug description: Cloud-init persists world-readable instance metadata in /run/cloud- init/instance-data.json and a read-only root /run/cloud-init/instance- data-sensitive.json. Cloud-init has a facility whereby clouds could defined a via sensitive_metadata_keys list as a class attribute in the platform's supported DataSource subclass. No clouds are redacting metadata using this mechanism currently. When cloud-init persists instannce-data.json it should write the redacted content to the world-readable /run/cloud-init/instance- data.json and unredacted content to root read-only /run/cloud-init /instance-data-sensitive.json. It currently writes the wrong content to each file. No clouds currently are exposed to this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1865947/+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 1866290] Re: EC2: Do not retry on disabled IMDSv2 api/token route returning a 403
maybe github squashed it and attributed to me due to the last commit on the branch having the reference Test provided by: Chad Smith I'll make sure if I see top-most commits with other attributions that we also place a trailing Authored-by: footer on the commit message to inform github to make the right decision on squash merge ** Changed in: cloud-init 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/1866290 Title: EC2: Do not retry on disabled IMDSv2 api/token route returning a 403 Status in cloud-init: Fix Released Bug description: The Ec2 IMDSv2 latest/api/token route can be set as disabled and return a 403 indefinitely for an instance. When receiving any HTTP status codes >= 400 from IMDSv2 on AWS' Ec2 cloud, 2 minutes of retries on the api/token route will not result in a successful Ec2 datasource detection. Quickly fail Ec2 datasource detection to allow the instance to potentially discover other datasources. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1866290/+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 1866290] [NEW] EC2: Do not retry on disabled IMDSv2 api/token route returning a 403
Public bug reported: The Ec2 IMDSv2 latest/api/token route can be set as disabled and return a 403 indefinitely for an instance. When receiving any HTTP status codes >= 400 from IMDSv2 on AWS' Ec2 cloud, 2 minutes or retries on the api/token route will not result in a successful Ec2 datasource detection. Quickly fail Ec2 datasource detection to allow the instance to potentially discover other DS types. ** 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/1866290 Title: EC2: Do not retry on disabled IMDSv2 api/token route returning a 403 Status in cloud-init: New Bug description: The Ec2 IMDSv2 latest/api/token route can be set as disabled and return a 403 indefinitely for an instance. When receiving any HTTP status codes >= 400 from IMDSv2 on AWS' Ec2 cloud, 2 minutes or retries on the api/token route will not result in a successful Ec2 datasource detection. Quickly fail Ec2 datasource detection to allow the instance to potentially discover other DS types. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1866290/+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 1865947] [NEW] instance-data.json could contain security sensitive content
*** This bug is a security vulnerability *** Private security bug reported: Cloud-init persists world-readable instance metadata in /run/cloud-init /instance-data.json and a read-only root /run/cloud-init/instance-data- sensitive.json. Any sensitive metadata provided by a cloud platform's metadata services should be redacted from instance-data.json by cloud-init if that DataSource class defines a list of sensitive metadata key names as a a class attribute "sensitive_metadata_keys". Cloud-init matches redacts the correct sensitive keys if discovered when crawling metadata, but it then writes the unredacted information to the world readable /run/cloud-init/instance-data.json instead of the root read-only /run/cloud-init/instance-data-sensitive.json. See the related code at: https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/__init__.py#L318-L323 This can affect any Datasource if either of the following apply: 1. It is not DataSourceEc2 and the platform metadata contains a sensitive 'security-credentials' key 2. It is a private subclassed DataSource that is not present in cloud-init upstream but has set the class attribute sensitive_metadata_keys to be something other that sensitive_metadata_keys = ['security_credentials'] The end result is the sensitive keys they thought they were redacting, end up being published to the world-readable /run/cloud/instance-data.json. In practice, the only cloud we are aware of that provides a 'security-credentials' key in metadata is Ec2 on VMs that are created with an IAM profile. This security exposure on Ec2 only is also negated because the utility that crawls ec2 metadata service also happens to skip 'security-credntials' when crawling metadata so cloud-init doesn't see that key anyway. See this code: https://github.com/canonical/cloud-init/blob/master/cloudinit/ec2_utils.py#L87-L89 ** Affects: cloud-init Importance: Undecided Status: New ** Information type changed from Public to Private Security -- 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/1865947 Title: instance-data.json could contain security sensitive content Status in cloud-init: New Bug description: Cloud-init persists world-readable instance metadata in /run/cloud- init/instance-data.json and a read-only root /run/cloud-init/instance- data-sensitive.json. Any sensitive metadata provided by a cloud platform's metadata services should be redacted from instance-data.json by cloud-init if that DataSource class defines a list of sensitive metadata key names as a a class attribute "sensitive_metadata_keys". Cloud-init matches redacts the correct sensitive keys if discovered when crawling metadata, but it then writes the unredacted information to the world readable /run/cloud-init/instance-data.json instead of the root read-only /run/cloud-init/instance-data-sensitive.json. See the related code at: https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/__init__.py#L318-L323 This can affect any Datasource if either of the following apply: 1. It is not DataSourceEc2 and the platform metadata contains a sensitive 'security-credentials' key 2. It is a private subclassed DataSource that is not present in cloud-init upstream but has set the class attribute sensitive_metadata_keys to be something other that sensitive_metadata_keys = ['security_credentials'] The end result is the sensitive keys they thought they were redacting, end up being published to the world-readable /run/cloud/instance-data.json. In practice, the only cloud we are aware of that provides a 'security-credentials' key in metadata is Ec2 on VMs that are created with an IAM profile. This security exposure on Ec2 only is also negated because the utility that crawls ec2 metadata service also happens to skip 'security-credntials' when crawling metadata so cloud-init doesn't see that key anyway. See this code: https://github.com/canonical/cloud-init/blob/master/cloudinit/ec2_utils.py#L87-L89 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1865947/+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 1865882] [NEW] EC2: token requests 400 due to redacted headers
Public bug reported:
On Focal EC2 cloud, Cloud-init v.20.1-5-g67c8e53c-0ubuntu1 recently
redacted header values from logs for security, but the redact operation
was operating on the source headers dictionary. Ec2 API token requests
are mangled with a 'REDACTED' value as a result and cloud-init can no
longer obtain a valid IMDSv2 token and falls back to IMDSv2 after 2
minutes of failed retries.
Commit introducing the regression:
https://github.com/canonical/cloud-
init/commit/87cd040ed8fe7195cbb357ed3bbf53cd2a81436c#diff-
a779470bb47168497ada0a33f7990b01R284
Error logs of interest
2020-03-03 13:27:47,839 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/latest/api/token (400, 341b) after 1 attempts
2020-03-03 13:27:47,839 - DataSourceEc2.py[WARNING]: Calling
'http://169.254.169.254/latest/api/token' failed [0/1s]: bad status code [400]
2020-03-03 13:27:47,847 - url_helper.py[DEBUG]: Please wait 1 seconds while we
wait to try again
2020-03-03 13:27:48,848 - DataSourceEc2.py[DEBUG]: Refreshing Ec2 metadata API
token
2020-03-03 13:27:48,848 - url_helper.py[DEBUG]: [0/1] open
'http://None/latest/api/token' with {'url': 'http://None/latest/api/token',
'allow_redirects': True, 'method': 'PUT', 'headers': {'User-Agent':
'Cloud-Init/20.1-5-g67c8e53c-0ubuntu1', 'X-aws-ec2-metadata-token-ttl-seconds':
'REDACTED'}} configuration
2020-03-03 13:27:48,849 - DataSourceEc2.py[WARNING]: Unable to get API token:
None/latest/api/token raised exception HTTPConnectionPool(host='none',
port=80): Max retries exceeded with url: /latest/api/token (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution'))
2020-03-03 13:27:48,850 - url_helper.py[DEBUG]: [0/1] open
'http://169.254.169.254/2009-04-04/meta-data/instance-id' with {'url':
'http://169.254.169.254/2009-04-04/meta-data/instance-id', 'allow_redirects':
True, 'method': 'GET', 'timeout': 50.0, 'headers': {'User-Agent':
'Cloud-Init/20.1-5-g67c8e53c-0ubuntu1'}} configuration
2020-03-03 13:27:48,869 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/2009-04-04/meta-data/instance-id (200, 19b) after 1
attempts
2020-03-03 13:27:48,869 - DataSourceEc2.py[DEBUG]: Using metadata source:
'http://169.254.169.254'
2020-03-03 13:27:48,869 - DataSourceEc2.py[DEBUG]: Refreshing Ec2 metadata API
token
** Affects: cloud-init
Importance: High
Assignee: Chad Smith (chad.smith)
Status: Triaged
** Changed in: cloud-init
Importance: Undecided => High
** Changed in: cloud-init
Assignee: (unassigned) => Chad Smith (chad.smith)
** Changed in: cloud-init
Status: New => Triaged
--
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/1865882
Title:
EC2: token requests 400 due to redacted headers
Status in cloud-init:
Triaged
Bug description:
On Focal EC2 cloud, Cloud-init v.20.1-5-g67c8e53c-0ubuntu1 recently
redacted header values from logs for security, but the redact
operation was operating on the source headers dictionary. Ec2 API
token requests are mangled with a 'REDACTED' value as a result and
cloud-init can no longer obtain a valid IMDSv2 token and falls back to
IMDSv2 after 2 minutes of failed retries.
Commit introducing the regression:
https://github.com/canonical/cloud-
init/commit/87cd040ed8fe7195cbb357ed3bbf53cd2a81436c#diff-
a779470bb47168497ada0a33f7990b01R284
Error logs of interest
2020-03-03 13:27:47,839 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/latest/api/token (400, 341b) after 1 attempts
2020-03-03 13:27:47,839 - DataSourceEc2.py[WARNING]: Calling
'http://169.254.169.254/latest/api/token' failed [0/1s]: bad status code [400]
2020-03-03 13:27:47,847 - url_helper.py[DEBUG]: Please wait 1 seconds while
we wait to try again
2020-03-03 13:27:48,848 - DataSourceEc2.py[DEBUG]: Refreshing Ec2 metadata
API token
2020-03-03 13:27:48,848 - url_helper.py[DEBUG]: [0/1] open
'http://None/latest/api/token' with {'url': 'http://None/latest/api/token',
'allow_redirects': True, 'method': 'PUT', 'headers': {'User-Agent':
'Cloud-Init/20.1-5-g67c8e53c-0ubuntu1', 'X-aws-ec2-metadata-token-ttl-seconds':
'REDACTED'}} configuration
2020-03-03 13:27:48,849 - DataSourceEc2.py[WARNING]: Unable to get API token:
None/latest/api/token raised exception HTTPConnectionPool(host='none',
port=80): Max retries exceeded with url: /latest/api/token (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution'))
2020-03-03 13:27:48,850 - url_helper.py[DEBUG]: [0/1] open
'http://169.254.169.254/2009-04-04/meta-data/instance-id' with {'url':
'http://169.254.169.254/2009-04-04/meta-data/instance-id', 'allow_redirects':
True, 'method': 'GET', 'timeout': 50.0, 'headers': {'User-Agent':
'Cloud-Init/20.1-5-g67c8e53c-0ubuntu1'}} configuration
[Yahoo-eng-team] [Bug 1860450] Re: SSH module documentation not generated in ReadTheDocs
Confirmed proper ssh module docs are now present and live https://cloudinit.readthedocs.io/en/latest/topics/modules.html#ssh ** Changed in: cloud-init 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/1860450 Title: SSH module documentation not generated in ReadTheDocs Status in cloud-init: Fix Released Bug description: It should appear on https://cloudinit.readthedocs.io/en/latest/topics/modules.html but it doesn't. If I run `tox -e doc` locally, it _is_ included, which suggests this is an issue with our ReadTheDocs generation specifically, not the docs in general. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1860450/+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 1858921] [NEW] schema: add jsonschema definition to cc_set_hostname
Public bug reported: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_set_hostname.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: bitesize ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged -- 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/1858921 Title: schema: add jsonschema definition to cc_set_hostname Status in cloud-init: Triaged Bug description: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_set_hostname.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858921/+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 1858918] [NEW] schema: add jsonschema definition to cc_scripts_user
Public bug reported: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_scripts_user.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: bitesize ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged -- 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/1858918 Title: schema: add jsonschema definition to cc_scripts_user Status in cloud-init: Triaged Bug description: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_scripts_user.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858918/+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 1858929] [NEW] schema: add jsonschema definition to cc_update_hostname
Public bug reported: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_update_hostname.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: bitesize ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged -- 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/1858929 Title: schema: add jsonschema definition to cc_update_hostname Status in cloud-init: Triaged Bug description: Add initial jsonschema definition for validation of cloud-config user data to cloudinit/config/cc_update_hostname.py. Add a schema dictionary to the cc_*.py module which describes allowed cloud-config properties which are honored by the module. jsonschema support for a cloud-config module should entail: - module-level schema dict definition in cc_*py - schema should contain the keys: id, name, title, description, distros, examples, frequency, type, properties - handler should call validate_cloudconfig_schema(cfg, schema) if valid top-level config module keys are provided Good examples are: - cloudinit/config/cc_runcmd.py - cloudinit/config/cc_ubuntu_drivers.py - cloudinit/config/cc_zypper_add_repo.py - cloudinit/config/cc_ntp.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858929/+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
