(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=rolling 2022-01-10T22:56:29+00:00 2022-01-10T22:56:29+00:00 James Falcon james.falcon@canonical.com 2022-01-10T22:56:29+00:00 urn:sha1:dc1aabfca851e520693c05322f724bd102c76364 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. 2021-12-16T02:16:38+00:00 James Falcon james.falcon@canonical.com 2021-12-16T02:16:38+00:00 urn:sha1:bae9b11da9ed7dd0b16fe5adeaf4774b7cc628cf Applied Black and isort, fixed any linting issues, updated tox.ini and CI. 2021-12-13T17:31:39+00:00 Gonéri Le Bouder goneri@lebouder.net 2021-12-13T17:31:39+00:00 urn:sha1:f4692c5d96323dc635fca26b742199d4c41f88d3 `sysctl -n hw.disknames` returns a trailing `\n`. We need to clean this up. In addition, the criteria matching system is a source of problem because: - we don't have a way to look up the label of the partition - we've got situation where an ISO image can be exposed through a virtio block device. So we just totally ignore the value of `criteria`. We end-up with a slightly longer loop of mount-retry. But this way we're sure we don't miss a configuration disk. Tested on Kubvirt with the help of Brady Pratt @jbpratt. 2021-12-09T22:46:27+00:00 Gonéri Le Bouder goneri@lebouder.net 2021-12-09T22:46:27+00:00 urn:sha1:24739592217e5ba91e09e8c28b852d31a2c0cc77 When the metadata is an ISO image and is exposed through a disk, the device is called `/dev/sd?a` internally. For instance `/dev/sd1a`. It can then be mounted with `mount_cd9660 /dev/sd1a /mnt`. Metadata in the FAT32 format are exposed as `/dev/sd?i`. With this change, we try to mount `/dev/sd?a` in addition to `/dev/sd?i`. Closes: https://github.com/ContainerCraft/kmi/issues/12 2021-12-07T20:36:23+00:00 Brett Holman bholman.devel@gmail.com 2021-12-07T20:36:23+00:00 urn:sha1:b21afb0a8ab64543715dffff490253db8ecefb9f Parametrized pytest tests get named by on their parameters. If a name has random characters, it can break the test collection of when using pytest-xdist. Replace random name with deterministic name. 2021-12-07T14:23:45+00:00 Haruki TSURUMOTO fortune.rocket42@gmail.com 2021-12-07T14:23:45+00:00 urn:sha1:0ed00ad9cdebc2d4dabd8bd6d7c901584963def5 2021-12-03T20:11:46+00:00 Brett Holman bholman.devel@gmail.com 2021-12-03T20:11:46+00:00 urn:sha1:039c40f9b3d88ee8158604bb18ca4bf2fb5d5e51 This attempts to standardize unit test file location under test/unittests/ such that any source file located at cloudinit/path/to/file.py may have a corresponding unit test file at test/unittests/path/to/test_file.py. Noteworthy Comments: ==================== Four different duplicate test files existed: test_{gpg,util,cc_mounts,cc_resolv_conf}.py Each of these duplicate file pairs has been merged together. This is a break in git history for these files. The test suite appears to have a dependency on test order. Changing test order causes some tests to fail. This should be rectified, but for now some tests have been modified in tests/unittests/config/test_set_passwords.py. A helper class name starts with "Test" which causes pytest to try executing it as a test case, which then throws warnings "due to Class having __init__()". Silence by changing the name of the class. # helpers.py is imported in many test files, import paths change cloudinit/tests/helpers.py -> tests/unittests/helpers.py # Move directories: cloudinit/distros/tests -> tests/unittests/distros cloudinit/cmd/devel/tests -> tests/unittests/cmd/devel cloudinit/cmd/tests -> tests/unittests/cmd/ cloudinit/sources/helpers/tests -> tests/unittests/sources/helpers cloudinit/sources/tests -> tests/unittests/sources cloudinit/net/tests -> tests/unittests/net cloudinit/config/tests -> tests/unittests/config cloudinit/analyze/tests/ -> tests/unittests/analyze/ # Standardize tests already in tests/unittests/ test_datasource -> sources test_distros -> distros test_vmware -> sources/vmware test_handler -> config # this contains cloudconfig module tests test_runs -> runs 2021-09-21T20:28:30+00:00 Paride Legovini paride.legovini@canonical.com 2021-09-21T20:28:30+00:00 urn:sha1:089a307db1fc572461eea1589f1876132c058311 tox: bump the pinned flake8 and pylint version * pylint: fix W1406 (redundant-u-string-prefix) The u prefix for strings is no longer necessary in Python >=3.0. * pylint: disable W1514 (unspecified-encoding) From https://www.python.org/dev/peps/pep-0597/ (Python 3.10): The new warning stems form https://www.python.org/dev/peps/pep-0597, which says: Developers using macOS or Linux may forget that the default encoding is not always UTF-8. [...] Even Python experts may assume that the default encoding is UTF-8. This creates bugs that only happen on Windows. The warning could be fixed by always specifying encoding='utf-8', however we should be careful to not break environments which are not utf-8 (or explicitly state that only utf-8 is supported). Let's silence the warning for now. * _quick_read_instance_id: cover the case where load_yaml() returns None Spotted by pylint: - E1135 (unsupported-membership-test) - E1136 (unsubscriptable-object) LP: #1944414 2021-06-14T19:39:05+00:00 Gonéri Le Bouder goneri@lebouder.net 2021-06-14T19:39:05+00:00 urn:sha1:59a848c5929cbfca45d95860eb60dfebd0786c94 - Mostly based on FreeBSD, the main exception is that `find_devs_with_on_freebsd` does not work. - Since we cannot get the CDROM or the partition labels, `find_devs_with_on_dragonflybsd()` has a more naive approach and returns all the block devices. 2021-03-19T14:06:42+00:00 Daniel Watkins oddbloke@ubuntu.com 2021-03-19T14:06:42+00:00 urn:sha1:b794d426b9ab43ea9d6371477466070d86e10668 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