Cédrix
97 lines
6.7 KiB
Markdown
97 lines
6.7 KiB
Markdown
# Mettre en place un serveur Debian administrable avec Webmin
|
|
|
|
Quand on monte un nouveau serveur, les premières heures sont toujours les mêmes : on durcit la machine, on crée un utilisateur correct, on coupe ce qui traîne, et on met en place de quoi l'administrer sans avoir à ouvrir un terminal pour chaque détail. Cet article décrit la procédure que j'utilise sur mes Debian fraîches : préparation via mes scripts, installation de Webmin, et activation de `firewalld` pour ne laisser passer que ce qui doit l'être.
|
|
|
|
L'idée n'est pas de transformer le serveur en sapin de Noël, mais d'avoir une base saine sur laquelle bâtir, qu'il s'agisse d'expérimenter dans un LXC ou de préparer une VM destinée à recevoir une vraie charge.
|
|
|
|
## Étape 1 — Préparer la machine
|
|
|
|
Sur une Debian neuve, on commence par récupérer un petit script qui en télécharge d'autres. C'est juste un point d'entrée : il va chercher dans mon dépôt Forgejo un ensemble de scripts d'initialisation que je maintiens à jour.
|
|
|
|
```bash
|
|
wget -O fetch_scripts.sh https://git.abonnel.fr/cedricAbonnel/notes-techniques/raw/branch/main/scripts/fetch_scripts.sh
|
|
chmod +x fetch_scripts.sh
|
|
./fetch_scripts.sh
|
|
```
|
|
|
|
À ce stade, un dossier `common/` apparaît à côté du script. C'est là que se trouve le vrai travail :
|
|
|
|
```bash
|
|
cd common/
|
|
./setup_debian.sh
|
|
```
|
|
|
|
`setup_debian.sh` fait ce qu'on a tous fini par écrire un jour : mise à jour des paquets, installation des outils de base, création d'un utilisateur non-root avec les bons droits sudo, durcissement minimal de SSH. Rien de magique, mais c'est répétable et c'est ce qui compte quand on provisionne souvent.
|
|
|
|
**Important** : une fois le script terminé, il faut se déconnecter de la session `root` et se reconnecter avec l'utilisateur que le script vient de créer. Tout ce qui suit se fait avec cet utilisateur, en passant par `sudo` quand nécessaire. Continuer en root est une mauvaise habitude qui finit toujours par se payer.
|
|
|
|
## Étape 2 — Installer Webmin
|
|
|
|
Webmin est une interface web d'administration système. Pour quelqu'un qui débute, c'est une porte d'entrée appréciable : on voit les services qui tournent, les utilisateurs, les paquets installés, les logs, le tout depuis un navigateur. Pour quelqu'un d'expérimenté, c'est un complément pratique quand on veut donner un accès limité à un collègue moins à l'aise en ligne de commande.
|
|
|
|
Webmin fournit son propre script pour configurer le dépôt apt :
|
|
|
|
```bash
|
|
curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
|
|
sudo sh webmin-setup-repo.sh
|
|
```
|
|
|
|
Ce script ajoute le dépôt officiel Webmin à la liste des sources apt et importe la clé GPG associée. Une fois fait, l'installation devient une commande apt classique :
|
|
|
|
```bash
|
|
sudo apt-get install webmin usermin --install-recommends
|
|
```
|
|
|
|
Petite précision sur les deux paquets : **Webmin** sert à l'administration système (root ou utilisateur sudo), **Usermin** est sa version pour les utilisateurs standards, qui leur permet de gérer leur propre compte, leurs mails, leurs fichiers, sans toucher au système. Sur une machine mono-utilisateur, on peut se passer d'Usermin, mais l'installer maintenant coûte trois mégaoctets et évite d'y revenir plus tard.
|
|
|
|
## Étape 3 — Se connecter à l'interface
|
|
|
|
Webmin écoute par défaut sur le port **10000** en HTTPS. Depuis un navigateur :
|
|
|
|
```
|
|
https://<ip-du-serveur>:10000
|
|
```
|
|
|
|
`<ip-du-serveur>` est à remplacer par l'adresse de la machine. Le navigateur va râler à propos du certificat — c'est normal, Webmin génère un certificat auto-signé à l'installation. On peut accepter l'avertissement pour l'instant ; si la machine est destinée à un usage durable, on remplacera ça plus tard par un vrai certificat (Let's Encrypt via un reverse proxy, par exemple).
|
|
|
|
Pour la connexion, **on utilise les identifiants Linux de l'utilisateur sudo**, pas un compte spécifique à Webmin. C'est l'utilisateur que `setup_debian.sh` a créé à l'étape 1. Webmin s'appuie sur PAM, donc tout compte système autorisé à se connecter peut potentiellement entrer — d'où l'importance de l'étape suivante.
|
|
|
|
## Étape 4 — Activer le pare-feu
|
|
|
|
Une machine accessible sur internet sans pare-feu, c'est une question de temps avant les premiers ennuis. Sur Debian, je préfère `firewalld` à `ufw` ou à la configuration brute de `nftables` : la notion de zones est pratique, la syntaxe se retient, et l'intégration avec Webmin est correcte.
|
|
|
|
Installation et activation :
|
|
|
|
```bash
|
|
sudo apt update
|
|
sudo apt install firewalld
|
|
sudo systemctl enable firewalld
|
|
sudo systemctl start firewalld
|
|
```
|
|
|
|
`enable` rend le service persistant au redémarrage, `start` le lance immédiatement. Vérification :
|
|
|
|
```bash
|
|
sudo firewall-cmd --state
|
|
```
|
|
|
|
Le retour attendu est `running`. Si c'est autre chose, `systemctl status firewalld` permet de comprendre ce qui coince — c'est souvent un conflit avec un autre service de filtrage déjà en place.
|
|
|
|
À ce stade, le pare-feu tourne mais avec une configuration par défaut qui, selon la zone active, peut bloquer Webmin. Il faut donc explicitement autoriser le port 10000 :
|
|
|
|
```bash
|
|
sudo firewall-cmd --add-port=10000/tcp --permanent
|
|
sudo firewall-cmd --reload
|
|
```
|
|
|
|
Le `--permanent` écrit la règle dans la configuration ; sans ça, elle disparaît au prochain redémarrage. Le `reload` recharge la configuration pour que la règle prenne effet immédiatement. C'est l'erreur classique : on ajoute une règle, on continue à ne pas pouvoir se connecter, on perd dix minutes avant de se rappeler du `reload`.
|
|
|
|
## Pour aller plus loin
|
|
|
|
Une fois cette base en place, plusieurs directions s'offrent selon le rôle de la machine.
|
|
|
|
Si elle est destinée à héberger un service web public, l'étape logique suivante consiste à placer Webmin **derrière un reverse proxy** plutôt que de l'exposer directement sur le port 10000. Le port 10000 est alors fermé vers l'extérieur, et l'interface devient accessible via un sous-domaine en HTTPS avec un vrai certificat. C'est plus propre, plus sûr, et ça évite l'avertissement de certificat à chaque connexion.
|
|
|
|
Si la machine est un serveur d'applications, autant profiter du fait que `firewalld` est en place pour réfléchir aux ports en amont. Mieux vaut décider tout de suite quelles applications écoutent où, plutôt que d'empiler les `--add-port` au fil de l'eau et de finir avec une configuration que plus personne ne comprend.
|
|
|
|
Et dans tous les cas, **garder une trace écrite** des choix faits : quels ports ouverts, quel utilisateur sudo, quelle convention de nommage. Un fichier `README.md` à la racine du home de l'admin, peu importe le support — l'important c'est que dans six mois, on puisse retrouver le fil sans avoir à tout rétro-ingénierer. |