Table des matières

nginx

nginx est un serveur Web (au même titre que Apache, Lighttpd, etc.), et proxy inverse.

Pour les systèmes Debian (et Ubuntu-like), la configuration du serveur est découpée entre plusieurs fichiers, au lieu du traditionnel nginx.conf.

Reportez-vous à la documentation de votre distribution, avant d'appliquer les modifications.

Configuration

Le fichier est décomposé en blocs, il s'agit de directives globales et particulières.

Traiter les journaux (erreur, accès)

Pour activer les journaux (erreur et accès).

[...]
error_log  /var/log/nginx/error.log;
#error_log  /var/log/nginx/error.log  notice;
#error_log  /var/log/nginx/error.log  info;
 
pid        /var/run/nginx.pid;
 
[...]
 
http {
[...]
     access_log  /var/log/nginx/access.log;
 
[...]
}

Lister le contenu d'un répertoire (autoindex)

Cela s'active avec la directive autoindex (la valeur est un booléen, on/off). Elle se définit dans un bloc location {}.

[...]
 
        location / {
             autoindex on;
             index  index.html index.htm;
        }
 
[...]

Avec cette option on peut également rajouter ces deux directives :

Ne pas afficher la version du serveur

La directive, qui prend en charge cette propriété s'appelle server_tokens (il s'agit d'un booléen). On peut la placer dans les blocs http {}, server {}, ou location {}.

[...]
 
http {
 
     server_tokens   off;
[...]
}

Accéder au serveur

Via le nom de domaine

Il faut utiliser la directive server_name dans le contexte d'un bloc server.

Il faut au préalable avoir défini un fichier de zone (faisant autorité) grâce à BIND, NSD, ou via le panel de votre bureau d'enregistrement de nom de domaine (registar).

On doit avoir quelque chose qui ressemble à ça (je ne mets pas le fichier au complet, juste les enregistrements A 1) et CNAME).

[...]

exemple.com.  IN              A              ip public du serveur
www           IN              CNAME          exemple.com.

Le principe c'est de faire correspondre un nom d'hôte à une adresse IP.

[...]
 
    server {
        server_name  exemple.com www.exemple.com;
        [...]
    }
[...]

Via une adresse IP

Si on n'a pas de nom de domaine, on accède au serveur par l'intermédiaire de son adresse IP.

On utilise dans ce cas la directive listen (toujours dans un contexte de type server).

[...]
 
    server {
        listen       10.0.2.1:80;
        [...]
    }
[...]

Dans ce cas précis j'indique l'adresse IP et le numéro de port.

Cas particulier des sous-domaines

Dans certains cas, on peut avoir besoin d'utiliser un sous domaine. Il faut définir une nouvelle entrée dans le fichier de zone.

[...]

exemple.com.  IN              A              ip public du serveur
blog          IN              A              exemple.com.
www           IN              CNAME          exemple.com.

J'ai défini un sous-domaine blog. Pour y avoir accès à travers mon navigateur, on doit définir un nouveau bloc server généralement avec un nouvelle directive root 2) (dans le contexte de http).

[...]
 
    server {
        server_name  exemple.com www.exemple.com;
        [...]
    }
 
    server {
        listen  80;
        server_name  blog.exemple.com;
        [...]
    }
[...]

Équivalent de la directive UserDir d'Apache

UserDir dans Apache (2.4).

Cela permet à un utilisateur de rendre accessible des pages, généralement placées dans le dossier public_html/.

Il faut utiliser une expression régulière, que l'on place dans un bloc location {}.

[...]
     server {
         [...]
 
         # users directory support
         location ~ ^/~(.+?)(/.*)?$ {
             alias   /home/$1/public_html$2;
             autoindex   on;
         }
     }
[...]

favicon.ico

Pour éviter d'enregistrer l'erreur 404 dans le fichier access.log pour le favicon, on rajoute ces lignes quelque part dans le bloc server { }.

[...]
     server {
         location = /favicon.ico { access_log off; log_not_found off; }
     }
