Digital Ocean emails you the VM's password in plain text. We shouldn't
have this work for longer than we have to.
(imported from commit 2310cac9a9aa085149b9438941ecb0a5f703c128)
On Debian systems, this is found in the `python-dns` package.
On OS X and others, install "pydns" using your Python package manager.
(imported from commit 17827d0a1d3d72b12945df5563295a1573bfa1ed)
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)
On EC2-VPC we have the ability to attach multiple addresses to one
interface, and multiple interfaces to one machine.
We should configure those interfaces whenever our system boots, and
ideally whenever networking is restarted.
This commit adds a script that is executed once eth0 is brought up that
proceeds to configure all subsequent interfaces, real and virtual.
The script is configured to be installed (along with the helper script
that calls it) on all systems via Puppet.
(imported from commit fdc153ef649edbb8fedd40ff4d77262aae593c39)
We switch to always specifying HostKeyAlgorithms=ssh-rsa because of a ECDSA
key bug in the Debian images which results in the fingerprint not being
printed to the console. Our config later forces RSA after we do a puppet
apply, so we might as well start using RSA from the beginning.
We start out sshing in as "admin", and delete the user (moving keys over to
"root") at the beginning.
We switch to the ops repo instead of backports, and drop the installation
of puppet from backports.
We no longer install humbug-self-signed.key on our servers; instead real
certificates must be installed manually.
(imported from commit cbabe65a4e0ef37df1fece6eaec053a2368f6ef5)
Unlike other directories, we explicitly enumerate the files we want to be
present in sites-available, so the previous commit series did not actually
instruct puppet to make the zulip-staging files accessible.
(imported from commit 22efc4d272eba8d6c869edbaa9114c50e1988288)
We create a new sites-available entry which is essentially a duplicate of
sites-available/humbug-staging with s/humbug/zulip, and add the associated
symlink directive in Puppet.
(imported from commit febcb585ce93c21c6849d96458cc2bd096b30538)
This must be deployed after we update our running nginx configuration
to serve api.humbughq.com.
(imported from commit b5c34ebdd595f55eecd6dca6a18a37f105107bd5)
This stop words file is just the default Postgres english stop file
with all the rest of the letters of the alphabet added. Adding the
extra letters ensures that, e.g., "bed" doesn't get transformed into
"bed | b".
(imported from commit 0be3ef9a43eb524ed4f081d5081a786cf602c487)
This saves something like 15ms on our 1000 message get_old_messages
queries, and will save even more when we start sending JSON dumps into
our memcached system.
We need to install python-ujson on servers and dev instances before
pushing this to prod.
(imported from commit 373690b7c056d00d2299a7588a33f025104bfbca)
The old bucket was versioned and didn't allow deletes. This was
great for paranoia, but not so great for being able to delete old
backups.
(imported from commit be79b5c582ca5ee466cdfea6d3093b6d5ba0e23d)
I hadn't changed it previously out of paranoia in the case we had a
faulty failover and had two masters both uploading to the same place.
However, I now don't think this can happen, as recovery completion
will cause Postgres to start a new timeline.
(imported from commit d58f1aa306eff4f6fd950664ff658539c1249bdf)
That's where it is supposed to be, and besides, that's what a Nagios
server is going to expect it to be.
(imported from commit c273f18533909fa8eac182246dbbe498a5381f6c)
It turns out that having a UID for one user that's 1000, and not
setting them for other users, is a disaster: puppet might create them
in the wrong order, using UID 1000, and thus breaking creating the
'humbug' user later on. The same issue applies to groups.
(imported from commit 02b4700278e5c495bd514802f41ae238e6b051ac)
This only affects DEPLOYED installations.
This does not take care of removing old versions of static files from
that directory. The problem is that staticfiles is clever and
doesn't copy files that are already there, so we can't depend on
mtime for detecting which files we no longer need. Hopefully that
won't be too much of a problem for now.
(imported from commit 4341460dd5bc6544086fd445014ebdac58192910)