-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Refactor] Move all Salt provisioning files into /srv/salt/securedrop_salt #1048
Conversation
f4f42ee
to
9a6862c
Compare
fa6cf6a
to
e0cecb7
Compare
I went back and forth a number of times on whether to put files in /srv/salt/securedrop_salt (a la unman/shaker) or in /srv/securedrop_salt (a la original #837 proposal, and in line with the user_dirs approach eg /srv/user_salt/).
Since we're not wild about Salt and trying to make it less of a feature in our lives, I'm going (back to) the second option and just putting our stuff in a subdirectory of /srv/salt. It feels like an okay compromise between not making a mess in /srv/salt/ vs not adding too much complexity to our lives. |
18e7ac7
to
af738b8
Compare
Not sure why sd testrunner isn't running on this |
b796dce
to
b2cd2db
Compare
Just ran through a successful provisioning locally - going to interrupt CI in order to sign that last commit, so it may not be green for another hour |
Update rpm specfile. Include all securedrop_salt files in MANIFEST.in. Use securedrop_salt path in Jinja and sls requirement import statements.
…f /srv/salt/_tops.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deployment is working and tests are passing - but the global copy of securedrop_salt includes the apt-test sources file and the test key. we shouldn't be packaging those in the RPM. They do need to be in place for dev and staging runs, - we could keep them in the repo and copy them in place via the make target (or some other solution).
include dom0/*.conf | ||
include dom0/remove-tags.py | ||
include dom0/securedrop-handle-upgrade | ||
include securedrop_salt/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This includes the apt-test key and sources file. We probably should be excluding these and adding them in via the dev setup script when make dev
or make staging
is run instead. They shouldn't be shipped in the prod RPM.
install -m 755 -d %{buildroot}/srv/salt/sd/usb-autoattach | ||
|
||
install -m 755 -d %{buildroot}/srv/salt/ | ||
cp -a securedrop_salt %{buildroot}/srv/salt/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as in manifest, should be excluding apt-test config.
Status
Ready for Review
Description of Changes
Towards #837 (this may be sufficient for our purposes to close it), helps with #1047 if we decide we like it
Changes proposed in this pull request:
/srv/salt/securedrop_salt/
directory (and adjust imports and provisioning scripts accordingly). This means thesd-proxy
,sd-whonix
andsd-workstation
directories are no longer used, and thedom0
directory becomessecuredrop_salt
./srv/salt/sd/
or/srv/salt/usb-autoattach
are now in/srv/salt/securedrop_salt
.sd-workstation.top
by name, instead of enabling all top files matching a given pattern. (If we ever add additional top files we will have to enable them specifically, which seems appropriately conservative.)securedrop_salt
into/srv/salt/securedrop_salt
on dom0. (This is a change from when we globbed by filename/type)files/
andsecuredrop_salt/
.To sum up, that means
securedrop_salt/
gets provisioned to/srv/salt/securedrop_salt
files/
gets provisioned to somewhere else on dom0, as defined in the .spec file (future possibility of organizing this in a directory structure instead of in the spec file: Simpler rpm build (and/or more legible repo) #1047)scripts/
is responsible for building, linting, or dev provisioning [and is not provisioned to sdw laptops]Testing
Deployment
Any special considerations for deployment? Consider both:
Checklist
If you have made changes to the provisioning logic
make test
) pass indom0
If you have added or removed files
MANIFEST.in
andrpm-build/SPECS/securedrop-workstation-dom0-config.spec
If documentation is required