Cours Ubuntu 26.04 / Configurer les sites Nginx avec sites-available et sites-enabled

Sur Ubuntu, gérez les sites Nginx en vérifiant les fichiers réellement inclus, puis en activant une configuration de sites-available par un lien dans sites-enabled. Ce laboratoire crée deux sites sur 127.0.0.1:8080 pour vérifier leur sélection par le nom Host ; cette écoute locale ne rend pas automatiquement les autres sites du serveur inaccessibles depuis le réseau.

Préparer une VM dédiée et inspecter les fichiers inclus

Utilisez une VM de laboratoire et préparez les règles UFW et l’accès d’administration avant l’installation, ou un réseau externe isolé. Le paquet Ubuntu peut démarrer Nginx et son site par défaut sur 80 ; n’attendez pas la fin de l’exercice pour examiner cette exposition.

sudo apt update
sudo apt install nginx curl
sudo nginx -t
sudo nginx -T
sudo ss -lntp

Relisez chaque résultat avant de poursuivre. Si un autre serveur utilise un port, identifiez-le et son usage au lieu de l’arrêter arbitrairement. Le guide d’installation Nginx d’Ubuntu présente le paquet et son service.

Dans nginx -T, cherchez l’inclusion de sites-enabled, les blocs server, listen, server_name et les serveurs par défaut. sites-available contient les sources proposées et sites-enabled les fichiers ou liens chargés par cette organisation de paquet ; un fichier dans sites-available seul ne s’active pas magiquement.

Une installation différente peut charger conf.d ou d’autres chemins : suivez ses Include réels. Ne chargez pas deux fois le même bloc via deux mécanismes. La configuration complète peut contenir des adresses internes ou des données d’authentification ; ne partagez pas toute la sortie -T sans examen.

Vérifier séparément l’exposition du site par défaut

sudo ss -lntp
sudo ufw status verbose
ls -l /etc/nginx/sites-enabled

Une écoute 0.0.0.0:80 ou [::]:80 est différente de 127.0.0.1:8080. Examinez aussi les règles de l’hôte, du fournisseur et les nouvelles connexions de clients autorisés ou exclus. Ne concluez pas à une isolation de tout le serveur à partir du seul futur bloc de laboratoire.

Sur cette VM neuve uniquement, si le site par défaut n’est pas utile, le bloc suivant vérifie puis sauvegarde son lien symbolique avant de le retirer. S’il n’existe déjà plus ou si sa cible diffère, inspectez l’état au lieu de forcer ce bloc :

(
set -eu
link=/etc/nginx/sites-enabled/default
if [ ! -L "$link" ] || [ "$(readlink -f "$link")" != /etc/nginx/sites-available/default ]; then
    printf 'Lien par défaut différent ; examinez la configuration.\n' >&2
    exit 1
fi
backup_dir=$(sudo mktemp -d /root/nginx-default-link.XXXXXX)
sudo cp -a "$link" "$backup_dir/default"
printf 'Lien conservé : %s/default\n' "$backup_dir"
sudo rm -- "$link"
sudo nginx -t
sudo systemctl reload nginx
sudo ss -lntp
)

Le fichier sites-available/default reste intact. Si la validation échoue après le retrait, ne rechargez pas : corrigez la cause ou restaurez ce seul lien depuis la sauvegarde, puis validez. La configuration déjà en cours peut continuer à écouter tant qu’un rechargement réussi n’a pas appliqué le changement.

Si le port 80 reste ouvert après réussite, cherchez un autre bloc ou processus. Pour revenir au lien sauvegardé, vérifiez d’abord qu’aucun nouvel objet n’occupe sa place et qu’aucune modification ultérieure ne serait écrasée.

Créer deux racines de documents sans écraser de fichiers

Les chemins du laboratoire doivent être neufs. Si un répertoire, un fichier ou un lien portant ces noms existe, choisissez d’autres noms et adaptez toute la configuration. Ce bloc refuse ces collisions avant la création :

(
set -eu
for lab_path in /srv/ubuntu-course-alpha /srv/ubuntu-course-beta /etc/nginx/sites-available/ubuntu-course-lab /etc/nginx/sites-enabled/ubuntu-course-lab; do
    if sudo test -e "$lab_path" || sudo test -L "$lab_path"; then
        printf 'Chemin déjà présent : %s\n' "$lab_path" >&2
        exit 1
    fi
done
sudo mkdir -m 0755 /srv/ubuntu-course-alpha /srv/ubuntu-course-beta
sudo sh -c 'set -C; umask 022; printf "%s\n" alpha-site > "$1"' sh /srv/ubuntu-course-alpha/index.html
sudo sh -c 'set -C; umask 022; printf "%s\n" beta-site > "$1"' sh /srv/ubuntu-course-beta/index.html
)

Les deux fichiers ont des contenus différents pour identifier le site qui répond. Le processus Nginx doit pouvoir traverser les répertoires et lire les fichiers ; il n’a pas besoin d’y écrire pour servir ces pages statiques. Ne donnez pas un mode 777 pour corriger une erreur de lecture.

Définir les sites locaux et un serveur de repli explicite

