Focal migration (take 2) #160
Conversation
path; rename docs from "focal_prep" to "focal_migration", and remove backup step from prep (this should occur during migration and not beforehand).
|
Curses, this is a clean branch so I'm not sure why I'm seeing those extra merge commits. Okay, well |
|
|
||
| Instances that already have :doc:`v3 onion services <../v3_services>` enabled | ||
| and follow our migration guide will be able to | ||
| preserve their existing *Source* and *Journalist Interface* onion URLs. |
There was a problem hiding this comment.
As a reader, that left me with the question "what if I'm not running v3?". I know this is clarified later in the doc, but maybe add another sentence here, e.g.:
If you are still running v2 onion services, you must switch to v3 as part of the migration at the latest, and your onion addresses will change.
| SecureDrop servers are updated automatically with the latest release version. | ||
| If your servers are running an old version, this indicates a major configuration | ||
| problem, and you may need to reinstall SecureDrop. In that case, please | ||
| :ref:`contact us <contact_us>` for assistance. |
There was a problem hiding this comment.
I realize this is language from the existing prep guide, but on re-reading it here, it seems to me we should probably drop the "you may need to reinstall SecureDrop" here. They'll need to reinstall SecureDrop regardless of their current version in order to migrate; if their current server is so badly misconfigured that it's not even on 1.7.1, that may just imply that a careful review is required to determine if the data can be safely moved over to the new install. So I would suggest just dropping that clause, and keeping the "please contact us".
| ---------------------------- | ||
| (For SecureDrop instances already using v3 onion services) | ||
|
|
||
| #. :doc:`Take a backup of the current instance <../backup_and_restore>`. |
There was a problem hiding this comment.
If there are steps that are identical for both migration scenarios (e.g., make a backup, download/verify Ubuntu 20.04 media), it may make sense to split those into their own section for preparatory steps. I do recognize that means that earlier links won't be able to go directly to the path-specific section.
There was a problem hiding this comment.
For downloading/verifying Ubuntu 20.04, yes, I can add that to the preparatory steps. The reason I think that making a backup belongs during the actual migration window is it's time-sensitive; ideally the instance would be backed up and then taken offline immediately, so that no submissions fall through the cracks.
There was a problem hiding this comment.
Yes, that makes sense; I meant that the backup paragraph is duplicated in the two sections for the different paths, and if we can consolidate migration steps that are the same regardless of v2/v3 status, that might make it easier to maintain. But understand if you prefer to err on the side of just having each migration procedure be fully self-contained.
|
Thanks @rocodes, what's there so far is looking very good to me on visual review. Note that this PR currently includes some merge commits and an unrelated commit; just ping me if you'd like help resolving that. |
|
Replaced by #169 |
Status
Work in progress - feedback welcome
Description of Changes
Testing
Visual review
Release
Wait for #133 to land, will require references to that PR
Wait for #154, will refer to Ubuntu 20.04 instructions as well
Checklist (Optional)
make docs-lint) passed locallymake docs-linkcheck) passedmake docs) docs at http://localhost:8000