Open eloquence opened 3 years ago
The extraction of the updater from the workstation repository turns out to require a couple of small migrations to ensure we don't leave old files laying around. We used this as an opportunity to start thinking about how the goals described above can be implemented in sensible way.
The approach we've settled on so far is described as follows:
0.7.0
to 0.8.0
, so we'll run migrations for 0.7.1
, 0.7.2
and finally 0.8.0
%pre
, %post
(and possibly %triggerin
) scriptlets as follows:
%pre
exclusively to help %post
with knowing which version of package we're upgrading from by creating a temporary file with the version number to be read later by %post
%post
reads the version file left by %pre
, checks which migrations are available and figures out the delta (see example from above) and runs the respective scripts/statesThis will be implemented as a kind of test-balloon for securedrop-updater
(to be reviewed / doula'd by @cfm) and if this approach works well, is intended to be subsequently ported to securedrop-workstation
.
This is still an open issue - for now the updater has been merged back to securedrop-workstation without the initial versioned migration code, but we can pull it back in if necessary.
The preflight updater currently has a very limited mechanism for triggering a full
sdw-admin --apply
run (i.e. enforcing all Salt states and not just the ones specified fordom0
via https://github.com/freedomofpress/securedrop-workstation/blob/main/dom0/sd-workstation.top#L5-L21).That mechanism works as follows:
check-migration
script performs feature tests to drop migration flag in/tmp/sdw-migrations
In the case of #661, the drawbacks of that approach became apparent:
/tmp
) if the user reboots after a failed update that successfully upgraded the RPM and the state of the system is not necessarily assured;In short, feature detection alone is insufficient to handle all migration types, and postinst-type hacks are hackish.
As we do with Alembic-managed database migrations, we need a way to version migrations and the state of the system, so we can apply the migrations that are required. The scope of this issue is:
1) Propose a lightweight implementation approach for versioning migrations (i.e. upgrades that require an
sdw-admin --apply
run); 2) If there is consensus, implement said approach.