vyos-cloud-init.git/cloudinit/config/tests, branch 20.1

unittest: fix stderr leak in cc_set_password random unittest output. (#208)

2020-02-10T16:17:56+00:00

cloudinit: replace "from six import X" imports (except in util.py) (#183)

2020-01-31T15:15:31+00:00

Replace mock library with unittest.mock (#186)

2020-01-29T21:55:39+00:00

* cloudinit: replace "import mock" with "from unittest import mock" * test-requirements.txt: drop mock Co-authored-by: Chad Smith

cloud-init: fix capitalisation of SSH (#126)

2019-12-18T21:22:02+00:00

* cc_ssh: fix capitalisation of SSH * doc: fix capitalisation of SSH * cc_keys_to_console: fix capitalisation of SSH * ssh_util: fix capitalisation of SSH * DataSourceIBMCloud: fix capitalisation of SSH * DataSourceAzure: fix capitalisation of SSH * cs_utils: fix capitalisation of SSH * distros/__init__: fix capitalisation of SSH * cc_set_passwords: fix capitalisation of SSH * cc_ssh_import_id: fix capitalisation of SSH * cc_users_groups: fix capitalisation of SSH * cc_ssh_authkey_fingerprints: fix capitalisation of SSH

fix unlocking method on FreeBSD

2019-12-12T20:04:54+00:00

on FreeBSD, `lock_passwd` is implemented as `pw usermod -h -` This does not lock the account. It prompts for a password change on the console during cloud-init run. To lock an account, we have to execute: `pw lock ` LP: #1854594

set_passwords: support for FreeBSD (#46)

2019-11-26T16:44:21+00:00

Allow setting of user passwords on FreeBSD The www/chpasswd utility which we depended on for FreeBSD installations does *not* do the same thing as the equally named Linux utility. For FreeBSD, we now use the pw(8) utility (which can only process one user at a time) Additionally, we abstract expire passwd into a function, and override it in the FreeBSD distro class. Co-Authored-By: Chad Smith

Add config for ssh-key import and consuming user-data

2019-10-31T16:26:54+00:00

This patch enables control over SSH public-key import and discarding supplied user-data (both disabled by default). allow-userdata: false ssh: allow_public_ssh_keys: false This feature enables closed appliances to prevent customers from unintentionally breaking the appliance which were not designed for user interaction. The downstream change for this is here: https://github.com/delphix/cloud-init/pull/4

ubuntu-drivers: call db_x_loadtemplatefile to accept NVIDIA EULA

2019-08-22T17:09:22+00:00

Emit a script allowing cloud-init to set linux/nvidia/latelink debconf selection to true. This avoids having to call debconf-set-selections and allows cloud-init to pre-confgure linux-restricted-modules to link NVIDIA drivers to the running kernel. Cloud-init loads this debconf template and sets the value to true in the debconf database by sourcing debconf's /usr/share/debconf/confmodule and uses db_x_loadtemplatefile to register cloud-init's setting for linux/nvidia/latelink. LP: #1840080

ubuntu-drivers: emit latelink=true debconf to accept nvidia eula

2019-08-19T21:37:29+00:00

To accept NVIDIA EULA, cloud-init needs to emit latelink=true debconf setting to the linux-restricted-modules package to allow NVIDIA drivers to properly link to the running kernel. LP: #1840080

Add support for publishing host keys to GCE guest attributes

2019-08-09T17:11:05+00:00

This adds an empty publish_host_keys() method to the default datasource that is called by cc_ssh.py. This feature can be controlled by the 'ssh_publish_hostkeys' config option. It is enabled by default but can be disabled by setting 'enabled' to false. Also, a blacklist of key types is supported. In addition, this change implements ssh_publish_hostkeys() for the GCE datasource, attempting to write the hostkeys to the instance's guest attributes. Using these hostkeys for ssh connections is currently supported by the alpha version of Google's 'gcloud' command-line tool. (On Google Compute Engine, this feature will be enabled by setting the 'enable-guest-attributes' metadata key to 'true' for the project/instance that you would like to use this feature for. When connecting to the instance for the first time using 'gcloud compute ssh' the hostkeys will be read from the guest attributes for the instance and written to the user's local known_hosts file for Google Compute Engine instances.)