The docs block is written, but nginx does not read it. In this step you enable the site.
The main file, /etc/nginx/nginx.conf, pulls sites in with the line include /etc/nginx/sites-enabled/*;. On Ubuntu the site files live in /etc/nginx/sites-available/, and sites-enabled/ holds symbolic links to the ones that are enabled. To disable a site, delete the link: the file stays where it is.
nginx -T shows which names nginx actually reads: it checks the configuration and prints all of it, every included file too.
The only site name in the output is portal.lab.test; the lines with # are comments from nginx.conf. The docs file sits in sites-available, and sites-enabled has no link to it.
You created a link to the docs file in sites-enabled and ran curl http://docs.lab.test/ right away. What will it print?
-
A new link does not stop nginx: it keeps working with the old configuration and answers with the portal.
-
nginx -Twill see the link: it reads the files from disk. The running nginx reads it onreloadand answers the old way, with the portal, until then.
The running nginx read its configuration at startup and does not see the new link until it gets a reload. Until then docs.lab.test goes to the default server, the portal.
You know the order for applying a change from the lesson on service failures. First sudo nginx -t: if a file has an error, reload will refuse and nginx keeps its old configuration. Then sudo systemctl reload nginx — nginx rereads the files without dropping open connections. Last, a request to the site by name: a clean nginx -t only speaks about the syntax of the files, and only curl shows which block answers the site name.
Give the docs their name back
Make http://docs.lab.test/ open the docs. The portal must answer as before; leave the files in /srv/www alone.
Goals · 0 of 2
- Open the docs by their name not done yet
- Keep the portal's answer not done yet