The concept of a "universal image" is clearly infeasible. The number of image flavors is growing, and we cannot stop its growth for multiple reasons:
- Cloud-init and vendor-specific tools: indispensable in the cloud environment they are meant for, useless and even dangerous outside of a trusted environment since they don't normally try to authenticate the server and can easily become high-risk attack vectors if an attacker can mimic a server response.
- Platform-specific drivers: required for a range of devices, useless for anyone else.
- Platform-specific NIC mapping link files: can be a huge quality of life improvement for users of certain hardware, will make NIC layout confusing outside of a specific model range.
All in all, different flavors do more good than harm. However, as the number of flavors grows, it becomes harder for users to pick correct images. We already see people getting confused. Ideally, we'd like to limit confusion to the initial installation phase, updates should be straightforward.
The idea to make an update check script has been around for a while, but now may be the right time to do it because: a) the issue on hand is getting more acute b) we have most of the infrastructure for that already.
By the infrastructure, I mean the S3 storage and the scripts to work with it. We can easily adapt our image directory listing scripts (those we use for generating the web pages for nightly builds and snapshots) to produce machine-readable versions of those listings. Then we can add a command like show system updates to retrieve that file and display available updates.
I propose the following:
- We should codify a system of flavors and allow multiple hyphen-separated flavors, e.g. vyos-1.2.100-amd64-azure.iso would produce a ["amd64", "azure"] flavor list.
- Use the following listing format:
{"latest-version": "1.3.0",
"images": [
{"url": "https://<some path>/vyos-1.3.0-amd64-vmware.ova", "flavors": ["amd64", "vmware"]},
...
]
}- Add the following CLI to the images:
system {
update-check {
server <hostname>
user <username>
password <password>
auto-check # not present by default
}
}The server option will default to the community update server in rolling release and snapshots. In LTS releases, it will default to another server that will require subscriber credentials to receive a list of updates from. When accessed without authentication, it will show the latest available version and some info regarding subscriptions.
Communication with the update server will occur:
- When a user runs run show system update
- When the auto-check option is true, it will also query the server periodically
The auto-check option will be disabled by default. The installer will suggest enabling it. The script will not transmit any information that could identify the sender.