loading...

Ubuntu Server 18.04 – Installing and configuring NGINX

Getting Started with the IIS Manager in IIS

Apache isn’t the only technology that is capable of allowing you to host web content on your server. NGINX also serves the same purpose and is gaining popularity quite rapidly. Although Apache is still the most common right now and is what I recommend for hosting sites, it’s a good idea to at least be familiar with NGINX and learn its basics.

Before we do so, I want to mention first that you can really only have one web server service running on a single web server. If you’ve been following along up to now, you currently have a functional Apache web server. If you were to also install NGINX, it probably wouldn’t start as the ports it wants to listen on (port 80 and/or 443) will already be in use. You can run both on a single server, but that’s outside the scope of this tutorial. Ideally, you’d want to use one or the other. Therefore, to continue with this section you’d either want to remove Apache or set up a separate web server for testing NGINX. I recommend the latter, because later on in this chapter we will take a look at hosting Nextcloud and we will be using Apache to do so. If you remove Apache now, you’d have to add it back in order to follow along in that section. Theoretically, you’d only have to stop the apache2 process before starting nginx, but the two resources sharing the same server has a lot of variables and may conflict.

To get started with NGINX, simply install it:

sudo apt install nginx

Just like with Apache, if we enter the IP address of our server in a browser, we’re presented with a sample page. This time, NGINX’s version instead of the one that ships with Apache. It certainly looks boring in comparison, but it works:

The nginx sample page

The default configuration files for nginx are stored in the /etc/nginx directory. Go ahead and peruse these files to get a general feel for how the configuration is presented. Similar to Apache, you also have a sites-enabled and sites-available directory here, which serve the same purpose.

Just as with Apache, the sites-available directory houses configuration files for sites that can be enabled, while the sites-enabled directory stores configuration files for sites that are enabled. Unlike Apache, though, we don’t have dedicated commands to enable these sites. We have to link them manually. Although we haven’t even looked at NGINX configuration files yet, let’s just assume that we have created the following configuration file:

/etc/nginx/sites-available/acmesales.com

To enable that site, we would need to create a symbolic link for it and store that link in the /etc/nginx/sites-enabled directory:

sudo ln -s /etc/nginx/sites-available/acmesales.com /etc/nginx/sites-enabled/acmesales.com

Then, we can reload nginx:

sudo systemctl reload nginx

As it stands right now, a site configuration file named default exists in /etc/nginx/sites-available and a symbolic link to it is already present in /etc/nginx/sites-enabled. If all we want to do is host a single site, we only need to replace the default content that NGINX serves which is located in the /var/www/html directory (the same as Apache) with the content for our site. After refreshing the page, we’re good to go.

In case we want to serve more than one site from one server, the default file is a great starting point for creating additional virtual hosts. We can start by copying it to a new name:

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/acmesales.com
Obviously, acmesales.com is an example, so feel free to name this whatever you wish.

Now, we can edit this file and change it to serve additional content. First of all, only one site can be referred to as a default site. A default site in NGINX is one that answers if none of the other sites match a request. Therefore, we want to remove both occurrences of default_server from our newly copied config. Change these lines:

listen 80 default_server;
listen [::]:80 default_server;

Change them to this:

listen 80;
listen [::]:80;

Next, we’ll need to adjust the server_name option to refer to the name of our new site. Add this line:

server_name acmesales.com www.acmesales.com;

Now, we’ll need to change the Document Root to the directory that will store the files for our new site. Find this line:

root /var/www/html;

And change it to this:

root /var/www/acmesales.com;

The final file should look like the following at this point:

server { 
        listen 80; 
        listen [::]:80; 
 
        root /var/www/acmesales.com; 
 
        index index.html index.htm index.nginx-debian.html; 
 
        server_name acmesales.com www.acmesales.com; 
 
        location / { 
                try_files $uri $uri/ =404; 
        } 
} 

You can probably see that the configuration format for NGINX configuration files is simpler than with Apache. I find this to be true, and I’ve noticed that sites I’ve configured with NGINX generally have fewer lines in their configuration files than Apache does.

At this point, assuming that you have the required content in /var/www/acmesales.com and have a proper configuration file, the new site should respond as soon as you reload nginx. But what about SSL? I recommend we always secure our websites, regardless of which solution we’re using to serve it. With NGINX, we can add that feature easily. The certificate files themselves are the same regardless of whether we’re using Apache or NGINX. If you haven’t already created your certificate files, refer back to the section in this chapter in which we did so. Assuming you already have certificate files, we just need to make additional changes to our configuration.

First, we change the first two lines to listen on port 443 with SSL instead of standard port 80:

listen 443 ssl; 
listen [::]:443 ssl; 

Next, we’ll add the following two lines before the location section:

ssl_certificate /etc/certs/cert.pem; 
ssl_certificate_key /etc/certs/cert.key; 
ssl_session_timeout 5m; 

For this to work, you’ll need to adjust the paths and the names of the cert files to make sure they match what you called them on your server. The entire file should look similar to the following at this point:

server { 
        listen 443 ssl; 
        listen [::]:443 ssl; 
 
        root /var/www/html; 
 
        index index.html index.htm index.nginx-debian.html; 
 
        server_name acmesales.com www.acmesales.com; 
 
         ssl_certificate /etc/certs/cert.pem; 
         ssl_certificate_key /etc/certs/cert.key; 
         ssl_session_timeout 5m; 
        location / { 
                try_files $uri $uri/ =404; 
        } 
} 

Finally, a potential problem is that users may access our site via port 80, instead of utilizing HTTPS. We can tell NGINX to forward these people to the secure version of our site automatically. To do that, we can edit the default configuration file (/etc/nginx/sites-available/default) and add the following line just after the two listen directives:

return 301 https://$host$request_uri; 

Now, anytime a user visits the HTTP version of our site, they’ll be redirected to the secure HTTPS version automatically.

Comments are closed.

loading...