create .securedrop_client dir and run alembic upgrade head in dev/staging mode

[sssoleileraaa]

Description

Sometimes things go wrong during provisioning VMs and config.json is missing and the db isn't set up properly. A little db and config verification on login would allow us to provide an error on the login screen rather than this when we try to mark all pending replies as failed:

[eloquence]

Is the DB expected to be initialized after make all, without running the client? I saw this issue yesterday after another make all run (after I shared the screenshot with you). These are the steps I was following:

1) make clean && make all 2) Install virtualenvwrapper and git in app template 3) Enable sys-firewall for sd-app 4) git clone client, make and activate virtualenv, install dependencies 5) Run client via python -m securedrop_client

The client did not start because it lacked a DB, complaining in the same manner about replysendstatuses (config.json was just fine). I was able to resolve by running alembic upgrade head in the checkout dir and moving the resulting svs.sqlite into the ~/.securedrop_client dir, but those steps I just improvised.

[redshiftzero]

which environment is this in reference to?

If it's the packaged code in a prod-like environment: the database should be created/upgraded via the entry point here https://github.com/freedomofpress/securedrop-client/blob/master/files/securedrop-client, i.e. it does require running securedrop-client.

If it's the staging environment then the securedrop-client package is installed, then you can either:

1. run securedrop-client once to set up the database/~/.securedrop_client directory, or
2. run these steps

[sssoleileraaa]

It's in reference to the staging environment.

1. run securedrop-client once to set up the database/~/.securedrop_client directory, or

that's right! i forget to run securedrop-clientto create the db before running python -m securedrop_client sometimes... so i think @eloquence steps just need one more step to work:

1) make clean && make all 2) Install virtualenvwrapper and git in app template 3) Enable sys-firewall for sd-app 4) git clone client, make and activate virtualenv, install dependencies

4.5) Run prod client via securdrop-client

5) Run client via python -m securedrop_client

So reducing the number of steps to test on staging is more of a nice-to-have than a bug-- i'll remove the bug tag on this issue

[eloquence]

In my case, I was running in Qubes against the SuperFun test instance (not a staging env), but same result.

That makes perfect sense, will make a small PR into the README to clarify that client dir needs to be initialized manually or by running the installed version.

[sssoleileraaa]

This can potentially be fixed by address this issue: https://github.com/freedomofpress/securedrop-client/issues/507