Oftentimes, we want to simulate a specific behavior of the application
when running in dry-run mode. To do so, we use either command line
parameters or environment variables.
This patch introduces a configuration object for dry-run executions
only. The object can be automatically loaded from a JSON file specified
via the --dry-run-config CLI argument.
Such a configuration object should help us cover way more test cases.
Going forward, I would like to use this object for things like:
* drivers - to instruct Subiquity what third-party drivers it should
suggest ; or if Subiquity should run ubuntu-drivers on the host
instead.
* ubuntu-pro - to specify the ua-contracts test environment URL - or
predefined automatic replies for the server
* to assume that /var/lib/snapd/seed/systems directory exists on the
source (or not).
* to specify the Ubuntu release that is returned by lsb_release ; can
be used to test behavior on LTS vs non LTS releases.
*
* ...
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The test_api.py is not meant to be used as en entry point. There is no
shebang so executing the script from a sh-compatible shell can be pretty
messy.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
ssh-keygen -l supports an input file that has multiple keys. As a
result, it will output multiple key fingerprints.
That being said, ssh-keygen will ignore empty newlines from the input
(and maybe other things?).
It makes it slightly challenging to associate each key with its
fingerprint because the number of lines in the input and output can
differ, e.g.:
input | output
-----------------------------------------------------------------------
ssh-rsa AA[...] user@host ◀-▶ 256 SHA256:[...] user@host (RSA)
<empty line> ┌▶ 3072 SHA256:[...] user@host (ED25519)
ssh-ed25519 AA[...] user@host ◀┘
To simplify this process, we will do one call to ssh-keygen -l for each
key from the input.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When fetching SSH keys, the proxy settings specified by the user were
not used. This resulted in the inability to import keys in networks where
a HTTP proxy is mandatory.
We now explicitly set the https_proxy environment variable when calling
ssh-import-id if a proxy was configured by the user.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Instead of fetching SSH keys on the client side, we now make the client
consume an API and have the implementation on the server.
The main benefit is that it gives us more control over the environment
where the ssh-import-id command is executed.
This should allow us to set HTTP proxy environment variables (and
optionally locale-related variables such as LC_MESSAGES) according to
the user's selection.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
ssh-import-id will include empty lines when multiple keys get imported.
These empty lines end up included in the array of authorized keys that
Subiquity manages and subsequently get passed to cloud-init and get
stored in autoinstall-user-data:
authorized_keys = [
'ssh-rsa AAAA[...] user@hostname',
'',
'ssh-ed255129 AAAA[...] user@hostname2',
]
Although cloud-init successfully ignores empty lines, it seems cleaner
to filter those out in Subiquity.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When executing a command via arun_command with check=True, we forge
and then raise a CalledProcessError exception if the command exits
abnormally (i.e., exit code != 0).
When doing so, we only instantiate the exception with the exit code and
the command executed. This means that we lose access to any output
captured so far. This is usually fine for stdout but stderr oftentimes
contains invaluable information to understand what caused the command to
exit abnormally.
Back in Python 3.5, stdout and stderr were introduced as new attributes
for CalledProcessError.
We now also include stdout and stderr in the CalledProcessError
instances that we forge. This allows us to access stderr (if any) when
catching the exception with:
try:
...
except CalledProcessError as exc:
print(exc.stderr)
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
This kind of change is a bit of a problem with the current approach to
talking to snapd I guess -- deserialization will fail if we encounter a
new value for one of these fields.
The code in subiquity main could plausibly be offered as an upgrade to
users installing focal server and focal server ISOs do not have a source
catalog so we need to support that. But we will never support a desktop
ISO that does not have a source catalog so we can remove some slightly
confusing code that attempted to cover that case.
The point of switching snap channel based on .disk/info is so that we
can avoid releasing updates to point release media if they won't work
there. If the snap is not tracking ubuntu/stable-XX.YY then there is
funny business afoot and we are not on point release media, so switching
channels as if we are is just unhelpful (for example, if you are working
on a project that is going to involve giving someone an image with a
subiquity from a non default track).
If the channel to switch to comes from the kernel command line or
autoinstall though, it should still be honoured.
For the systems currently being tested, the live installer environment
is stacked on the one being installed and so the system definition for
the system being installed is already available. That's not going to be
true in full generality though, so add some helpers to make all systems
defined in the source available in the live installer environment before
calling into snapd to find out about them.
Subiquity now supports a new endpoint that can be used by the desktop
installer to configure whether the ubuntu-restricted-addons package
should be installed. This package contains third-party codecs commonly
used on a desktop install.
curl --unix-socket /run/subiquity/socket http://a/codecs
> {"install": false}
curl --unix-socket /run/subiquity/socket \
http://a/codecs -d '{"install": true}'
curl --unix-socket /run/subiquity/socket http://a/codecs
> {"install": true}
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Olivier Gayot