diff --git a/docs/production/install-existing-server.md b/docs/production/install-existing-server.md index e46e43e311..be587851ef 100644 --- a/docs/production/install-existing-server.md +++ b/docs/production/install-existing-server.md @@ -21,7 +21,7 @@ Linux sysadmin, you will have a much better experience if you get a dedicated VM to install Zulip on instead (or [use zulip.com](https://zulip.com)). -### Nginx +### nginx Copy your existing nginx configuration to a backup and then merge the one created by Zulip into it: diff --git a/docs/production/requirements.md b/docs/production/requirements.md index ec224ea3be..64ecdacf9c 100644 --- a/docs/production/requirements.md +++ b/docs/production/requirements.md @@ -23,7 +23,7 @@ For details on each of these requirements, see below. #### General The installer expects Zulip to be the **only thing** running on the -system; it will install system packages with `apt` (like Nginx, +system; it will install system packages with `apt` (like nginx, PostgreSQL, and Redis) and configure them for its own use. We strongly recommend using either a fresh machine instance in a cloud provider, a fresh VM, [our Docker image][docker-zulip-homepage], or a dedicated diff --git a/docs/production/troubleshooting.md b/docs/production/troubleshooting.md index 2d9502de5b..ba102570a7 100644 --- a/docs/production/troubleshooting.md +++ b/docs/production/troubleshooting.md @@ -106,7 +106,7 @@ application: - PostgreSQL - RabbitMQ -- Nginx +- nginx - Redis - memcached @@ -216,7 +216,7 @@ standard stuff: especially for the database and where uploads are stored. - Service uptime and standard monitoring for the [services Zulip depends on](#troubleshooting-services). Most monitoring software - has standard plugins for Nginx, PostgreSQL, Redis, RabbitMQ, + has standard plugins for nginx, PostgreSQL, Redis, RabbitMQ, and memcached, and those will work well with Zulip. - `supervisorctl status` showing all services `RUNNING`. - Checking for processes being OOM killed. diff --git a/docs/production/upgrade-or-modify.md b/docs/production/upgrade-or-modify.md index 5ac0cac59f..db5de728ff 100644 --- a/docs/production/upgrade-or-modify.md +++ b/docs/production/upgrade-or-modify.md @@ -282,7 +282,7 @@ instructions for other supported platforms. 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 + 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. @@ -429,7 +429,7 @@ instructions for other supported platforms. 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 + 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. @@ -492,7 +492,7 @@ instructions for other supported platforms. 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 + 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. diff --git a/docs/subsystems/dependencies.md b/docs/subsystems/dependencies.md index da7f381158..4a8396b25f 100644 --- a/docs/subsystems/dependencies.md +++ b/docs/subsystems/dependencies.md @@ -90,7 +90,7 @@ the backend, but does in JavaScript. ## System packages -For the third-party services like PostgreSQL, Redis, Nginx, and RabbitMQ +For the third-party services like PostgreSQL, Redis, nginx, and RabbitMQ that are documented in the [architecture overview](../overview/architecture-overview.md), we rely on the versions of those packages provided alongside the Linux distribution diff --git a/docs/tutorials/life-of-a-request.md b/docs/tutorials/life-of-a-request.md index 8b557d79bc..024ed7b3c6 100644 --- a/docs/tutorials/life-of-a-request.md +++ b/docs/tutorials/life-of-a-request.md @@ -7,18 +7,18 @@ Zulip codebase, and dive deep into how each part works. We will use as our example the creation of users through the API, but we will also highlight how alternative requests are handled. -## A request is sent to the server, and handled by [Nginx](https://nginx.org/en/docs/) +## A request is sent to the server, and handled by [nginx](https://nginx.org/en/docs/) When Zulip is deployed in production, all requests go through nginx. For the most part we don't need to know how this works, except for when -it isn't working. Nginx does the first level of routing--deciding which +it isn't working. nginx does the first level of routing--deciding which application will serve the request (or deciding to serve the request itself for static content). In development, `tools/run-dev.py` fills the role of nginx. Static files are in your Git checkout under `static`, and are served unminified. -## Static files are [served directly][served-directly] by Nginx +## Static files are [served directly][served-directly] by nginx [served-directly]: https://github.com/zulip/zulip/blob/main/puppet/zulip/files/nginx/zulip-include-frontend/app @@ -37,7 +37,7 @@ location /static/ { } ``` -## Nginx routes other requests [between Django and Tornado][tornado-django] +## nginx routes other requests [between Django and Tornado][tornado-django] [tornado-django]: ../overview/architecture-overview.html?highlight=tornado#django-and-tornado diff --git a/zproject/urls.py b/zproject/urls.py index 040e738bc6..8d55164bd3 100644 --- a/zproject/urls.py +++ b/zproject/urls.py @@ -226,7 +226,7 @@ if settings.TWO_FACTOR_AUTHENTICATION_ENABLED: # - runtornado.py has its own URL list for Tornado views. See the # invocation of web.Application in that file. # -# - The Nginx config knows which URLs to route to Django or Tornado. +# - The nginx config knows which URLs to route to Django or Tornado. # # - Likewise for the local dev server in tools/run-dev.py.