Personals are now just private messages between two people (which
sometimes manifests as a private message with one recipient). The
new message type on the send path is 'private'. Note that the receive
path still has 'personal' and 'huddle' message types.
(imported from commit 97a438ef5c0b3db4eb3e6db674ea38a081265dd3)
Previously messages sent to zephyr instance " " wouldn't be forwarded
zephyr=>humbug because the target instance is the null instance; I
learned this when we got a few tracebacks in the zephyr_mirror log, so
clearly this does happen.
(imported from commit 08bd7470e75ac6af24ac83696b6cf68d70654664)
This is useful for trying out new versions of the forwarding code
while the mirroring bot is still running in production.
(imported from commit bcdaf91fed55ac0974b1efe31dd13ed006b6fd06)
This happens sometimes (especially when our server is restarting), and
isn't a _real_ problem -- it's much more important that we have a
completely reliable test that we can put a Nagios alert against.
(imported from commit 0add0b3dfc5447307014bbb9137366bd7141ade0)
Previously we were spending 15 seconds on linerva (and more like 2.5
minutes on the not-yet-operational zmirror.humbughq.com) to subscribe
to all of our streams.
(imported from commit c36cb1c26868f142683d9c92d4875fcd4931886e)
We've had multiple requests from MIT zephyr users to allow
non-alphanumeric stream names, and we haven't decided what we want to
allow, so for now allow everything.
Note that the web client and mirror script limit stream names to 30
characters, which is our database limit.
(imported from commit 2acb5ee04e5ee7c40031ac831e12d09d04bbb2e6)
Zephyr has this great property where a small fraction of the time, the
Zephyr server rejects your attempt to subscribe to something for no
particular reason, returning a "SERVNAK" error.
(imported from commit 6d5ed033d46d77a5b02539a816453724740f8fb0)
This does introduce a small security issue, in that a shell with
expired AFS tokens on the machine running the mirroring script will be
able to read the Humbug API key using /proc/pid/environ. I think this
is fine -- you can steal the API key from a running process using
ptrace anyway.
(imported from commit c6fdb798294fb32d640823b409f3e46274ca01f4)
Because in the zephyr world, people often manually linewrap their
zephyrs, we need to relax the algorithm's assumption that every line
was wrapped to the same linewrapping threshhold. Otherwise messages
that look like this:
aaaaa aaaaa aaaaa aaaaaaaaaa aaaaa aaaaa aaaaa aaaaa
aaaaa aaaaa aaaaa aaaaaaaaaa aaaaa aaaaa aaaaa aaaaa aaaaa aaaaaa
aaaaa aaaaa aaaaa aaaaaaaaaa aaaaa aaaaa aaaaa aaaaa
might be treated as a paragraph break, even though that was unlikely
to have been the sender's intention.
(imported from commit e1144da2a3efc3241a8f15b0f19fea2ea6684254)
It's generally best to first try killing with SIGTERM, and if we fail
to kill the child, we'll end up trying to kill them with SIGKILL
anyway when the new zephyr_mirror process starts up,
(imported from commit cfee2dd5f809f6e38d90a09be82719a8660d8377)
