Skip to content
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

Prevent admins from using ansible to clobber servers / configs #2964

Closed
heartsucker opened this issue Feb 3, 2018 · 1 comment
Closed

Prevent admins from using ansible to clobber servers / configs #2964

heartsucker opened this issue Feb 3, 2018 · 1 comment

Comments

@heartsucker
Copy link
Contributor

Feature request

Description

Right now an admin could locally be checked out at some version X. The servers could have updated to some version Y > X. When the admin runs the playbooks against the servers, it could introduce bugs (security or otherwise) or could break the server my adding conflicting dependencies.

Additionally, two admins could be checked out at different versions OR two admins could be at the same version but have different values for the configs (e.g., OSSEC email addresses).

Proposed Solution

Ansible should check the file /var/lib/securedrop/version and do a SemVer check against the version checked out on the admin's machine. If the checked out version is not greater than or equal to the server's version, the playbook would abort.

The second step is that /var/lib/securedrop/config.yml is a copy of the entire set of config values need to provision the machine. This is checked against the local config to look for conflicting values. This would either

  1. Merge them
  2. Use the latest value
  3. Abort

This would help admin's keep their values in sync. We could write this merge with a custom python script that allows some values to change (e.g., email addresses) but others cannot (e.g., salt).

User Stories

As an admin, I don't want to accidentally brick my server by running the playbooks.

@eloquence
Copy link
Member

Duplicate of #5317 which speaks a bit more to the behavior we want from an admin's perspective, closing and cross-referencing this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants