Hi list, I’ve been thinking about the best way to upstream the support for grabbing OSTree updates from the local network and from USB drives which Endless OS has (in eos-updater[1]). Currently, eos-updater implements this with some custom polling code for the local network (looking for well-known DNS-SD records) and USB drives (looking for a well-known directory in the root of a mount), which derives a URI (HTTP over LAN; ‘file:’ for USB drives) to pass to ostree_repo_pull() — so only one URI is ever tried. After that point, everything which happens is fairly standard OSTree functionality. I’ve been thinking today about whether we should instead be treating them like mirrors of the canonical upstream remote. I *think* we could potentially already implement this by having some external process generate a local mirrorlist file for each remote, and update it just before polling for updates. However, this is a bit ugly, prone to synchronisation problems between the update processes, and would mean having a daemon in ostree.git (which I know people are against). Instead, I’m wondering whether libostree could gain explicit support for finding mirrors using Avahi and monitoring mounts, similarly to how it can currently resolve metalink and mirrorlist files. Some requirements we have for this functionality: • Remotes can change over time: we want to be able to update a repository from a USB drive one week, then from the local network the next. • Machines need to be configurable to enable none/some/all of these remote mirrors. So for Avahi support, I’d define a DNS-SD record format, and some repository configuration which would enable it. The format would need to scale to multiple repositories (for example, if a machine used OSTree for the OS, and flatpak for apps). Any machines on the local network which advertise repositories matching the local repository’s canonical remote URI, would be added as HTTP mirrors. This would require some server support (at the minimum, an Avahi .service file and a running OSTree simple HTTP server). For USB drive support, I’d define some repository configuration which enables it and specifies which well-known directory to look for in each mount (for example, check if $mount/.updates-in-here is an OSTree repository for each $mount point when we do a pull; ‘.updates-in-here’ would be specified in the repository configuration), and adds each of them as a mirror. In both cases, requiring GPG verification of the remote would be essential in any normal situation. All the mirrored content would have to be signed with the same GPG key as the canonical upstream. Thoughts? Philip [1]: https://github.com/endlessm/eos-updater
Attachment:
signature.asc
Description: This is a digitally signed message part