| Age | Commit message (Collapse) | Author |
|---|
|
The following commit merged all ssh keys into a default user file
`~/.ssh/authorized_keys` in sshd_config had multiple files configured for
AuthorizedKeysFile:
commit f1094b1a539044c0193165a41501480de0f8df14
Author: Eduardo Otubo <otubo@redhat.com>
Date: Thu Dec 5 17:37:35 2019 +0100
Multiple file fix for AuthorizedKeysFile config (#60)
This commit ignored the case when sshd_config would have a single file for
AuthorizedKeysFile, but a non default configuration, for example
`~/.ssh/authorized_keys_foobar`. In this case cloud-init would grab all keys
from this file and write a new one, the default `~/.ssh/authorized_keys`
causing the bug.
rhbz: #1862967
Signed-off-by: Eduardo Otubo <otubo@redhat.com>
|
|
bddeb builds a .deb package using the template packaging files in
packages/debian/.
The new --packaging-branch flag allows to specify a git branch
where to pull the packaging (i.e. the debian/ directory) from.
This is useful to build a .deb package from master with the very
same packaging which is used for the uploads.
|
|
Translate the following tests from `cloud_tests` to the new integration test framework:
* test_runcmd.py
* seed_random_data.py
* set_hostname.py
* set_hostname_fqdn.py
* snap.py
* ssh_auth_key_fingerprints_disable.py
* ssh_auth_key_fingerprints_enable.py
* ssh_import_id.py
* ssh_keys_generate.py
* ssh_keys_provided.py
* timezone.py
* write_files.py
|
|
DataSourceAzure previously writes the preprovisioning
reported ready marker file before it goes through the
report ready workflow. On certain VM instances, the
marker file is successfully written but then reporting
ready fails.
Upon rare VM reboots by the platform, cloud-init sees
that the report ready marker file already exists.
The existence of this marker file tells cloud-init
not to report ready again (because it mistakenly
assumes that it already reported ready in
preprovisioning).
In this scenario, cloud-init instead erroneously
takes the reprovisioning workflow instead of
reporting ready again.
|
|
|
|
Specifically:
* `apt_configure_sources_list`
* `ntp_servers`
* `set_password_list`
* `users_groups`
Although not currently run in Travis, `set_password_list_string` was
ported over alongside `set_password_list` (as `test_set_password`).
|
|
|
|
Consider valid product names as valid chassis asset tags when detecting
OpenStack platform before crawling for OpenStack metadata.
As `ds-identify` tool uses product name as valid chassis asset tags,
let's replicate the behaviour in the OpenStack platform detection too.
This change should be backwards compatible and a temporary fix for the
current limitations on the OpenStack platform detection.
LP: #1895976
|
|
This moves logging into `report_diagnostic_event`, to clean up its callsites.
|
|
enumeration of physical network devices (#591)
|
|
pycloudlib's default behaviour is to raise an exception if cloud-init
fails to run in an instance being launched. For cloud-init testing, we
want our test assertions to flag up failures, so we disable this
behaviour for instances we launch.
|
|
|
|
This means that the integration tests do not need to install
test-requirements.txt in order to successfully import `conftest.py`.
|
|
|
|
|
|
|
|
|
|
cc_vyos: T2117: Revert back to _find_networking_config() function
|
|
The service installed by the CentOS and RHEL 'ntp' package is
ntpd.service
not
ntp.service
Fix that for those two distros.
Also fix chrony service from 'chrony' to 'chronyd'.
LP: #1897915
|
|
|
|
In rare cases, when network-config provided not by a true data source, but via kernel argument, initramfs, cloud-config file, the cloud.datasource.network_config variable may be empty. So, to make such configuration available we need to revert back to the previous variant with cloudinit.stages.Init()._find_networking_config().
|
|
fails (#549)
Azure datasource's `parse_network_config` throws a fatal uncaught exception when an exception is raised during generation of network config from IMDS metadata. This happens when IMDS metadata is invalid/corrupted (such as when it is missing network or interface metadata). This causes the rest of provisioning to fail.
This changes `parse_network_config` to be a non-fatal implementation. Additionally, when generating network config from IMDS metadata fails, fall back on generating fallback network config (`_generate_network_config_from_fallback_config`).
This also changes fallback network config generation (`_generate_network_config_from_fallback_config`) to blacklist an additional driver: `mlx5_core`.
|
|
|
|
|
|
Co-authored-by: Rick Harding <rharding@mitechie.com>
|
|
|
|
|
|
cc_vyos: T2117: Revert back to get_hostname_fqdn() function
|
|
Unfortunately, `cloud.get_hostname()` does not work if a hostname was configured using cloud-config. So, we still need to use the `get_hostname_fqdn()` from `cloudinit.util`.
Also, was added configuration for domain-name to handle FQDN properly, if it is available.
|
|
T2117: Cleaned up systemd service for cloud-config
|
|
The startup order control was moved from the `cloud-config.service.tmpl` template to the `vyos-router.service` in the https://github.com/vyos/vyatta-cfg/commit/94f7abdf748c24b70c4741417c74147e52689da3
|
|
LP: #1888858
|
|
- use `sh` as highlight language of the code block
- change order so that the confusing indentation is less confusing
|
|
cc_vyos: T2117: OVF datasource cleanup
|
|
The `DataSourceOVF.py` file was cleaned up from VyOS-specific changes.
Also was changed related functionality in the `cc_vyos.py`:
- in addition to limited metadata provided by Cloud-init, the function `get_properties` from the `DataSourceOVF.py` used to get unfiltered values from an OVF environment;
- `set_tag` for the `interfaces ethernet` node was moved from multiple places to the `set_ipaddress` function;
- multiple checks for 'null' value in OVF were replaced with the iteration via all values and replacing `null` with `None`. This allows using easier logic during values check;
- simplified conversion of the values from OVF to an IP address;
- added logging for all actions in the `set_config_ovf` function.
|
|
Co-authored-by: Rick Harding <rharding@mitechie.com>
|
|
Under FreeBSD, we want to use "shutdown -p" for poweroff.
Alpine Linux also has some specificities.
We choose to define a method that returns the shutdown command line to
use, rather than a method that actually does the shutdown. This makes it
easier to have the tests in test_handler_power_state do their
verifications.
Two tests are added for the special behaviours that are known so far.
|
|
This was added in d00126c167fc06d913d99cfc184bf3402cb8cf53, but not
removed in ef041fd822a2cf3a4022525e942ce988b1f95180 which removed the
one usage of it from the original commit.
|
|
T2117: Cloud-init updated to 20.3
|
|
Prior to this change, vlans were rendered in sysconfig with
'TYPE=Ethernet', and incorrectly rendered the PHYSDEV based on
the name of the vlan device rather than the 'link' provided
in the network config.
The change here fixes:
* rendering of TYPE=Ethernet for a vlan
* adds a warning if the configured device name is not supported
per the RHEL 7 docs "11.5. Naming Scheme for VLAN Interfaces"
LP: #1788915
LP: #1826608
RHBZ: #1861871
|
|
Merged with 20.3 tag from the upstream Cloud-init repository
|
|
* pull ssh keys from imds first and fall back to ovf if unavailable
* refactor log and diagnostic messages
* refactor the OpenSSLManager instantiation and certificate usage
* fix unit test where exception was being silenced for generate cert
* fix tests now that certificate is not always generated
* add documentation for ssh key retrieval
* add ability to check if http client has security enabled
* refactor certificate logic to GoalState
|
|
Improved compatibility with upstream version
|
|
VyOS-specific configuration were moved from the `cloud.cfg.tmpl` to the separated file `cloud.cfg.d/10_vyos.cfg`.
With changes in the default template, some build tests failed, and everything from this default configuration can be overwritten in the config file, so there is no strict necessity to keep our changes in the configuration template.
|
|
Since the `instance-data.json` file is the only way offered by Cloud-Init to get formatted metadata, using it instead of `_get_standardized_metadata()` function is safer and must be compatible with all versions.
|
|
|
|
Co-authored-by: Rick Harding <rharding@mitechie.com>
|
|
cc_vyos: T2726: User creating optimizations and small fixes
|
|
This commit is addressed to solve some old issues with creating users in the system and simplify the parts of the module related to this. Also, some small fixes.
- removed Python modules os, cloudinit.stages, cloudinit.util dependencies. Related functionality replaced by other modules (see below)
- detection of hashed passwords was simplified, made 100% compatible with the rest Cloud-init documentation and recommendations. Also, it was moved from the `handle` function to the `set_pass_login` to reduce the code size and make it more clear
- replaced sequenced SSH public keys enumeration for keys without comments to UUID-based to simplify the code and make the logic easier
- replaced home-growed SSH key parser/checker to the native cloudinit.ssh_util.AuthKeyLineParser()
- added support for SSH key options configuration
- added possibility to use all key types supported by VyOS: 'ssh-dss', 'ssh-rsa', 'ecdsa-sha2-nistp256', 'ecdsa-sha2-nistp384', 'ssh-ed25519', 'ecdsa-sha2-nistp521'
- fixed typo in configuration for `distance`/`metric` option in set_config_interfaces_v1()
- added the stable format of the Meta-Data: `v1`. It must be absolutely equal for any datasource, therefore it is always better to use data from it than from any other sources if this is possible
- added User-Data and Vendor-Data logging. Currently not used for anything, but required for a proper debugging
- replaced datasource source from the unstable metadata field to the stable `cloud.datasource.dsname`
- replaced Network-Config source from `init._find_networking_config()` to the more correct `cloud.datasource.network_config`
- replaced hostname source from the `util.get_hostname_fqdn()` to `cloud.get_hostname()`, what is actually the same, to drop `util` dependency
- the part specific for Azure cloud united with the main part of users creating code, since there is actually no platform-specific functions and everything was moved to the common places, what improved compatibility with the similar environments
- rewritten users creating logic
**Important information about users and credentials**
In the Cloud-init exists multiple ways of how to configure authentication: public keys in Meta-Data, default user name and options in the main config file, several config modules (`cc_set_passwords`, `cc_ssh`, `cc_users_groups`) configurable via `#cloud-config`, maybe something more. Cloud-Init solves this by merging information from most of these sources to a single users' database, but information can overwrite each other.
Very simplified logic description: if something is configured in a User-Data (`#cloud-config`), then most likely default values like username `vyos`, or SSH public keys from Meta-Data will be dropped by Cloud-Init.
This implementation should apply public SSH keys and passwords without associated username to the default user (usually `vyos`, but some platforms may allow using your own). If you are creating any additional user, a default one will not be created and common authentication methods will not be applied, so you need to provide the complete authentication details for it.
|
|
During the ec2 integration test runs we occasionally see failures in
deleting test instances. Hopefully a newer boto3 will be more robust.
Also bump: paramiko, cryptography, pylxd (now pulling it from pypi).
Tested with a full Xenial EC2 cloud_tests run.
|
