Heavily consolidate all manual steps for the installation process

[msheiny]

There are too many manual steps that currently take place in the installation of SD that introduce the opportunity for human error, and :astonished: vulnerabilities. Where possible I'd like to squash these down into a set of discrete scripts that users kick off that handles the bulk of the current logic (including prompting for text when necessary). From a high-level perspective I'm currently looking at the following workflow.

1. OS INSTALLATION User installs OS from a customized ISO ( see #1532 )
2. Would be nice if we could automate the Tails stick generation from our custom OS but this is a reach goal. Otherwise user manually sets up the Tails disks here.
3. User sets up firewall. If they are using recommended pfsense model we provide them a base configuration reference and from prompts fill in pieces. Using jinja or some other equivalent templating framework.
4. ADMIN Setup Stage 1 User sets up persistence and reboots. Then runs Admin workstation script manually (need to pull down securedrop code, verify and execute script outlined in docs). This will process: a. Installing virtualenv and ansible dependencies (see #1531 ) b. Setup keepass from template and start populating. Prepare a diceware based password for the user, print out to screen, temporarily need to hold that passphrase til the end of the script run. User can change this pass if they want to later but lets start them off. c. Format, and encrypt a staging USB drive. Shove passphrase into KeePass d. Copy a gpg generation script to the USB drive. Prompt user to also copy any relevant journal public gpg keys at this time to the drive.
5. SVS setup User boots into this tails drive, inserts USB from previous stage and runs the GPG generation script which handles: a. Configure tails persistence and prompt user for reboot b. SD gpg key generation - prompt for custom values, generate key, and copy public key back to transfer USB drive. Print fingerprint to screen and prompt user to write down.
6. Admin Stage 2 - User will re-run the the original script which will at the end basically serve as a thin wrapper over ansible calls. I dont think administrators of the system should be running raw ansible commands. We should be controlling that process tightly for new users and allowing commands to be exposed for experts/troubleshooting. Maybe also test the OSSEC email details before they are spit out to the server to ensure that things are on the up and up. a. Additionally prompt for configuring journal interface admin user, ssh to do that, and pull back Google authenticator QR b. Call the equivalent of the current securedrop/tails_files/install.sh script which sets up Mon/App servers tor settings on the current admin tails stick. Updates the ansible inventory and plop in the onion address.

I think the firewall is going to be the hardest to automate cleanly just because users have different network stacks, equipment, and existing environments they have to operate in. If they choose the pfsense we recommend that is great and we can offer a templated config to bootstrap that process.

I also think there is more opportunity to automate lower level pieces of the the Tails process to provision sticks with built-in persistence configured and our scripts injected into those disk areas.

This is kind of a catch all issue ticket for latest experience I ran through during an install. When it comes time for implementation, might carve this up into separate tickets so its easiest to pull PRs against. I dont anticipate a giant PR with all these changes. That would be a nightmare to review anyways.

[zenmonkeykstop]

A lot of the automation reccos have been implemented, the firewall setup is still an open question, but we can create a separate issue to track it if an existing one doesn't fit.