Support enforcing state for other VMs

[eloquence]

The updater enforces dom0 state via Salt (#458), but it does not currently allow state to be applied to any other VMs due to the runtime this would require. This causes problems when we want to make more complex system-level changes, e.g., #563.

For future changes of this type, it would be useful to have a mechanism to selectively apply a state update to specific VMs as part of an update.

[eloquence]

Would it be feasible for the RPM to create a file (perhaps in its %post stage) that instructs the updater to apply state to specific VMs beyond dom0? We would probably also want to keep track of failures for each state (so the file isn't cleared out and additional updates are deferred until it's been run successfully) and perhaps keep better logs.

[eloquence]

We'll consider our options in the context of the pending template consolidation (#471). For this one-time consolidation, we may utilize a simple one-time flag ("template consolidation tasks have not run yet"), but as part of investigating this, @conorsch has committed to considering ways this could be made more reusable for future updates, with a timebox of 8 hours total.

[conorsch]

The first option considered for a generalized approach is to manage the requests for a full-state run similar to how database migrations are managed: an ordered list of transitions that can be safely reapplied with no side-effects. We could store a list of such "migrations" in dom0:/usr/share/securedrop-workstation-dom0-config/migrations/. That'd add a lot of wall time to each updater run, ~10-20m per update. To prevent rerunning the full state on every update, we could drop a flag, i.e. touch a file, after first successful update—but then testing becomes problematic, because a clean dev or staging environment would lack the success flags.

So we need a mechanism to detect whether a full-state run is required. We already have a "handle-upgrade" script that we used to migrate from Stretch to Buster templates (#352). During that point in the dom0 state run, we can run a simple command to determine whether or not a full-state run is required, and drop a flag in /tmp/ that can be consumed by the GUI updater code. For now, that's mostly going to handle the case of #471, but if it works, it should be flexible enough that we can reuse it in future RPM updates to trigger a full-state run based on a custom query command run in dom0.

[conorsch]

We've got a candidate implementation for triggering a full-state run via the GUI updater, as part of #619 However, we're unable to use that new method for template consolidation, because we need to update the updater first. Once 0.5.0 ships, though, we'll have the ability to manage more complicated changes in an unattended manner, which will resolve this issue.

[eloquence]

Support for enforcing state changes if certain conditions are present was indeed shipped as part of the template consolidation epic (#471), so closing this old issue.