Revisit dev environment or provisioning logic for dev and staging/production

[emkll]

There are some situations where the provisioning logic (dev and staging/prod) where files are copied twice, in staging and prod scenarios:

• once via the rpm package to its destination
• once via rpm to /srv/salt and then to its destination via salt

The problem with this approach is that it makes tracking the files inside RPM manifest more complex, resulting in a higher likelihood of provisioning errors. An example can be found in #468 , and given that the files are logic-dependent, it's very hard to catch regressions: In this case they were only caught by installing on a clean Qubes install.

1. Keep the dev env as-is and not use rpm to copy any file outside of /srv/salt. The downside is that is requires applying dom0 state in order to update critical scripts, such as the updater. They will not be updated if there's an error with salt
2. Keep the dev env as is, and introduce more conditionals in the salt logic. This might become complicated to track requires and correctly test the execution flow
3. Rework make dev / make all to use RPMs to install to dom0 in the dev scenario. We could consider distinct packages that would include dev-only tools to help with copying/cleaning files to dom0. I think this method is preferred, as it would ensure the dev environment mirrors staging and production environments more closely.

[eloquence]

An example of how the current approach complicates debugging are the issues encountered here:
#499 (comment)

Files are copied into /opt/securedrop via RPM, and then the same files are provisioned via Salt. If the second step fails, the files are correctly provisioned but the install errors out.

See also the issue with cleanly uninstalling, where we see warnings and errors, as noted on #505.

IMO cleaning up this logic (I suspect we're all leaning towards your proposal 3 to use RPM for dom0 files wherever possible) is one of the highest priority near term architectural improvements to consider alongside template consolidation.

[conorsch]

As @eloquence helpfully points out, I opened a duplicate issue in #538 strongly encouraging adoption of option three. If anyone's got arguments for options one or two (or something else!), now's the time to say so.

[eloquence]

We are pursuing option 3 identified in this issue, which is tracked as #538 and has PR #587 against it, so this issue is now duplicative. Closing.