Aller au contenu principal

TP 2 – Gestion de plusieurs sites web avec un reverse proxy (proxy inverse) dans un environnement Linux

Table des matières​

CONTEXTE​

Vous êtes administrateur système dans une entreprise de services numériques. Votre mandat consiste à configurer un environnement local hébergeant trois instances indépendantes de Wiki.js, chacune représentant un environnement classique de développement logiciel :

  • Environnement de développement (dev.site1.local)
  • Environnement de test (test.site1.local)
  • Environnement de production (prod.site1.local)

Chaque instance de Wiki.js devra être installée manuellement sur une seule machine Ubuntu Server 24.04 LTS, connectée à sa propre base de données MariaDB et exposée via un reverse proxy NGINX.

OBJECTIFS DE L'ÉPREUVE​

  • Maîtriser l'installation manuelle d'un moteur de wiki basé sur Node.js
  • Gérer correctement des bases de données SQL distinctes
  • Automatiser le démarrage des services via systemd
  • Configurer un reverse proxy HTTP avec des sous-domaines internes
  • Diagnostiquer des erreurs de déploiement fréquentes
  • Appliquer les meilleures pratiques en matière d'isolation de service

Retour à la table des matières

CONSIGNES GÉNÉRALES​

  • Vous travaillez sur une seule machine virtuelle Ubuntu 24.04
  • Toutes les instances doivent être indépendantes, sans ports en conflit
  • Aucun serveur ne doit être exposé directement : seul le proxy NGINX écoute sur le port 80
  • Les adresses *.site1.local doivent fonctionner via /etc/hosts
  • Vous devez suivre une démarche professionnelle, avec structure, clarté et rigueur

Retour à la table des matières

PARTIE 1 – INSTALLATION ET CONFIGURATION DE WIKI.JS (40 POINTS)​

  1. Créez trois utilisateurs Linux dédiés : wikijs_dev, wikijs_test, wikijs_prod

  2. Créez trois bases de données distinctes sous MariaDB :

    • wikidb_dev, wikidb_test, wikidb_prod

  3. Installez manuellement Wiki.js dans :

    • /var/www/dev.site1
    • /var/www/test.site1
    • /var/www/prod.site1

  4. Modifiez le fichier config.yml de chaque instance :

    • Port différent (3000, 3001, 3002)
    • bindIP: 127.0.0.1
    • Informations de connexion correctes à la base

  5. Créez et activez les services systemd :

    • wikijs-dev.service, wikijs-test.service, wikijs-prod.service

Retour à la table des matières

PARTIE 2 – CONFIGURATION DU REVERSE PROXY NGINX (30 POINTS)​

  1. Configurez NGINX pour servir les sous-domaines suivants :
Nom d'hôtePort interneChemin local
dev.site1.local3000/var/www/dev.site1
test.site1.local3001/var/www/test.site1
prod.site1.local3002/var/www/prod.site1

  1. Modifiez /etc/hosts pour faire pointer ces domaines vers 127.0.0.1

  2. Testez l'accès aux sites avec un navigateur ou curl

Retour à la table des matières

PARTIE 3 – VALIDATION, DÉPANNAGE ET ANALYSE (30 POINTS)​

  1. Corrigez les erreurs suivantes si elles apparaissent :

    • Mauvaise indentation YAML
    • Problèmes de connexion MariaDB
    • Port déjà occupé
    • Droits de fichiers insuffisants

  2. Justifiez les décisions suivantes :

    • Pourquoi utiliser des utilisateurs différents pour chaque Wiki.js ?
    • Pourquoi préférer un reverse proxy plutôt que l'exposition directe ?
    • Quels sont les risques de sécurité si les ports sont exposés sans NGINX ?

  3. Proposez une méthode pour sécuriser l'installation avec HTTPS :

    • Utilisation de certbot
    • Configuration du bindIP
    • Rôle du DNS public

Retour à la table des matières

PARTIE 4 – QUESTION D'ANALYSE ARCHITECTURALE (10 POINTS)​

Énoncé​

Deux approches sont possibles pour exposer plusieurs environnements :

Approche A : sous-domaines → http://dev.site1.local, http://test.site1.local, http://prod.site1.local

Approche B : chemins internes → http://site1.local/dev, http://site1.local/test, http://site1.local/prod

Question​

  1. Comparez les deux approches :

    a) Implications techniques principales (4 points) b) Cas d'usage où l'approche B est tolérable, et quand elle est déconseillée (3 points) c) Quelle approche recommandez-vous et pourquoi ? (3 points)

Retour à la table des matières

GRILLE D'ÉVALUATION​

CritèresPoints
Wiki.js (x3) installé et fonctionnel15
Bases de données distinctes10
Configuration config.yml correcte10
Services systemd fonctionnels5
NGINX reverse proxy configuré15
/etc/hosts bien édité5
Diagnostic et résolution des erreurs10
Justification technique10
Proposition HTTPS argumentée10
Total90
Analyse de l'architecturePoints
Présentation des différences2
Cas d'usage pour chaque approche2
Analyse des risques et compatibilité2
Recommandation claire et motivée4
Sous-total10

MODULE BONUS 1 – Utilisateurs système vs utilisateurs normaux (humains) sur Linux​

Convention des UID sur Linux​

Sur la plupart des distributions Linux modernes, les utilisateurs sont classés selon leur UID (User ID) :

Plage d'UIDType de compteExemples
0Superutilisateurroot
1 – 999Comptes système / servicesdaemon, www-data, sshd, systemd-*, apache
≥ 1000Utilisateurs normaux (humains)alice, bob, etudiant
info

