Passer le contrôle technique de son serveur, et corriger les défauts

Le contrôle technique fait le tour de votre serveur comme on le fait pour une voiture : sécurité, mises à jour, conteneurs, disque, sauvegardes, certificats. Il donne un verdict et, pour chaque défaut, comment le réparer. Il marche sur n’importe quel serveur Ubuntu ou Debian, installé avec MarketCompose ou non.

1. Lancer le relevé

Sur le serveur :

curl -fsSL https://marketcompose.com/controle-technique.sh -o controle-technique.sh
less controle-technique.sh          # facultatif : lisez-le (q pour quitter)
sudo bash controle-technique.sh

Le script :

ne modifie rien : il ne fait que lire (versions, configuration SSH, état des conteneurs, place disque…) ;
n’envoie rien : il affiche ce qu’il a relevé, puis un code ;
dure quelques secondes (un peu plus s’il vérifie beaucoup de certificats).

Sans sudo, il fonctionne aussi, mais ne peut vérifier ni SSH, ni le pare-feu, ni le détail de Docker.

Pourquoi le télécharger plutôt que curl … | sudo bash ? Pour pouvoir le lire avant de le lancer. C’est une bonne habitude avec tout script trouvé sur internet. La page du contrôle technique donne aussi son empreinte SHA-256, pour vérifier que le fichier n’a pas été modifié.

2. Ce qu’il y a dans le code

Avant le code, le script affiche exactement ce qu’il contient : des lignes comme disk_pct 42 ou ssh_pw no. Il n’y a ni mot de passe, ni adresse IP, ni nom de machine. On y trouve vos noms de domaine (pour les certificats) et les noms de vos conteneurs.

Le code commence par MCCT1- et tient sur une seule ligne, souvent longue : copiez-la en entier.

3. Lire le procès-verbal

Collez le code sur la page et cliquez sur Voir le procès-verbal. Le verdict reprend celui du contrôle automobile :

Verdict	Ce que ça veut dire
Favorable	Rien à signaler sur les points contrôlés
Favorable, avec défaillances mineures	En bon état, quelques améliorations à faire sans urgence
Contre-visite	Au moins une défaillance majeure : un vrai risque de panne, de piratage ou de perte de données
Défaillance critique	Danger immédiat : à traiter avant tout le reste

Chaque point indique le constat, ce qu’il faut faire (avec la commande) et un lien vers le guide ou la fiche d’erreur qui explique en détail.

4. Corriger dans le bon ordre

Les critiques d’abord. Un compte administrateur caché ou une base de données ouverte sur Internet passent avant tout. Un compte caché que vous n’avez pas créé signifie que le serveur est sans doute piraté : ne le réparez pas, reconstruisez-en un neuf.
Puis les majeures qui touchent aux données : sauvegarde absente ou trop vieille, disque presque plein. Faites une sauvegarde avant de corriger le reste.
Puis la sécurité : mots de passe SSH, pare-feu, mises à jour.
Les mineures quand vous avez le temps.

Pour les changements SSH, gardez toujours une session ouverte pendant que vous testez la connexion dans un second terminal.

5. Repasser le contrôle

Relancez simplement le script et collez le nouveau code. Le procès-verbal doit montrer vos corrections en « Conforme ». Le bouton Imprimer / PDF garde une trace datée, pratique pour suivre l’évolution.

La routine conseillée

Une fois par mois : 10 minutes, relevé + corrections mineures.
Après chaque gros changement : nouvelle application, mise à jour du système, déménagement.
Après un incident : pour vérifier que tout est revenu (conteneurs relancés, certificats renouvelés).

Ce que le contrôle ne voit pas

Si vos sauvegardes sont copiées ailleurs (il ne voit que le serveur) : la règle 3-2-1.
Les failles à l’intérieur de vos applications : gardez-les à jour.
Ce qui se passe entre deux contrôles : pour être prévenu en continu, surveillez votre serveur.

Une commande qui ne marche pas, une explication pas claire ? Signaler une erreur dans cette page.