| Age | Commit message (Collapse) | Author |
|---|
|
If a key with the same comment already exists in a configuration, generate a new
ID for a new one.
Example of such a case:
```
ssh-rsa <base64> my_user_name
ssh-ed25519 <base64> my_user_name
```
|
|
Cloud-init in environments where Meta-data is available via network configures
the main interface and keeps the config in `/etc/network/interfaces.d/`.
This config later interferes with the VyOS configuration.
To avoid the problem previously the code in the `cc_vyos.py` module was used,
but this is not enough. The module is running only once during instance
deployment. But Cloud-init will re-add the config file with each boot.
There are two ways to solve this incompatibility (within Cloud-init) - disable
network config or perform cleanup during each boot.
Disabling network config is not correct in this context, because it blocks the
ability to fetch Meta-data after the first boot, which in turn blocks the
ability to run per-boot modules with an updated config.
Therefore, the cleanup code was extracted to an independent
`cc_vyos_ifupdown.py` module that performs proper cleanup with each boot.
|
|
Improperly generated configuration can break the configuration process. This fix
updates CLI items from the old to the current syntax.
Fixed CLI config items for:
- NTP servers
- HTTPS API
- domain-search
|
|
Configuration in `vyos_config_commands` is expected to use a syntax from the
target VyOS version. But, if Cloud-init applies configuration commands to a
default file, all the migrations (from the 0 version to the latest) will still
be executed on top of it.
This process can break proper config, for example, if the current syntax variant
partially repeats one of the older ones, which will trigger a migration without
need.
|
|
|
|
- added extra check for maximum supported MTU to avoid exceeding it during
configuration
- remove udev rules created by cloud-init after initialization
- fixed logic for config file selection
|
|
To avoid problems with SSH public key comments with special characters the
parser now generates UUID names for keys if a comment contains anything
except `[a-zA-Z0-9_]`.
|
|
A new option for Cloud-Init was added:
```
vyos_config_options:
network_config: <disabled/enabled>
```
Possible values:
* by default - equal to the `network['config']` from the active Cloud-Init
configuration
* `enabled` - configure networking, even if global `network['config']` is set
to `disabled`
* `disabled` - do not configure networking, regardless of global
`network['config']` value
|
|
network-config: T4954: Fixed DNS settings
|
|
Fixed different mistakes in the `cc_vyos` module, like wrong variable types,
functions calls or returns.
|
|
This commit fixes setting DNS configuration if it was presented as a string
instead array of strings.
|
|
Added the support for all types of interfaces supported in
network-config. See detail here:
https://cloudinit.readthedocs.io/en/22.1_a/topics/network-config.html
For Networking Config Version 1:
- physical
- bond
- bridge
- vlan
- nameserver
- route
For Networking Config Version 2:
- ethernets
- bonds
- bridges
- vlans
Also, the code was refactored to reduce actions duplication and prepare
for future syntax and structure improvements.
|
|
Merged with 22.1 tag from the upstream Cloud-init repository.
Our modules were slightly modified for compatibility with the new
version.
|
|
This commit adds the ability to deconfigure all the interfaces that
Cloud-init configured during deployment and remove the configuration
file `/etc/network/interfaces.d/50-cloud-init`. This should protect from
conflicts between CLI config and actual interfaces states.
|
|
mask (255.255.255.0)
|
|
|
|
|
|
|
|
provided.
|
|
This commit reverts the 5b47d9dc1cd80e3dbd0fb21125febab2e99d5f9c and 57e53d13ad772a74f55c38d95f6d61623fe08633 since Cloud-init 20.4 is not affected by the problem.
|
|
filter.
|
|
|
|
|
|
In rare cases, udev scripts may try to rename ethernet interfaces at the first boot, including an interface used to configure the system. This leads to inconsistency between the config and actual interface names and sometimes to wrong interfaces (`renameX`).
If we will configure the `hw-id` option via Cloud-init, this must guarantee that interface will have a proper (expected) config and name.
|
|
The commit ceaa51c3df393d8bcfb8aa58e47d9d2eb7a9efb2 fixed receiving network-config for non-typical, "internal" datasources not addressed to be used normally, but broke this for normal ones.
So, this is the third time when this part of the module must be changed to combine both methods: `cloud.datasource.network_config` for normal and `init_stage._find_networking_config()` for internal.
|
|
To provide connectivity to the CLI in cases when there were no credentials in metadata added a fallback user `vyos/vyos`.
|
|
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().
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
This commit fixes a situation when it is necessary to configure more than one IP address on an interface. Previously only the latest one address survived. With this fix, it is possible to add all compatible addresses.
|
|
Changes:
- added logging messages
- optimized structure
- added back network configuration version 1 support (new implementation)
- fixed static gateway settings in network configuration version 2
|
|
Since not all data-sources filter hostname in Meta-Data, we need to be sure that the value received from Meta-Data can be applied to the system. The new filter cut all prohibited symbols and takes only that part of the filtered result, which can be used as a hostname.
Additionally, the source was cleaned where it is possible, according to linter recommendations.
|
|
- Merge 20.1 version from the Canonical repository
- Removed unneeded changes in datasources (now only OVF datasource is not equal to upstream's version)
- Adapted cc_vyos module to new Cloud-init version
- Changed Jenkinsfile to use build scripts, provided by upstream
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rework check to see which part of ssh key is which
|
|
|
|
|
