A mismatch between the key names in BondConfig's to_config method
and NetworkDev's netdev_info function was causing subiquity to
crash when creating a bond with a valid transmit hash policy and
then later trying to edit it (LP: #2051586).
The correct key name set by the to_config method should be
"transmit-hash-policy" since this later gets passed to netplan
and neither "xmit-hash-policy" nor "xmit_hash_policy" is a valid
key name in pure netplan config.
Subiquity has a mechanism to detect the presence of netplan. It does so
by checking the existence of the file /lib/netplan/generate. This
mechanism is used in the network screen to validate the YAML
configuration.
However, since netplan 0.107 (present in mantic and noble), the file
/lib/netplan/generate is no longer present. It used to be provided as an
alias for /usr/libexec/netplan/generate ; starting in jammy.
This made Subiquity unable to detect that netplan is running ; and
therefore skip the YAML validation against netplan.
Since we support focal in Subiquity, let's change the detection code so
that we look for both locations. When we stop supporting Focal in the
future, we can drop the reference to /lib/netplan/generate.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Previously we had stripped the wifi config and wrote it separately with
stricter permissions than normal to avoid leaking sensitive data, but
now at first glance this seems redundant with all the netplan config
file permissions being the same. The reason we didn't collapse
everything back to one file with the permissions change is that
there are scenarios in which the 00-installer-config.yaml file could
purposefully be shared, so we should continue to strip known private
information from that file.
We now rely on distro-info to find out the EOL ESM date on LTS releases.
This information is meant to be shown on the Ubuntu Pro screens ;
instead of hardcoded values.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
A new table shows all the SSH identities/keys that are currently
imported. The user can select one and delete it from the list if he
wants to.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When running answers-based automation, the SSH controller looks into
more than one section to find ssh-import-id directives.
If the "SSH" section exists, then it is where the ssh-import-id
directives must be placed. However, if the section does not exist, the
controller will also look for ssh-import-id directives in the "Identity"
section.
The answers.yaml file used this special mechanism. This is fine.
However, if one adds a SSH section to customize other settings (e.g.,
install_server, pwauth), then the ssh-import-id directives in the
Identity section suddently get ignored ; which is confusing and looks
as if there is a bug.
Let's move ssh-import-id directives to the SSH section.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When trying to delete a partition using the answers-based mechanism,
subiquity tries to call .done() on the ConfirmDeletesStretchy overlay.
However, this method does not exist. The .confirm() method is what we
should use instead.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Previously, on the SSH screen, the ability to enable/disable the SSH
server and the ability to import a SSH identity were both covered by a
single form. Therefore, there was no way to import multiple identities.
This change adds a button "Import SSH key" which opens a new form to
import an identity. The button can be pressed multiple times and the
resulting identities are all submitted when the user clicks on Done.
Furthermore, navigating back to the SSH screen does not "forget" already
imported identities.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When running in strict snap confinement snap client binary is not
accessible. Additionally output format of snap client binary is
not guaranteed not to change. snapd REST API should be used instead.
Signed-off-by: Ondrej Kubik <ondrej.kubik@canonical.com>
Chris Peterson