Previously I've wanted to have this page spell out the concrete
version number that our clients support, rather than the policy we
use for determining that version number, because that's the sort of
question that I feel like as a user I'd want a straight answer to
and would be annoyed if I couldn't get one.
But as the text stands, it's come to look more like it's the policy
(something that's heavyweight to change) than like the value that
the policy currently happens to work out to. Also, because this page
is kind of chaotically organized (and fixing that is a bigger yak
than I want to shave right now), it repeats the 18-month rule in
three separate places and the current value (version 4.0) is in
a fourth separate place, so it looks internally inconsistent.
Let's therefore take a different tack: like in those other three
spots on this page, state just the policy instead of the value it
currently works out to; but also add a link to help the reader
pin down for themselves what value that does work out to.
This also means we no longer need to update this page as old releases
age and that value advances.
Also fix a typo, and cut the reference to working degraded on
older releases. Starting earlier this year we finally started
hard-refusing such connections:
https://github.com/zulip/zulip-mobile/issues/5102https://github.com/zulip/zulip-mobile/pull/5633
(which was because there were some swathes of compatibility code
that we could only cut if we completely broke the handling of
ancient servers, and so we preferred to have the app communicate
that break clearly up front.)
(cherry picked from commit bb6fe0385e)
Restore the default django.utils.log.AdminEmailHandler when
ERROR_REPORTING is enabled. Those with more sophisticated needs can
turn it off and use Sentry or a Sentry-compatible system.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
(cherry picked from commit b285813beb)
Users can, quite understandably, assume that upgrading Zulip upgraded
the underlying PostgreSQL version. Though it is mentioned at the top
of the page, mentioning it here clarifies that it is an additional
step.
(cherry picked from commit a7b9e67c06)
Previously, `X-Forwarded-Proto` did not need to be set, and failure to
set `loadbalancer.ips` would merely result in bad IP-address
rate-limiting and incorrect access logs; after 0935d388f0, however,
failure to do either of those, if Zulip is deployed with `http_only`,
will lead to infinite redirect loops after login. These are
accompanied by a misleading error, from Tornado, of:
Forbidden (Origin checking failed - https://zulip.example.com does not match any trusted origins.): /json/events
This is most common with Docker deployments, where deployments use
another docker container, such as nginx or Traefik, to do SSL
termination. See zulip/docker-zulip#403.
Update the documentation to reinforce that `loadbalancer.ips` also
controls trust of `X-Forwarded-Proto`, and that failure to set it will
cause the application to not function correctly.
(cherry picked from commit d46279c41e)
- Create a dedicated "Reporting bugs" page to learly document
where and how bugs should be reported.
- Drop "Reporting issues" section from the Contributing guide.
- Delete "Bug report guidelines" page.
(cherry picked from commit 052a109ba4)
04cf68b45e make nginx responsible for downloading (and caching)
files from S3. As noted in that commit, nginx implements its own
non-blocking DNS resolver, since the base syscall is blocking, so
requires an explicit nameserver configuration. That commit used
127.0.0.53, which is provided by systemd-resolved, as the resolver.
However, that service may not always be enabled and running, and may
in fact not even be installed (e.g. on Docker). Switch to parsing
`/etc/resolv.conf` and using the first-provided nameserver. In many
deployments, this will still be `127.0.0.53`, but for others it will
provide a working DNS server which is external to the host.
In the event that a server is misconfigured and has no resolvers in
`/etc/resolv.conf`, it will error out:
```console
Error: Evaluation Error: Error while evaluating a Function Call, No nameservers found in /etc/resolv.conf! Configure one by setting application_server.nameserver in /etc/zulip/zulip.conf (file: /home/zulip/deployments/current/puppet/zulip/manifests/app_frontend_base.pp, line: 76, column: 70) on node example.zulipdev.org
```
(cherry picked from commit bd217ad31b)
This better presents the CSS organization for readers, and also
removes a stale reference and link to Bootstrap.
Because postcss-nesting's spec-aligned syntax has tripped up some
contributors, the mention of PostCSS now includes a link to the
postcss-nesting README and the CSS Nesting spec from the W3C, which
PostCSS Nesting attempts to adhere to.
