Ubuntu/focal: 24.3.1 upstream snapshot release #5679
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Azure Guest Proxy Agent is a new feature in Azure that offers a key exchange protocol to secure communication between guest and host using eBPF. Add opt-in feature which enables the Azure Guest Proxy Agent when ovf-env.xml has ProvisionGuestProxyAgent=True. Report provisioning failures if ProvisionGuestProxyAgent is enabled but images do not have azure-proxy-agent installed or functional.
- fix exception handling when retr fails - test: Close connection on failure - test: Ensure server is running before it is queried
User output and service names recently changed.
…anonical#5426) When snap refresh.hold is set to forever, an admin is saying they do not want generic automated refreshes of snaps performed by default. This should be an indicator to cloud-init to avoid calling snap refresh on such systems due to a `package_upgrade: true` present in user-data. For network-limited environments with images which have the snap package manager but don't want to wait and timeout on snap refresh, the following user-data can be provided to still allow for package_upgrade: true, and avoid a 20-30 second wait on snaps being unable to access certain snap URLs. #cloud-config package_upgrade: true snap: commands: 00: snap refresh --hold=forever cloud-init now interrogates the state refresh.hold value by calling snap get system -d If snap refresh --hold was called in that environment to set 'forever', cloud-init will skip calling refresh and log the reason for skipping. We cannot honor short time-based refresh.holds because the snap services place a short hold in early boot anyway as systemd units startup. Fixes: canonicalGH-5290
…onical#5471)" (canonical#5596) This reverts commit 2b6fe64. When there is no IPv6 set to dhcp explicitly, NetworkManager keyfile defaults to method=auto, may-fail=true. When there is Ipv6 set to dhcp explictily, NetworkManager keyfile will be set to method=auto, may-fail=false. The default settings are what we want, so revert the previous change to keep IPv6 not set explicitly.
…nonical#5598) chore: add comment explaining the NetworkManager may-fail setting The value of may-fail in network manager keyfile is a source of confusion as the default value of it is True for Network Manager and False for network manager renderer implementation. Add a comment to explain why the renderer sets may-fail to False in its implementation.
Also shift the format page higher in the explanation page list, since this is a high traffic page.
…canonical#5602) Recently noticed that doc file changes in nested subdirs were not triggering documentation auto label. Example of subdir match at https://github.com/actions/labeler?tab=readme-ov-file#basic-examples
) As noted in the systemd documentation, /etc is reserved for "System units created by the administrator" while the lib directory should be used by "System units installed by the distribution package manager". Fixes canonicalGH-5613
When referencing a command from another environment, it will cause errors when the other environment already exists. Fix it by avoiding indirection in environment command definitions. Additionally, simplify envoronment dependency management by defining two lists of dependencies: a default one with pinned versions for all environments, and an unpinned on for "tip" environments. Several dependencies have been missed in the mypy envornments, so this should make it easier by standardizing environment dependencies to be consistent across environments.
Bump Ubuntu version for better pip dependency resolution.
…#5385) When using NetworkManager, if the base bond interface does not have subnet information configured, ensure it is disabled with respect to ipv4 and ipv6. Otherwise, the base bond interface defaults to 'auto' and will try to configure itself via DHCP. This is problematic when using a tagged VLAN interface on top of the bond as the base interface will try to configure itself via DHCP on the untagged VLAN.
…on (canonical#5383) The cloud-init network config version 1 schema defines the bond properties with underscores, prepended with 'bond-'. This change ensures consistency with the schema for the bond property names. canonicalGH-5366
Avoid exclusive expectations that cloud-init is the only agent registering certificates in a system to /etc/ssl/certs/ca-certificates.crt. On Google Cloud Platform, Google Guest Agent does setup root certs which makes performing a checksum of ca-certificates.crt incorrect due to extra certs present in ca-certificates.crt. Adapt test to assert that cloud-init's cert is contained in ca-certificates.crt but not exclusive content of the file. Fixes canonicalGH-5609
* Collect sensitive data by default since we ask for it more often than not * Output warning that we're collecting sensitive data * Glob most of /run/cloud-init, /etc/cloud, and /var/lib/cloud * Stop creating empty directories in the tarball * Require running as root given that the logs are root read-only * Update apport accordingly Fixes canonicalGH-5297
In the case of Pro, if either agent or user data is not cloud-config user-data, combine the parse in `self.userdata_raw` as a #include file so cloud-init transforms that internally into a multipart data. Avoid passing strings and lists directly, which confused the processor due the lack of a mime type. Being explicit about only loading text/cloud-config parts also allow other composition of cloud-init features to just work, like jinja templates. This error was surfaced when testing with empty Landscape data, but any non-text/cloud-config content type would trigger the same behavior. Add merge_agent_landscape_data to process agent.yaml or Landscape data and ignore any empty files present in .ubuntupro/.cloud-init/
…ical#5562) Also emphasize ''users''.
Adapt to new annotation formating from a2193da.
…onical#5636) Directly calling execute("cloud-init clean --logs --reboot") on an integration instances also involves awaiting a new boot id upon next interaction with with instance to ensure a reboot has actually taken place already on this target machine. Slow responding test instances/platforms may not completed the shutdown restart sequence yet when trying to iteract with an immediate blocking call to execut("cloud-init status --wait") which may exit early if accessing the prior instance boot before the reboot occurred. It is preferable to use inspect /proc/sys/kernel/random/boot_id before issuing a reboot request and block until a delta is seen in boot_id. This blocking wait on reboot and new boot_id is encapsulated inside pycloudlib.BaseInstance.restart which will inspect /proc/sys/kernel/random/boot_id before restart and block until a delta in boot_id across the requested restart. Fix test_status_block_through_all_boot_status to call instance.clean() and restart() to ensure we do not beat the instance reboot race with our post-boot assertions.
Add PPS support for azure-proxy agent and improve error logging.
…nical#5633) Do not treat the emptiness of .cloud-init/ as an error in the logs if agent.yaml is present. Fixes canonicalGH-5632
…ply (canonical#5622) Perform the same steps that cloud-init daily recipe builds performs to assert any packaging branch updates will not break daily builds due to quilt patch apply issues. Steps of daily build recipe reflected in this workflow: - checkout main - merge packaging branch topmost commit - quilt push -a - run unittests (via tox -e py3) - quilt pop -a
…cal#5641) Reintroduce strict assert that cloud-init's cert in userdata is the only root cert defined on the platform. Google guest agent was installed a secondary root cert in ca_certifications.crt for a period of time and this was determined to be less than ideal practice. Allow cloud-init's integration tests to remain strict validation of cert checksum to provide a signal if other platforms or agents attempt to extend or alter the system-wide CA.
…d field (canonical#5355) Currently cc_user_groups assumes that "useradd" never locks the password field of newly created users. This is an incorrect assumption. Change add_user (in both __init__.py and alpine.py) to explicitly call either lock_passwd or unlock_passwd at all times to achieve the desired final result. For existing users with empty or empty locked passwords, no password unlock will be performed and warnings will be issued. To support empty password validation, provide functionality to parse /etc/shadow and /var/lib/extrausers/shadow to assert existing users do not have empty passwords before unlocking. Additionally in this commit: - add NetworkBSD.ifs property to avoid subp side-effect in ___init__ which calls ifconfig -a at every instance initialization Useradd background: From the useradd manpage: '-p, --password PASSWORD The encrypted password, as returned by crypt(3). The default is to disable the password.' That is, if cloud-init runs 'useradd' but does not pass it the "-p" option (with an encrypted password) then the new user's password field will be locked by "useradd". cloud-init only passes the "-p" option when calling "useradd" when user-data specifies the "passwd" option for a new user. For user-data that specifies either the "hashed_passwd" or "plain_text_passwd" options instead then cloud-init calls "useradd" without the "-p" option and so the password field of such a user will be locked by "useradd". For user-data that specifies "hashed_passwd" for a new user then "useradd" is called with no "-p" option, so causing "useradd" to lock the password field, however then cloud-init calls "chpasswd -e" to set the encrypted password which also results in the password field being unlocked. For user-data that specifies either "plain_text_passwd" for a new user then "useradd" is called with no "-p" option, so causing "useradd" to lock the password. cloud-init then calls "chpasswd" to set the password which also results in the password field being unlocked. For user-data that specifies no password at all for a new user then "useradd" is called with no "-p" option, so causing "useradd" to lock the password. The password field is left locked. In all the above scenarios "passwd -l" may be called later by cloud-init to enforce "lock_passwd: true"). Conversely where "lock_passwd: false" applies the above "usermod" situation (for "hash_passwd", "plain_text_passwd" or no password) means that newly created users may have password fields locked when they should be unlocked. For Alpine, "adduser" does not support any form of password being passed and it always locks the password field (the same point applies about password field being unlocked when/if "chpasswd" is called). Therefore in some situations (i.e. no password specified in user-data) the password needs to be unlocked if "lock_passwd: false".
Bump the version in cloudinit/version.py to 24.3 and update ChangeLog.
Drop unnecessary environment variable. Fixes canonicalGH-5648
Bump the version in cloudinit/version.py to 24.3.1 and update ChangeLog.
patches: debian/patches/cli-retain-file-argument-as-main-cmd-arg.patch debian/patches/drop-unsupported-systemd-condition-environment.patch debian/patches/netplan99-cannot-use-default.patch debian/patches/no-nocloud-network.patch debian/patches/no-single-process.patch debian/patches/revert-551f560d-cloud-config-after-snap-seeding.patch
blackboxsw
force-pushed
the
ubuntu/focal
branch
from
1015dfe
to
968c6f8
Compare
Revert remaning functional references to cloud-init-network service which will not exist on stable releases.
blackboxsw
force-pushed
the
ubuntu/focal
branch
from
968c6f8
to
377b501
Compare
blackboxsw
force-pushed
the
ubuntu/focal
branch
from
377b501
to
29ed383
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New upstream snapshot release of 24.3.1 into focal for SRU
Additional Context
Full package diff review branch
For full package dff please see: blackboxsw#27
The upstream/ubuntu/focal branch receives multiple unreleased pull request merges between the time the previous 24.2 published release and a new upstream release 24.3 for a couple of reasons:
Given that this PR is only the latest unreleased changeset proposed into upstream/ubuntu/focal, it doesn't represent the full debdiff SRU reviewers would expect to see of all unreleased content since latest published cloud-init in focal-updates. To aid the review of this changeset, we propose a secondary PR to containing the entire diff of all unreleased content to make that coordination and discussion easier in github prior to landing this PR and performing an upload to focal:
new Quilt patches retaining stable behavior
5139603 quilt patch fix in noble is approved which is reflected in this PR .
Testing and validation
expected CI failures