This shows up when you're not running a Zephyr mirroring bot and lets
you use Webathena to have us run it. Obviously needs more docs.
Current problems include:
* supervisorctl reload ends up recreating /var/run/supervisor.sock
with the wrong permissions, so it only works once in a row before
you need to chmod that.
* /etc/supervisor/conf.d needs to be humbug-writeable; this is a clear
local root vulnerability
* This uses SSH and thus is kinda slow.
(imported from commit 7029979615ffd50b10f126ce2cf9a85a5eefd7a2)
The davidben-patched-for-roost Zephyr branch (available at
https://github.com/davidben/zephyr/tree/roost) adds Zephyr support for
these options. We also patch python-zephyr to expose them. These
basically let you save your Zephyr tickets and port number to a file,
so that you can later restore them (even potentially after the machine
rebooted). Basically because Zephyr is UDP, the Zephyr server will
continue trying to deliver messages to a particular port number that
was registered for up to 20 minutes after getting an error; so we can
even have downtime and reboot and still get our packets so long as we
restore the sessions within 20 minutes.
(imported from commit 986cbb157ddfa57aa4b644cd826f8418e9876dc7)
Previously it only provided the list of all public streams; now it
allows one to specify any union of some of the following:
* all public streams
* all streams the user subscribed to
(the most relevant being the union of those two, which is what we want
for the "streams" page).
Or:
* all streams in realm (superuser only)
The manual task required is that when this is pushed to prod, we need
to also deploy the new sync-public-streams version to zmirror.
(imported from commit 27848b8bd136e2777f399b7d05b2fdcec35e4e21)
Our .crypt-table parsing code isn't quite correct, in that we don't
handle either the "zcrypt default" or "zcrypt by class/instance" pair
options (for sending messages in either direction) -- you have to be
zcrypting for an entire class. I think this makes sense given that on
the Zulip end we can only enforce anything on a stream level.
(imported from commit a7901b1dc025a04a23ee71ecdd499e3f150ba614)
When we deploy this, we should remove the relevant jobs from root's
crontab on our app servers.
(imported from commit 749be952d504f5a4d243cf59f6430acc689fc821)
For now we only support the AES encryption type since the DES one is
probably not used anymore.
(imported from commit 222606db9f704917e74159e7d07a110187a236e6)
When we deploy this, we'll need to of course actually build and deploy
the new API tarball.
(imported from commit 03c853e8a9424a63f1c74bb83637d5a1e50a159a)
This makes our life a bit nicer if the message is super-long,
because then even when it's "condensed", we still get a link
to the actual article.
(imported from commit 32e70d29cb702ce73f6cd0c04dbc58457cd2e6b5)
Even though we support a command-line option of --user=,
it gets stored in a field called 'email'.
(imported from commit f2956524517a93187ed182caf8e2d85ccbc1a0f4)
Previously, we would return a JSONDecodeError to the user in the event
that the server returned a 500 error (or other non-JSON content).
(imported from commit 1624dfec6ac65d34216f4de91e33116a54e414fa)
Just before this is pushed to prod, we need to rename the Humbug feedback
bot in the database using:
./manage.py change_user_email feedback@humbughq.comfeedback@zulip.com
/etc/init.d/memcached restart
and we also need to update and restart feedback-bot in its deployed
location.
No action is required on pushing this to staging, but in between when
this is pushed to staging and when it is pushed to prod (and that
transition performed), feedback will not work on staging.
(imported from commit 73fc36f680b978f3aebae5df1822918ae4d4e952)
When we push this to staging, we'll need to rename the bot in the
database and also pull on git.zulip.net.
(imported from commit 22b2397b197c8820f0e55daecd8f98d829e195bd)
