Update documentation installation/upgrade of version 2.13.0 (Debian package)

[ChumOfChance]

In SecureDrop 2.13.0 securedrop-admin is a Debian package. See https://github.com/freedomofpress/securedrop/pull/7606

Consequently the instructions for installing SecureDrop need to change.

Upgrade instructions to 2.13.0, which workarounds for potential issues, also need to be included.

[ChumOfChance]

See https://github.com/freedomofpress/securedrop/pull/7606#issuecomment-3542424304 for the latest overview of fresh installation and upgrading/migrating for existing users.

[ChumOfChance]

From https://github.com/freedomofpress/securedrop/pull/7606#issuecomment-3542424304:

Manual updates are straightforward: Check out the release tag with the debian packaging changes run ./securedrop-admin setup, which does much the same as above except for not having to kill the GUI updater.

Question for @zenmonkeykstop: in the event of a manual upgrade scenario, does the user also need to run ./securedrop-admin localconfig ? If looks like ./securedrop-admin setup will run localconfig, just confirming that's the case.

[zenmonkeykstop]

Yup, securedrop-admin localconfig gets run as part of the migration triggered by ./securedrop-admin setup - the user will be prompted for the tails admin password when that happens.

[ChumOfChance]

Another Q:

From the current Admin Workstation install docs:

Next, run the configuration playbook and answer the prompts with values that match your environment: ./securedrop-admin sdconfig

The script will automatically validate the answers you provided and display error messages if any problems are detected. The answers will be written to the file install_files/ansible-base/group_vars/all/site-specific.

Confirming if that statement is still true. @zenmonkeykstop

[ChumOfChance]

Similarly, are the onion service files still saved there? Basically are the Ansible paths unchanged? Or moved to the new config dir?

[ChumOfChance]

Ah, is it all here: /usr/share/securedrop-admin/ansible-base/ ?

[zenmonkeykstop]

• the command is now securedrop-admin sdconfig (no ./ path part as it's installed in /usr/bin
• site specific config (like site-specific, the tor auth_private files etc) is now in ~/.config/securedrop-admin and backups are written there too. /usr/share/securedrop-admin/ansible-base has the roles and playbooks but not site-specific info. (If you spot some that's a bug IMO)

[ChumOfChance]

Yeah I've got the change to the securedrop-admin command, I was just quoting the current docs.

Thanks for the paths clarification, I think I've got it now.

[ChumOfChance]

Here's a more fun docs question:

For an initial fresh install, should the git repo be cloned to ~/Persistent? After the successful installation of the deb package securedrop-admin I don't think it is needed anymore, and if anything its presence may cause confusion for previous users of SecureDrop who are expecting to run all their commands from that directory. So maybe it just gets cloned to ~/ for the install, and then is nuked on reboot. Nice and clean and very clear we are using a deb package now, no need to add ./ to the commands.

[zenmonkeykstop]

That is a more fun question - I haven't tested it but that should work!

[ChumOfChance]

Are there new instructions for "Troubleshooting Workstation Updates", beyond the specific case of 2.12.10 -> 2.13.0? How will updates be done manually post 2.13.0?

[ChumOfChance]

There are few places in the docs where we ask a user to check the current installed version of securedrop-admin. Will the new securedrop-admin package self-report the installed version (e.g. --version)? What's the best way to check the installed version? apt show securedrop-admin | grep Version maybe?

[zenmonkeykstop]

There are few places in the docs where we ask a user to check the current installed version of securedrop-admin. Will the new securedrop-admin package self-report the installed version (e.g. --version)? What's the best way to check the installed version? apt show securedrop-admin | grep Version maybe?

There isn't a --version flag unfortunately. Anything apty will work. apt-cache policy securedrop-admin is likely the most useful, a good old apt list --installed| grep securedrop-admin should also be good.

[zenmonkeykstop]

Are there new instructions for "Troubleshooting Workstation Updates", beyond the specific case of 2.12.10 -> 2.13.0? How will updates be done manually post 2.13.0?

A manual update would be via apt - sudo apt update && sudo apt install --upgrade securedrop-admin most likely. There is still an update check in the securedrop-admin tool itself - so long as it's not run with --force, it will run a small playbook first to check and fail if it's not updated.

Tails Additional Software feature should automatically update installed packages on startup/network connection. I dunno how reliable it is though.

[nathandyer]

@zenmonkeykstop Just double-checking my assumptions for organizations who have not yet completed the Tails 7 / SD 2.12.10 upgrades -- should we advise that they first upgrade to 2.12.10 as an intermediate step, or can they jump straight to the packaged version (assuming they complete the Tails 7 upgrade first)?

[zenmonkeykstop]

If they're on Tails 7 they can and should jump straight to 2.13.0 and the packaged version from any previous (Tails-7-compatible) version.

[zenmonkeykstop]

Bit more context: the GUI updater normally just does ./securedrop-admin update, then ./securedrop-admin setup, then ./securedrop-admin tailsconfig in that order. In this case, the update command will put them on latest release (2.13.0) and in 2.13.0 ./securedrop-admin setup will kill the GUI updater and trigger the migration. So it doesn't really matter which version of the GUI updater they use.