Avec sudoedit, créez /etc/nginx/sites-available/ubuntu-course-lab et enregistrez toute cette configuration, en conservant les signes $ de Nginx. Ces blocs sont destinés au contexte http déjà utilisé par l’inclusion de sites-enabled, pas à remplacer tout nginx.conf :

server {
    listen 127.0.0.1:8080 default_server;
    server_name _;
    return 404;
}
server {
    listen 127.0.0.1:8080;
    server_name alpha.example.test;
    root /srv/ubuntu-course-alpha;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
server {
    listen 127.0.0.1:8080;
    server_name beta.example.test;
    root /srv/ubuntu-course-beta;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

127.0.0.1 désigne la boucle locale : exécutez les tests depuis le serveur. Un client qui vise 192.168.56.20:8080 n’atteint pas cette écoute. Les noms alpha.example.test et beta.example.test appartiennent à l’espace .test réservé à cet usage ; ils ne sont pas des domaines à enregistrer pour obtenir un certificat public.

Nginx choisit d’abord selon l’adresse et le port, puis selon Host parmi les blocs correspondants. Ici, le bloc default_server reçoit les noms sans correspondance et renvoie 404. Le soulignement de server_name _ n’est pas un mécanisme spécial de refus ; le rôle de repli vient de default_server. Le traitement des requêtes par Nginx décrit cette sélection.

root définit le répertoire de documents et index la page par défaut. try_files cherche les chemins dans le contexte de cette racine puis renvoie 404 si rien ne correspond. N’ajoutez pas un second default_server sur le même couple adresse-port.

Activer le fichier, valider puis demander la relecture

Vérifiez encore que le nom de lien n’a pas été utilisé depuis la préparation. La création suivante refuse aussi de traiter la destination comme un répertoire :

(
set -eu
enabled=/etc/nginx/sites-enabled/ubuntu-course-lab
if [ -e "$enabled" ] || [ -L "$enabled" ]; then
    printf 'Destination déjà présente ; examinez son contenu.\n' >&2
    exit 1
fi
sudo ln -sT -- /etc/nginx/sites-available/ubuntu-course-lab "$enabled"
sudo nginx -t
sudo systemctl reload nginx
sudo ss -lntp
)

Les options Nginx -t et -T valident la configuration et tentent d’ouvrir les fichiers référencés ; elles ne remplacent pas un test HTTP avec le compte effectif des workers. Si -t échoue, ne rechargez pas, corrigez la source ou retirez seulement le nouveau lien avant de revalider.

Après reload, consultez l’état et les journaux de nginx si le résultat est inattendu. Un échec de rechargement peut laisser l’ancienne configuration active. Confirmez aussi que la nouvelle écoute reste précisément sur 127.0.0.1:8080.

Tester Host, contenu, chemin absent et repli

Depuis le serveur, demandez les deux noms en forçant leur résolution pour ces requêtes seulement :

curl --noproxy '*' --fail --show-error --resolve alpha.example.test:8080:127.0.0.1 http://alpha.example.test:8080/
curl --noproxy '*' --fail --show-error --resolve beta.example.test:8080:127.0.0.1 http://beta.example.test:8080/
curl --noproxy '*' -i -H 'Host: unknown.example.test' http://127.0.0.1:8080/
curl --noproxy '*' -i --resolve alpha.example.test:8080:127.0.0.1 http://alpha.example.test:8080/missing-lab-file

Les réponses attendues sont alpha-site pour la première requête, beta-site pour la deuxième et HTTP 404 pour le nom inconnu et le chemin absent. Les requêtes de 404 n’emploient pas --fail afin que vous puissiez lire la réponse complète ; un code de sortie curl réussi ne signifie pas automatiquement HTTP 200.

--resolve associe un nom et un port à une adresse pour curl sans changer le DNS du système. --noproxy '*' empêche un proxy configuré dans l’environnement de détourner ces tests locaux. Le manuel curl décrit ces options.

En cas de mauvais contenu, comparez le port, Host, les inclusions et les noms dupliqués. Pour un refus d’accès, vérifiez root, index, les permissions de chaque répertoire parent et, si un profil intervient, ses journaux. Distinguez fichier absent, page d’un autre site et erreur de connexion au service.

Désactiver uniquement le laboratoire et vérifier l’état final

Pour retirer ces nouveaux sites du chargement, vérifiez que le lien pointe toujours vers le fichier créé ici, retirez uniquement /etc/nginx/sites-enabled/ubuntu-course-lab, puis exécutez nginx -t. Après réussite, rechargez Nginx et relisez ses écoutes. Conservez les sources et les pages tant que vous n’avez pas terminé la revue du laboratoire.

Ne supprimez ni les autres sites ni le répertoire sites-enabled entier. Si vous restaurez le lien par défaut sauvegardé, reprenez la validation et l’examen de son exposition sur 80. Le retrait du laboratoire n’annule pas à lui seul la politique du pare-feu ni l’installation du paquet.

Un déploiement public demande ensuite son propre domaine, la résolution DNS, les adresses d’écoute, les règles d’accès, HTTPS, la gestion des journaux et des sauvegardes. Le succès de deux noms .test sur la boucle locale valide ce laboratoire de sélection des sites, pas cette préparation de production.