This includes a hack to preserve humbug/backends.py as a symlink, so
that we don't need to regenerate all our old sessions.
(imported from commit b7918988b31c71ec01bbdc270db7017d4069221d)
This needs to be deployed to both staging and prod at the same
off-peak time (and the schema migration run).
At the time it is deployed, we need to make a few changes directly in
the database:
(1) UPDATE django_content_type set app_label='zerver' where app_label='zephyr';
(2) UPDATE south_migrationhistory set app_name='zerver' where app_name='zephyr';
(imported from commit eb3fd719571740189514ef0b884738cb30df1320)
Unlike the other workers, this process runs on the database server.
To prevent duplicate work, only the worker on the master actually
processes updates.
To deploy, we in theory just need to apply the new puppet config. In
practice, the database servers aren't on wheezy yet, so the changes
should be applied by hand to postgres0 and postgres1. This only
needs to be done on deploy to staging.
(imported from commit d679ffc0838f9fc8c7f0bede08a5568b339b7ddb)
This is a module we're using for REMOTE_USER support in MediaWiki. It is
not used in any app code nor is it distributed, nor is it incorporated
into any comapny works.
License: GPLv2+
(imported from commit da9a81db251cf850335987697ea8383623b58c53)
The value it is passed is usually https://staging.humbughq.com, not
just staging.humbughq.com.
(imported from commit c3cd8fc5baa767377f506570aa8e7d2e1ed399ec)
The old name was very confusing, and this fits the convention of "the
processor for the signups" queue a la "process_user_activity".
This requires doing a
supervisorctl stop humbug-workers:humbug-events-subscribe-new-users
puppet apply
to deploy the supervisord configuration changes and properly restart
the signups queue.
(imported from commit 0ee2dad837142afa64025446e22956709771a192)
We were previously running it against the 'postgres' database, which
meant we weren't actually checking the non-clusterwide statistics.
(imported from commit a6be529b16d5f1927463e49a7f7f4cf0b5299213)
We only want to change cases where we're talking about the hostname; HTTP
requests should still go to staging.humbughq.com for now.
Before this commit is deployed the hostname of staging.humbughq.com should
be changed to staging.zulip.net on the VM.
(the same for prod)
(imported from commit 7412530773f720ac227f40061c9ddb1a851e19bb)
lb0.zulip.net will proxy connections to the relevant backend servers.
Depressingly, SSL certificate verification of the backend servers is not
performed at this time, see:
<http://trac.nginx.org/nginx/ticket/13>
The above-mentioned bug has existed since 2011, but a CVE was not
allocated until January. The nginx developers don't seem to care. Sigh.
In any case, this is of somewhat limited impact at Humbug, since we can
have reasonable confidence that communications within AWS are not
subject to active MITMs. Passive MITM is not a concern, because the
traffic *is* in fact encrypted.
(imported from commit c96e1235fc17192c7452e0417a1309cfcda62de2)
Tim Abbott
Tim Abbott
Zev Benjamin
Luke Faraone
Leo Franchi
Scott Feeney