2023-01-17 04:33:42 +01:00
|
|
|
# Upgrade Zulip
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2023-01-25 02:31:54 +01:00
|
|
|
This page explains how to upgrade a Zulip server, including:
|
2019-10-14 21:40:48 +02:00
|
|
|
|
|
|
|
- [Upgrading to a release](#upgrading-to-a-release)
|
2020-10-23 02:43:28 +02:00
|
|
|
- [Upgrading from a Git repository](#upgrading-from-a-git-repository)
|
2022-02-16 01:39:15 +01:00
|
|
|
- [Updating `settings.py` inline documentation](#updating-settingspy-inline-documentation)
|
2019-10-14 21:40:48 +02:00
|
|
|
- [Troubleshooting and rollback](#troubleshooting-and-rollback)
|
2021-04-22 00:04:09 +02:00
|
|
|
- [Preserving local changes to service configuration files](#preserving-local-changes-to-service-configuration-files)
|
2019-10-14 21:40:48 +02:00
|
|
|
- [Upgrading the operating system](#upgrading-the-operating-system)
|
2020-06-26 23:40:36 +02:00
|
|
|
- [Upgrading PostgreSQL](#upgrading-postgresql)
|
2019-10-14 21:40:48 +02:00
|
|
|
|
|
|
|
## Upgrading to a release
|
|
|
|
|
|
|
|
Note that there are additional instructions if you're [using
|
2023-01-17 03:02:58 +01:00
|
|
|
docker-zulip][docker-upgrade], have [patched Zulip](modify.md),
|
2019-10-14 21:40:48 +02:00
|
|
|
or have [modified Zulip-managed configuration
|
2021-08-20 21:53:28 +02:00
|
|
|
files](#preserving-local-changes-to-service-configuration-files). To upgrade
|
2019-10-14 21:40:48 +02:00
|
|
|
to a new Zulip release:
|
|
|
|
|
2022-02-16 01:39:15 +01:00
|
|
|
1. Read the [upgrade notes](../overview/changelog.md#upgrade-notes)
|
2020-06-23 00:55:55 +02:00
|
|
|
for all releases newer than what is currently installed.
|
|
|
|
|
2019-10-14 21:40:48 +02:00
|
|
|
1. Download the appropriate release tarball from
|
2021-09-10 00:16:29 +02:00
|
|
|
<https://download.zulip.com/server/>. You can get the latest
|
|
|
|
release (**Zulip Server {{ LATEST_RELEASE_VERSION }}**) with the
|
|
|
|
following command:
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
|
|
|
|
```
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
You also have the option of upgrading Zulip [to a version in a Git
|
|
|
|
repository directly](#upgrading-from-a-git-repository) or creating
|
|
|
|
your own release tarballs from a copy of the [zulip.git
|
|
|
|
repository](https://github.com/zulip/zulip) using
|
|
|
|
`tools/build-release-tarball`.
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2020-08-11 02:20:10 +02:00
|
|
|
1. Log in to your Zulip and run as root:
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
2021-09-10 00:16:29 +02:00
|
|
|
/home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz
|
2021-08-20 22:54:08 +02:00
|
|
|
```
|
|
|
|
|
|
|
|
The upgrade process will:
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
- Run `apt-get upgrade`
|
|
|
|
- Install new versions of Zulip's dependencies (mainly Python packages).
|
|
|
|
- (`upgrade-zulip-from-git` only) Build Zulip's frontend assets using `webpack`.
|
|
|
|
- Shut down the Zulip service
|
|
|
|
- Run a `puppet apply`
|
|
|
|
- Run any database migrations
|
|
|
|
- Bring the Zulip service back up on the new version.
|
2019-10-14 21:40:48 +02:00
|
|
|
|
|
|
|
Upgrading will result in brief downtime for the service, which should
|
|
|
|
be under 30 seconds unless there is an expensive database migration
|
|
|
|
involved (these will be documented in the [release
|
|
|
|
notes](../overview/changelog.md), and usually can be avoided with
|
2021-08-20 21:53:28 +02:00
|
|
|
some care). If downtime is problematic for your organization,
|
2019-10-14 21:40:48 +02:00
|
|
|
consider testing the upgrade on a
|
2022-02-16 01:39:15 +01:00
|
|
|
[backup](export-and-import.md#backups) in advance,
|
2019-10-14 21:40:48 +02:00
|
|
|
doing the final upgrade at off hours, or buying a support contract.
|
|
|
|
|
|
|
|
See the [troubleshooting guide](#troubleshooting-and-rollback) if you
|
|
|
|
run into any issues or need to roll back the upgrade.
|
|
|
|
|
2023-07-11 23:24:12 +02:00
|
|
|
After you have completed the Zulip upgrade, you may also wish to [upgrade the
|
2023-08-15 00:57:59 +02:00
|
|
|
version of PostgreSQL](#upgrading-postgresql).
|
2023-07-11 23:24:12 +02:00
|
|
|
|
2020-08-11 01:47:54 +02:00
|
|
|
## Upgrading from a Git repository
|
2019-10-14 21:40:48 +02:00
|
|
|
|
|
|
|
Zulip supports upgrading a production installation to any commit in a
|
|
|
|
Git repository, which is great for [running pre-release changes from
|
2023-01-17 03:02:58 +01:00
|
|
|
`main`](modify.md#applying-changes-from-main) or [maintaining a
|
|
|
|
fork](modify.md#making-changes). The process is simple:
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
```bash
|
2019-10-14 21:40:48 +02:00
|
|
|
# Upgrade to an official release
|
|
|
|
/home/zulip/deployments/current/scripts/upgrade-zulip-from-git 1.8.1
|
2020-02-29 03:32:23 +01:00
|
|
|
# Upgrade to a branch (or other Git ref)
|
|
|
|
/home/zulip/deployments/current/scripts/upgrade-zulip-from-git 2.1.x
|
2021-09-01 00:15:31 +02:00
|
|
|
/home/zulip/deployments/current/scripts/upgrade-zulip-from-git main
|
2019-10-14 21:40:48 +02:00
|
|
|
```
|
|
|
|
|
|
|
|
Zulip will automatically fetch the relevant Git commit and upgrade to
|
2020-02-29 03:32:23 +01:00
|
|
|
that version of Zulip.
|
|
|
|
|
|
|
|
Branches with names like `2.1.x` are stable release branches,
|
|
|
|
containing the changes planned for the next minor release
|
|
|
|
(E.g. 2.1.5); we support these stable release branches as though they
|
|
|
|
were a published release.
|
|
|
|
|
2021-09-01 00:15:31 +02:00
|
|
|
The `main` branch contains changes planned for the next major
|
2020-06-25 01:25:14 +02:00
|
|
|
release (E.g. 3.0); see our documentation on [running
|
2023-01-17 03:02:58 +01:00
|
|
|
`main`](modify.md#upgrading-to-main) before upgrading to it.
|
2019-10-14 21:40:48 +02:00
|
|
|
|
|
|
|
By default, this uses the main upstream Zulip server repository, but
|
|
|
|
you can configure any other Git repository by adding a section like
|
|
|
|
this to `/etc/zulip/zulip.conf`:
|
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
```ini
|
2019-10-14 21:40:48 +02:00
|
|
|
[deployment]
|
|
|
|
git_repo_url = https://github.com/zulip/zulip.git
|
|
|
|
```
|
|
|
|
|
|
|
|
See also our documentation on [upgrading
|
|
|
|
docker-zulip](https://github.com/zulip/docker-zulip#upgrading-from-a-git-repository).
|
|
|
|
|
2021-04-22 00:04:09 +02:00
|
|
|
## Updating `settings.py` inline documentation
|
|
|
|
|
|
|
|
Zulip installations often upgrade many times over their lifetime, and
|
|
|
|
we strive to keep all configuration files backwards-compatible.
|
|
|
|
However, our practice of leaving the `/etc/zulip/settings.py`
|
|
|
|
unchanged during upgrades means that there may be new features which
|
|
|
|
are not documented in that file, since it was based on a template
|
|
|
|
provided by an earlier version of Zulip, during the initial install.
|
|
|
|
|
|
|
|
After upgrading across major versions of Zulip Server, we recommend
|
|
|
|
comparing your `/etc/zulip/settings.py` file to the current settings
|
|
|
|
template, which can be found in
|
|
|
|
`/home/zulip/deployments/current/zproject/prod_settings_template.py`. We
|
|
|
|
suggest using that updated template to update
|
|
|
|
`/etc/zulip/settings.py`:
|
|
|
|
|
|
|
|
1. Copy the current `settings.py` to make a backup (especially if you
|
|
|
|
do not have a recent [complete backup][backups]), and make a copy
|
|
|
|
of the current template:
|
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
```bash
|
2021-04-22 00:04:09 +02:00
|
|
|
cp -a /etc/zulip/settings.py ~/zulip-settings-backup.py
|
|
|
|
cp -a /home/zulip/deployments/current/zproject/prod_settings_template.py /etc/zulip/settings-new.py
|
|
|
|
```
|
|
|
|
|
|
|
|
1. Open both `/etc/zulip/settings.py` and `/etc/zulip/settings-new.py`
|
|
|
|
files in an editor; for each setting set in `settings.py`, find its
|
|
|
|
section in `/etc/zulip/settings-new.py` and copy the setting from
|
|
|
|
`settings.py` into there.
|
|
|
|
|
2021-04-22 00:21:46 +02:00
|
|
|
The following tool may help, by finding the most likely version of
|
|
|
|
the template that your `/etc/zulip/settings.py` was installed
|
|
|
|
using, and the differences that your file has from that:
|
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
```bash
|
2021-04-22 00:21:46 +02:00
|
|
|
/home/zulip/deployments/current/scripts/setup/compare-settings-to-template
|
|
|
|
```
|
|
|
|
|
2021-04-22 00:04:09 +02:00
|
|
|
If there are settings which you cannot find documented in
|
|
|
|
`/etc/zulip/settings-new.py`, check the [changelog][changelog] to see
|
|
|
|
if they have been removed.
|
|
|
|
|
2022-02-04 21:14:32 +01:00
|
|
|
1. Overwrite the configuration with the updated file, and restart the
|
|
|
|
server to pick up the updates; this should be a no-op, but it is
|
|
|
|
much better to discover immediately if it is not:
|
2021-04-22 00:04:09 +02:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
```bash
|
2021-04-22 00:04:09 +02:00
|
|
|
cp -a /etc/zulip/settings-new.py /etc/zulip/settings.py
|
|
|
|
su zulip -c '/home/zulip/deployments/current/scripts/restart-server'
|
|
|
|
```
|
|
|
|
|
2022-02-16 01:39:15 +01:00
|
|
|
[backups]: export-and-import.md#backups
|
2021-04-22 00:04:09 +02:00
|
|
|
[changelog]: ../overview/changelog.md
|
|
|
|
|
2019-10-14 21:40:48 +02:00
|
|
|
## Troubleshooting and rollback
|
|
|
|
|
|
|
|
See also the general Zulip server [troubleshooting
|
2022-02-24 00:17:21 +01:00
|
|
|
guide](troubleshooting.md).
|
2019-10-14 21:40:48 +02:00
|
|
|
|
|
|
|
The upgrade scripts are idempotent, so there's no harm in trying again
|
2021-08-20 21:53:28 +02:00
|
|
|
after resolving an issue. The most common causes of errors are:
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- Networking issues (e.g. your Zulip server doesn't have reliable
|
2021-08-20 21:53:28 +02:00
|
|
|
Internet access or needs a proxy set up). Fix the networking issue
|
2019-10-14 21:40:48 +02:00
|
|
|
and try again.
|
2021-08-20 21:45:39 +02:00
|
|
|
- Especially when using `upgrade-zulip-from-git`, systems with the
|
2019-10-14 21:40:48 +02:00
|
|
|
minimal RAM for running Zulip can run into out-of-memory issues
|
|
|
|
during the upgrade process (generally `tools/webpack` is the step
|
2021-08-20 21:53:28 +02:00
|
|
|
that fails). You can get past this by shutting down the Zulip
|
2022-03-18 01:10:28 +01:00
|
|
|
server with `./scripts/stop-server` to free up RAM before running
|
2019-10-14 21:40:48 +02:00
|
|
|
the upgrade process.
|
|
|
|
|
|
|
|
Useful logs are available in a few places:
|
2021-08-20 22:54:08 +02:00
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- The Zulip upgrade scripts log all output to
|
2019-10-14 21:40:48 +02:00
|
|
|
`/var/log/zulip/upgrade.log`.
|
2021-08-20 21:45:39 +02:00
|
|
|
- The Zulip server logs all Internal Server Errors to
|
2019-10-14 21:40:48 +02:00
|
|
|
`/var/log/zulip/errors.log`.
|
|
|
|
|
|
|
|
If you need help and don't have a support contract, you can visit
|
|
|
|
[#production
|
2024-06-06 21:48:31 +02:00
|
|
|
help](https://chat.zulip.org/#narrow/channel/31-production-help) in the
|
2019-10-14 21:40:48 +02:00
|
|
|
[Zulip development community
|
2021-12-09 20:15:18 +01:00
|
|
|
server](https://zulip.com/development-community/) for best-effort help.
|
2019-10-14 21:40:48 +02:00
|
|
|
Please include the relevant error output from the above logs in a
|
2020-08-11 01:47:49 +02:00
|
|
|
[Markdown code
|
2021-05-05 02:05:47 +02:00
|
|
|
block](https://zulip.com/help/code-blocks)
|
2019-10-14 21:40:48 +02:00
|
|
|
in any reports.
|
|
|
|
|
|
|
|
### Rolling back to a prior version
|
|
|
|
|
2019-12-13 01:58:10 +01:00
|
|
|
This rollback process is intended for minor releases (e.g. `2.0.3` to
|
|
|
|
`2.0.6`); a more complicated process is required to roll back database
|
|
|
|
migrations before downgrading to an older major release.
|
2019-10-14 21:40:48 +02:00
|
|
|
|
|
|
|
The Zulip upgrade process works by creating a new deployment under
|
|
|
|
`/home/zulip/deployments/` containing a complete copy of the Zulip server code,
|
|
|
|
and then moving the symlinks at `/home/zulip/deployments/{current,last,next}`
|
|
|
|
as part of the upgrade process.
|
|
|
|
|
|
|
|
This means that if the new version isn't working,
|
|
|
|
you can quickly downgrade to the old version by running
|
|
|
|
`/home/zulip/deployments/last/scripts/restart-server`, or to an
|
|
|
|
earlier previous version by running
|
2021-08-20 21:53:28 +02:00
|
|
|
`/home/zulip/deployments/DATE/scripts/restart-server`. The
|
2019-10-14 21:40:48 +02:00
|
|
|
`restart-server` script stops any running Zulip server, and starts
|
|
|
|
the version corresponding to the `restart-server` path you call.
|
|
|
|
|
2023-01-30 21:30:34 +01:00
|
|
|
## Deployment hooks
|
|
|
|
|
|
|
|
Zulip's upgrades have a hook system which allows for arbitrary
|
|
|
|
user-configured actions to run before and after an upgrade.
|
|
|
|
|
|
|
|
Files in the `/etc/zulip/pre-deploy.d` and `/etc/zulip/post-deploy.d`
|
2023-05-30 20:05:15 +02:00
|
|
|
directories are inspected for files ending with `.hook`, just before and after
|
|
|
|
the critical period when the server is restarted. Each file is called, sorted in
|
|
|
|
alphabetical order, from the working directory of the new version, with
|
|
|
|
environment variables as described below. If any of them exit with non-0 exit
|
|
|
|
code, the upgrade will abort.
|
|
|
|
|
|
|
|
The hook is run with the following environment variables set:
|
|
|
|
|
|
|
|
- `ZULIP_OLD_VERSION`: The version being upgraded from, which may either be a
|
|
|
|
release name (e.g. `7.0` or `7.0-beta3`) or the output from `git describe`
|
|
|
|
(e.g. `7.0-beta3-2-gdc158b18f2`).
|
|
|
|
- `ZULIP_NEW_VERSION`: The version being upgraded to, in the same format as
|
|
|
|
`ZULIP_OLD_VERSION`.
|
|
|
|
|
|
|
|
If the upgrade is upgrading between [versions in `git`][upgrade-from-git], then
|
|
|
|
the following environment variables will also be present:
|
|
|
|
|
|
|
|
- `ZULIP_OLD_COMMIT`: The full commit hash of the version being upgraded from
|
|
|
|
- `ZULIP_NEW_COMMIT`: The full commit hash of the version being upgraded to
|
|
|
|
- `ZULIP_OLD_MERGE_BASE_COMMIT`: The full commit hash of the merge-base of the
|
|
|
|
version being upgraded from, and the public branch in
|
|
|
|
[`zulip/zulip`][zulip/zulip]. This will be the closest commit in standard
|
|
|
|
Zulip Server to the version being upgraded from.
|
|
|
|
- `ZULIP_NEW_MERGE_BASE_COMMIT`: The full commit hash of the merge-base of the
|
|
|
|
version being upgraded to, and the public branch in
|
|
|
|
[`zulip/zulip`][zulip/zulip]. This will be the closest commit in standard
|
|
|
|
Zulip Server to the version being upgraded to.
|
2023-01-30 21:30:34 +01:00
|
|
|
|
2023-01-28 02:00:15 +01:00
|
|
|
See the [deploy documentation](deployment.md#deployment-hooks) for
|
|
|
|
hooks included with Zulip.
|
|
|
|
|
2023-05-31 00:28:07 +02:00
|
|
|
[upgrade-from-git]: #upgrading-from-a-git-repository
|
2023-05-30 20:05:15 +02:00
|
|
|
[zulip/zulip]: https://github.com/zulip/zulip/
|
|
|
|
|
2021-04-22 00:04:09 +02:00
|
|
|
## Preserving local changes to service configuration files
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-10 07:55:12 +02:00
|
|
|
:::{warning}
|
|
|
|
If you have modified service configuration files installed by
|
|
|
|
Zulip (e.g. the nginx configuration), the Zulip upgrade process will
|
|
|
|
overwrite your configuration when it does the `puppet apply`.
|
|
|
|
:::
|
2019-10-14 21:40:48 +02:00
|
|
|
|
|
|
|
You can test whether this will happen assuming no upstream changes to
|
|
|
|
the configuration using `scripts/zulip-puppet-apply` (without the
|
2020-10-23 02:43:28 +02:00
|
|
|
`-f` option), which will do a test Puppet run and output and changes
|
2019-10-14 21:40:48 +02:00
|
|
|
it would make. Using this list, you can save a copy of any files
|
|
|
|
that you've modified, do the upgrade, and then restore your
|
|
|
|
configuration.
|
|
|
|
|
|
|
|
That said, Zulip's configuration files are designed to be flexible
|
|
|
|
enough for a wide range of installations, from a small self-hosted
|
2021-08-20 21:53:28 +02:00
|
|
|
system to Zulip Cloud. Before making local changes to a configuration
|
2019-10-14 21:40:48 +02:00
|
|
|
file, first check whether there's an option supported by
|
2021-08-20 21:53:28 +02:00
|
|
|
`/etc/zulip/zulip.conf` for the customization you need. And if you
|
2019-10-14 21:40:48 +02:00
|
|
|
need to make local modifications, please report the issue so that we
|
2020-10-23 02:43:28 +02:00
|
|
|
can make the Zulip Puppet configuration flexible enough to handle your
|
2019-10-14 21:40:48 +02:00
|
|
|
setup.
|
|
|
|
|
|
|
|
### nginx configuration changes
|
|
|
|
|
|
|
|
If you need to modify Zulip's `nginx` configuration, we recommend
|
|
|
|
first attempting to add configuration to `/etc/nginx/conf.d` or
|
|
|
|
`/etc/nginx/zulip-include/app.d`; those directories are designed for
|
2022-05-07 01:18:30 +02:00
|
|
|
custom configuration, and are not overridden during upgrades. The
|
|
|
|
former is useful for directives with the `http` [context][context],
|
|
|
|
and the latter for `server` contexts.
|
|
|
|
|
|
|
|
[context]: http://nginx.org/en/docs/beginners_guide.html#conf_structure
|
2019-10-14 21:40:48 +02:00
|
|
|
|
|
|
|
## Upgrading the operating system
|
|
|
|
|
|
|
|
When you upgrade the operating system on which Zulip is installed
|
2022-09-27 21:10:30 +02:00
|
|
|
(E.g. Ubuntu 20.04 Focal to Ubuntu 22.04 Jammy), you need to take
|
2019-10-14 21:40:48 +02:00
|
|
|
some additional steps to update your Zulip installation, documented
|
|
|
|
below.
|
|
|
|
|
|
|
|
The steps are largely the same for the various OS upgrades aside from
|
2020-10-26 22:27:53 +01:00
|
|
|
the versions of PostgreSQL, so you should be able to adapt these
|
2019-10-14 21:40:48 +02:00
|
|
|
instructions for other supported platforms.
|
|
|
|
|
2022-09-27 21:10:30 +02:00
|
|
|
### Upgrading from Ubuntu 20.04 Focal to 22.04 Jammy
|
|
|
|
|
|
|
|
1. Upgrade your server to the latest Zulip `5.x` release (at
|
|
|
|
least 5.3, which adds support for Ubuntu 22.04 and above).
|
|
|
|
|
|
|
|
2. As the Zulip user, stop the Zulip server and run the following
|
|
|
|
to back up the system:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
supervisorctl stop all
|
|
|
|
/home/zulip/deployments/current/manage.py backup --output=/home/zulip/release-upgrade.backup.tar.gz
|
|
|
|
```
|
|
|
|
|
|
|
|
3. Switch to the root user and upgrade the operating system using the
|
|
|
|
OS's standard tooling. E.g. for Ubuntu, this means running
|
|
|
|
`do-release-upgrade` and following the prompts until it completes
|
|
|
|
successfully:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
sudo -i # Or otherwise get a root shell
|
|
|
|
do-release-upgrade
|
|
|
|
```
|
|
|
|
|
|
|
|
When `do-release-upgrade` asks you how to upgrade configuration
|
|
|
|
files for services that Zulip manages like Redis, PostgreSQL,
|
|
|
|
nginx, and memcached, the best choice is `N` to keep the
|
|
|
|
currently installed version. But it's not important; the next
|
|
|
|
step will re-install Zulip's configuration in any case.
|
|
|
|
|
|
|
|
4. As root, upgrade the database to the latest version of PostgreSQL:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
/home/zulip/deployments/current/scripts/setup/upgrade-postgresql
|
|
|
|
```
|
|
|
|
|
|
|
|
5. Next, we need to reinstall the current version of Zulip, which
|
|
|
|
among other things will recompile Zulip's Python module
|
|
|
|
dependencies for your new version of Python and rewrite Zulip's
|
|
|
|
full-text search indexes to work with the upgraded dictionary
|
|
|
|
packages:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
rm -rf /srv/zulip-venv-cache/*
|
|
|
|
/home/zulip/deployments/current/scripts/lib/upgrade-zulip-stage-2 \
|
|
|
|
/home/zulip/deployments/current/ --ignore-static-assets --audit-fts-indexes
|
|
|
|
```
|
|
|
|
|
|
|
|
This will finish by restarting your Zulip server; you should now be
|
|
|
|
able to navigate to its URL and confirm everything is working
|
|
|
|
correctly.
|
|
|
|
|
2020-06-09 07:11:25 +02:00
|
|
|
### Upgrading from Ubuntu 18.04 Bionic to 20.04 Focal
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-11-08 22:12:57 +01:00
|
|
|
1. Upgrade your server to the latest Zulip `3.x` or `4.x` release (at
|
|
|
|
least 3.0, which adds support for Ubuntu 20.04). You can only
|
|
|
|
upgrade to Zulip 5.0 and newer after completing this process, since
|
|
|
|
newer releases don't support Ubuntu 18.04.
|
2020-04-16 23:38:44 +02:00
|
|
|
|
|
|
|
2. As the Zulip user, stop the Zulip server and run the following
|
|
|
|
to back up the system:
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
supervisorctl stop all
|
|
|
|
/home/zulip/deployments/current/manage.py backup --output=/home/zulip/release-upgrade.backup.tar.gz
|
|
|
|
```
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2020-04-16 23:38:44 +02:00
|
|
|
3. Switch to the root user and upgrade the operating system using the
|
2021-08-20 21:53:28 +02:00
|
|
|
OS's standard tooling. E.g. for Ubuntu, this means running
|
2020-04-16 23:38:44 +02:00
|
|
|
`do-release-upgrade` and following the prompts until it completes
|
|
|
|
successfully:
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
sudo -i # Or otherwise get a root shell
|
|
|
|
do-release-upgrade
|
|
|
|
```
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
When `do-release-upgrade` asks you how to upgrade configuration
|
|
|
|
files for services that Zulip manages like Redis, PostgreSQL,
|
2022-01-25 07:21:47 +01:00
|
|
|
nginx, and memcached, the best choice is `N` to keep the
|
2021-08-20 22:54:08 +02:00
|
|
|
currently installed version. But it's not important; the next
|
|
|
|
step will re-install Zulip's configuration in any case.
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2020-06-26 23:33:38 +02:00
|
|
|
4. As root, upgrade the database to the latest version of PostgreSQL:
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
/home/zulip/deployments/current/scripts/setup/upgrade-postgresql
|
|
|
|
```
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2022-04-06 02:30:51 +02:00
|
|
|
5. Next, we need to reinstall the current version of Zulip, which
|
2020-06-26 23:33:38 +02:00
|
|
|
among other things will recompile Zulip's Python module
|
2020-07-05 14:57:52 +02:00
|
|
|
dependencies for your new version of Python and rewrite Zulip's
|
|
|
|
full-text search indexes to work with the upgraded dictionary
|
|
|
|
packages:
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
rm -rf /srv/zulip-venv-cache/*
|
|
|
|
/home/zulip/deployments/current/scripts/lib/upgrade-zulip-stage-2 \
|
|
|
|
/home/zulip/deployments/current/ --ignore-static-assets --audit-fts-indexes
|
|
|
|
```
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2020-08-11 00:20:10 +02:00
|
|
|
This will finish by restarting your Zulip server; you should now be
|
|
|
|
able to navigate to its URL and confirm everything is working
|
|
|
|
correctly.
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2022-04-06 02:30:51 +02:00
|
|
|
6. Finally, Ubuntu 20.04 has a different version of the low-level
|
|
|
|
glibc library, which affects how PostgreSQL orders text data (known
|
|
|
|
as "collations"); this corrupts database indexes that rely on
|
|
|
|
collations. Regenerate the affected indexes by running:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
/home/zulip/deployments/current/scripts/setup/reindex-textual-data --force
|
|
|
|
```
|
|
|
|
|
2024-03-25 22:31:39 +01:00
|
|
|
7. [Upgrade from Ubuntu 20.04 to
|
|
|
|
22.04](#upgrading-from-ubuntu-2004-focal-to-2204-jammy), so that
|
|
|
|
you are running a supported operating system.
|
2022-09-27 21:10:30 +02:00
|
|
|
|
2020-06-09 07:11:25 +02:00
|
|
|
### Upgrading from Ubuntu 16.04 Xenial to 18.04 Bionic
|
|
|
|
|
2021-08-20 21:53:28 +02:00
|
|
|
1. Upgrade your server to the latest Zulip `2.1.x` release. You can
|
2020-06-26 23:37:20 +02:00
|
|
|
only upgrade to Zulip 3.0 and newer after completing this process,
|
|
|
|
since newer releases don't support Ubuntu 16.04 Xenial.
|
2020-06-09 07:11:25 +02:00
|
|
|
|
2022-02-23 05:15:21 +01:00
|
|
|
2. Same as for Ubuntu 18.04 to 20.04.
|
2020-06-09 07:11:25 +02:00
|
|
|
|
2022-02-23 05:15:21 +01:00
|
|
|
3. Same as for Ubuntu 18.04 to 20.04.
|
2020-06-09 07:11:25 +02:00
|
|
|
|
|
|
|
4. As root, upgrade the database installation and OS configuration to
|
|
|
|
match the new OS version:
|
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
touch /usr/share/postgresql/10/pgroonga_setup.sql.applied
|
|
|
|
/home/zulip/deployments/current/scripts/zulip-puppet-apply -f
|
|
|
|
pg_dropcluster 10 main --stop
|
|
|
|
systemctl stop postgresql
|
|
|
|
pg_upgradecluster 9.5 main
|
|
|
|
pg_dropcluster 9.5 main
|
|
|
|
apt remove postgresql-9.5
|
|
|
|
systemctl start postgresql
|
|
|
|
systemctl restart memcached
|
|
|
|
```
|
2020-06-09 07:11:25 +02:00
|
|
|
|
2020-08-03 21:41:14 +02:00
|
|
|
5. Finally, we need to reinstall the current version of Zulip, which
|
|
|
|
among other things will recompile Zulip's Python module
|
|
|
|
dependencies for your new version of Python:
|
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
rm -rf /srv/zulip-venv-cache/*
|
|
|
|
/home/zulip/deployments/current/scripts/lib/upgrade-zulip-stage-2 \
|
|
|
|
/home/zulip/deployments/current/ --ignore-static-assets
|
|
|
|
```
|
2020-06-09 07:11:25 +02:00
|
|
|
|
2020-08-11 00:20:10 +02:00
|
|
|
This will finish by restarting your Zulip server; you should now
|
|
|
|
be able to navigate to its URL and confirm everything is working
|
|
|
|
correctly.
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-11-08 22:12:57 +01:00
|
|
|
6. [Upgrade to the latest `4.x` release](#upgrading-to-a-release).
|
2020-08-03 22:24:38 +02:00
|
|
|
|
2021-11-08 22:12:57 +01:00
|
|
|
7. As root, verify the contents of the full-text indexes:
|
2020-08-11 00:30:07 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
/home/zulip/deployments/current/manage.py audit_fts_indexes
|
|
|
|
```
|
2020-08-11 00:30:07 +02:00
|
|
|
|
2022-02-23 05:15:21 +01:00
|
|
|
8. [Upgrade from Ubuntu 18.04 to
|
2024-03-25 22:31:39 +01:00
|
|
|
20.04](#upgrading-from-ubuntu-1804-bionic-to-2004-focal), the next
|
|
|
|
in chain of upgrades leading to a supported operating system.
|
2021-11-08 22:12:57 +01:00
|
|
|
|
2019-12-13 01:58:10 +01:00
|
|
|
### Upgrading from Ubuntu 14.04 Trusty to 16.04 Xenial
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 21:53:28 +02:00
|
|
|
1. Upgrade your server to the latest Zulip `2.0.x` release. You can
|
2020-06-26 23:37:20 +02:00
|
|
|
only upgrade to Zulip `2.1.x` and newer after completing this
|
|
|
|
process, since newer releases don't support Ubuntu 14.04 Trusty.
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2022-02-23 05:15:21 +01:00
|
|
|
2. Same as for Ubuntu 18.04 to 20.04.
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2022-02-23 05:15:21 +01:00
|
|
|
3. Same as for Ubuntu 18.04 to 20.04.
|
2020-04-16 23:38:44 +02:00
|
|
|
|
|
|
|
4. As root, upgrade the database installation and OS configuration to
|
2020-08-11 00:20:10 +02:00
|
|
|
match the new OS version:
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
apt remove upstart -y
|
|
|
|
/home/zulip/deployments/current/scripts/zulip-puppet-apply -f
|
|
|
|
pg_dropcluster 9.5 main --stop
|
|
|
|
systemctl stop postgresql
|
|
|
|
pg_upgradecluster -m upgrade 9.3 main
|
|
|
|
pg_dropcluster 9.3 main
|
|
|
|
apt remove postgresql-9.3
|
|
|
|
systemctl start postgresql
|
|
|
|
service memcached restart
|
|
|
|
```
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2020-08-03 21:41:14 +02:00
|
|
|
5. Finally, we need to reinstall the current version of Zulip, which
|
|
|
|
among other things will recompile Zulip's Python module
|
|
|
|
dependencies for your new version of Python:
|
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
rm -rf /srv/zulip-venv-cache/*
|
|
|
|
/home/zulip/deployments/current/scripts/lib/upgrade-zulip-stage-2 \
|
|
|
|
/home/zulip/deployments/current/ --ignore-static-assets
|
|
|
|
```
|
2020-04-16 23:38:44 +02:00
|
|
|
|
2020-08-11 00:20:10 +02:00
|
|
|
This will finish by restarting your Zulip server; you should now be
|
|
|
|
able to navigate to its URL and confirm everything is working
|
|
|
|
correctly.
|
2020-06-26 23:39:07 +02:00
|
|
|
|
2022-02-23 05:15:21 +01:00
|
|
|
6. [Upgrade from Ubuntu 16.04 to
|
2024-03-25 22:31:39 +01:00
|
|
|
18.04](#upgrading-from-ubuntu-1604-xenial-to-1804-bionic), the next
|
|
|
|
in chain of upgrades leading to a supported operating system.
|
2020-08-03 22:24:38 +02:00
|
|
|
|
2023-05-10 23:20:46 +02:00
|
|
|
### Upgrading from Debian 11 to 12
|
|
|
|
|
|
|
|
1. Upgrade your server to the latest `7.x` release.
|
|
|
|
|
|
|
|
2. As the Zulip user, stop the Zulip server and run the following
|
|
|
|
to back up the system:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
/home/zulip/deployments/current/scripts/stop-server
|
|
|
|
/home/zulip/deployments/current/manage.py backup --output=/home/zulip/release-upgrade.backup.tar.gz
|
|
|
|
```
|
|
|
|
|
|
|
|
3. Follow [Debian's instructions to upgrade the OS][bookworm-upgrade].
|
|
|
|
|
|
|
|
[bookworm-upgrade]: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.html
|
|
|
|
|
|
|
|
When prompted for you how to upgrade configuration
|
|
|
|
files for services that Zulip manages like Redis, PostgreSQL,
|
|
|
|
nginx, and memcached, the best choice is `N` to keep the
|
|
|
|
currently installed version. But it's not important; the next
|
|
|
|
step will re-install Zulip's configuration in any case.
|
|
|
|
|
|
|
|
4. As root, run the following steps to regenerate configurations
|
|
|
|
for services used by Zulip:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
apt remove upstart -y
|
|
|
|
/home/zulip/deployments/current/scripts/zulip-puppet-apply -f
|
|
|
|
```
|
|
|
|
|
|
|
|
5. Reinstall the current version of Zulip, which among other things
|
|
|
|
will recompile Zulip's Python module dependencies for your new
|
|
|
|
version of Python:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
rm -rf /srv/zulip-venv-cache/*
|
|
|
|
/home/zulip/deployments/current/scripts/lib/upgrade-zulip-stage-2 \
|
|
|
|
/home/zulip/deployments/current/ --ignore-static-assets --audit-fts-indexes
|
|
|
|
```
|
|
|
|
|
|
|
|
This will finish by restarting your Zulip server; you should now
|
|
|
|
be able to navigate to its URL and confirm everything is working
|
|
|
|
correctly.
|
|
|
|
|
|
|
|
6. As an additional step, you can also [upgrade the PostgreSQL version](#upgrading-postgresql).
|
|
|
|
|
2022-02-23 05:15:21 +01:00
|
|
|
### Upgrading from Debian 10 to 11
|
2021-09-09 09:38:43 +02:00
|
|
|
|
2022-04-19 03:18:48 +02:00
|
|
|
1. Upgrade your server to the latest `5.x` release. You can only
|
|
|
|
upgrade to Zulip Server 6.0 and newer after completing this
|
|
|
|
process, since newer releases don't support Debian 10.
|
2021-09-09 09:38:43 +02:00
|
|
|
|
2021-09-30 21:36:55 +02:00
|
|
|
2. As the Zulip user, stop the Zulip server and run the following
|
|
|
|
to back up the system:
|
|
|
|
|
|
|
|
```bash
|
2022-03-18 01:10:28 +01:00
|
|
|
/home/zulip/deployments/current/scripts/stop-server
|
2021-09-30 21:36:55 +02:00
|
|
|
/home/zulip/deployments/current/manage.py backup --output=/home/zulip/release-upgrade.backup.tar.gz
|
|
|
|
```
|
2021-09-30 12:12:38 +02:00
|
|
|
|
|
|
|
3. Follow [Debian's instructions to upgrade the OS][bullseye-upgrade].
|
|
|
|
|
|
|
|
[bullseye-upgrade]: https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.html
|
|
|
|
|
|
|
|
When prompted for you how to upgrade configuration
|
|
|
|
files for services that Zulip manages like Redis, PostgreSQL,
|
2022-01-25 07:21:47 +01:00
|
|
|
nginx, and memcached, the best choice is `N` to keep the
|
2021-09-30 12:12:38 +02:00
|
|
|
currently installed version. But it's not important; the next
|
|
|
|
step will re-install Zulip's configuration in any case.
|
|
|
|
|
|
|
|
4. As root, run the following steps to regenerate configurations
|
|
|
|
for services used by Zulip:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
apt remove upstart -y
|
|
|
|
/home/zulip/deployments/current/scripts/zulip-puppet-apply -f
|
|
|
|
```
|
|
|
|
|
2021-09-30 21:36:55 +02:00
|
|
|
5. Reinstall the current version of Zulip, which among other things
|
|
|
|
will recompile Zulip's Python module dependencies for your new
|
|
|
|
version of Python:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
rm -rf /srv/zulip-venv-cache/*
|
|
|
|
/home/zulip/deployments/current/scripts/lib/upgrade-zulip-stage-2 \
|
2022-04-06 02:34:48 +02:00
|
|
|
/home/zulip/deployments/current/ --ignore-static-assets --audit-fts-indexes
|
2021-09-30 21:36:55 +02:00
|
|
|
```
|
|
|
|
|
|
|
|
This will finish by restarting your Zulip server; you should now
|
|
|
|
be able to navigate to its URL and confirm everything is working
|
|
|
|
correctly.
|
2021-09-30 12:12:38 +02:00
|
|
|
|
2022-02-23 05:15:21 +01:00
|
|
|
6. Debian 11 has a different version of the low-level glibc
|
2021-09-30 12:12:38 +02:00
|
|
|
library, which affects how PostgreSQL orders text data (known as
|
|
|
|
"collations"); this corrupts database indexes that rely on
|
|
|
|
collations. Regenerate the affected indexes by running:
|
|
|
|
|
|
|
|
```bash
|
2022-02-25 23:04:27 +01:00
|
|
|
/home/zulip/deployments/current/scripts/setup/reindex-textual-data --force
|
2021-09-30 12:12:38 +02:00
|
|
|
```
|
|
|
|
|
2022-04-19 03:18:48 +02:00
|
|
|
7. As an additional step, you can also [upgrade the PostgreSQL version](#upgrading-postgresql).
|
2021-09-09 09:38:43 +02:00
|
|
|
|
2024-03-25 22:31:39 +01:00
|
|
|
8. [Upgrade from Debian 11 to 12](#upgrading-from-debian-11-to-12),
|
|
|
|
so that you are running a supported operating system.
|
|
|
|
|
2022-02-23 05:15:21 +01:00
|
|
|
### Upgrading from Debian 9 to 10
|
2020-04-16 23:38:44 +02:00
|
|
|
|
2021-08-20 21:53:28 +02:00
|
|
|
1. Upgrade your server to the latest Zulip `2.1.x` release. You can
|
2020-06-26 23:37:20 +02:00
|
|
|
only upgrade to Zulip 3.0 and newer after completing this process,
|
2022-02-23 05:15:21 +01:00
|
|
|
since newer releases don't support Debian 9.
|
2020-04-16 23:38:44 +02:00
|
|
|
|
2021-09-30 21:36:55 +02:00
|
|
|
2. As the Zulip user, stop the Zulip server and run the following
|
|
|
|
to back up the system:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
supervisorctl stop all
|
|
|
|
/home/zulip/deployments/current/manage.py backup --output=/home/zulip/release-upgrade.backup.tar.gz
|
|
|
|
```
|
2020-04-16 23:38:44 +02:00
|
|
|
|
|
|
|
3. Follow [Debian's instructions to upgrade the OS][debian-upgrade-os].
|
|
|
|
|
|
|
|
[debian-upgrade-os]: https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.html
|
|
|
|
|
|
|
|
When prompted for you how to upgrade configuration
|
2020-10-26 22:27:53 +01:00
|
|
|
files for services that Zulip manages like Redis, PostgreSQL,
|
2022-01-25 07:21:47 +01:00
|
|
|
nginx, and memcached, the best choice is `N` to keep the
|
2021-08-20 21:53:28 +02:00
|
|
|
currently installed version. But it's not important; the next
|
2020-04-16 23:38:44 +02:00
|
|
|
step will re-install Zulip's configuration in any case.
|
|
|
|
|
|
|
|
4. As root, upgrade the database installation and OS configuration to
|
|
|
|
match the new OS version:
|
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
apt remove upstart -y
|
|
|
|
/home/zulip/deployments/current/scripts/zulip-puppet-apply -f
|
|
|
|
pg_dropcluster 11 main --stop
|
|
|
|
systemctl stop postgresql
|
|
|
|
pg_upgradecluster -m upgrade 9.6 main
|
|
|
|
pg_dropcluster 9.6 main
|
|
|
|
apt remove postgresql-9.6
|
|
|
|
systemctl start postgresql
|
|
|
|
service memcached restart
|
|
|
|
```
|
2020-04-16 23:38:44 +02:00
|
|
|
|
2020-08-03 21:41:14 +02:00
|
|
|
5. Finally, we need to reinstall the current version of Zulip, which
|
|
|
|
among other things will recompile Zulip's Python module
|
|
|
|
dependencies for your new version of Python:
|
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
rm -rf /srv/zulip-venv-cache/*
|
|
|
|
/home/zulip/deployments/current/scripts/lib/upgrade-zulip-stage-2 \
|
|
|
|
/home/zulip/deployments/current/ --ignore-static-assets
|
|
|
|
```
|
2019-10-14 21:40:48 +02:00
|
|
|
|
2020-08-11 00:20:10 +02:00
|
|
|
This will finish by restarting your Zulip server; you should now
|
|
|
|
be able to navigate to its URL and confirm everything is working
|
|
|
|
correctly.
|
2020-06-26 23:39:07 +02:00
|
|
|
|
2022-04-19 03:18:48 +02:00
|
|
|
6. [Upgrade to the latest `5.x` release](#upgrading-to-a-release), now
|
2020-08-03 22:24:38 +02:00
|
|
|
that your server is running a supported operating system.
|
|
|
|
|
2022-02-23 05:15:21 +01:00
|
|
|
7. Debian 10 has a different version of the low-level glibc
|
2021-07-13 04:23:46 +02:00
|
|
|
library, which affects how PostgreSQL orders text data (known as
|
|
|
|
"collations"); this corrupts database indexes that rely on
|
2021-08-20 21:53:28 +02:00
|
|
|
collations. Regenerate the affected indexes by running:
|
2021-07-13 04:23:46 +02:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
```bash
|
2022-02-25 23:04:27 +01:00
|
|
|
/home/zulip/deployments/current/scripts/setup/reindex-textual-data --force
|
2021-07-13 04:23:46 +02:00
|
|
|
```
|
|
|
|
|
|
|
|
8. As root, finish by verifying the contents of the full-text indexes:
|
2020-08-11 00:30:07 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
/home/zulip/deployments/current/manage.py audit_fts_indexes
|
|
|
|
```
|
2020-08-11 00:30:07 +02:00
|
|
|
|
2024-03-25 22:31:39 +01:00
|
|
|
9. [Upgrade from Debian 10 to 11](#upgrading-from-debian-10-to-11),
|
|
|
|
the next in chain of upgrades leading to a supported operating
|
|
|
|
system.
|
2022-04-19 03:18:48 +02:00
|
|
|
|
2020-06-26 23:40:36 +02:00
|
|
|
## Upgrading PostgreSQL
|
|
|
|
|
|
|
|
Starting with Zulip 3.0, we use the latest available version of
|
2024-04-01 22:35:09 +02:00
|
|
|
PostgreSQL at installation time (currently version 16). Upgrades to
|
2020-06-26 23:40:36 +02:00
|
|
|
the version of PostgreSQL are no longer linked to upgrades of the
|
2024-04-01 22:35:09 +02:00
|
|
|
distribution; that is, you may opt to upgrade to PostgreSQL 16 while
|
2024-03-25 22:31:39 +01:00
|
|
|
running Ubuntu 22.04.
|
2020-06-26 23:40:36 +02:00
|
|
|
|
2023-06-13 00:58:51 +02:00
|
|
|
Not all versions of Zulip Server support all versions of PostgreSQL, however:
|
|
|
|
|
2024-04-04 20:04:56 +02:00
|
|
|
```{include} postgresql-support-table.md
|
|
|
|
|
|
|
|
```
|
2023-06-13 00:58:51 +02:00
|
|
|
|
2020-06-26 23:40:36 +02:00
|
|
|
To upgrade the version of PostgreSQL on the Zulip server:
|
|
|
|
|
|
|
|
1. Upgrade your server to the latest Zulip release (at least 3.0).
|
|
|
|
|
2021-08-18 22:35:44 +02:00
|
|
|
1. Stop the server, as the `zulip` user:
|
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
# On Zulip before 4.0, use `supervisor stop all` instead
|
|
|
|
/home/zulip/deployments/current/scripts/stop-server
|
|
|
|
```
|
2021-08-18 22:35:44 +02:00
|
|
|
|
|
|
|
1. Take a backup, in case of any problems:
|
2020-06-26 23:40:36 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
/home/zulip/deployments/current/manage.py backup --output=/home/zulip/postgresql-upgrade.backup.tar.gz
|
|
|
|
```
|
2020-06-26 23:40:36 +02:00
|
|
|
|
2021-08-18 22:35:44 +02:00
|
|
|
1. As root, run the database upgrade tool:
|
2020-06-26 23:40:36 +02:00
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
/home/zulip/deployments/current/scripts/setup/upgrade-postgresql
|
|
|
|
```
|
2020-06-26 23:40:36 +02:00
|
|
|
|
2021-08-18 22:35:44 +02:00
|
|
|
1. As the `zulip` user, start the server again:
|
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```bash
|
|
|
|
# On Zulip before 4.0, use `restart-server` instead of `start-server` instead
|
|
|
|
/home/zulip/deployments/current/scripts/start-server
|
|
|
|
```
|
2021-08-18 22:35:44 +02:00
|
|
|
|
|
|
|
You should now be able to navigate to the Zulip server's URL and
|
|
|
|
confirm everything is working correctly.
|
2020-06-26 23:40:36 +02:00
|
|
|
|
2019-10-14 21:40:48 +02:00
|
|
|
[docker-upgrade]: https://github.com/zulip/docker-zulip#upgrading-the-zulip-container
|