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>