Add make_cloudconfig as a function that models should offer that allows
for generation of the cloud-config snippet.
Move snaplist and locale to this mechanism.
Add a test for snaplist output.
* Add element updates (non-UI)
This can be controlled with autoinstall
updates: security or all
Also an API for controlling this:
curl --silent --unix-socket .subiquity/socket a/updates ->
"security"
curl -d '"all"' --unix-socket .subiquity/socket a/updates
* Automated tests - log grep for default/none/all states
* Enforce possible values on Updates controller
Route all the various get/set thru 2 common functions.
Validate incoming data.
Continuing the theme of previous work, this branch parses pc105.tree
into API-friendly attr-based classes at snap build time (which also lets
us check some constraints then and not at run time).
This is a bit sideways from the real thing I'm working on which is
moving most of the logic of keyboard handling to the server side but
anyway. This also lets me check some assumptions while processing the
data rather than in the view code.
The first of these scripts mashes the current branch's code over that of
a pre-existing subiquity snap.
The second uses the first to mash the current branch's code over the
subiquity snap from an ISO and then creates a new ISO with this new
snap.
It's all a bit terrifying but being able to get your changes into a
bootable ISO in about 30s is quite a large improvement on building the
snap from scratch.
Accidental schema updates are unintended, so enforce that. Schema
updates that don't break API are fine, we can handle that by manually
regenerating the schema at such time.
The inject-subiquity-snap.sh script rebuilds the installer.squashfs filesystem, but does not recalculate its MD5 hash.
This leads to an error message during bootup process, complaining about one of the files being damaged, that file
being installer.squashfs.
This commit introduces an extra step to recalculate the MD5 hash of the installer.squashfs and write it into
md5sum.txt, as well as to remove the GPG signature of the installer filesystem, since it's invalid anyway.
Using the NoCloud source meant that a filesystem label of "cidata"
(probably containing autoinstall config) could override the cloud-init
nocloud seed subiquity wrote and then users would not get created. So
instead write cloud config directly that hardcodes using the
DataSourceNone source and config for it.
https://bugs.launchpad.net/subiquity/+bug/1879103
Dan Bungert