Skip to content

Latest commit

 

History

History
187 lines (132 loc) · 6.24 KB

4.web_server.md

File metadata and controls

187 lines (132 loc) · 6.24 KB
Raw

4. Web Server

If you go to http://<host> in a browser, you won't be able to see anything. The reasons is your server does not know how to respond to HTTP requests and terminate them. To handle HTTP requests, we need a Web Server.

A Web Server is a program (in case you did not understand so far, everything on a server is more or less a program) that can satisfy a Web request. It implements the HTTP protocol.

⚠️ warning

  • frequent confusion: a "protocol" is a standard, not a program

The most famous Web Server is probably apache2 (you may have seen before files like .htpasswd or .htaccess which are configuration file for Apache).

Other famous Web Servers are:

  • nginx: a more performant variant of Apache
  • httpd: the oldest web server program
  • caddy: a Web Server with an extremely easy configuration and SSL automation

In this chapter, we will install and configure nginx.

⁉️ why

  • apache is slower and older than nginx, and nginx can do many things apache cannot
  • httpd is just not used by the industry anymore
  • caddy is too easy (also, it is not always necessary to have SSL certificates - like when developing locally)

4.1 Installation

apt install nginx

If you open your favorite browser and input the IP of your server, you should see a Welcome to Nginx message.

4.2 Configuration

Configuration files for nginx are located in etc/nginx. The following directories/files are especially interesting for us:

  • nginx.conf the default configuration for all virtualhosts
  • sites-available/ list of all websites/virtualhosts on the current server
  • sites-enabled/ list of all running* websites/virtualhosts on the current server

* after nginx is reloaded, cf below.

4.2.1 Removing the default site

The site located in sites-enabled/default is the default one provided by nginx. We can safely remove it with:

rm /etc/nginx/sites-enabled/default

ℹ️ information

the default file is a symlink to a file located in /etc/nginx/sites-available. So deleting the symlink is safe.

To restart nginx with the latest changes, you can:

systemctl restart nginx

http://<host> should be unavailable after this operation.

4.2.2 Duplicating the default site and enabling it

Let's duplicate the default site configuration:

cp /etc/nginx/sites-available/default /etc/nginx/sites-available/<something>

And let's put it in the "enabled" folder by symlinking it:

ln -s /etc/nginx/sites-available/<something> /etc/nginx/sites-enabled/

Restart the server, and we should be back to where we started and the website should be available again.

⁉️ why

It can be disturbing to understand why we did not use the default site by default and why we needed all these manipulations. There are multiple reasons:

  • so you can understand how sites-available and sites-enabled work
  • default is a "default", not the website you want to deploy
  • if you screw up with the config of <something> (and it will happen), you can easily restore the default site configuration
  • I personally recommend to name your sites files based on their domain name

4.2.3 Site configuration's first glance

Let's have a look at the site configuration file:

cat /etc/nginx/sites-enabled/<something>
  • server {} delimits a "virtualhost" (or server)
  • listen tell nginx what ports it should listen to
  • default_server indicates that in case of multiple virtualhosts, this one should be used when accessing the server via a domain name not listed in the config
  • root indicates which folder to serve on your server
  • index define files that will be used as an index (accessing http://<host>/tada will try to get <root>/tada/index.html for example
  • server_name is useful to declare which domain name this site will be using. This is extremely useful in case you have multiple websites with different domains on the same server. _ is a "catch all".
  • location {} indicates a sub-block and different rules may be applied by sub-block
  • try_files is to indicate which files nginx should try to serve: try_files $uri $uri.html $uri/ =404; sill for example try to serve the file $uri, or the filename + $uri.html, or the subdirectory $uri, or will return a 404.

📖 Resources

4.2.4 Editing the site configuration

Let's edit this file in order to adapt it to serve a static website:

nano /etc/nginx/sites-enabled/<something>

In location {}, let's add

# Media: images, icons, video, audio, HTC
location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|mp4|ogg|ogv|webm|htc)$ {
  add_header Cache-Control "max-age=2592000";
  access_log off;
}

# CSS and Javascript
location ~* \.(?:css|js)$ {
  add_header Cache-Control "max-age=31536000";
  access_log off;
}

This will tell the browsers to cache CSS, JS and other assets.

Also, let's enable gzip by adding:

gzip on;
gzip_vary on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
gzip_disable "MSIE [1-6]\.";

in the server {} block.

There are a lot of other rules we could use (cf. the docs), but we'll keep it simple for now.

4.3 Writing your own website files

By default, on most servers, the website folders are located in /var/www/html or /usr/share/nginx. Let's go to this folder and create a basic html file:

nano /var/www/html/test.html

ℹ️ information

you can also use touch to create empty files

And place this little HTML page in it:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Document</title>
  </head>

  <body>
    <h1>Hello World!</h1>
  </body>
</html>

After saving your file, you should be able to access http://<host>/test.html and see the content of the page.

We can now create files and access them via the browser, let's enable HTTP2 and SSL certificates!