It is possible that the platform integration glue may have already prepared a
summary of host key fingerprints at the state directory. If so, use it
otherwise, try to build the summary directly.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
In strict snap confinement, sshd config or host keys are not accessible.
If strict confinement is detected, instead allow reuse of
the host keys fingerprints already prepared by invoking process.
Prepared fingerprints are stored in: /run/console-conf/host-fingerprints.txt
Signed-off-by: Ondrej Kubik <ondrej.kubik@canonical.com>
In preparation for running console-conf as a strictly confined snaps, review of
the existing code has shown that user's key fingerprints are not being used or
displayed anywhere. Since we would not be able to read those public keys anyway,
we may as well drop the code which attempts to device the key fingerprints.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Add version checks for cloud-init to know if we can read status in JSON
format or not. If so, use that for a superior answer to the legacy
format. Handle legacy code paths also.
Autoinstall related failures are more likely than not going to be
user caused, so we shouldn't immediately generate a crash report
for these types of failures. This should hopefully allow the user
to debug their autoinstall data much faster and reduce the number
of autoinstall-related bugs reported.
When setting up the logging in a strictly confined snap, use the 'root' group,
rather than 'adm'. This will not interfere with the sandbox's policy but also
does not result in providing wider access to the logs.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Adds a base exception type for Autoinstall related failures and a
specific implementation for autoinstall validation failures.
When a user passes incorrect autoinstall data, the installer will crash
with an AutoinstallValidationError exception. Failure messages are
currently in the form of:
"Malformed autoinstall in '<autoinstall_key>' section"
where <autoinstall_key> is the name of the top-level key a particular
controller is responsible (e.g., 'apt' and MirrorController).
The section reporting is a little crude in the validation
of the base schema done by SubiquityServer, which can't discern
between the 'interative-sessions' and 'version' keys, but for now
the scope is pretty limited and can be fixed up at a later time.
SubiquityServer is responsible for checking and loading the
interactive-sessions, so it should be responsible for validating
this section as well. Additionally add this to the autoinstall
schema in the docs.
_AsyncValidatedMixin has been merged into the parent UsernameEditor,
reluctantly. I like the concept of _AsyncValidatedMixin, but what's
happening here is that UsernameEditor has inherited from 3 classes, the
first of which is in urwid, and when the constructor /
super().__init__() status changed in urwid,
_AsyncValidatedMixin.__init__() stopped being called.
OK cool, so maybe we'll just manually run initializers in the case where
it matters. That's semi-better, but with old urwid we end up calling
_AsyncValidatedMixin.__init__() twice (once directly, once by the urwid
__init__ using super()).
Further workarounds could be employed but at the moment there is one
user of _AsyncValidatedMixin, so just merge it into UsernameEditor.
Instead of manually changing the autoinstall-schema reference,
use literalinclude to insert the autoinstall-schema.json file
from the root of the repository.
Provided autoinstall data is already validated against a specific
schema by the relevant controller, but these schemas themselves
are never validated against a meta schema to guarantee they are
valid JSON schemas. This patch adds unit tests for each controller,
as well as SubiquityServer, to validate their autoinstall schema
against the latest JSON meta schema draft (that is supported in
jsonschema). A particular draft validator can be used instead by
specifying meta schema in the schema definition.
The SSHModel contained a ssh_import_id member variable. According to the
comment, it was originally meant to store meta-data about a SSH key ;
and was supposed to allow showing some sort of info back in the SSH view
if the user decides to go back.
I suspect that this variable has been unused for a long time.
Furthermore, it can only hold information about a single SSH key and we
support multiple keys..
Let's get rid of it.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Back when sources.list was always present, we would:
* move the contents of sources.list to sources.list.d/original.list
* write the CDROM info to sources.list so the CDROM cat be used as an
APT source
* restore the original sources.list file when .deconfigure() is called,
effectively discarding CDROM info
Nowadays, there is no guarantee that sources.list exists. So restoring
the contents of sources.list may mean deleting sources.list if it wasn't
present in the first place.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When an error occurs during the execution of a "$ curtin install"
invocation, the associated bug report would be titled:
"install failed crashed with CalledProcessError"
This is not very user friendly and it does not immediately give any
insight on:
With the number of reports that we receive these days, I think
classifying these reports would make our life a bit easier, and possibly
make the users understand better what's going on.
This change adds a wat to detect if a bug report is the result of a
"$ curtin install" invocation failing. If it is, subiquity sets the
title of the bug report accordingly. Examples:
* "partitioning crashed with CurtinInstallError"
* "extract crashed with CurtinInstallError"
* "curthooks crashed with CurtinInstallError"
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
We know that running os-prober on some systems is slow, potentially very
slow, especially when multiple removable devices are present.
This results in many bug reports showing "block probing crashed with
TimeoutError".
For now, I suggest we double the probert timeout when os-prober is
involved.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
We backup the sources.list to a file in sources.list.d to be
able to insert our source first; if we do not have a sources.list
this is not necessary.
If an image uses ubuntu.sources, this logic also works fine as
sources.list that we write will be sourced before the ubuntu.sources.
Dan Bungert