[...]

Bloquer l'accès aux fichiers cachés

Les fichiers cachés sont ceux commençant par “.”.

On rajoute cette ligne quelque part dans le bloc server { }.

[...]
     server {
        location ~ /\. { access_log off; log_not_found off; deny all; }
     }
[...]

Support de PHP

nginx prend en charge le langage PHP, via le protocole FastCGI. Généralement avec ce langage on installe le module FastCGI Process Manager (FPM).

On utilise un bloc location {} pour ça :

[...]
     server {
         [...]
         # pass the PHP scripts to FastCGI server using socket Unix
         #
         location ~ \.php$ {
             root   /srv/www/htdocs/;
             try_files $uri =404;
             fastcgi_pass   unix:/var/run/php5-fpm.sock;
             fastcgi_index  index.php;
             fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
             include        fastcgi_params;
         }
         [...]
     }
[...]

Dans cet exemple, on utilise un socket unix, mais on pourrait également recourir à un socket TCP/IP. La valeur de la directive fastcgi_pass dans ce cas préciser sera un nom de domaine (ou une adresse IP) et un port (autre que celui utilisé dans le bloc server {}).

Support de PHP pour la directive UserDir

Il faut respecter l'ordre des différents blocs location, sinon on obtient des erreurs.

[...]
     server {
         [...]
         location ~ ^/~(.+?)(/.*\.php)$ {
             alias /home/$1/public_html$2;
             autoindex on;
             include fastcgi_params;
             fastcgi_pass unix:/var/run/php5-fpm.sock;
             fastcgi_index index.php;
             fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
         }
 
         location ~ \.php$ {
             root   /srv/www/htdocs/;
             try_files $uri =404;
             fastcgi_pass   unix:/var/run/php5-fpm.sock;
             fastcgi_index  index.php;
             fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
             include        fastcgi_params;
         }
 
         # users directory support
         #
         location ~ ^/~(.+?)(/.*)?$ {
             alias   /home/$1/public_html$2;
             autoindex   on;
             index  index.html index.php;
         }
         [...]
     }
[...]

Basic authentication

Le mot de passe sera transmis en clair.

Basic authentication ou authentification HTTP RFC 2617 permet de s'identifier auprès du serveur, pour accéder à une ressource restreinte. Le fonctionnement général est très bien décrit sur la page Wikipédia.

Il faut créer un fichier qui va contenir les identifiant (login et hash du mot de passe).

Génération du hash du mot de passe

On va utiliser la boîte à outil OpenSSL (ou LibreSSL). L'algorithme sera apr1.

La commande est la suivante :

openssl passwd -apr1 -salt ...1... ...2...

  1. correspond au salage
  2. correspond au mot de passe

Le « sel » est une chaîne de caractères aléatoires, afin de renforcer la sécurité.

openssl rand -base64 6

Une chaîne de 8 caractères est ainsi générée. On peut combiner les deux commandes (c'est mieux).

openssl passwd -apr1 -salt `openssl rand -base64 6` ...2...

On copie le résultat dans un fichier (par exemple passwd). Il doit être sous cette forme :

# Comment
login1:password
login2:password2
[...]
loginN:passwordN

<note important>C'est un fichier sensible, il faut donc restreindre certains droits.

chmod o-r passwd
chmod u-w passwd
chown root:nginx passwd

Explication : Personne ne peut l'éditer, root et les membres du groupe nginx ont uniquement le droit de le lire.</note>

Règle dans nginx.conf

À placer dans un bloc location {}.

[...]
         # HTTP Basic Authentication
         #
         location /secret/ {
             auth_basic "Chouffe";
             auth_basic_user_file /etc/nginx/passwd;
         }
[...]

La directive auth_basic_user_file contient le chemin (complet) vers le fichier où sont stockés les identifiants.

auth_basic définit le domaine de protection.

1)
Pour les adresses IPv6 on emploie plutôt AAAA.
2)
L'équivalent de DocumentRoot sous Apache.