Open nathandyer opened 2 months ago
Thank you for filing - I think we do have some undocumented behaviour when orchestrating directly on top of an existing setup but switching environments (staging/prod/dev) like this.
My suspicion is that sudo rm /var/salt/cache
, then sudo qubesctl saltutil.sync_all
then sdw-admin --apply
would resolve this, but not sure if it's worth testing too much since it's a developer-facing problem and right now the best case is to sdw-admin --uninstall
then apply
if switching between dev/staging/prod
A "fix it with documentation" approach so we don't get bitten by our own tooling: check if config.json
has changed[^1] since the last sdw-admin --apply
, in which case insist on sdw-admin --uninstall
.
[^1]: diff config.json /usr/share/securedrop-workstation-dom0-config/config.json
might be sufficient, unless there's some other canonical configuration used by sdw-admin --{validate,apply}
.
Description
While trying to install
securedrop-workstation-dom0-config-1.0.0rc2
for QA testing, I discovered an issue wheresdw-admin --apply
can get into an inconsistent state where it doesn't pick up on changes to theconfig.json
file.Specifically, I originally had the environment set to "prod" in
config.json
. When runningsdw-admin --apply
it provided an error with the repo (which is expected, sinceyum.securedrop.org
does not have have fc37 packages yet).After changing the environment to "staging" in
config.json
and re-runningsdw-admin --apply
, it produced the exact same error.Only after manually editing
/etc/yum.repos.d/securedrop-workstation-dom0.repo
to includeyum-test
didsdw-admin --apply
complete successfully.Steps to Reproduce
Qubes-R4.2.2-rc1-x86_64.iso
for testing purposes)securedrop-workstation-dom0-config-1.0.0rc2-1.fc37.noarch.rpm
from yum-test.securedrop.org for QA purposes)config.json
, but leave it set toprod
for the environmentsdw-admin --apply
and receive an error that it couldn't find the repo (expected)config.json
and set the environment tostaging
sdw-admin --apply
againExpected Behavior
sdw-admin --apply
detects the change and completes successfullyActual Behavior
sdw-admin --apply
gives the exact same error message, immediatelyError:
Comments
May be an issue in this part of the provisioning script. (hat tip to @cfm for pulling that up so quickly)