Chapter 5. Setting up and configuring NGINX

Procedure

1. Install the nginx package:

   # dnf install nginx

2. Open the ports on which NGINX should run its service in the firewall. For example, to open the default ports for HTTP (port 80) and HTTPS (port 443) in firewalld, enter:

   # firewall-cmd --permanent --add-port={80/tcp,443/tcp}
   # firewall-cmd --reload

3. Enable the nginx service to start automatically when the system boots:

   # systemctl enable nginx

4. Optional: Start the nginx service:

   # systemctl start nginx

   If you do not want to use the default configuration, skip this step, and configure NGINX before you start the service.

Verification

1. Verify the installation of the nginx package:

   # dnf list installed nginx

   Installed Packages
   nginx.x86_64    1:1.14.1-9.module+el8.0.0+4108+af250afe    @rhel-8-for-x86_64-appstream-rpms

2. Verify the allowed ports through the firewall on which NGINX should run its service:

   # firewall-cmd --list-ports

   80/tcp 443/tcp

3. Verify the nginx service is enabled:

   # systemctl is-enabled nginx

   enabled

Procedure

1. Edit the /etc/nginx/nginx.conf file:

   1. By default, the /etc/nginx/nginx.conf file already has a catch-all configuration. If you have deleted this part from the configuration, re-add the following server block to the http block in the /etc/nginx/nginx.conf file:

      server {
          listen       80 default_server;
          listen       [::]:80 default_server;
          server_name  _;
          root         /usr/share/nginx/html;
      }

      • The listen directive defines which IP address and ports the service listens. In this case, NGINX listens on port 80 on both all IPv4 and IPv6 addresses. The default_server parameter indicates that NGINX uses this server block as the default for requests matching the IP addresses and ports.
      • The server_name parameter defines the host names for which this server block is responsible. Setting server_name to _ configures NGINX to accept any hostname for this server block.
      • The root directive sets the path to the web content for this server block.

   2. Append a similar server block for the example.com domain to the http block:

      server {
          server_name  example.com;
          root         /var/www/example.com/;
          access_log   /var/log/nginx/example.com/access.log;
          error_log    /var/log/nginx/example.com/error.log;
      }

      • The access_log directive defines a separate access log file for this domain.
      • The error_log directive defines a separate error log file for this domain.

   3. Append a similar server block for the example.net domain to the http block:

      server {
          server_name  example.net;
          root         /var/www/example.net/;
          access_log   /var/log/nginx/example.net/access.log;
          error_log    /var/log/nginx/example.net/error.log;
      }

2. Create the main directories for both domains:

   # mkdir -p /var/www/example.com/
   # mkdir -p /var/www/example.net/

3. Set the httpd_sys_content_t context on both main directories:

   # semanage fcontext -a -t httpd_sys_content_t "/var/www/example.com(/.*)?"
   # restorecon -Rv /var/www/example.com/
   # semanage fcontext -a -t httpd_sys_content_t "/var/www/example.net(/.\*)?"
   # restorecon -Rv /var/www/example.net/

   These commands set the httpd_sys_content_t context on the /var/www/example.com/ and /var/www/example.net/ directories.

   Note that you must install the policycoreutils-python-utils package to run the restorecon commands.

4. Create the log directories for both domains:

   # mkdir /var/log/nginx/example.com/
   # mkdir /var/log/nginx/example.net/

5. Restart the nginx service:

   # systemctl restart nginx

Verification

1. Create a different example file in each virtual host’s document root:

   # echo "Content for example.com" > /var/www/example.com/index.html
   # echo "Content for example.net" > /var/www/example.net/index.html
   # echo "Catch All content" > /usr/share/nginx/html/index.html

2. Use a browser and connect to http://example.com. The web server shows the example content from the /var/www/example.com/index.html file.
3. Use a browser and connect to http://example.net. The web server shows the example content from the /var/www/example.net/index.html file.
4. Use a browser and connect to http://IP_address_of_the_server. The web server shows the example content from the /usr/share/nginx/html/index.html file.

Procedure

1. Edit the /etc/nginx/nginx.conf file, and add the following server block to the http block in the configuration:

   server {
       listen              443 ssl;
       server_name         example.com;
       root                /usr/share/nginx/html;
       ssl_certificate     /etc/pki/tls/certs/example.com.crt;
       ssl_certificate_key /etc/pki/tls/private/example.com.key;
   }

2. Optional: Starting from RHEL 9.3, you can use the ssl_pass_phrase_dialog directive to configure an external program that NGINX calls at startup for each encrypted private key. Add one of the following lines to the /etc/nginx/nginx.conf file:

   • To call an external program for each encrypted private key file, enter:

     ssl_pass_phrase_dialog exec:<path_to_program>;

     NGINX calls this program with the following two arguments:

     • The server name specified in the server_name setting.
     • One of the following algorithms: RSA, DSA, EC, DH, or UNK if NGINX cannot recognize a cryptographic algorithm.

   • If you want to manually enter a passphrase for each encrypted private key file, enter:

     ssl_pass_phrase_dialog builtin;

     This is the default behavior if ssl_pass_phrase_dialog is not configured.

     Note that the nginx service fails to start if you use this method but have at least one private key protected by a passphrase. In this case, use one of the other methods.

   • If you want systemd to prompt for the passphrase for each encrypted private key when you start the nginx service by using the systemctl utility, enter:

     ssl_pass_phrase_dialog exec:/usr/libexec/nginx-ssl-pass-dialog;

3. For security reasons, configure that only the root user can access the private key file:

   # chown root:root /etc/pki/tls/private/example.com.key
   # chmod 600 /etc/pki/tls/private/example.com.key

   Warning

   If unauthorized users have access to the private key, revoke the certificate, create a new private key, and request a new certificate. Otherwise, the TLS connection is no longer secure.

4. Restart the nginx service:

   # systemctl restart nginx

Procedure

1. Edit the /etc/nginx/nginx.conf file and add the following settings to the server block that should provide the reverse proxy:

   location /example {
       proxy_pass https://example.com;
   }

   The location block defines that NGINX passes all requests in the /example directory to https://example.com.

2. Set the httpd_can_network_connect SELinux boolean parameter to 1 to configure that SELinux allows NGINX to forward traffic:

   # setsebool -P httpd_can_network_connect 1

3. Restart the nginx service:

   # systemctl restart nginx

Procedure

1. Edit settings in the /etc/nginx/nginx.conf file:

   http {
       upstream backend {
           least_conn;
           server server1.example.com;
           server server2.example.com;
           server server3.example.com backup;
       }
   
       server {
           location / {
               proxy_pass http://backend;
           }
       }
   }

   The least_conn directive in the host group named backend defines that NGINX sends requests to server1.example.com or server2.example.com, depending on which host has the least number of active connections. NGINX uses server3.example.com only as a backup in case that the other two hosts are not available.

   With the proxy_pass directive set to http://backend, NGINX acts as a reverse proxy and uses the backend host group to distribute requests based on the settings of this group.

   Instead of the least_conn load balancing method, you can specify:

   • No method to use round robin and distribute requests evenly across servers.
   • ip_hash: Send requests from one client address to the same server based on a hash calculated from the first three octets of the IPv4 address or the whole IPv6 address of the client.
   • hash: Decide the server based on a user-defined key, which can be a string, a variable, or a combination of both. The consistent parameter configures that NGINX distributes requests across all servers based on the user-defined hashed key value.
   • random: Send requests to a randomly selected server.

2. Restart the nginx service:

   # systemctl restart nginx