Cette plage est définie dans le fichier /etc/login.defs de votre distribution. Ce n'est pas une règle universelle, mais une convention largement adoptée (Debian, Ubuntu, RHEL, Fedora, etc.).

Comment vérifier les plages sur votre machine​

# Voir les plages UID définies sur votre distro
grep -E '^(UID_MIN|UID_MAX|SYS_UID_MIN|SYS_UID_MAX)' /etc/login.defs

Résultat typique sur Ubuntu :

SYS_UID_MIN    100
SYS_UID_MAX    999
UID_MIN        1000
UID_MAX        60000

Comptes système (UID < 1000) – Caractéristiques​

Les comptes système sont créés pour exécuter des services/démons, pas pour des connexions humaines.

Indices typiques d'un compte système :

  • UID bas (< 1000)
  • Shell = /usr/sbin/nologin ou /bin/false (pas de connexion interactive)
  • Pas de vrai dossier home utilisateur (ou un home « technique »)
  • Créé avec useradd -r (flag system account)

Exemples courants :

CompteServiceUID typiqueShell
rootSuperutilisateur0/bin/bash
www-dataApache / Nginx (Debian/Ubuntu)33/usr/sbin/nologin
apacheApache (RHEL/CentOS)48/sbin/nologin
sshdServeur SSH105/usr/sbin/nologin
mysqlMariaDB / MySQL27/bin/false

Vérification rapide :

# Voir l'UID et le shell de www-data
id www-data
getent passwd www-data
# Résultat : uid=33(www-data) gid=33(www-data) groups=33(www-data)

Comptes normaux / humains (UID ≥ 1000) – Caractéristiques​

Les comptes humains sont créés pour des personnes qui se connectent au système.

Indices typiques d'un compte humain :

  • UID ≥ 1000
  • Shell = /bin/bash ou /bin/sh
  • Dossier home dans /home/<username>
  • Créé avec useradd (sans le flag -r) ou adduser

Commandes utiles pour lister et distinguer les types d'utilisateurs​

Lister les utilisateurs humains (UID ≥ 1000) :

UID_MIN=$(awk '/^UID_MIN/{print $2}' /etc/login.defs)
awk -F: -v m="$UID_MIN" '$3>=m {print $1" (uid="$3")"}' /etc/passwd | sort -t'=' -k2 -n

Lister les utilisateurs système (UID < 1000) :

UID_MIN=$(awk '/^UID_MIN/{print $2}' /etc/login.defs)
awk -F: -v m="$UID_MIN" '$3<m {print $1" (uid="$3")"}' /etc/passwd | sort -t'=' -k2 -n

Lister les comptes sans login (typiquement des services) :

awk -F: '($7 ~ /(nologin|false)$/) {print $1" -> "$7}' /etc/passwd

Lister les comptes « humains probables » (home dans /home + shell bash/sh) :

awk -F: '($6 ~ /^\/home\//) && ($7 ~ /(bash|sh)$/) {print $1" home="$6" shell="$7}' /etc/passwd

Lien avec le TP : Pourquoi wikijs_dev, wikijs_test, wikijs_prod sont des comptes système ?​

Dans ce TP, les utilisateurs Wiki.js ont été créés avec la commande :

sudo useradd -r -m -s /bin/bash wikijs_dev
sudo useradd -r -m -s /bin/bash wikijs_test
sudo useradd -r -m -s /bin/bash wikijs_prod
OptionRôle
-rCrée un compte système → UID attribué dans la plage système (< 1000)
-mCrée un répertoire home (utile pour les fichiers de config)
-s /bin/bashDéfinit le shell (ici bash pour faciliter le debug en TP)
astuce

C'est le flag -r qui fait la différence ! Sans -r, le compte serait un utilisateur normal (UID ≥ 1000). Le flag -s ne définit que le shell, il ne rend pas le compte « système ».

Ces comptes sont des « service accounts » : ils sont responsables d'exécuter les services Wiki.js, comme défini dans les fichiers systemd :

[Service]
User=wikijs_dev    # ← le service tourne sous ce compte système

Vérification :

# Voir l'UID attribué (devrait être < 1000)
id wikijs_dev
id wikijs_test
id wikijs_prod

# Voir quel utilisateur exécute chaque processus Wiki.js
ps -eo user,pid,cmd | grep '[n]ode'

# Vérifier le statut du service
systemctl status wikijs-dev

Recommandation en production​

En production, il est préférable de ne pas donner un shell interactif aux comptes de service :

# Meilleure pratique (shell nologin)
sudo useradd -r -m -s /usr/sbin/nologin wikijs_dev
sudo useradd -r -m -s /usr/sbin/nologin wikijs_test
sudo useradd -r -m -s /usr/sbin/nologin wikijs_prod

Avec /usr/sbin/nologin, personne ne peut ouvrir une session interactive avec ce compte, mais systemd et sudo -u wikijs_dev <commande> fonctionnent toujours normalement. C'est le principe du moindre privilège.

Résumé
  • useradd -r → compte système (UID < 1000, destiné à un service)
  • useradd (sans -r) → compte humain (UID ≥ 1000, destiné à une personne)
  • -s → définit le shell, ne change pas le type de compte
  • Les comptes wikijs_* de ce TP sont des comptes système responsables d'exécuter le service Wiki.js
  • En production : toujours utiliser -s /usr/sbin/nologin pour les comptes de service

Retour à la table des matières

TP créé le: Décembre 2024