How to migrate to package-based deployment for admin tooling in Tails?

[zenmonkeykstop]

SecureDrop instances are currently managed by administrators using a dedicated Tails-based Administrator Workstation, which is created during the install process by verifying and checking out the latest release version of the repo from Github and running scripts to set up a virtualenv and apply an Ansible playbook. this git-based deployment process worked around issues with persisting applications and config files in Tails, but said issues have been solved in modern Tails. See Dangerzone's installation instructions, for example. Moving to packaged-based deployments would be an improvement - for example, it would remove the need for the GUI updater,

In addition, as the Qubes-based SecureDrop Workstation moves closer to being the default option for journalists, it would make sense to be able to deploy the admin tools on Qubes (first as an alternative to Tails, and likely eventually as the default option), and to do that via packages as opposed to replicating the git-based flow.

#7576 added Qubes support for the admin tools, and work on packaging them as APT packages for Debian Bookworm (Tail's base OS and one of Qubes 4.2's core templates) is ongoing in #7606. Once the packaging PR is ready to land, a plan for migrating existing users from the git-based flow to a package-based one will be needed.

Migration is likely to consist of the following:

• ensure persistence is configured correctly to persist packages and config files
• configure persistence for the apt.freedom.press repo (similarly to Dangerzone)
• install the package and dependencies
• copy existing configuration files from ~/Persistent/securedrop/ to their new home
• remove or archive ~/Persistent/securedrop and remove the old config (network hooks, Tor changes etc)
• rerun the tails config Ansible playbook from the packaged tools

There are 2 options worth considering for existing installs:

• provide migration instructions and support to admins
• do a final git-based release including a migration script, either
  • run as part of the GUI updater process (likely in the tails config playbook), or
  • run as a one-time command by admins.

Automating the migration process as much as possible would seem to be the best path.

There's also the open question of how to handle Tails-based journalist workstations, which use the same tooling as admin workstations, but with reduced access (no server SSH, just the Journalist Interface). A similar migration process is likely needed. IMO this argues more for an automated migration, as otherwise the support burden for admins and FPF folks is likely to be pretty intense.

Interested in folks' thoughts - ideally it would be good to avoid solutions requiring either a lot of coordinated outreach or for admins to have to rebuild from scratch.

[nathandyer]

Thanks for starting this discussion, @zenmonkeykstop.

I definitely think that having one final git-based release that supplies a migration script is essential, for all the reasons you mentioned. I believe that having it run as part of the GUI updater process would be better than having it be a one-off command that Admins have to manually run. Assuming the script itself can perform all the migration steps (including checking that persistence is set up correctly), it would be nice if this could all be completely transparent to the admins -- it would just be a slightly longer-running update.

Relatedly, is it fair to assume this will require changes to our documentation? I imagine at a minimum,

cd ~/Persistent/securedrop
~./securedrop-admin

references would all change to simply

securedrop-admin

[zenmonkeykstop]

Yup there'd be a lot of docs changes - more in the install section tho (since fresh installs would need some of the steps above either as a bootstrap script or as manual instructions).

[deeplow]

Sounds like a great idea. I was wondering how tails would handle external software updates. Fortunately the answer is that it gets updated (emphasis added):

If you choose Install Every Time, the package is saved in the Persistent Storage and will be reinstalled automatically every time you start Tails.

The package will also be updated automatically when you connect to the Internet.

[zenmonkeykstop]

If you choose Install Every Time, the package is saved in the Persistent Storage and will be reinstalled automatically every time you start Tails.
The package will also be updated automatically when you connect to the Internet.

That would simplify things even more, if we could rely on it.

[micahflee]

I think a final git-based release including a migration script makes a lot of sense.

[ChumOfChance]

I agree that having a final git-based migration that runs as part of the GUI updater is the best route.

I would propose that we also provide a more manual path for situations where the totally hands-free option fails. Whether that is documented steps, or a migration script that does checks and provides output if something isn't ready or some combination of both.

[zenmonkeykstop]

Looking at whether we can remove differences between the Tails and Qubes behaviour of the packaged version (see #7606 (comment)), I think there's more of a case for a bootstrap script. Which means figuring out how to deploy that (cries in curl|bash).