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

Migrate to static config #3850

Closed
wants to merge 72 commits into from
Closed

Migrate to static config #3850

wants to merge 72 commits into from

Conversation

heartsucker
Copy link
Contributor

@heartsucker heartsucker commented Oct 7, 2018

Status

Ready for review

Description of Changes

Fixes #1966

Changes proposed in this pull request:

  • Define config.json configuration file and fields
  • Create a migration tool to convert old config.py into new config.json
  • Set defaults at runtime
  • Populate missing config values via ansible

Testing

New Installs

  • Checkout this branch
  • Build debs, provision staging VM
  • Check that app works
  • Back up the configs
  • dpkg -i the app code deb (or just run postinst)
  • Check that the it was idempotent and the configs weren't changed

Old Installs (with ansible)

  • Checkout the commit on develop that this branch
  • Build debs, provision staging VM
  • Check out the head of this branch
  • Build debs, provision new VM
  • Check that app works
  • Check that config was migrated and contains the same values as config.py
  • Back up the new configs to /tmp or ~
  • dpkg -i the app code deb (or just run postinst)
  • Check that the it was idempotent and the configs weren't changed

Old Installs (without ansible)

  • Checkout the commit on develop that this branch
  • Build debs, provision staging VM
  • Check out the head of this branch
  • Build debs, scp to VM
  • Install debs manually (to simulate cron-apt)
  • Check that app works
  • Check that config was migrated and contains the same values as config.py
  • Back up the new configs to /tmp or ~
  • dpkg -i the app code deb (or just run postinst)
  • Check that the it was idempotent and the configs weren't changed

