This needs to be deployed on both prod and lb0 to be functional
DEPLOY INSTRUCTIONS: restart carefully
(imported from commit d97a450754608357418c80e5b3c7b3bbcd1d09fb)
I don't think this matters a ton, but there's no reason for
the two muting files to come before setup.js.
(imported from commit c18231b633fba6acccaf5bc180c7605f7591462e)
This experiment has been disabled for everyone for a while: if we
bring something like this back, it is not likely to be exactly the same,
and will be different enough to require a different implementation.
As it is, the summarization code was making a few code paths (rendering
especially) more complex, and is worth removing for simplicity's sake.
(imported from commit 6ac8cdc9f7077a5a1da01ab4268aba3db0bc43f8)
Before we deploy this commit, we must migrate the data from the staging redis
server to the new, dedicated redis server. The steps for doing so are the
following:
* Remove the zulip::redis puppet class from staging's zulip.conf
* ssh once from staging to redis-staging.zulip.net so that the host key is known
* Create a tunnel from redis0.zulip.net to staging.zulip.net
* zulip@redis0:~$ ssh -N -L 127.0.0.1:6380:127.0.0.1:6379 -o ServerAliveInterval=30 -o ServerAliveCountMax=3 staging.zulip.net
* Set the redis instance on redis0.zulip.net to replicate the one on staging.zulip.net
* redis 127.0.0.1:6379> slaveof 127.0.0.1 6380
* Stop the app on staging
* Stop redis-server on staging
* Promote the redis server on redis0.zulip.net to a master
* redis 127.0.0.1:6379> slaveof no one
* Do a puppet apply at this commit on staging (this will bring up the tunnel to redis0)
* Deploy this commit to staging (start the app on staging)
* Kill the tunnel from redis0.zulip.net to staging.zulip.net
* Uninstall redis-server on staging
The steps for migrating prod will be the same modulo s/staging/prod0/.
(imported from commit 546d258883ac299d65e896710edd0974b6bd60f8)
The file test_runner.py has our subclass of DjangoTestSuiteRunner
and various methods that help it work.
(imported from commit 8eca39a7ed3f8312c986224a810d4951559e7a8b)
Before deploying to staging, create the tutorial bot:
email: welcome-bot@zulip.com
name: Zulip Welcome Bot
(imported from commit 2f337a00ffac888b121975bdb95a89cf2f8ab3a7)
Add javascript to handle the button clicks and update the status based
on the subscribe and unsubscribe events from the server.
(imported from commit 6b9c0b40d9084e3d8b64bed701ebc786bef6d432)
The one call we were making to it was actually unnecessary since highlighting is
no longer done client-side.
(imported from commit 7644a5961ca48cd57f4b65c6f698083677e0a130)
Make our dev setup more similar to prod by using compiled.js,
instead of AJAX-ing templates on the fly and compiling them
with non-node code. This will make our dev environment more
consistent with prod (to avoid surprising bugs), plus it should
be faster (fewer AJAX calls).
This change also means we don't have to keep two copies
of static/third/handlebars/handlebars.js around.
(imported from commit d8d584b9aa13adcdcce7e424033610d77d2df79b)
Otherwise the app would crash when it tried to build template context:
Traceback (most recent call last):
[...]
File ".../zerver/context_processors.py", line 23, in add_settings
'email_gateway_example': settings.EMAIL_GATEWAY_EXAMPLE,
File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 55, in __getattr__
return getattr(self._wrapped, name)
AttributeError: 'Settings' object has no attribute 'EMAIL_GATEWAY_EXAMPLE'
(imported from commit 6cc5d3f150326a55230ea91e6c228ae9b1e19df3)
We now have 2 variablse:
EXTERNAL_API_PATH: e.g. staging.zulip.com/api
EXTERNAL_API_URI: e.g. https://staging.zulip.com/api
The former is primarily needed for certain integrations.
(imported from commit 3878b99a4d835c5fcc2a2c6001bc7eeeaf4c9363)
Many deployments will not set AUTH_LDAP_BIND_DN , because they allow
anonymous binding. It is better for us to use AUTH_LDAP_SERVER_URI as a
signal for whether to use LDAP, since any deployment that uses LDAP will
set that local setting.
(imported from commit ad70bedfb572b42a9df954819593e2678729647b)
If authoritative data is available from say the LDAP database, we now
ignore the POSTed user name, and don't offer it as a form field.
We fall back to giving the user a text field if they aren't in LDAP.
If users do not have any form fields to fill out, we simply bring them
to the app without the registration page, logging them in using a dummy
backend.
(imported from commit 6bee87430ba46ff753ea3408251e8a80c45c713f)
The latter doesn't depend on the former; we can still fill in your full
name even if you didn't authenticate via LDAP.
This commit requires django_auth_ldap to be installed. On Debian
systems, you can do so via APT:
sudo apt-get install python-django-auth-ldap
On OS X, use your favourite package manager. For pip, I believe this
will work:
pip install django_auth_ldap
django_auth_ldap depends on the "ldap" Python package, which should be
installed automatically on your system.
(imported from commit 43967754285990b06b5a920abe95b8bce44e2053)
This could potentially help with debugging exactly what happened with
some issue down the line.
(imported from commit cc7321d742875b644d4727a084b462dcd01dcf10)
This is useful for the occasional case where we cannot figure out what
is causing a particular problem, but it can be easily reproduced on
staging.
(imported from commit 8b51184a8b686814f2c6ff103ba355538463ceb0)
CUSTOMER13 doesn't want it, and there's currently no nginx config
or configurable Camo URI, so it wouldn't work if image preview
were enabled.
(imported from commit 615d4a32acbc4d4d590f88cf4e7d45d8f49db1d3)
It throws an exception when the mixpanel library is not present. This
exception breaks emoji autocomplete, among other things.
(imported from commit 6ae2a69d40282701b8717b60d887836416c85a6c)
This command should be run continuously via supervisor. It periodically
checks for new email messages to send, and then sends them. This is for
sending email that you've queued via the Email table, instead of mandrill
(as is the case for our localserver/development deploys).
(imported from commit a2295e97b70a54ba99d145d79333ec76b050b291)
ScheduledJobs with type Email displace the usual mandrill codepaths
in the Zulip Enterprise deploys
* Email-specific helper functions will appear in deliver_email.py
* 0058_auto__add_scheduledjob.py
(imported from commit 8db08d8a279600322acfdbed792dc1a676f7a0ab)
update-prod-static needs DEBUG=False. This also replaces our
local_settings.py before generating anything included in the tarball.
(imported from commit 890cd9d1a44acfd2c20e1662e0c68132c633d1b3)
This was recommended by:
https://docs.djangoproject.com/en/dev/howto/deployment/checklist/
Since we don't change our deployments without restarting Django and
don't use any custom template magic, this should be a free performance
win.
(imported from commit fd498ab97d0669c3a14b342b2d2f01994a1f1ee1)
I figure we can start with 600s as a maximum age -- our threads do
many dozens of requests per minute, so I figure we'll get most of the
benefit of permanently persisting connections this way. I could also
be convinced to do just 60s, though the impact will likely to be less
visible on staging. 600s seems to be what Django originally had for
this parameter before they disabled it by default. See:
https://groups.google.com/forum/#!msg/django-developers/rH0QQP7tI6w/yBusiFTNBR4J
for discussion, which also suggests we might have issues with
runserver that we should watch out for.
(imported from commit 0ae09fa4f1b39cc88c76fa58258aaf20ab168dcf)
Move commands related to stats collection and reporting from
zilencer to analytics. To do this, we had to make "analytics"
officially an app.
(imported from commit 63ef6c68d1b1ebb5043ee4aca999aa209e7f494d)
Run the following commands as root before deploying this branch:
# /root/zulip/tools/migrate-server-config
# rm /etc/zulip/machinetype /etc/zulip/server /etc/zulip/local /etc/humbug-machinetype /etc/humbug-server /etc/humbug-local
(imported from commit aa7dcc50d2f4792ce33834f14761e76512fca252)
This moves the list of removed files from .gitattributes to
tools/build-local-server-tarball because static/ and tools/ are
necessary for update-prod-static, and it seemed best to keep the
entire list in one place.
(imported from commit 2a447cbde29e90d776da43bb333650a40d4d363c)
This is something we'll want to do before we switch to Django 1.6,
since it's the default there, and I'm not aware of any significant
problems this switch will cause.
(imported from commit fadea41f09e2179735328f99a3ec55b46c92041e)
Looking at the historical data, fewer than 50% of active users have
completed the checklist, which means that it is just persistent
clutter. We also have other better ways of encouraging people to send
traffic and get the apps now.
This commit removes both the frontend UI and backend work but leaves
the db row for now for the historical data.
(imported from commit e8f5780be37bbc75f794fb118e4dd41d8811f2bf)
The moved files are:
humbug-server
humbug-local
humbug-machinetype
Their new names are their old names with 'humbug-' removed.
zulip-puppet-apply must be run before this commit is deployed
(imported from commit f4eb523244d3409b5809c279301225d3fdf0c230)
Subclasses of QueueProcessingWorker that don't override start() will
have their consume() functions wrapped by consume_wrapper(), which
will catch exceptions and log data from troublesome events to a log
file.
We need to do a puppet apply to create /var/log/zulip/queue_error.
(imported from commit 3bd7751da5fdef449eeec3f7dd29977df11e2b9c)
This commit must be simultaneously deployed on both staging and
prod0. It also requires completely taking down the app.
To deploy these changes, do:
* check out this commit at /root/zulip on postgres0, postgres1, staging, and prod0
* stop the process_fts_updates job on postgres0 and postgres1
* stop the app on staging and prod0
* do a puppet apply on postgres0, postgres1, staging, and prod0
* move the new client certificates into place on staging and app
* move the new server certificates into place on postgres0 and postgres1
* reload the database config on postgres0 and postgres1 (this might
actually require a restart)
* run tools/migrate-db on postgres0 as root
* do a deploy through this commit on staging and prod0
* start the process_fts_updates job on postgres0 and postgres1
* do a puppet apply on nagios
(imported from commit 819bdd14326c1425e2d3041a491a8ca3b9716506)
Here we introduce a new Django app, zilencer. The intent is to not have
this app enabled on LOCALSERVER instances, and for it to grow to include
all the functionality we want to have in our central server that isn't
relevant for local deployments.
Currently we have to modify functions in zerver/* to match; in the
future, it would be cool to have the relevant shared code broken out
into a separate library.
This commit inclues both the migration to create the models as well as a
data migration that (for non-LOCALSERVER) creates a single default
Deployment for zulip.com.
To apply this migration to your system, run:
./manage.py migrate zilencer
(imported from commit 86d5497ac120e03fa7f298a9cc08b192d5939b43)
Before deploying this commit, the following commands must be run:
# rabbitmqctl add_user zulip $(tools/get-django-setting RABBITMQ_PASSWORD)
# rabbitmqctl set_user_tags zulip administrator
# rabbitmqctl set_permissions -p / zulip '.*' '.*' '.*'
(imported from commit 76d66fa6ac69aa39c91f55b9b5d5a954f9e94d73)
New dependency: sockjs-tornado
One known limitation is that we don't clean up sessions for
non-websockets transports. This is a bug in Tornado so I'm going to
look at upgrading us to the latest version:
https://github.com/mrjoes/sockjs-tornado/issues/47
(imported from commit 31cdb7596dd5ee094ab006c31757db17dca8899b)
This may require just doing an mv on the home directory, plus changing
the home directory in /etc/passwd. It should of course be done carefully.
(imported from commit 660997d897ee6d33563af74f0fc5d4267a911755)
This has been deployed, so the current code is now properly
minified, and we don't need the force_minify flag any more.
(The flag is needed when you remove a JS file from JS_SPECS.)
(imported from commit 8b3c7ffdbc875011d59c2560034750f0077db616)
The minify logic doesn't have an easy way to detect that you
removed a file since the last deployment.
(imported from commit 50d05fcdad382a586073c06d29d279433d1bba81)
We are still showing the same data points, but the logic to drill
down on details for a particular realm is now all server side,
not client side, and we are smarter about omitting fields. In
summary mode, we don't show empty Name or Email columns. In
detailed mode, we show the realm as a headline instead of a column.
In this version you do lose the ability to see all system users in
the same view, but Waseem is ok with this.
(imported from commit edd2e646ab4cf5783ea64232d0cd621debece8d4)
When you load the activity report, it will just show summary
counts for realms, but if you click on a realm, you will see
details about users in the realms. You can also click "Show all"
to see an interleaved view of realms and users.
(imported from commit b106557b1fae64d525071afc124b5a8aed319086)
I believe this was the source of the "Handlebars.compile is not a
function" errors, though I don't know why so few users got it.
(imported from commit f4a72e35bf25f679461d3c9e6938d118fec30278)
Luke Faraone
Tim Abbott
Steve Howell
Waseem Daher
Jason Michalski
Allen Rabinovich
Leo Franchi
Zev Benjamin
Jessica McKellar
Luke Faraone
Kevin Mehall
acrefoot
acrefoot
Jessica McKellar