| Age | Commit message (Collapse) | Author |
|---|
|
There are inconsistencies for cryptographic libraries across
major distribution releases.
From a bionic host, which doesn't support yescrypt hashing scheme,
attempting run run crypt.crypt locally using a yescrypt hash
from a Jammmy /etc/shadow file will result in failure to produce an
encrypted password. For "unsupported" hash schemes, crypt.crypt
returns None.
To avoid inconsistencies of python cryptographic libs across Linux
releases, perform the password encryption on the system under test.
|
|
Delivered in /etc/cloud/cloud.cfg.d/90-azure.cfg
|
|
Ubuntu Jammy output from lsblk --json now contains
'mountpoints': [...] instead of 'mountpoint' for children devs.
Let our integration test handle either case.
|
|
Fixes the spaces introduced in #1213
Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
|
|
Once a valid datasource is detected, publish the following artifacts
to expedite cloud-identification without having to invoke cloud-id from
shell scripts or sheling out from python.
These files can also be relied on in systemd ConditionPathExists
directives to limit execution of services and units to specific
clouds.
/run/cloud-init/cloud-id:
- A symlink with content that is the canonical cloud-id of the
datasource detected. This content is the same lower-case value
as the output of /usr/bin/cloud-id.
/run/cloud-init/cloud-id-<canonical-cloud-id>:
- A single file which will contain the canonical cloud-id encoded
in the filename
|
|
* Wrap the log fetching code in a try/except in case file is missing
* Stop checking NoCloud seed dir when testing datasource detection
|
|
* Include CI and Fixtures sections in integration test docs
* Incorporate additional variable annotations
* Remove unnecessary IntegrationInstance subclasses
* Move setup_image teardown into its fixture
|
|
Migrate from legacy schema or define new schema in
cloud-init-schema.json, adding extensive schema tests for:
- cc_apt_configure
- cc_bootcmd
- cc_byobu
- cc_ca_certs
- cc_chef
- cc_debug
- cc_disable_ec2_metadata
- cc_disk_setup
Deprecate config hyphenated schema keys in favor of underscores:
- ca_certs and ca_certs.remove_defaults instead of
ca-certs and ca-certs.remove-defaults
- Continue to honor deprecated config keys but emit DEPRECATION
warnings in logs for continued use of the deprecated keys:
- apt_sources key
- any apt v1 or v2 keys
- use or ca-certs or ca_certs.remove-defaults
- Extend apt_configure schema
- Define more strict schema below object opaque keys using
patternProperties
- create common $def apt_configure.mirror for reuse in 'primary'
and 'security' schema definitions within cc_apt_configure
Co-Authored-by: James Falcon <james.falcon@canonical.com>
|
|
Package a single JSON schema file for user-data validation at
cloudinit/config/cloud-init-schema.json.
Perform validate_cloudconfig_schema call to just after the
user-data is consumed. This will allow single validation of all
user-data against the full schema instead of
repetitive validatation calls against each cloud-config module
(cloudinit.config.cc_*) sub-schemas.
This branch defines the simple apt_pipelining schema and
migrates existing cc_apk_configure into cloud-init-schema.json.
The expectation will be additional branches to migrate from legacy
"schema" attributes inside each cloud-config module toward unique
cc_<module_name> definitions in the global shema file under "$defs"
of cloud-init-schema-X.Y..json.
Before legacy sub-schema definitions are migrated the following
funcs grew support to read sub-schemas from both static
cloud-init-schema.json and the individual cloud-config module
"schema" attributes:
- get_schema: source base schema file from cloud-init-schema.json
and supplement with all legacy cloud-config module "schema" defs
- get_meta_doc: optional schema param so cloud-config modules
no longer provide the own local sub-schemas
- _get_property_doc: render only documentation of sub-schema based
on meta['id'] provided
- validate_cloudconfig_schema: allow optional schema param
Additionally, fix two minor bugs in _schemapath_for_cloudconfig:
- `cloud-init devel schema --annotate` which results in a Traceback
if two keys at the same indent level have invalid types.
- exit early on empty cloud-config to avoid a Traceback on the CLI
|
|
Adds a new module to allow setting keyboard layout,
for use-cases in which cloud-init is used to configure
OS images meant for physical computers instead
of the cloud.
This initial release only implements support
for Linux distributions that allow layout to be
set through systemd's localectl.
LP: #1951593
|
|
Includes:
- Update tox.ini and .travis.yml accordingly
- Cleanup tox.ini with new tox syntax and cloud-init dependencies
- Update documentation accordingly
- Replace/remove xenial references where additional testing isn't required
- Remove xenial checks in integration tests
- Replace yield_fixture with fixture in pytest tests
Sections of code commented with lines like "Remove when Xenial is no
longer supported" still exist as they're require additional testing.
|
|
Applied Black and isort, fixed any linting issues, updated tox.ini
and CI.
|
|
(#1123)
Allow #cloud-config and cloud-init query to use underscore-delimited
"jinja-safe" key aliases for any instance-data.json keys
containing jinja operator characters.
This provides a means to use Jinja's dot-notation instead of square brackets
and quoting to reference "unsafe" obtain attribute names.
Support for these aliased keys is available to both #cloud-config user-data and
`cloud-init query`.
For example #cloud-config alias access can look like:
{{ ds.config.user_network_config }}
- instead of -
{{ ds.config["user.network-config"] }}
|
|
|
|
GCE currently fetches metadata after network has come up. There's no
reason we can't fetch at init-local time, so update GCE to fetch at
init-local time to be more performant and consistent with other
datasources.
|
|
When cloud-init is configured to show SSH user key fingerprints during
boot two of the same message appears for each user. This appears to be as
the util.multi_log call defaults to send to both console directly and to
stderr (which also goes to console).
This change sends them only to console directly.
|
|
Add growpart integration test and associated unit tests
Additionally, a small runcmd check for a commented line.
|
|
Move more tests into test_combined.py and remove the CI mark from module
tests that aren't updated often or don't represent core functionality.
|
|
- Added to list of expected warnings on Oracle when opc user has
no ssh key
- Added retries to tests that read from syslog as that can sometimes
take time to reflect in the log
- Updated test_apt.py to remove proxy info into its own test as that
can cause failures in updating, which will immediately traceback
out of the module and prevent us from running further class tests
- Updated test_apt.py to use a more updated ppa in the test_keyserver
- Added basic rsyslog test to test_combined.py
- Added basic puppet test as test_puppet.py
|
|
Also, add the "signed by" option to source definitions. This enables
users to limit the scope of trust for individual keys.
LP: #1836336
|
|
This commit removes automatically installing udev rules for hotplug
and adds a module to install them instead.
Automatically including the udev rules and checking if hotplug was
enabled consumed too many resources in certain circumstances. Moving the
rules to a module ensures we don't spend extra extra cycles on hotplug
if hotplug functionality isn't desired.
LP: #1946003
|
|
The main idea is to introduce a second module that takes care of
writing files, but in the 'final' stage.
While the introduction of a second module would allow for choosing
the appropriate place withing the order of modules (and stages),
there is no addition top-level directive being added to the cloud
configuration schema. Instead, 'write-files' schema is being extended
to include a 'defer' attribute used only by the 'write-deffered-files'
modules.
The new module 'write-deferred-files' reuses as much as
possible of the 'write-files' functionality.
|
|
|
|
In #1006, we set Azure to apply networking config every
BOOT_NEW_INSTANCE because the BOOT_LEGACY option was causing problems
applying networking the second time per boot. However,
BOOT_NEW_INSTANCE is also wrong as Azure needs to apply networking
once per boot, during init-local phase.
|
|
* Update test_combined.py to allow either valid LXD subplatform
* Split jinja templated tests into separate module as they can be more
fragile
* Move checks for warnings and tracebacks into dedicated utility
function. This allows us to work around persistent and expected
tracebacks/warnings on particular clouds.
* Update test_upgrade.py to allow either valid Azure datasource.
/var/lib/waagent or a mounted device are both valid.
* Add specificity to test_ntp_servers.py
Clouds will often specify their own ntp servers in the ntp
configuration files, so make the tests manually specify their own.
* Account for additional keys on system in test_ssh_keysfiles.py
* Update tests to account for invalid cache
test_user_events.py and test_version_change.py both have tests that
assume we will have valid ds cache when rebooting.
In test_user_events.py, subsequent boots should block applying
network on boot if boot event is denied. However, if the cache is
invalid, it is valid to apply networking config that boot.
In test_version_change.py no cache found won't trigger the expected
debug log. Additionally, the pickle used for that test on an older
release triggered an unexpected issue that took a different error
path.
* Ignore bionic in hotplug tests (LP: #1942247)
On Bionic, we traceback when attempting to detect the hotplugged
device in the updated metadata. This is because Bionic is
specifically configured not to provide network metadata.
See LP: #1942247 for more details.
* Fix date used in test_final_message.
In test_final_message, we ensured the variable substitution works as
expected. For $timestamp, we compared against the current date. It's
possible for the host date to be massively different from the client
date, so obtain date on client rather than host.
* Remove module success from lp1813396 test. Module may fail
unrelatedly (in this case apt-get update is failing), but the test
should still pass.
* Skip testing events if network is disabled
* Ensure we install expected version of cloud-init
As part of test setup, we can install cloud-init from various
sources, including PROPOSED, PPAs, etc. We were never checking that
this install completes successfully, and on OCI, it wasn't
completing successfully because of apt locking issues. Code has
been updated to retry, and then fail loudly if we can't complete the
install.
* Remove ubuntu-azure-fips metapkg which mandates FIPS-flavour kernel
In test_lp1835584.py
* Update test_user_events.py to account for Azure behavior
since Azure has a separate service to clear the pickled metadata
every boot
* Change failure to warning in test_upgrade.py if initial boot errors
If there's already a pre-existing cause for warnings or tracebacks,
that shouldn't cause the new version to fail.
* Add retry to test_random_passwords_emitted_to_serial_console
It's possible we haven't retrieved the entire log when the call returns,
so retry a few times if the output isn't empty.
|
|
Home directory permissions changed in hirsute. The integration test
assumed permissions from earlier releases. Test was fixed to take both
permissions into account
|
|
Fix home permissions modified by ssh module
In #956, we updated the file and directory permissions for keys not in
the user's home directory. We also unintentionally modified the
permissions within the home directory as well. These should not change,
and this commit changes that back.
LP: #1940233
|
|
Ensure jinja templates work for both instance-data.json and
instance-data-sensitive.json. Test for LP: #1931392
Also removed test_runcmd.py as it's made redundant by this change.
|
|
Alters hotplug hook to have a query mechanism checking if the
functionality is enabled. This allows us to avoid using the hotplug
socket and service when hotplug is disabled.
|
|
(SC-191) (#955)
This should enable us to remove the cloud-tests entirely.
|
|
Implement missing device_aliases feature
The device_aliases key has been documented as part of disk_setup for
years, however the feature was never implemented. This implements the
feature as documented allowing usercfg (rather than dsconfig) to create
a mapping of device names.
This is not to be confused with disk_aliases, a very similar map but
existing solely for use by datasources.
LP: #1867532
|
|
test_ssh_import_id.py occassionally fails because cloud-init finishes
before the keys have been fully imported. A retry has been added to the
test.
|
|
Adds a udev script which will invoke a hotplug hook script on all net
add events. The script will write some udev arguments to a systemd FIFO
socket (to ensure we have only instance of cloud-init running at a
time), which is then read by a new service that calls a new 'cloud-init
devel hotplug-hook' command to handle the new event.
This hotplug-hook command will:
- Fetch the pickled datsource
- Verify that the hotplug event is supported/enabled
- Update the metadata for the datasource
- Ensure the hotplugged device exists within the datasource
- Apply the config change on the datasource metadata
- Bring up the new interface (or apply global network configuration)
- Save the updated metadata back to the pickle cache
Also scattered in some unrelated typing where helpful
|
|
Python 3.6 added a new `policy` attribute to `MIMEMultipart`.
MIMEMultipart may be part of the cached object pickle of a datasource.
Upgrading from an old version of python to 3.6+ will cause the
datasource to be invalid after pickle load.
This commit uses the upgrade framework to attempt to access the mime
message and fail early (thus discarding the cache) if we cannot.
Commit 78e89b03 should fix this issue more generally.
|
|
defined in AuthorizedKeysFile (#937)
This patch aims to fix LP1911680, by analyzing the files provided
in sshd_config and merge all keys into an user-specific file. Also
introduces additional tests to cover this specific case.
The file is picked by analyzing the path given in AuthorizedKeysFile.
If it points inside the current user folder (path is /home/user/*), it
means it is an user-specific file, so we can copy all user-keys there.
If it contains a %u or %h, it means that there will be a specific
authorized_keys file for each user, so we can copy all user-keys there.
If no path points to an user-specific file, for example when only
/etc/ssh/authorized_keys is given, default to ~/.ssh/authorized_keys.
Note that if there are more than a single user-specific file, the last
one will be picked.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Co-authored-by: James Falcon <therealfalcon@gmail.com>
LP: #1911680
RHBZ:1862967
|
|
summary: Clear cache when a Python version change is detected
When a distribution gets updated it is possible that the Python version
changes. Python makes no guarantee that pickle is consistent across
versions as such we need to purge the cache and start over.
Co-authored-by: James Falcon <therealfalcon@gmail.com>
|
|
Control is currently limited to boot events, though this should
allow us to more easily incorporate HOTPLUG support. Disabling
'instance-first-boot' is not supported as we apply networking config
too early in boot to have processed userdata (along with the fact
that this would be a pretty big foot-gun).
The concept of update events on datasource has been split into
supported update events and default update events. Defaults will be
used if there is no user-defined update events, but user-defined
events won't be supplied if they aren't supported.
When applying the networking config, we now check to see if the event
is supported by the datasource as well as if it is enabled.
Configuration looks like:
updates:
network:
when: ['boot']
|
|
the above option allows the user to control the behavior of a distro
hostname selection if both short hostname and FQDN are supplied.
If `prefer_fqdn_over_hostname` is true the FQDN will be selected as
hostname; if false the hostname will be selected
LP: #1921004
|
|
The current method of running a background sleep until travis is
finished is causing integration test runs to pass even when they should
be failing.
Instead, update the code to emit dots itself.
|
|
When output of SSH host keys and/or SSH fingerprints are disabled for
all keys do not display headers and footers.
Prevent risk of message text being interpreted as "logger" option by
appending "--" to logger options.
Correct syslog output that was tagged with "ec2" regardless of DataSource
in use. Now use "cloud-init" tag instead.
Various "shellcheck" corrections.
Add testcase for disabled output of SSH host keys.
|
|
Prior to this commit, when a user specified configuration which would
generate random passwords for users, cloud-init would cause those
passwords to be written to the serial console by emitting them on
stderr. In the default configuration, any stdout or stderr emitted by
cloud-init is also written to `/var/log/cloud-init-output.log`. This
file is world-readable, meaning that those randomly-generated passwords
were available to be read by any user with access to the system. This
presents an obvious security issue.
This commit responds to this issue in two ways:
* We address the direct issue by moving from writing the passwords to
sys.stderr to writing them directly to /dev/console (via
util.multi_log); this means that the passwords will never end up in
cloud-init-output.log
* To avoid future issues like this, we also modify the logging code so
that any files created in a log sink subprocess will only be
owner/group readable and, if it exists, will be owned by the adm
group. This results in `/var/log/cloud-init-output.log` no longer
being world-readable, meaning that if there are other parts of the
codebase that are emitting sensitive data intended for the serial
console, that data is no longer available to all users of the system.
LP: #1918303
|
|
The apt default test wasn't ported over from cloud-tests correctly.
uri should be specified in the test, but it was not, so the test
failed on openstack (and likely other platforms) because without
a specified uri, the default uri will vary by platform. I separated
this uri test out into a separate test function.
Also add openstack specific test for apt configuration with no uri.
Other platform-specific tests should be added here over time.
|
|
Newer verisons of /etc/sudoers prefer @includedir over
#includedir. Ensure we handle that properly and don't include an
additional #includedir when one isn't warranted.
|
|
* Xenial issue
The `apt-key finger` format changed since Xenial. Sample Xenial output:
pub 4096R/991BC93C 2018-09-17
Key fingerprint = F6EC B376 2474 EDA9 D21B 7022 8719 20D1 991B
Sample Focal output:
pub rsa4096 2016-04-12 [SC]
EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796
What didn't change is the format of the key fingerprint, which should be
enough to ensure that the right key is in place across all the supported
releases.
* Hirsute issue
TestApt::test_ppa_source also fails on Hirsute because of a difference
in how the PPA keys are added. On Focla this command:
add-apt-repository ppa:simplestreams-dev/trunk
install /etc/apt/trusted.gpg.d/simplestreams-dev_ubuntu_trunk.gpg, while
on Hirsute the file is names simplestreams-dev-ubuntu-trunk.gpg. The
filename is part of the `apt-key finger` output, and this the test
fails. Only checking for the presence of the key fingerprint in apt-key
also covers this case.
LP: #1916629
|
|
Specifically:
ssh:
emit_keys_to_console: false
We also port the cc_keys_to_console cloud tests to the new integration
testing framework, and add a test for this new option.
LP: #1915460
|
|
|
|
`test_seed_random_data.py` was failing on openstack as openstack
provides additional binary seed data to the end of the specified file.
The test has been changed to only read the ascii porition of
seed file.
|
|
|
|
pycloudlib no longer raises exceptions when cloud-init fails to start,
and the API has been updated accordingly. Changes have been made to
integration tests accordingly
|
|
The documentation did not mention that the given data may not be the
exact string written: the cloud's random data may be added to it.
Additionally, the documentation of the command key was incorrect.
test_seed_random_data was updated to check that the given data is a
prefix of the written data, to match cloud-init's expected (and, now,
documented) behaviour.
LP: #1911227
|
