Compare commits

...

2 Commits

Author SHA1 Message Date
7b5265805c
added nginx 2024-11-03 16:44:20 -06:00
af9a204b30
added postgresql 2024-11-03 16:38:52 -06:00
12 changed files with 2080 additions and 2 deletions

View File

@ -14,10 +14,11 @@ This repository contains guides and notes written in markdown.
## Features / TODOS ## Features / TODOS
- [x] SSH Server - [x] SSH Server
- [ ] Postgresql - [x] Postgresql
- [ ] Gitea - [ ] Gitea
- [ ] Nginx - [x] Nginx
- [ ] Solidworks - [ ] Solidworks
- [ ] Docker
## Usage ## Usage
Each project or subject should have it's own folder with a descriptive name. It will contain a README file that is the subject of the folder. It will also contain a resources folder that contain media for the guides/notes.<br> Each project or subject should have it's own folder with a descriptive name. It will contain a README file that is the subject of the folder. It will also contain a resources folder that contain media for the guides/notes.<br>

86
nginx/README.md Normal file
View File

@ -0,0 +1,86 @@
# Nginx Server
Walkthrough of installing Nginx Webserver
## Table of Contents
- [Step One - Installing Nginx](#step-one---installing-nginx)
- [Step Two - Configuring our Server](#step-2---configuring-our-server)
- [Step Three - Troubleshooting your Server](#step-3---troubleshooting-your-server)
- [Step Four - OPTIONAL - Setting up HTTPS with Certbot](#step-4---setting-up-https-with-certbot)
- [Resources](#resoureces)
### Step One - Installing Nginx
First we need to install Nginx.<br>
`sudo apt update`<br>
`sudo apt install nginx`<br>
If you have UFW on you should allow HTTP with:<br>
`sudo ufw allow 'Nginx Full'`
Nginx should now be fully operational, to check.<br>
`sudo systemctl enable nginx` - To set up nginx to start up on reboot.<br>
`sudo systemctl start nginx`<br>
`sudo systemctl status nginx` - Should give you the status of the server.<br>
Go to your ip address to see the nginx default page. Next, we'll configure our server.
### Step 2 - Configuring Our Server
Now that nginx is install and running, we should now configure our server. Here are the files we normally edit.<br>
`/var/www/html` Typically you'll remove the default and create a folder like `/var/www/mysite.com`<br>
`/etc/nginx`: The Nginx configuration directory. All of the Nginx configuration files reside here.<br>
`/etc/nginx/nginx.conf`:The main Nginx configuration file. This can be modified to make changes to the Nginx global configuration.<br>
`/etc/nginx/snippets`: This directory contains configuration fragments that can be included elsewhere in the Nginx configuration. Potentially repeatable configuration segments are good candidates for refactoring into snippets.<br>
`/etc/nginx/sites-available/mysite.com`:The directory where per-site server blocks can be stored. Nginx will not use the configuration files found in this directory unless they are linked to the **sites-enabled** directory. Typically, all server block configuration is done in this directory, and then enabled by linking to the other directory.<br>
`/etc/nginx/sites-enabled/mysite.com`: he directory where enabled per-site server blocks are stored. Typically, these are created by linking to configuration files found in the **sites-available** directory.<br>
You can link those by:<br>
`sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/`<br>
Here are some samples of files you may encounter, and settings you may set.<br>
[/etc/nginx/nginx.conf](./defaults/nginx.conf)<br>
[/etc/nginx/sites-available](./defaults/nginx.conf)<br>
[Digital Ocean - Server Blocks](./resources/DigitalOcean_ServerBlocks.md)<br>
[Rate Limiting With Nginx](./resources/Rate_Limiting_With_Nginx)<br>
### Step 3 - Troubleshooting Your Server
`/var/log/nginx/access.log`: Every request to your web server is recorded in this log file unless Nginx is configured to do otherwise.<br>
`/var/log/nginx/error.log`:
Any Nginx errors will be recorded in this log.<br>
### Step 4 - Setting up HTTPS with Certbot
Now with Nginx configured and running we should set up HTTPS with Certbot.<br>
`sudo apt update`<br>
`sudo apt install snapd`<br>
`sudo snap install core`<br>
`sudo snap refresh core`<br>
`sudo snap install --classic certbot`<br>
`sudo ln -s /snap/bin/certbot /usr/bin/certbot`<br>
`sudo certbot --nginx`
Fill out the questions about domain name email etc.<br>
`sudo nginx -t`<br>
`sudo systemctl reload nginx`<br>
Now you should have a fully functional HTTPS server.
### Resources
I found these resources helpful.
[Digital Ocean - Nginx ](./resources/DigitalOcean_Nginx.md)<br>
[Digital Ocean - Let's Encrypt](./resources/DigitalOcean_LetsEncrypt.md)<br>
[Digital Ocean - Server Blocks](./resources/DigitalOcean_ServerBlocks.md)<br>
[Rate Limiting With Nginx](./resources/Rate_Limiting_With_Nginx)<br>
[![Youtube](https://i.ytimg.com/vi/HaY8QB5kkGw/hqdefault.jpg)](https://youtu.be/HaY8QB5kkGw?si=9k44i9hon35KsaYp)<br>
[![YouTube](https://i.ytimg.com/vi/-lrSPJTeGhQ/hqdefault.jpg)](https://www.youtube.com/watch?v=-lrSPJTeGhQ)

View File

@ -0,0 +1,140 @@
### [Introduction](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-22-04#introduction)
Lets Encrypt is a Certificate Authority (CA) that provides an accessible way to obtain and install free [TLS/SSL certificates](https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs), thereby enabling encrypted HTTPS on web servers. It simplifies the process by providing a software client, Certbot, that attempts to automate most (if not all) of the required steps. Currently, the entire process of obtaining and installing a certificate is fully automated on both Apache and Nginx.
In this tutorial, you will use Certbot to obtain a free SSL certificate for Nginx on Ubuntu 22.04 and set up your certificate to renew automatically.
This tutorial will use a separate Nginx server configuration file instead of the default file. [We recommend](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-22-04#step-5-%E2%80%93-setting-up-server-blocks-(recommended)) creating new Nginx server block files for each domain because it helps to avoid common mistakes and maintains the default files as a fallback configuration.
## [Prerequisites](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-22-04#prerequisites)
To follow this tutorial, you will need:
- One Ubuntu 22.04 server set up by following this [initial server setup for Ubuntu 22.04](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-22-04) tutorial, including a sudo-enabled non-**root** user and a firewall.
- A registered domain name. This tutorial will use `example.com` throughout. You can purchase a domain name from [Namecheap](https://namecheap.com/), get one for free with [Freenom](https://www.freenom.com/), or use the domain registrar of your choice.
- Both of the following DNS records set up for your server. If you are using DigitalOcean, please see our [DNS documentation](https://www.digitalocean.com/docs/networking/dns/) for details on how to add them.
- An A record with `example.com` pointing to your servers public IP address.
- An A record with `www.example.com` pointing to your servers public IP address.
- Nginx installed by following [How To Install Nginx on Ubuntu 22.04](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-22-04). Be sure that you have a [server block](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-22-04#step-5-%E2%80%93-setting-up-server-blocks-(recommended)) for your domain. This tutorial will use `/etc/nginx/sites-available/example.com` as an example.
## [Step 1 — Installing Certbot](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-22-04#step-1-installing-certbot)
Certbot recommends using their _snap_ package for installation. Snap packages work on nearly all Linux distributions, but they require that youve installed snapd first in order to manage snap packages. Ubuntu 22.04 comes with support for snaps out of the box, so you can start by making sure your snapd core is up to date:
If youre working on a server that previously had an older version of certbot installed, you should remove it before going any further:
After that, you can install the `certbot` package:
Finally, you can link the `certbot` command from the snap install directory to your path, so youll be able to run it by just typing `certbot`. This isnt necessary with all packages, but snaps tend to be less intrusive by default, so they dont conflict with any other system packages by accident:
Now that we have Certbot installed, lets run it to get our certificate.
## [Step 2 — Confirming Nginxs Configuration](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-22-04#step-2-confirming-nginx-s-configuration)
Certbot needs to be able to find the correct `server` block in your Nginx configuration for it to be able to automatically configure SSL. Specifically, it does this by looking for a `server_name` directive that matches the domain you request a certificate for.
If you followed the [server block set up step in the Nginx installation tutorial](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-22-04#step-5-%E2%80%93-setting-up-server-blocks-(recommended)), you should have a server block for your domain at `/etc/nginx/sites-available/example.com` with the `server_name` directive already set appropriately.
To check, open the configuration file for your domain using `nano` or your favorite text editor:
Find the existing `server_name` line. It should look like this:
/etc/nginx/sites-available/example.com
If it does, exit your editor and move on to the next step.
If it doesnt, update it to match. Then save the file, quit your editor, and verify the syntax of your configuration edits:
If you get an error, reopen the server block file and check for any typos or missing characters. Once your configuration files syntax is correct, reload Nginx to load the new configuration:
Certbot can now find the correct `server` block and update it automatically.
Next, lets update the firewall to allow HTTPS traffic.
## [Step 3 — Allowing HTTPS Through the Firewall](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-22-04#step-3-allowing-https-through-the-firewall)
If you have the `ufw` firewall enabled, as recommended by the prerequisite guides, youll need to adjust the settings to allow for HTTPS traffic. Luckily, Nginx registers a few profiles with `ufw` upon installation.
You can see the current setting by typing:
It will probably look like this, meaning that only HTTP traffic is allowed to the web server:
```
<p>Output</p>Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)
```
To additionally let in HTTPS traffic, allow the Nginx Full profile and delete the redundant Nginx HTTP profile allowance:
Your status should now look like this:
```
<p>Output</p>Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx Full ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx Full (v6) ALLOW Anywhere (v6)
```
Next, lets run Certbot and fetch our certificates.
## [Step 4 — Obtaining an SSL Certificate](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-22-04#step-4-obtaining-an-ssl-certificate)
Certbot provides a variety of ways to obtain SSL certificates through plugins. The Nginx plugin will take care of reconfiguring Nginx and reloading the config whenever necessary. To use this plugin, type the following:
This runs `certbot` with the `--nginx` plugin, using `-d` to specify the domain names wed like the certificate to be valid for.
When running the command, you will be prompted to enter an email address and agree to the terms of service. After doing so, you should see a message telling you the process was successful and where your certificates are stored:
```
<p>Output</p>IMPORTANT NOTES:
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/<mark>your_domain</mark>/fullchain.pem
Key is saved at: /etc/letsencrypt/live/<mark>your_domain</mark>/privkey.pem
This certificate expires on 2022-06-01.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le
```
Your certificates are downloaded, installed, and loaded, and your Nginx configuration will now automatically redirect all web requests to `https://`. Try reloading your website and notice your browsers security indicator. It should indicate that the site is properly secured, usually with a lock icon. If you test your server using the [SSL Labs Server Test](https://www.ssllabs.com/ssltest/), it will get an **A** grade.
Lets finish by testing the renewal process.
## [Step 5 — Verifying Certbot Auto-Renewal](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-22-04#step-5-verifying-certbot-auto-renewal)
Lets Encrypts certificates are only valid for ninety days. This is to encourage users to automate their certificate renewal process. The `certbot` package we installed takes care of this for us by adding a systemd timer that will run twice a day and automatically renew any certificate thats within thirty days of expiration.
You can query the status of the timer with `systemctl`:
```
<p>Output</p>○ snap.certbot.renew.service - Service for snap application certbot.renew
Loaded: loaded (/etc/systemd/system/snap.certbot.renew.service; static)
Active: inactive (dead)
TriggeredBy: ● snap.certbot.renew.timer
```
To test the renewal process, you can do a dry run with `certbot`:
If you see no errors, youre all set. When necessary, Certbot will renew your certificates and reload Nginx to pick up the changes. If the automated renewal process ever fails, Lets Encrypt will send a message to the email you specified, warning you when your certificate is about to expire.
## [Conclusion](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-22-04#conclusion)
In this tutorial, you installed the Lets Encrypt client `certbot`, downloaded SSL certificates for your domain, configured Nginx to use these certificates, and set up automatic certificate renewal. If you have further questions about using Certbot, [the official documentation](https://certbot.eff.org/docs/) is a good place to start.

View File

@ -0,0 +1,211 @@
### [Introduction](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#introduction)
[Nginx](https://www.nginx.com/) is one of the most popular web servers in the world and is responsible for hosting some of the largest and highest-traffic sites on the internet. It is a lightweight choice that can be used as either a web server or reverse proxy.
In this guide, well discuss how to install Nginx on your Ubuntu 20.04 server, adjust the firewall, manage the Nginx process, and set up server blocks for hosting more than one domain from a single server.
Simplify deploying applications with [DigitalOcean App Platform](https://www.digitalocean.com/products/app-platform). Deploy directly from GitHub in minutes.
## [Prerequisites](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#prerequisites)
Before you begin this guide, you should have a regular, non-root user with sudo privileges configured on your server. You can learn how to configure a regular user account by following our [Initial server setup guide for Ubuntu 20.04](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-20-04).
You will also optionally want to have registered a domain name before completing the last steps of this tutorial. To learn more about setting up a domain name with DigitalOcean, please refer to our [Introduction to DigitalOcean DNS](https://www.digitalocean.com/community/tutorials/an-introduction-to-digitalocean-dns).
When you have an account available, log in as your non-root user to begin.
## [Step 1 Installing Nginx](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#step-1-installing-nginx)
Because Nginx is available in Ubuntus default repositories, it is possible to install it from these repositories using the `apt` packaging system.
Since this is our first interaction with the `apt` packaging system in this session, we will update our local package index so that we have access to the most recent package listings. Afterwards, we can install `nginx`:
After accepting the procedure, `apt` will install Nginx and any required dependencies to your server.
## [Step 2 Adjusting the Firewall](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#step-2-adjusting-the-firewall)
Before testing Nginx, the firewall software needs to be adjusted to allow access to the service. Nginx registers itself as a service with `ufw` upon installation, making it straightforward to allow Nginx access.
List the application configurations that `ufw` knows how to work with by typing:
You should get a listing of the application profiles:
```
<p>Output</p>Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH
```
As demonstrated by the output, there are three profiles available for Nginx:
- **Nginx Full**: This profile opens both port 80 (normal, unencrypted web traffic) and port 443 (TLS/SSL encrypted traffic)
- **Nginx HTTP**: This profile opens only port 80 (normal, unencrypted web traffic)
- **Nginx HTTPS**: This profile opens only port 443 (TLS/SSL encrypted traffic)
It is recommended that you enable the most restrictive profile that will still allow the traffic youve configured. Right now, we will only need to allow traffic on port 80.
You can enable this by typing:
You can verify the change by typing:
The output will indicated which HTTP traffic is allowed:
```
<p>Output</p>Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)
```
## [Step 3 Checking your Web Server](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#step-3-checking-your-web-server)
At the end of the installation process, Ubuntu 20.04 starts Nginx. The web server should already be up and running.
We can check with the `systemd` init system to make sure the service is running by typing:
```
<p>Output</p>● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: <mark>active (running)</mark> since Fri 2020-04-20 16:08:19 UTC; 3 days ago
Docs: man:nginx(8)
Main PID: 2369 (nginx)
Tasks: 2 (limit: 1153)
Memory: 3.5M
CGroup: /system.slice/nginx.service
├─2369 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
└─2380 nginx: worker process
```
As confirmed by this out, the service has started successfully. However, the best way to test this is to actually request a page from Nginx.
You can access the default Nginx landing page to confirm that the software is running properly by navigating to your servers IP address. If you do not know your servers IP address, you can find it by using the [icanhazip.com](http://icanhazip.com/) tool, which will give you your public IP address as received from another location on the internet:
When you have your servers IP address, enter it into your browsers address bar:
```
http://<mark>your_server_ip</mark>
```
You should receive the default Nginx landing page:
![Nginx default page](https://assets.digitalocean.com/articles/nginx_1604/default_page.png)
If you are on this page, your server is running correctly and is ready to be managed.
## [Step 4 Managing the Nginx Process](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#step-4-managing-the-nginx-process)
Now that you have your web server up and running, lets review some basic management commands.
To stop your web server, type:
To start the web server when it is stopped, type:
To stop and then start the service again, type:
If you are only making configuration changes, Nginx can often reload without dropping connections. To do this, type:
By default, Nginx is configured to start automatically when the server boots. If this is not what you want, you can disable this behavior by typing:
To re-enable the service to start up at boot, you can type:
You have now learned basic management commands and should be ready to configure the site to host more than one domain.
## [Step 5 Setting Up Server Blocks (Recommended)](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#step-5-setting-up-server-blocks-recommended)
When using the Nginx web server, _server blocks_ (similar to virtual hosts in Apache) can be used to encapsulate configuration details and host more than one domain from a single server. We will set up a domain called **your\_domain**, but you should **replace this with your own domain name**.
Nginx on Ubuntu 20.04 has one server block enabled by default that is configured to serve documents out of a directory at `/var/www/html`. While this works well for a single site, it can become unwieldy if you are hosting multiple sites. Instead of modifying `/var/www/html`, lets create a directory structure within `/var/www` for our **your\_domain** site, leaving `/var/www/html` in place as the default directory to be served if a client request doesnt match any other sites.
Create the directory for **your\_domain** as follows, using the `-p` flag to create any necessary parent directories:
Next, assign ownership of the directory with the `$USER` environment variable:
The permissions of your web roots should be correct if you havent modified your `umask` value, which sets default file permissions. To ensure that your permissions are correct and allow the owner to read, write, and execute the files while granting only read and execute permissions to groups and others, you can input the following command:
Next, create a sample `index.html` page using `nano` or your favorite editor:
Inside, add the following sample HTML:
/var/www/your\_domain/html/index.html
Save and close the file by pressing `Ctrl+X` to exit, then when prompted to save, `Y` and then `Enter`.
In order for Nginx to serve this content, its necessary to create a server block with the correct directives. Instead of modifying the default configuration file directly, lets make a new one at `/etc/nginx/sites-available/your_domain`:
Paste in the following configuration block, which is similar to the default, but updated for our new directory and domain name:
/etc/nginx/sites-available/your\_domain
Notice that weve updated the `root` configuration to our new directory, and the `server_name` to our domain name.
Next, lets enable the file by creating a link from it to the `sites-enabled` directory, which Nginx reads from during startup:
**Note:** Nginx uses a common practice called symbolic links, or symlinks, to track which of your server blocks are enabled. Creating a symlink is like creating a shortcut on disk, so that you could later delete the shortcut from the `sites-enabled` directory while keeping the server block in `sites-available` if you wanted to enable it.
Two server blocks are now enabled and configured to respond to requests based on their `listen` and `server_name` directives (you can read more about how Nginx processes these directives [here](https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms)):
- `your_domain`: Will respond to requests for `your_domain` and `www.your_domain`.
- `default`: Will respond to any requests on port 80 that do not match the other two blocks.
To avoid a possible hash bucket memory problem that can arise from adding additional server names, it is necessary to adjust a single value in the `/etc/nginx/nginx.conf` file. Open the file:
Find the `server_names_hash_bucket_size` directive and remove the `#` symbol to uncomment the line. If you are using nano, you can quickly search for words in the file by pressing `CTRL` and `w`.
**Note:** Commenting out lines of code usually by putting `#` at the start of a line is another way of disabling them without needing to actually delete them. Many configuration files ship with multiple options commented out so that they can be enabled or disabled, by toggling them between active code and documentation.
/etc/nginx/nginx.conf
```
...
http {
...
server_names_hash_bucket_size 64;
...
}
...
```
Save and close the file when you are finished.
Next, test to make sure that there are no syntax errors in any of your Nginx files:
If there arent any problems, restart Nginx to enable your changes:
Nginx should now be serving your domain name. You can test this by navigating to `http://your_domain`, where you should see something like this:
![Nginx first server block](https://assets.digitalocean.com/articles/how-to-install-nginx-u18.04/your-domain-server-block-nginx.PNG)
## [Step 6 Getting Familiar with Important Nginx Files and Directories](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#step-6-getting-familiar-with-important-nginx-files-and-directories)
Now that you know how to manage the Nginx service itself, you should take a few minutes to familiarize yourself with a few important directories and files.
### [Content](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#content)
- `/var/www/html`: The actual web content, which by default only consists of the default Nginx page you saw earlier, is served out of the `/var/www/html` directory. This can be changed by altering Nginx configuration files.
### [Server Configuration](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#server-configuration)
- `/etc/nginx`: The Nginx configuration directory. All of the Nginx configuration files reside here.
- `/etc/nginx/nginx.conf`: The main Nginx configuration file. This can be modified to make changes to the Nginx global configuration.
- `/etc/nginx/sites-available/`: The directory where per-site server blocks can be stored. Nginx will not use the configuration files found in this directory unless they are linked to the `sites-enabled` directory. Typically, all server block configuration is done in this directory, and then enabled by linking to the other directory.
- `/etc/nginx/sites-enabled/`: The directory where enabled per-site server blocks are stored. Typically, these are created by linking to configuration files found in the `sites-available` directory.
- `/etc/nginx/snippets`: This directory contains configuration fragments that can be included elsewhere in the Nginx configuration. Potentially repeatable configuration segments are good candidates for refactoring into snippets.
### [Server Logs](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#server-logs)
- `/var/log/nginx/access.log`: Every request to your web server is recorded in this log file unless Nginx is configured to do otherwise.
- `/var/log/nginx/error.log`: Any Nginx errors will be recorded in this log.
## [Conclusion](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04#conclusion)
Now that you have your web server installed, you have many options for the type of content to serve and the technologies you want to use to create a richer experience.
If youd like to build out a more complete application stack, check out the article [How To Install Linux, Nginx, MySQL, PHP (LEMP stack) on Ubuntu 20.04](https://www.digitalocean.com/community/tutorials/how-to-install-linux-nginx-mysql-php-lemp-stack-on-ubuntu-20-04).
In order to set up HTTPS for your domain name with a free SSL certificate using _Lets Encrypt_, you should move on to [How To Secure Nginx with Lets Encrypt on Ubuntu 20.04](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-20-04).

View File

@ -0,0 +1,303 @@
### [Introduction](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#introduction)
When using the Nginx web server, **server blocks** (similar to virtual hosts in Apache) can be used to encapsulate configuration details and host more than one domain on a single server.
In this guide, well discuss how to configure server blocks in Nginx on an Ubuntu 16.04 server.
Deploy your applications from GitHub using [DigitalOcean App Platform](https://www.digitalocean.com/products/app-platform). Let DigitalOcean focus on scaling your app.
## [Prerequisites](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#prerequisites)
Were going to be using a non-root user with `sudo` privileges throughout this tutorial. If you do not have a user like this configured, you can create one by following our [Ubuntu 16.04 initial server setup](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04) guide.
You will also need to have Nginx installed on your server. The following guides cover this procedure:
- [How To Install Nginx on Ubuntu 16.04](https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-16-04): Use this guide to set up Nginx on its own.
- [How To Install Linux, Nginx, MySQL, PHP (LEMP stack) in Ubuntu 16.04](https://www.digitalocean.com/community/tutorials/how-to-install-linux-nginx-mysql-php-lemp-stack-in-ubuntu-16-04): Use this guide if you will be using Nginx in conjunction with MySQL and PHP.
When you have fulfilled these requirements, you can continue on with this guide.
## [Example Configuration](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#example-configuration)
For demonstration purposes, were going to set up two domains with our Nginx server. The domain names well use in this guide are **[example.com](http://example.com/)** and **[test.com](http://test.com/)**.
If you do not have two spare domain names to play with, use placeholder names for now and well show you later how to configure your local computer to test your configuration.
## [Step 1 — Setting Up New Document Root Directories](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#step-1-setting-up-new-document-root-directories)
By default, Nginx on Ubuntu 16.04 has one server block enabled. It is configured to serve documents out of a directory at `/var/www/html`.
While this works well for a single site, we need additional directories if were going to serve multiple sites. We can consider the `/var/www/html` directory the default directory that will be served if the client request doesnt match any of our other sites.
We will create a directory structure within `/var/www` for each of our sites. The actual web content will be placed in an `html` directory within these site-specific directories. This gives us some additional flexibility to create other directories associated with our sites as siblings to the `html` directory if necessary.
We need to create these directories for each of our sites. The `-p` flag tells `mkdir` to create any necessary parent directories along the way:
Now that we have our directories, we will reassign ownership of the web directories to our normal user account. This will let us write to them without `sudo`.
**Note:** Depending on your needs, you might need to adjust the permissions or ownership of the folders again to allow certain access to the `www-data` user. For instance, dynamic sites will often need this. The specific permissions and ownership requirements entirely depend on your configuration. Follow the recommendations for the specific technology youre using.
We can use the `$USER` environmental variable to assign ownership to the account that we are currently signed in on (make sure youre not logged in as **root**). This will allow us to easily create or edit the content in this directory:
The permissions of our web roots should be correct already if you have not modified your `umask` value, but we can make sure by typing:
Our directory structure is now configured and we can move on.
## [Step 2 — Creating Sample Pages for Each Site](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#step-2-creating-sample-pages-for-each-site)
Now that we have our directory structure set up, lets create a default page for each of our sites so that we will have something to display.
Create an `index.html` file in your first domain:
Inside the file, well create a really basic file that indicates what site we are currently accessing. It will look like this:
/var/www/example.com/html/index.html
```
&lt;html&gt;
&lt;head&gt;
&lt;title&gt;Welcome to <mark>Example.com</mark>!&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;h1&gt;Success! The <mark>example.com</mark> server block is working!&lt;/h1&gt;
&lt;/body&gt;
&lt;/html&gt;
```
Save and close the file when you are finished. To do this in `nano`, press `CTRL+o` to write the file out, then `CTRL+x` to exit.
Since the file for our second site is basically going to be the same, we can copy it over to our second document root like this:
Now, we can open the new file in our editor:
Modify it so that it refers to our second domain:
/var/www/test.com/html/index.html
```
&lt;html&gt;
&lt;head&gt;
&lt;title&gt;Welcome to <mark>Test.com</mark>!&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;h1&gt;Success! The <mark>test.com</mark> server block is working!&lt;/h1&gt;
&lt;/body&gt;
&lt;/html&gt;
```
Save and close this file when you are finished. We now have some pages to display to visitors of our two domains.
## [Step 3 — Creating Server Block Files for Each Domain](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#step-3-creating-server-block-files-for-each-domain)
Now that we have the content we wish to serve, we need to create the server blocks that will tell Nginx how to do this.
By default, Nginx contains one server block called `default` which we can use as a template for our own configurations. We will begin by designing our first domains server block, which we will then copy over for our second domain and make the necessary modifications.
### [Creating the First Server Block File](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#creating-the-first-server-block-file)
As mentioned above, we will create our first server block config file by copying over the default file:
Now, open the new file you created in your text editor with `sudo` privileges:
Ignoring the commented lines, the file will look similar to this:
/etc/nginx/sites-available/example.com
```
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
try_files $uri $uri/ =404;
}
}
```
First, we need to look at the listen directives. **Only one of our server blocks on the server can have the `default_server` option enabled.** This specifies which block should serve a request if the `server_name` requested does not match any of the available server blocks. This shouldnt happen very frequently in real world scenarios since visitors will be accessing your site through your domain name.
You can choose to designate one of your sites as the “default” by including the `default_server` option in the `listen` directive, or you can leave the default server block enabled, which will serve the content of the `/var/www/html` directory if the requested host cannot be found.
In this guide, well leave the default server block in place to serve non-matching requests, so well remove the `default_server` from this and the next server block. You can choose to add the option to whichever of your server blocks makes sense to you.
/etc/nginx/sites-available/example.com
```
server {
listen 80;
listen [::]:80;
. . .
}
```
**Note:** You can check that the `default_server` option is only enabled in a single active file by typing:
If matches are found uncommented in more than on file (shown in the leftmost column), Nginx will complain about an invalid configuration.
The next thing were going to have to adjust is the document root, specified by the `root` directive. Point it to the sites document root that you created:
/etc/nginx/sites-available/example.com
```
server {
listen 80;
listen [::]:80;
root /var/www/<mark>example.com</mark>/html;
}
```
Next, we need to modify the `server_name` to match requests for our first domain. We can additionally add any aliases that we want to match. We will add a `www.example.com` alias to demonstrate.
When you are finished, your file will look something like this:
/etc/nginx/sites-available/example.com
```
server {
listen 80;
listen [::]:80;
root /var/www/<mark>example.com</mark>/html;
index index.html index.htm index.nginx-debian.html;
server_name <mark>example.com</mark> www.<mark>example.com</mark>;
location / {
try_files $uri $uri/ =404;
}
}
```
That is all we need for a basic configuration. Save and close the file to exit.
### [Creating the Second Server Block File](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#creating-the-second-server-block-file)
Now that we have our initial server block configuration, we can use that as a basis for our second file. Copy it over to create a new file:
Open the new file with `sudo` privileges in your editor:
Again, make sure that you do not use the `default_server` option for the `listen` directive in this file if youve already used it elsewhere. Adjust the `root` directive to point to your second domains document root and adjust the `server_name` to match your second sites domain name (make sure to include any aliases).
When you are finished, your file will likely look something like this:
/etc/nginx/sites-available/test.com
```
server {
listen 80;
listen [::]:80;
root /var/www/<mark>test.com</mark>/html;
index index.html index.htm index.nginx-debian.html;
server_name <mark>test.com</mark> www.<mark>test.com</mark>;
location / {
try_files $uri $uri/ =404;
}
}
```
When you are finished, save and close the file.
## [Step 4 — Enabling your Server Blocks and Restart Nginx](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#step-4-enabling-your-server-blocks-and-restart-nginx)
Now that we have our server block files, we need to enable them. We can do this by creating symbolic links from these files to the `sites-enabled` directory, which Nginx reads from during startup.
We can create these links by typing:
These files are now linked into the enabled directory. We now have three server blocks enabled, which are configured to respond based on their `listen` directive and the `server_name` (you can read more about how Nginx processes these directives [here](https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms)):
- `example.com`: Will respond to requests for `example.com` and `www.example.com`
- `test.com`: Will respond to requests for `test.com` and `www.test.com`
- `default`: Will respond to any requests on port 80 that do not match the other two blocks.
In order to avoid a possible hash bucket memory problem that can arise from adding additional server names, we will also adjust a single value within our `/etc/nginx/nginx.conf` file. Open the file now:
Within the file, find the `server_names_hash_bucket_size` directive. Remove the `#` symbol to uncomment the line:
/etc/nginx/nginx.conf
```
http {
. . .
server_names_hash_bucket_size 64;
. . .
}
```
Save and close the file when you are finished.
Next, test to make sure that there are no syntax errors in any of your Nginx files:
If no problems were found, restart Nginx to enable your changes:
Nginx should now be serving both of your domain names.
## [Step 5 — Modifying Your Local Hosts File for Testing (Optional)](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#step-5-modifying-your-local-hosts-file-for-testing-optional)
If you have not been using domain names that you own and instead have been using placeholder values, you can modify your local computers configuration to let you to temporarily test your Nginx server block configuration.
This will not allow other visitors to view your site correctly, but it will give you the ability to reach each site independently and test your configuration. This works by intercepting requests that would usually go to DNS to resolve domain names. Instead, we can set the IP addresses we want our local computer to go to when we request the domain names.
**Note:** Make sure you are operating on your local computer during these steps and not a remote server. You will need to have root access, be a member of the administrative group, or otherwise be able to edit system files to do this.
If you are on a Mac or Linux computer at home, you can edit the file needed by typing:
If you are on Windows, you can [find instructions for altering your hosts file](https://www.thewindowsclub.com/hosts-file-in-windows) here.
You need to know your servers public IP address and the domains you want to route to the server. Assuming that my servers public IP address is `203.0.113.5`, the lines I would add to my file would look something like this:
/etc/hosts
```
127.0.0.1 localhost
. . .
<mark>203.0.113.5 example.com www.example.com</mark>
<mark>203.0.113.5 test.com www.test.com</mark>
```
This will intercept any requests for `example.com` and `test.com` and send them to your server, which is what we want if we dont actually own the domains that we are using.
Save and close the file when you are finished.
## [Step 6 — Testing Your Results](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#step-6-testing-your-results)
Now that you are all set up, you should test that your server blocks are functioning correctly. You can do that by visiting the domains in your web browser:
```
http://<mark>example.com</mark>
```
You should see a page that looks like this:
![Nginx first server block](https://assets.digitalocean.com/articles/nginx_server_block_1404/first_block.png)
If you visit your second domain name, you should see a slightly different site:
```
http://<mark>test.com</mark>
```
![Nginx second server block](https://assets.digitalocean.com/articles/nginx_server_block_1404/second_block.png)
If both of these sites work, you have successfully configured two independent server blocks with Nginx.
At this point, if you adjusted your `hosts` file on your local computer in order to test, youll probably want to remove the lines you added.
If you need domain name access to your server for a public-facing site, you will probably want to purchase a domain name for each of your sites.
## [Conclusion](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04#conclusion)
You should now have the ability to create server blocks for each domain you wish to host from the same server. There arent any real limits on the number of server blocks you can create, so long as your hardware can handle the traffic.

View File

@ -0,0 +1,232 @@
One of the most useful, but often misunderstood and misconfigured, features of NGINX is rate limiting. It allows you to limit the amount of HTTP requests a user can make in a given period of time. A request can be as simple as a `GET` request for the homepage of a website or a `POST` request on a login form.
Rate limiting can be used for security purposes, for example to slow down bruteforce passwordguessing attacks. It can help [protect against DDoS attacks](https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/) by limiting the incoming request rate to a value typical for real users, and (with logging) identify the targeted URLs. More generally, it is used to protect upstream application servers from being overwhelmed by too many user requests at the same time.
In this blog we will cover the basics of rate limiting with NGINX as well as more advanced configurations. Rate limiting works the same way in NGINX Plus.
To learn more about rate limiting with NGINX, watch our [on-demand webinar](https://www.nginx.com/resources/webinars/rate-limiting-nginx/).
## How NGINX Rate Limiting Works
NGINX rate limiting uses the “leaky bucket algorithm”, which is widely used in telecommunications and packetswitched computer networks to deal with burstiness when bandwidth is limited. The analogy is with a bucket where water is poured in at the top and leaks from the bottom; if the rate at which water is poured in exceeds the rate at which it leaks, the bucket overflows. In terms of request processing, the water represents requests from clients, and the bucket represents a queue where requests wait to be processed according to a firstinfirstout (FIFO) scheduling algorithm. The leaking water represents requests exiting the buffer for processing by the server, and the overflow represents requests that are discarded and never serviced.
## Configuring Basic Rate Limiting
Rate limiting is configured with two main directives, `limit_req_zone` and `limit_req`, as in this example:
```
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
server {
location /login/ {
limit_req zone=mylimit;
proxy_pass http://my_upstream;
}
}
```
The [`limit_req_zone`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_zone) directive defines the parameters for rate limiting while [`limit_req`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req) enables rate limiting within the context where it appears (in the example, for all requests to **/login/**).
The `limit_req_zone` directive is typically defined in the `http` block, making it available for use in multiple contexts. It takes the following three parameters:
- **Key**  Defines the request characteristic against which the limit is applied. In the example it is the NGINX variable `$binary_remote_addr`, which holds a binary representation of a clients IP address. This means we are limiting each unique IP address to the request rate defined by the third parameter. (Were using this variable because it takes up less space than the string representation of a client IP address, `$remote_addr`).
- **Zone**  Defines the shared memory zone used to store the state of each IP address and how often it has accessed a requestlimited URL. Keeping the information in shared memory means it can be shared among the NGINX worker processes. The definition has two parts: the zone name identified by the `zone=` keyword, and the size following the colon. State information for about 16,000 IP addresses takes 1 ;megabyte, so our zone can store about 160,000 addresses.
- If storage is exhausted when NGINX needs to add a new entry, it removes the oldest entry. If the space freed is still not enough to accommodate the new record, NGINX returns status code `503 (Service Temporarily Unavailable)`. Additionally, to prevent memory from being exhausted, every time NGINX creates a new entry it removes up to two entries that have not been used in the previous 60 seconds.
- **Rate**  Sets the maximum request rate. In the example, the rate cannot exceed 10 requests per second. NGINX actually tracks requests at millisecond granularity, so this limit corresponds to 1 request every 100 milliseconds (ms). Because we are not allowing for bursts (see the [next section](https://blog.nginx.org/blog/rate-limiting-nginx#bursts)), this means that a request is rejected if it arrives less than 100ms after the previous permitted one.
The `limit_req_zone` directive sets the parameters for rate limiting and the shared memory zone, but it does not actually limit the request rate. For that you need to apply the limit to a specific `location` or `server` block by including a `limit_req` directive there. In the example, we are rate limiting requests to **/login/**.
So now each unique IP address is limited to 10 requests per second for **/login/**  or more precisely, cannot make a request for that URL within 100ms of its previous one.
## Handling Bursts
What if we get 2 requests within 100ms of each other? For the second request NGINX returns status code `503` to the client. This is probably not what we want, because applications tend to be bursty in nature. Instead we want to buffer any excess requests and service them in a timely manner. This is where we use the `burst` parameter to `limit_req`, as in this updated configuration:
```
location /login/ {
limit_req zone=mylimit <strong>burst=20</strong>;
proxy_pass http://my_upstream;
}
```
The `burst` parameter defines how many requests a client can make in excess of the rate specified by the zone (with our sample **mylimit** zone, the rate limit is 10 requests per second, or 1 every 100ms). A request that arrives sooner than 100ms after the previous one is put in a queue, and here we are setting the queue size to 20.
That means if 21 requests arrive from a given IP address simultaneously, NGINX forwards the first one to the upstream server group immediately and puts the remaining 20 in the queue. It then forwards a queued request every 100ms, and returns `503` to the client only if an incoming request makes the number of queued requests go over 20.
## Queueing with No Delay
A configuration with `burst` results in a smooth flow of traffic, but is not very practical because it can make your site appear slow. In our example, the 20th packet in the queue waits 2 seconds to be forwarded, at which point a response to it might no longer be useful to the client. To address this situation, add the `nodelay` parameter along with the `burst` parameter:
```
location /login/ {
limit_req zone=mylimit <strong>burst=20 nodelay</strong>;
proxy_pass http://my_upstream;
}
```
With the `nodelay` parameter, NGINX still allocates slots in the queue according to the `burst` parameter and imposes the configured rate limit, but not by spacing out the forwarding of queued requests. Instead, when a request arrives “too soon”, NGINX forwards it immediately as long as there is a slot available for it in the queue. It marks that slot as “taken” and does not free it for use by another request until the appropriate time has passed (in our example, after 100ms).
Suppose, as before, that the 20slot queue is empty and 21 requests arrive simultaneously from a given IP address. NGINX forwards all 21 requests immediately and marks the 20 slots in the queue as taken, then frees 1 slot every 100ms. (If there were 25 requests instead, NGINX would immediately forward 21 of them, mark 20 slots as taken, and reject 4 requests with status `503`.)
Now suppose that 101ms after the first set of requests was forwarded another 20 requests arrive simultaneously. Only 1 slot in the queue has been freed, so NGINX forwards 1 request and rejects the other 19 with status `503`. If instead 501ms have passed before the 20 new requests arrive, 5 slots are free so NGINX forwards 5 requests immediately and rejects 15.
The effect is equivalent to a rate limit of 10 requests per second. The `nodelay` option is useful if you want to impose a rate limit without constraining the allowed spacing between requests.
**Note:** For most deployments, we recommend including the `burst` and `nodelay` parameters to the `limit_req` directive.
## Two-Stage Rate Limiting
With NGINX Open Source 1.15.7, you can configure NGINX to allow a burst of requests to accommodate the typical web browser request pattern, and then throttle additional excessive requests up to a point, beyond which additional excessive requests are rejected. Two-stage rate limiting is enabled with the [`delay`](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_delay) parameter to the `limit_req` directive.
To illustrate twostage rate limiting, here we configure NGINX to protect a website by imposing a rate limit of 5 requests per second (r/s). The website typically has 46 resources per page, and never more than 12 resources. The configuration allows bursts of up to 12 requests, the first 8 of which are processed without delay. A delay is added after 8 excessive requests to enforce the 5 r/s limit. After 12 excessive requests, any further requests are rejected.
```
limit_req_zone $binary_remote_addr zone=ip:10m rate=5r/s;
server {
listen 80;
location / {
limit_req zone=ip burst=12 delay=8;
proxy_pass http://website;
}
}
```
The `delay` parameter defines the point at which, within the burst size, excessive requests are throttled (delayed) to comply with the defined rate limit. With this configuration in place, a client that makes a continuous stream of requests at 8 r/s experiences the following behavior.
![Illustration of ratelimiting behavior with rate=5r/s burst=12 delay=8](https://nginxblog-8de1046ff5a84f2c-endpoint.azureedge.net/blobnginxbloga72cde487e/wp-content/uploads/2024/06/two-stage-rate-limiting-example.png)
Illustration of ratelimiting behavior with `rate=5r/s` `burst=12` `delay=8`
The first 8 requests (the value of `delay`) are proxied by NGINX Plus without delay. The next 4 requests (`burst` `-` `delay`) are delayed so that the defined rate of 5 r/s is not exceeded. The next 3 requests are rejected because the total burst size has been exceeded. Subsequent requests are delayed.
## Advanced Configuration Examples
By combining basic rate limiting with other NGINX features, you can implement more nuanced traffic limiting.
### Allowlisting
This example shows how to impose a rate limit on requests from anyone who is not on an “allowlist”.
```
geo $limit {
default 1;
10.0.0.0/8 0;
192.168.0.0/24 0;
}
map $limit $limit_key {
0 "";
1 $binary_remote_addr;
}
limit_req_zone $limit_key zone=req_zone:10m rate=5r/s;
server {
location / {
limit_req zone=req_zone burst=10 nodelay;
# ...
}
}
```
This example makes use of both the [`geo`](http://nginx.org/en/docs/http/ngx_http_geo_module.html#geo) and [`map`](http://nginx.org/en/docs/http/ngx_http_map_module.html#map) directives. The `geo` block assigns a value of `0` to `$limit` for IP addresses in the allowlist and `1` for all others. We then use a map to translate those values into a key, such that:
- If `$limit` is `0`, `$limit_key` is set to the empty string
- If `$limit` is `1`, `$limit_key` is set to the clients IP address in binary format
Putting the two together, `$limit_key` is set to an empty string for allowlisted IP addresses, and to the clients IP address otherwise. When the first parameter to the `limit_req_zone` directory (the key) is an empty string, the limit is not applied, so allowlisted IP addresses (in the 10.0.0.0/8 and 192.168.0.0/24 subnets) are not limited. All other IP addresses are limited to 5 requests per second.
The `limit_req` directive applies the limit to the **/** location and allows bursts of up to 10 packets over the configured limit with no delay on forwarding
### Including Multiple `limit_req` Directives in a Location
You can include multiple `limit_req` directives in a single location. All limits that match a given request are applied, meaning the most restrictive one is used. For example, if more than one directive imposes a delay, the longest delay is used. Similarly, requests are rejected if that is the effect of any directive, even if other directives allow them through.
Extending the previous example we can apply a rate limit to IP addresses on the allowlist:
```
http {
# ...
limit_req_zone $limit_key zone=req_zone:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=req_zone_wl:10m rate=15r/s;
server {
# ...
location / {
limit_req zone=req_zone burst=10 nodelay;
limit_req zone=req_zone_wl burst=20 nodelay;
# ...
}
}
}
```
IP addresses on the allowlist do not match the first rate limit (**req\_zone**) but do match the second (**req\_zone\_wl**) and so are limited to 15 requests per second. IP addresses not on the allowlist match both rate limits so the more restrictive one applies: 5 requests per second.
## Configuring Related Features
### Logging
By default, NGINX logs requests that are delayed or dropped due to rate limiting, as in this example:
```
2015/06/13 04:20:00 [error] 120315#0: *32086 limiting requests, excess: 1.000 by zone "mylimit", client: 192.168.1.2, server: nginx.com, request: "GET / HTTP/1.0", host: "nginx.com"
```
Fields in the log entry include:
- **`2015/06/13` `04:20:00`**  Date and time the log entry was written
- `**[error]**`  Severity level
- `**120315#0**`  Process ID and thread ID of the NGINX worker, separated by the `#` sign
- `***32086**`  ID for the proxied connection that was ratelimited
- **`limiting` `requests`**  Indicator that the log entry records a rate limit
- `**excess**`  Number of requests per millisecond over the configured rate that this request represents
- `**zone**`  Zone that defines the imposed rate limit
- `**client**`  IP address of the client making the request
- `**server**`  IP address or hostname of the server
- `**request**`  Actual HTTP request made by the client
- `**host**`  Value of the `Host` HTTP header
By default, NGINX logs refused requests at the `error` level, as shown by `[error]` in the example above. (It logs delayed requests at one level lower, so `warn` by default.) To change the logging level, use the [`limit_req_log_level`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_log_level) directive. Here we set refused requests to log at the `warn` level:
```
location /login/ {
limit_req zone=mylimit burst=20 nodelay;
<strong>limit_req_log_level warn;</strong>
proxy_pass http://my_upstream;
}
```
### Error Code Sent to Client
By default NGINX responds with status code `503 (Service Temporarily Unavailable)` when a client exceeds its rate limit. Use the [`limit_req_status`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_status) directive to set a different status code (`444` in this example):
```
location /login/ {
limit_req zone=mylimit <strong>burst=20 nodelay;
limit_req_status 444</strong>;
}
```
### Denying All Requests to a Specific Location
If you want to deny all requests for a specific URL, rather than just limiting them, configure a [`location`](http://nginx.org/en/docs/http/ngx_http_core_module.html#location) block for it and include the [`deny`](http://nginx.org/en/docs/http/ngx_http_access_module.html#deny) `all` directive:
```
location /foo.php {
deny all;
}
```
## Conclusion
We have covered many features of rate limiting that NGINX offers, including setting up request rates for different locations on HTTP requests, and configuring additional features to rate limiting such as the `burst` and `nodelay` parameters. We have also covered advanced configuration for applying different limits for allowlisted and denylisted client IP addresses, and explained how to log rejected and delayed requests.

View File

@ -0,0 +1,83 @@
user www-data;
worker_processes auto;
pid /run/nginx.pid;
error_log /var/log/nginx/error.log;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
##
# Gzip Settings
##
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
#mail {
# # See sample authentication script at:
# # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
# # auth_http localhost/auth.php;
# # pop3_capabilities "TOP" "USER";
# # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
# server {
# listen localhost:110;
# protocol pop3;
# proxy on;
# }
#
# server {
# listen localhost:143;
# protocol imap;
# proxy on;
# }
#}

View File

@ -0,0 +1,91 @@
##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# pass PHP scripts to FastCGI server
#
#location ~ \.php$ {
# include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
# fastcgi_pass unix:/run/php/php7.4-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
# listen 80;
# listen [::]:80;
#
# server_name example.com;
#
# root /var/www/example.com;
# index index.html;
#
# location / {
# try_files $uri $uri/ =404;
# }
#}

46
postgresql/README.md Normal file
View File

@ -0,0 +1,46 @@
# Postgresql Database
Walkthrough of installing Postgresql database.
## Table of Contents
- [Step 1 - Installing Postgresql](#step-1---installing-postgresql)
- [Step 2 - Create user and database.](#step-2---create-user-and-database)
- [Step 3 - Configure postgresql](#step-3---configure-postgresql)
- [Step 4 - Configure access](#step-3---configure-access)
### Step 1 - Installing Postgresql
`sudo apt-get update`<br>
`sudo apt-get -y install postgresql`<br>
### Step 2 - Create User and Database
`sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git git`<br>
`su -c "psql" - postgres`<br>
Change postgresql password.<br>
`ALTER USER postgres WITH PASSWORD 'new_password';`<br>
Create app user etc.<br>
`CREATE ROLE git WITH LOGIN PASSWORD 'userpass';`<br>
`CREATE DATABASE gitdb WITH OWNER git TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';`<br>
### Step 3 - Configure Postgresql
Next, You need to switch to 'SCRAM-SHA-256' scheme from md5 encryption scheme for better security. If you want to connect to PostgreSQL remotely, then you need to allow your IP address in the PostgreSQL configuration file.<br>
[/etc/postgresql/versionNum/main/postgresql.conf](./resources/postgresql.conf)<br>
Next, change the following variables as per your requirement:<br>
`listen_addresses = 'localhost, IF_REMOTEIP'`<br>
`password_encryption = scram-sha-256`<br>
`sudo systemctl restart postgresql`<br>
### Step 4 - Configure Access
At this point, your PostgreSQL setup and ready for your app user, verify authentication settings in /etc/postgresql/14/main/pg_hba.conf file.
PostgreSQL accepts all local connections by defaults.<br>
[/etc/postgresql/versionNum/main/pg_hba.conf](./resources/pg_hba.conf)<br>
![Example](./resources/Example.webp)<br>

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

View File

@ -0,0 +1,103 @@
# PostgreSQL Client Authentication Configuration File
# ===================================================
#
# Refer to the "Client Authentication" section in the PostgreSQL
# documentation for a complete description of this file. A short
# synopsis follows.
#
# This file controls: which hosts are allowed to connect, how clients
# are authenticated, which PostgreSQL user names they can use, which
# databases they can access. Records take one of these forms:
#
# local DATABASE USER METHOD [OPTIONS]
# host DATABASE USER ADDRESS METHOD [OPTIONS]
# hostssl DATABASE USER ADDRESS METHOD [OPTIONS]
# hostnossl DATABASE USER ADDRESS METHOD [OPTIONS]
# hostgssenc DATABASE USER ADDRESS METHOD [OPTIONS]
# hostnogssenc DATABASE USER ADDRESS METHOD [OPTIONS]
#
# (The uppercase items must be replaced by actual values.)
#
# The first field is the connection type: "local" is a Unix-domain
# socket, "host" is either a plain or SSL-encrypted TCP/IP socket,
# "hostssl" is an SSL-encrypted TCP/IP socket, and "hostnossl" is a
# non-SSL TCP/IP socket. Similarly, "hostgssenc" uses a
# GSSAPI-encrypted TCP/IP socket, while "hostnogssenc" uses a
# non-GSSAPI socket.
#
# DATABASE can be "all", "sameuser", "samerole", "replication", a
# database name, or a comma-separated list thereof. The "all"
# keyword does not match "replication". Access to replication
# must be enabled in a separate record (see example below).
#
# USER can be "all", a user name, a group name prefixed with "+", or a
# comma-separated list thereof. In both the DATABASE and USER fields
# you can also write a file name prefixed with "@" to include names
# from a separate file.
#
# ADDRESS specifies the set of hosts the record matches. It can be a
# host name, or it is made up of an IP address and a CIDR mask that is
# an integer (between 0 and 32 (IPv4) or 128 (IPv6) inclusive) that
# specifies the number of significant bits in the mask. A host name
# that starts with a dot (.) matches a suffix of the actual host name.
# Alternatively, you can write an IP address and netmask in separate
# columns to specify the set of hosts. Instead of a CIDR-address, you
# can write "samehost" to match any of the server's own IP addresses,
# or "samenet" to match any address in any subnet that the server is
# directly connected to.
#
# METHOD can be "trust", "reject", "md5", "password", "scram-sha-256",
# "gss", "sspi", "ident", "peer", "pam", "ldap", "radius" or "cert".
# Note that "password" sends passwords in clear text; "md5" or
# "scram-sha-256" are preferred since they send encrypted passwords.
#
# OPTIONS are a set of options for the authentication in the format
# NAME=VALUE. The available options depend on the different
# authentication methods -- refer to the "Client Authentication"
# section in the documentation for a list of which options are
# available for which authentication methods.
#
# Database and user names containing spaces, commas, quotes and other
# special characters must be quoted. Quoting one of the keywords
# "all", "sameuser", "samerole" or "replication" makes the name lose
# its special character, and just match a database or username with
# that name.
#
# This file is read on server startup and when the server receives a
# SIGHUP signal. If you edit the file on a running system, you have to
# SIGHUP the server for the changes to take effect, run "pg_ctl reload",
# or execute "SELECT pg_reload_conf()".
#
# Put your actual configuration here
# ----------------------------------
#
# If you want to allow non-local connections, you need to add more
# "host" records. In that case you will also need to make PostgreSQL
# listen on a non-local interface via the listen_addresses
# configuration parameter, or via the -i or -h command line switches.
# DO NOT DISABLE!
# If you change this first entry you will need to make sure that the
# database superuser can access the database using some other method.
# Noninteractive access to all databases is required during automatic
# maintenance (custom daily cronjobs, replication, and similar tasks).
#
# Database administrative login by Unix domain socket
local all postgres peer
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all peer
host replication all 127.0.0.1/32 md5
host replication all ::1/128 md5

View File

@ -0,0 +1,782 @@
# -----------------------------
# PostgreSQL configuration file
# -----------------------------
#
# This file consists of lines of the form:
#
# name = value
#
# (The "=" is optional.) Whitespace may be used. Comments are introduced with
# "#" anywhere on a line. The complete list of parameter names and allowed
# values can be found in the PostgreSQL documentation.
#
# The commented-out settings shown in this file represent the default values.
# Re-commenting a setting is NOT sufficient to revert it to the default value;
# you need to reload the server.
#
# This file is read on server startup and when the server receives a SIGHUP
# signal. If you edit the file on a running system, you have to SIGHUP the
# server for the changes to take effect, run "pg_ctl reload", or execute
# "SELECT pg_reload_conf()". Some parameters, which are marked below,
# require a server shutdown and restart to take effect.
#
# Any parameter can also be given as a command-line option to the server, e.g.,
# "postgres -c log_connections=on". Some parameters can be changed at run time
# with the "SET" SQL command.
#
# Memory units: B = bytes Time units: us = microseconds
# kB = kilobytes ms = milliseconds
# MB = megabytes s = seconds
# GB = gigabytes min = minutes
# TB = terabytes h = hours
# d = days
#------------------------------------------------------------------------------
# FILE LOCATIONS
#------------------------------------------------------------------------------
# The default values of these variables are driven from the -D command-line
# option or PGDATA environment variable, represented here as ConfigDir.
data_directory = '/var/lib/postgresql/13/main' # use data in another directory
# (change requires restart)
hba_file = '/etc/postgresql/13/main/pg_hba.conf' # host-based authentication file
# (change requires restart)
ident_file = '/etc/postgresql/13/main/pg_ident.conf' # ident configuration file
# (change requires restart)
# If external_pid_file is not explicitly set, no extra PID file is written.
external_pid_file = '/var/run/postgresql/13-main.pid' # write an extra PID file
# (change requires restart)
#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------
# - Connection Settings -
#listen_addresses = 'localhost' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
# (change requires restart)
port = 5432 # (change requires restart)
max_connections = 100 # (change requires restart)
#superuser_reserved_connections = 3 # (change requires restart)
unix_socket_directories = '/var/run/postgresql' # comma-separated list of directories
# (change requires restart)
#unix_socket_group = '' # (change requires restart)
#unix_socket_permissions = 0777 # begin with 0 to use octal notation
# (change requires restart)
#bonjour = off # advertise server via Bonjour
# (change requires restart)
#bonjour_name = '' # defaults to the computer name
# (change requires restart)
# - TCP settings -
# see "man tcp" for details
#tcp_keepalives_idle = 0 # TCP_KEEPIDLE, in seconds;
# 0 selects the system default
#tcp_keepalives_interval = 0 # TCP_KEEPINTVL, in seconds;
# 0 selects the system default
#tcp_keepalives_count = 0 # TCP_KEEPCNT;
# 0 selects the system default
#tcp_user_timeout = 0 # TCP_USER_TIMEOUT, in milliseconds;
# 0 selects the system default
# - Authentication -
#authentication_timeout = 1min # 1s-600s
#password_encryption = md5 # md5 or scram-sha-256
#db_user_namespace = off
# GSSAPI using Kerberos
#krb_server_keyfile = 'FILE:${sysconfdir}/krb5.keytab'
#krb_caseins_users = off
# - SSL -
ssl = on
#ssl_ca_file = ''
ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem'
#ssl_crl_file = ''
ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'
#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
#ssl_prefer_server_ciphers = on
#ssl_ecdh_curve = 'prime256v1'
#ssl_min_protocol_version = 'TLSv1.2'
#ssl_max_protocol_version = ''
#ssl_dh_params_file = ''
#ssl_passphrase_command = ''
#ssl_passphrase_command_supports_reload = off
#------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------
# - Memory -
shared_buffers = 128MB # min 128kB
# (change requires restart)
#huge_pages = try # on, off, or try
# (change requires restart)
#temp_buffers = 8MB # min 800kB
#max_prepared_transactions = 0 # zero disables the feature
# (change requires restart)
# Caution: it is not advisable to set max_prepared_transactions nonzero unless
# you actively intend to use prepared transactions.
#work_mem = 4MB # min 64kB
#hash_mem_multiplier = 1.0 # 1-1000.0 multiplier on hash table work_mem
#maintenance_work_mem = 64MB # min 1MB
#autovacuum_work_mem = -1 # min 1MB, or -1 to use maintenance_work_mem
#logical_decoding_work_mem = 64MB # min 64kB
#max_stack_depth = 2MB # min 100kB
#shared_memory_type = mmap # the default is the first option
# supported by the operating system:
# mmap
# sysv
# windows
# (change requires restart)
dynamic_shared_memory_type = posix # the default is the first option
# supported by the operating system:
# posix
# sysv
# windows
# mmap
# (change requires restart)
# - Disk -
#temp_file_limit = -1 # limits per-process temp file space
# in kilobytes, or -1 for no limit
# - Kernel Resources -
#max_files_per_process = 1000 # min 64
# (change requires restart)
# - Cost-Based Vacuum Delay -
#vacuum_cost_delay = 0 # 0-100 milliseconds (0 disables)
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 1-10000 credits
# - Background Writer -
#bgwriter_delay = 200ms # 10-10000ms between rounds
#bgwriter_lru_maxpages = 100 # max buffers written/round, 0 disables
#bgwriter_lru_multiplier = 2.0 # 0-10.0 multiplier on buffers scanned/round
#bgwriter_flush_after = 512kB # measured in pages, 0 disables
# - Asynchronous Behavior -
#effective_io_concurrency = 1 # 1-1000; 0 disables prefetching
#maintenance_io_concurrency = 10 # 1-1000; 0 disables prefetching
#max_worker_processes = 8 # (change requires restart)
#max_parallel_maintenance_workers = 2 # taken from max_parallel_workers
#max_parallel_workers_per_gather = 2 # taken from max_parallel_workers
#parallel_leader_participation = on
#max_parallel_workers = 8 # maximum number of max_worker_processes that
# can be used in parallel operations
#old_snapshot_threshold = -1 # 1min-60d; -1 disables; 0 is immediate
# (change requires restart)
#backend_flush_after = 0 # measured in pages, 0 disables
#------------------------------------------------------------------------------
# WRITE-AHEAD LOG
#------------------------------------------------------------------------------
# - Settings -
#wal_level = replica # minimal, replica, or logical
# (change requires restart)
#fsync = on # flush data to disk for crash safety
# (turning this off can cause
# unrecoverable data corruption)
#synchronous_commit = on # synchronization level;
# off, local, remote_write, remote_apply, or on
#wal_sync_method = fsync # the default is the first option
# supported by the operating system:
# open_datasync
# fdatasync (default on Linux and FreeBSD)
# fsync
# fsync_writethrough
# open_sync
#full_page_writes = on # recover from partial page writes
#wal_compression = off # enable compression of full-page writes
#wal_log_hints = off # also do full page writes of non-critical updates
# (change requires restart)
#wal_init_zero = on # zero-fill new WAL files
#wal_recycle = on # recycle WAL files
#wal_buffers = -1 # min 32kB, -1 sets based on shared_buffers
# (change requires restart)
#wal_writer_delay = 200ms # 1-10000 milliseconds
#wal_writer_flush_after = 1MB # measured in pages, 0 disables
#wal_skip_threshold = 2MB
#commit_delay = 0 # range 0-100000, in microseconds
#commit_siblings = 5 # range 1-1000
# - Checkpoints -
#checkpoint_timeout = 5min # range 30s-1d
max_wal_size = 1GB
min_wal_size = 80MB
#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
#checkpoint_flush_after = 256kB # measured in pages, 0 disables
#checkpoint_warning = 30s # 0 disables
# - Archiving -
#archive_mode = off # enables archiving; off, on, or always
# (change requires restart)
#archive_command = '' # command to use to archive a logfile segment
# placeholders: %p = path of file to archive
# %f = file name only
# e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
#archive_timeout = 0 # force a logfile segment switch after this
# number of seconds; 0 disables
# - Archive Recovery -
# These are only used in recovery mode.
#restore_command = '' # command to use to restore an archived logfile segment
# placeholders: %p = path of file to restore
# %f = file name only
# e.g. 'cp /mnt/server/archivedir/%f %p'
# (change requires restart)
#archive_cleanup_command = '' # command to execute at every restartpoint
#recovery_end_command = '' # command to execute at completion of recovery
# - Recovery Target -
# Set these only when performing a targeted recovery.
#recovery_target = '' # 'immediate' to end recovery as soon as a
# consistent state is reached
# (change requires restart)
#recovery_target_name = '' # the named restore point to which recovery will proceed
# (change requires restart)
#recovery_target_time = '' # the time stamp up to which recovery will proceed
# (change requires restart)
#recovery_target_xid = '' # the transaction ID up to which recovery will proceed
# (change requires restart)
#recovery_target_lsn = '' # the WAL LSN up to which recovery will proceed
# (change requires restart)
#recovery_target_inclusive = on # Specifies whether to stop:
# just after the specified recovery target (on)
# just before the recovery target (off)
# (change requires restart)
#recovery_target_timeline = 'latest' # 'current', 'latest', or timeline ID
# (change requires restart)
#recovery_target_action = 'pause' # 'pause', 'promote', 'shutdown'
# (change requires restart)
#------------------------------------------------------------------------------
# REPLICATION
#------------------------------------------------------------------------------
# - Sending Servers -
# Set these on the master and on any standby that will send replication data.
#max_wal_senders = 10 # max number of walsender processes
# (change requires restart)
#wal_keep_size = 0 # in megabytes; 0 disables
#max_slot_wal_keep_size = -1 # in megabytes; -1 disables
#wal_sender_timeout = 60s # in milliseconds; 0 disables
#max_replication_slots = 10 # max number of replication slots
# (change requires restart)
#track_commit_timestamp = off # collect timestamp of transaction commit
# (change requires restart)
# - Master Server -
# These settings are ignored on a standby server.
#synchronous_standby_names = '' # standby servers that provide sync rep
# method to choose sync standbys, number of sync standbys,
# and comma-separated list of application_name
# from standby(s); '*' = all
#vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed
# - Standby Servers -
# These settings are ignored on a master server.
#primary_conninfo = '' # connection string to sending server
#primary_slot_name = '' # replication slot on sending server
#promote_trigger_file = '' # file name whose presence ends recovery
#hot_standby = on # "off" disallows queries during recovery
# (change requires restart)
#max_standby_archive_delay = 30s # max delay before canceling queries
# when reading WAL from archive;
# -1 allows indefinite delay
#max_standby_streaming_delay = 30s # max delay before canceling queries
# when reading streaming WAL;
# -1 allows indefinite delay
#wal_receiver_create_temp_slot = off # create temp slot if primary_slot_name
# is not set
#wal_receiver_status_interval = 10s # send replies at least this often
# 0 disables
#hot_standby_feedback = off # send info from standby to prevent
# query conflicts
#wal_receiver_timeout = 60s # time that receiver waits for
# communication from master
# in milliseconds; 0 disables
#wal_retrieve_retry_interval = 5s # time to wait before retrying to
# retrieve WAL after a failed attempt
#recovery_min_apply_delay = 0 # minimum delay for applying changes during recovery
# - Subscribers -
# These settings are ignored on a publisher.
#max_logical_replication_workers = 4 # taken from max_worker_processes
# (change requires restart)
#max_sync_workers_per_subscription = 2 # taken from max_logical_replication_workers
#------------------------------------------------------------------------------
# QUERY TUNING
#------------------------------------------------------------------------------
# - Planner Method Configuration -
#enable_bitmapscan = on
#enable_hashagg = on
#enable_hashjoin = on
#enable_indexscan = on
#enable_indexonlyscan = on
#enable_material = on
#enable_mergejoin = on
#enable_nestloop = on
#enable_parallel_append = on
#enable_seqscan = on
#enable_sort = on
#enable_incremental_sort = on
#enable_tidscan = on
#enable_partitionwise_join = off
#enable_partitionwise_aggregate = off
#enable_parallel_hash = on
#enable_partition_pruning = on
# - Planner Cost Constants -
#seq_page_cost = 1.0 # measured on an arbitrary scale
#random_page_cost = 4.0 # same scale as above
#cpu_tuple_cost = 0.01 # same scale as above
#cpu_index_tuple_cost = 0.005 # same scale as above
#cpu_operator_cost = 0.0025 # same scale as above
#parallel_tuple_cost = 0.1 # same scale as above
#parallel_setup_cost = 1000.0 # same scale as above
#jit_above_cost = 100000 # perform JIT compilation if available
# and query more expensive than this;
# -1 disables
#jit_inline_above_cost = 500000 # inline small functions if query is
# more expensive than this; -1 disables
#jit_optimize_above_cost = 500000 # use expensive JIT optimizations if
# query is more expensive than this;
# -1 disables
#min_parallel_table_scan_size = 8MB
#min_parallel_index_scan_size = 512kB
#effective_cache_size = 4GB
# - Genetic Query Optimizer -
#geqo = on
#geqo_threshold = 12
#geqo_effort = 5 # range 1-10
#geqo_pool_size = 0 # selects default based on effort
#geqo_generations = 0 # selects default based on effort
#geqo_selection_bias = 2.0 # range 1.5-2.0
#geqo_seed = 0.0 # range 0.0-1.0
# - Other Planner Options -
#default_statistics_target = 100 # range 1-10000
#constraint_exclusion = partition # on, off, or partition
#cursor_tuple_fraction = 0.1 # range 0.0-1.0
#from_collapse_limit = 8
#join_collapse_limit = 8 # 1 disables collapsing of explicit
# JOIN clauses
#force_parallel_mode = off
#jit = on # allow JIT compilation
#plan_cache_mode = auto # auto, force_generic_plan or
# force_custom_plan
#------------------------------------------------------------------------------
# REPORTING AND LOGGING
#------------------------------------------------------------------------------
# - Where to Log -
#log_destination = 'stderr' # Valid values are combinations of
# stderr, csvlog, syslog, and eventlog,
# depending on platform. csvlog
# requires logging_collector to be on.
# This is used when logging to stderr:
#logging_collector = off # Enable capturing of stderr and csvlog
# into log files. Required to be on for
# csvlogs.
# (change requires restart)
# These are only used if logging_collector is on:
#log_directory = 'log' # directory where log files are written,
# can be absolute or relative to PGDATA
#log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern,
# can include strftime() escapes
#log_file_mode = 0600 # creation mode for log files,
# begin with 0 to use octal notation
#log_truncate_on_rotation = off # If on, an existing log file with the
# same name as the new log file will be
# truncated rather than appended to.
# But such truncation only occurs on
# time-driven rotation, not on restarts
# or size-driven rotation. Default is
# off, meaning append to existing files
# in all cases.
#log_rotation_age = 1d # Automatic rotation of logfiles will
# happen after that time. 0 disables.
#log_rotation_size = 10MB # Automatic rotation of logfiles will
# happen after that much log output.
# 0 disables.
# These are relevant when logging to syslog:
#syslog_facility = 'LOCAL0'
#syslog_ident = 'postgres'
#syslog_sequence_numbers = on
#syslog_split_messages = on
# This is only relevant when logging to eventlog (win32):
# (change requires restart)
#event_source = 'PostgreSQL'
# - When to Log -
#log_min_messages = warning # values in order of decreasing detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# info
# notice
# warning
# error
# log
# fatal
# panic
#log_min_error_statement = error # values in order of decreasing detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# info
# notice
# warning
# error
# log
# fatal
# panic (effectively off)
#log_min_duration_statement = -1 # -1 is disabled, 0 logs all statements
# and their durations, > 0 logs only
# statements running at least this number
# of milliseconds
#log_min_duration_sample = -1 # -1 is disabled, 0 logs a sample of statements
# and their durations, > 0 logs only a sample of
# statements running at least this number
# of milliseconds;
# sample fraction is determined by log_statement_sample_rate
#log_statement_sample_rate = 1.0 # fraction of logged statements exceeding
# log_min_duration_sample to be logged;
# 1.0 logs all such statements, 0.0 never logs
#log_transaction_sample_rate = 0.0 # fraction of transactions whose statements
# are logged regardless of their duration; 1.0 logs all
# statements from all transactions, 0.0 never logs
# - What to Log -
#debug_print_parse = off
#debug_print_rewritten = off
#debug_print_plan = off
#debug_pretty_print = on
#log_checkpoints = off
#log_connections = off
#log_disconnections = off
#log_duration = off
#log_error_verbosity = default # terse, default, or verbose messages
#log_hostname = off
log_line_prefix = '%m [%p] %q%u@%d ' # special values:
# %a = application name
# %u = user name
# %d = database name
# %r = remote host and port
# %h = remote host
# %b = backend type
# %p = process ID
# %t = timestamp without milliseconds
# %m = timestamp with milliseconds
# %n = timestamp with milliseconds (as a Unix epoch)
# %i = command tag
# %e = SQL state
# %c = session ID
# %l = session line number
# %s = session start timestamp
# %v = virtual transaction ID
# %x = transaction ID (0 if none)
# %q = stop here in non-session
# processes
# %% = '%'
# e.g. '<%u%%%d> '
#log_lock_waits = off # log lock waits >= deadlock_timeout
#log_parameter_max_length = -1 # when logging statements, limit logged
# bind-parameter values to N bytes;
# -1 means print in full, 0 disables
#log_parameter_max_length_on_error = 0 # when logging an error, limit logged
# bind-parameter values to N bytes;
# -1 means print in full, 0 disables
#log_statement = 'none' # none, ddl, mod, all
#log_replication_commands = off
#log_temp_files = -1 # log temporary files equal or larger
# than the specified size in kilobytes;
# -1 disables, 0 logs all temp files
log_timezone = 'Etc/UTC'
#------------------------------------------------------------------------------
# PROCESS TITLE
#------------------------------------------------------------------------------
cluster_name = '13/main' # added to process titles if nonempty
# (change requires restart)
#update_process_title = on
#------------------------------------------------------------------------------
# STATISTICS
#------------------------------------------------------------------------------
# - Query and Index Statistics Collector -
#track_activities = on
#track_counts = on
#track_io_timing = off
#track_functions = none # none, pl, all
#track_activity_query_size = 1024 # (change requires restart)
stats_temp_directory = '/var/run/postgresql/13-main.pg_stat_tmp'
# - Monitoring -
#log_parser_stats = off
#log_planner_stats = off
#log_executor_stats = off
#log_statement_stats = off
#------------------------------------------------------------------------------
# AUTOVACUUM
#------------------------------------------------------------------------------
#autovacuum = on # Enable autovacuum subprocess? 'on'
# requires track_counts to also be on.
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
# their durations, > 0 logs only
# actions running at least this number
# of milliseconds.
#autovacuum_max_workers = 3 # max number of autovacuum subprocesses
# (change requires restart)
#autovacuum_naptime = 1min # time between autovacuum runs
#autovacuum_vacuum_threshold = 50 # min number of row updates before
# vacuum
#autovacuum_vacuum_insert_threshold = 1000 # min number of row inserts
# before vacuum; -1 disables insert
# vacuums
#autovacuum_analyze_threshold = 50 # min number of row updates before
# analyze
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
#autovacuum_vacuum_insert_scale_factor = 0.2 # fraction of inserts over table
# size before insert vacuum
#autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
# (change requires restart)
#autovacuum_multixact_freeze_max_age = 400000000 # maximum multixact age
# before forced vacuum
# (change requires restart)
#autovacuum_vacuum_cost_delay = 2ms # default vacuum cost delay for
# autovacuum, in milliseconds;
# -1 means use vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
# autovacuum, -1 means use
# vacuum_cost_limit
#------------------------------------------------------------------------------
# CLIENT CONNECTION DEFAULTS
#------------------------------------------------------------------------------
# - Statement Behavior -
#client_min_messages = notice # values in order of decreasing detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# log
# notice
# warning
# error
#search_path = '"$user", public' # schema names
#row_security = on
#default_tablespace = '' # a tablespace name, '' uses the default
#temp_tablespaces = '' # a list of tablespace names, '' uses
# only default tablespace
#default_table_access_method = 'heap'
#check_function_bodies = on
#default_transaction_isolation = 'read committed'
#default_transaction_read_only = off
#default_transaction_deferrable = off
#session_replication_role = 'origin'
#statement_timeout = 0 # in milliseconds, 0 is disabled
#lock_timeout = 0 # in milliseconds, 0 is disabled
#idle_in_transaction_session_timeout = 0 # in milliseconds, 0 is disabled
#vacuum_freeze_min_age = 50000000
#vacuum_freeze_table_age = 150000000
#vacuum_multixact_freeze_min_age = 5000000
#vacuum_multixact_freeze_table_age = 150000000
#vacuum_cleanup_index_scale_factor = 0.1 # fraction of total number of tuples
# before index cleanup, 0 always performs
# index cleanup
#bytea_output = 'hex' # hex, escape
#xmlbinary = 'base64'
#xmloption = 'content'
#gin_fuzzy_search_limit = 0
#gin_pending_list_limit = 4MB
# - Locale and Formatting -
datestyle = 'iso, mdy'
#intervalstyle = 'postgres'
timezone = 'Etc/UTC'
#timezone_abbreviations = 'Default' # Select the set of available time zone
# abbreviations. Currently, there are
# Default
# Australia (historical usage)
# India
# You can create your own file in
# share/timezonesets/.
#extra_float_digits = 1 # min -15, max 3; any value >0 actually
# selects precise output mode
#client_encoding = sql_ascii # actually, defaults to database
# encoding
# These settings are initialized by initdb, but they can be changed.
lc_messages = 'en_US.UTF-8' # locale for system error message
# strings
lc_monetary = 'en_US.UTF-8' # locale for monetary formatting
lc_numeric = 'en_US.UTF-8' # locale for number formatting
lc_time = 'en_US.UTF-8' # locale for time formatting
# default configuration for text search
default_text_search_config = 'pg_catalog.english'
# - Shared Library Preloading -
#shared_preload_libraries = '' # (change requires restart)
#local_preload_libraries = ''
#session_preload_libraries = ''
#jit_provider = 'llvmjit' # JIT library to use
# - Other Defaults -
#dynamic_library_path = '$libdir'
#extension_destdir = '' # prepend path when loading extensions
# and shared objects (added by Debian)
#------------------------------------------------------------------------------
# LOCK MANAGEMENT
#------------------------------------------------------------------------------
#deadlock_timeout = 1s
#max_locks_per_transaction = 64 # min 10
# (change requires restart)
#max_pred_locks_per_transaction = 64 # min 10
# (change requires restart)
#max_pred_locks_per_relation = -2 # negative values mean
# (max_pred_locks_per_transaction
# / -max_pred_locks_per_relation) - 1
#max_pred_locks_per_page = 2 # min 0
#------------------------------------------------------------------------------
# VERSION AND PLATFORM COMPATIBILITY
#------------------------------------------------------------------------------
# - Previous PostgreSQL Versions -
#array_nulls = on
#backslash_quote = safe_encoding # on, off, or safe_encoding
#escape_string_warning = on
#lo_compat_privileges = off
#operator_precedence_warning = off
#quote_all_identifiers = off
#standard_conforming_strings = on
#synchronize_seqscans = on
# - Other Platforms and Clients -
#transform_null_equals = off
#------------------------------------------------------------------------------
# ERROR HANDLING
#------------------------------------------------------------------------------
#exit_on_error = off # terminate session on any error?
#restart_after_crash = on # reinitialize after backend crash?
#data_sync_retry = off # retry or panic on failure to fsync
# data?
# (change requires restart)
#------------------------------------------------------------------------------
# CONFIG FILE INCLUDES
#------------------------------------------------------------------------------
# These options allow settings to be loaded from files other than the
# default postgresql.conf. Note that these are directives, not variable
# assignments, so they can usefully be given more than once.
include_dir = 'conf.d' # include files ending in '.conf' from
# a directory, e.g., 'conf.d'
#include_if_exists = '...' # include file only if it exists
#include = '...' # include file
#------------------------------------------------------------------------------
# CUSTOMIZED OPTIONS
#------------------------------------------------------------------------------
# Add settings for extensions here