Old Installs Backup/Restore

  • Checkout the commit on develop that this branch
  • Build debs, provision staging VM
  • Run backup script
  • Check out the head of this branch
  • Build debs, provision new VM
  • rm /etc/securedrop/*.json
  • Run restore script
  • Check that config was migrated and contains the same values as config.py

Deployment

We need to be able to support the following cases:

  1. config.py is not present
  2. config.py present, config.py has partial configuration
  3. config.json present, config.json has partial configuration

Checklist

If you made changes to the server application code:

  • Linting (make ci-lint) and tests (make -C securedrop test) pass in the development container

If you made changes to the system configuration:

If you made non-trivial code changes:

  • I have written a test plan and validated it for this PR

@eloquence
Copy link
Member

eloquence commented Nov 28, 2018

For the 11/28-12/12 sprint, we will aim to do a first time-boxed review; not planning to merge yet.

@kushaldas
Copy link
Contributor

I was planning to make the SDConfig class into a proper strictly defined class (this is just a comment).

Copy link
Contributor

@redshiftzero redshiftzero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did a first pass review this afternoon, some comments/thoughts inline!

sd_custom_logo = os.path.join(sd_code, "static/i/logo.png")

tor_hidden_services = "/var/lib/tor/services"
torrc = "/etc/tor/torrc"

with tarfile.open(backup_filename, 'w:gz') as backup:
backup.add(sd_config_py)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possible edge case here:

  1. User backs up SecureDrop on 0.11.0 which uses config.py
  2. User restores to new SecureDrop 0.12.0 install which uses config.json

The migration won't occur in this case, no? Running migrate_config.py as part of the restore logic should resolve.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see the logic in restore.py to see if this does the trick.

securedrop/migrate_config.py Outdated Show resolved Hide resolved
securedrop/manage.py Show resolved Hide resolved
securedrop/source_app/__init__.py Show resolved Hide resolved
@heartsucker
Copy link
Contributor Author

Before this is merged, an open question is: should config.json be split into source-config.json and journalist-config.json? I swear there was a reason I didn't do this at first, but I can't for the life of me remember what that might have been. Probably that this was just simpler? The advantage of this would be in the future we could have stricter permissions / AppArmor rules to prevent the source app from reading secret data from the journalist config.

@kushaldas
Copy link
Contributor

Before this is merged, an open question is: should config.json be split into source-config.json and journalist-config.json? I swear there was a reason I didn't do this at first, but I can't for the life of me remember what that might have been. Probably that this was just simpler? The advantage of this would be in the future we could have stricter permissions / AppArmor rules to prevent the source app from reading secret data from the journalist config.

As we discussed last night, please go ahead and split them across into two files. This PR also needs Test steps.

@heartsucker
Copy link
Contributor Author

@kushaldas @redshiftzero I've made a few more changes. Basically all all the config generation logic has been moved into populate_config.py and doesn't exist in ansible (other than as a shell-out to it). There were some tests added for a couple of common cases for the state of the config files, but there are tons of edge cases and I'm not sure how thorough we want to be about the entire space of possibilities for this.

@heartsucker
Copy link
Contributor Author

Ah, also the configs were split into a source and journalist version, both as python classes and different JSON files. I also stripped out all global references to the config and everything is injected (for tests and the application).

@codecov-io
Copy link

codecov-io commented Dec 15, 2018

Codecov Report

Merging #3850 into develop will increase coverage by 0.17%.
The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #3850      +/-   ##
===========================================
+ Coverage    84.67%   84.85%   +0.17%     
===========================================
  Files           43       44       +1     
  Lines         2760     2918     +158     
  Branches       299      318      +19     
===========================================
+ Hits          2337     2476     +139     
- Misses         355      364       +9     
- Partials        68       78      +10
Impacted Files Coverage Δ
securedrop/securedrop/source.py 0% <0%> (-100%) ⬇️
securedrop/securedrop/journalist.py 0% <0%> (-100%) ⬇️
securedrop/securedrop/i18n.py 92.3% <0%> (-2.57%) ⬇️
securedrop/securedrop/crypto_util.py 95.45% <0%> (-0.67%) ⬇️
securedrop/securedrop/qa_loader.py 85.62% <0%> (-0.54%) ⬇️
securedrop/securedrop/create-dev-data.py 0% <0%> (ø) ⬆️
securedrop/securedrop/populate_config.py 75.67% <0%> (ø)
securedrop/securedrop/manage.py 80.18% <0%> (+1.41%) ⬆️
securedrop/securedrop/source_app/__init__.py 94.25% <0%> (+2.11%) ⬆️
securedrop/securedrop/journalist_app/__init__.py 94.11% <0%> (+2.16%) ⬆️
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7b727a9...e5195dd. Read the comment docs.

install_files/ansible-base/roles/backup/files/backup.py Outdated Show resolved Hide resolved
molecule/builder/tests/test_securedrop_deb_package.py Outdated Show resolved Hide resolved
securedrop/i18n.py Show resolved Hide resolved
securedrop/sdconfig.py Outdated Show resolved Hide resolved
self.DATABASE_USERNAME = _config.DATABASE_USERNAME # type: ignore
except AttributeError:
pass
self.SECUREDROP_DATA_ROOT = '/var/lib/securedrop/'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add the type annotations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you check again that sufficient type annotations have been added?

@eloquence
Copy link
Member

Recapping our discussion from sprint planning today:

We want to minimize the risks associated with this big (and important!) change by ensuring we express through automated tests the potential states that the configuration file can be in. The number of states should be manageable given that the file is not manually edited: when have the playbooks been run, and what features have been explicitly enabled? We must assume that there are long-running instances that have not run playbooks since pre-0.4.

@heartsucker -- on the FPF side, we've committed to up to 8 person hours to help get this closer to the finish line, but we should make sure we're on the same page vis-a-vis the testing strategy. Let's discuss w/ @redshiftzero on Gitter, or during standup, next time you're around.

@heartsucker
Copy link
Contributor Author

As a note to reviewers, the test test_populate_config.py is the primary place one would want to look to check for what states of config files we are currently operating under. Additional tests would probably be added here.

@heartsucker heartsucker force-pushed the static-config branch 2 times, most recently from 79db0b0 to 3c5d2e2 Compare January 14, 2019 16:36
@eloquence
Copy link
Member

eloquence commented Jun 18, 2020

Hi @heartsucker, this has been sitting for a long time and I think it's time to acknowledge that we're probably not going to land a version of this change, which would require significant PR surgery at this point, and which is quite high-risk in terms of potential for breaking existing configs.

Instead our bias is to prioritize moving as many settings as reasonably possible to the database (where we can use alembic migrations for change management) and to expose them via the web-based admin UI.

I'm going to leave this open a few more days in case other folks want to make the case for revisiting this PR, and then close if there are no objections.

@eloquence
Copy link
Member

Closing PR per the above comment; let's keep the static-config branch around for now in case we want to revisit at a later date.

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

Successfully merging this pull request may close these issues.

Automated web application configuration migration
6 participants