virtualenv needs to be activated before adding users via manage.py

[redshiftzero]

Description

The documentation to add users needs to be updated after the recent change to use a virtualenv

Steps to Reproduce

Follow instructions in https://docs.securedrop.org/en/latest/create_admin_account.html to create an account

Expected Behavior

User account is made

Actual Behavior

Python dependencies cannot be found

Comments

We can instruct the user to activate the virtualenv first (source /opt/venvs/securedrop-app-code/bin/activate)

[zenmonkeykstop]

Should the venv activation maybe be wrapped in a script or added in the www-data user's .profile? ( Not sure they have one apart from system default).

[conorsch]

Wrapper script is a fine idea here, it can handle:

1. sourcing the venv
2. managing user (e.g. suing to www-data)
3. passing args to manage.py

Of course we'd still need to update the docs to map. Makes sense to call the script securedrop-admin, although we already have such as script in the Tails environment, and potentially in a Qubes Workstation environment (#51), as well.

[kushaldas]

The best way is to point the executable to the inside of virtualenv. This is what happens by using entrypoints in setup.py.

[rmol]

To use an entry point, wouldn't we need what's now in /var/www/securedrop installed in site-packages under /opt/venvs/securedrop-app-code, so that manage.py is on sys.path?

[kushaldas]

We can just add some sys.path entries for that. Have to verify the change though.

[redshiftzero]

Copying my comment here from private discussion:

Recap: The problem is that we need to make sure that manage.py uses the proper Python 3 virtualenv and the dependencies installed in that virtualenv. We have a bunch of manage.py commands used in: our docs, cron jobs that are configured already on production machines, OSSEC, etc. We need these ./manage.py invocations to continue to work, or we need to update them.

Ideas/options:

1. Switch the shebang in manage.py to the new path and hardcode it in securedrop-app-code postinst
2. Modify the securedrop-app-code debian package build process to replace the shebang similar to the above (h/t to @rmol who suggested this).
3. Modify the server dev/test env to use a virtualenv with the same path as in staging and prod - this way since dev/test environments are containerized we can keep the shebang hardcoded.
4. Add a console entry point as recommended in PEP 394 (recommended reading: this section which discusses our issue here). The downside with this is that we have to update everywhere we invoke ./manage.py (including e.g. configured cronjobs).
5. Set the first directory in $PATH to the path of the python 3 virtualenv: this way the env invocation in the existing shebang will result in the python 3 virtualenv being used.
   I just thought of 3 now - what do you think about that? That way no postinst/build changes, we just straight up hardcode the shebang - and I think that's also a better pattern (modifying dev to more closely resemble prod/staging)

I think 3 is the best thing to do for backwards compatibility (PR incoming from @rmol that does this) - that would close this ticket for the purpose of the 1.0.0 release. That said, I think we could also add an entrypoint - since it's a little nicer from the admin's perspective when they are interactively using the CLI. Thoughts @zenmonkeykstop @rmol @kushaldas ?

[rmol]

I've tested that the changes from #4713 (options 1+3 above) do solve the problem; having the virtualenv python in the shebang line of manage.py makes it work.

I think getting entry points working deserves a separate post-1.0.0 ticket.

[redshiftzero]

@rmol tested this, so closing