Nettoyer ce serveur

Un serveur qui tourne depuis des mois accumule des choses inutiles : téléchargements de paquets dont il n’a plus besoin, anciennes images de noyau dans /boot, conteneurs Docker arrêtés, caches de compilation, fichiers de logs archivés, mises à jour de sécurité en attente et services qui perdent lentement de la mémoire. Pris séparément, rien de tout ça n’est forcément un problème, mais l’ensemble finit par remplir le disque, faire échouer une mise à jour ou ralentir un site plus qu’il ne devrait.

Nettoyer ce serveur est un bouton unique qui s’occupe de tout en une seule passe — avec une conversation dans le chat pour confirmer ce qui présente un risque avant exécution.

Ce que ça fait concrètement

Trois catégories, chacune exécutable séparément : coche ce que tu veux lancer et laisse le reste de côté.

• Libérer de l’espace disque — vide le cache de téléchargement des paquets, supprime les dépendances de paquets désinstallés, nettoie les conteneurs Docker arrêtés et les images orphelines, réduit le cache de build Docker de plus d’une semaine, limite les journaux systemd aux 30 derniers jours, supprime les fichiers de logs archivés (.gz / .1 / .old) de plus de 30 jours et peut aussi supprimer les anciennes images de noyau / révisions snap désactivées.
• Installer les mises à jour de sécurité — actualise la liste des paquets et installe la version la plus récente de chaque paquet installé (apt update + apt upgrade). Si la mise à jour inclut un nouveau noyau, cela devient une action de suivi « redémarrer quand ce sera pratique », pas quelque chose qui t’arrive sans prévenir.
• Redémarrer les services qui fuient — facultatif. Redémarre tes sites web, bases de données et workers un par un (~10 à 30 s d’indisponibilité chacun) afin de remettre à zéro la mémoire qu’ils ont lentement accumulée au fil des semaines. Nous mesurons le temps de réponse avant et après, et nous n’annonçons une amélioration que s’il y a une preuve réelle.

En plus de ça, quelques vérifications en lecture seule s’exécutent toujours : rapport des zones qui occupent le disque (les dossiers les plus volumineux), services en échec (tout ce que systemd a signalé), connexions SSH récentes (pour repérer celles que tu ne reconnais pas), état de Fail2ban et vérification de /var/run/reboot-required (le fichier créé par une mise à jour du noyau pour signaler qu’un redémarrage est nécessaire).

Comment le lancer

Quatre points d’entrée, une même fenêtre modale :

Le chemin le plus courant est celui depuis le stockage : tu as remarqué que le disque se remplissait, tu es allé voir le stockage, et le bouton de nettoyage est juste là.

La fenêtre de vérification préalable

Cliquer sur n’importe quel point d’entrée ouvre la même liste de vérification. La fenêtre fait deux choses à la fois : elle te montre exactement ce qui va se passer, et elle autorise les étapes sûres pour éviter que le chat te redemande confirmation pour des actions que tu as déjà cochées.

Lis les pastilles : elles indiquent à quoi t’attendre.

• Sauge (sûr) — s’exécute immédiatement. Pas de question dans le chat, pas de confirmation, seulement un statut d’une ligne après coup.
• Pêche (confirmation dans le chat) — met l’exécution en pause pour demander oui/non dans la conversation. Utilisé pour des actions comme l’installation de mises à jour pouvant redémarrer des services.
• Rose (confirmation par élément) — liste chaque candidat (par exemple chaque volume Docker orphelin) et demande un par un. Le niveau « es-tu vraiment sûr pour cet élément précis ».

Chaque ligne comporte aussi un volet « À quoi ça sert ? » avec la commande shell exacte que nous exécuterons, afin que les utilisateurs techniques puissent vérifier qu’il n’y a pas de surprise. Les utilisateurs non techniques peuvent l’ignorer.

L’interrupteur Redémarrer tes charges de travail après le nettoyage en bas de la fenêtre est une décision à part. Il redémarre chaque site web / base de données / worker en cours d’exécution, un à la fois, avec environ 10 à 30 secondes d’indisponibilité chacun, mesure le temps de réponse avant et après, puis t’indique l’écart. Laisse-le désactivé si une indisponibilité maintenant est pire qu’une légère fuite mémoire ; active-le si tu es déjà en train de faire de la maintenance.

Tes cases cochées sont mémorisées par serveur : la prochaine fois que tu ouvres la fenêtre sur le même serveur, les mêmes cases sont déjà cochées. Les nouvelles actions ajoutées par de futures mises à jour apparaîtront automatiquement cochées par défaut lorsqu’elles sont sûres, et décochées pour les autres.

Ce qui se passe pendant l’exécution

Clique sur Démarrer le nettoyage et la fenêtre se ferme. À partir de là, la conversation prend le relais :

1. Instantané — un lot rapide de commandes en lecture seule capture l’état « avant » (espace disque libre, RAM, taille des logs, mises à jour en attente, services en échec, plus gros dossiers, connexions récentes, Fail2ban). Le chat indique simplement « Instantané pris, X Go libres, N mises à jour en attente. Démarrage du nettoyage… » : tu ne vois pas un mur de sortie brute.
2. Les étapes sûres s’exécutent automatiquement. apt update, apt clean, journalctl --vacuum, docker system prune, la suppression des logs archivés : elles s’exécutent discrètement, chacune avec un statut d’une ligne. Aucune demande d’approbation, car la fenêtre les a autorisées.
3. Les étapes de prudence demandent confirmation. Tout ce qui porte une pastille pêche (apt upgrade, docker system prune -a, suppression de noyaux, révisions snap) pose une question d’une ligne dans le chat avant de s’exécuter. Tu réponds oui, l’action s’exécute ; tu réponds non, elle est ignorée et l’action suivante continue : la recette ne s’arrête pas à cause d’un seul refus.

4. Les étapes par élément demandent confirmation pour chaque candidat. Si tu as coché la suppression des volumes orphelins, Faro liste chaque volume inutilisé et demande un par un, avec un indice sur l’image qui le montait auparavant. « Non à tout » / « stop » / « ignorer le reste » court-circuite les éléments restants.

5. Redémarrages facultatifs des charges de travail. Si tu l’as activé, chaque site/base de données en cours d’exécution est redémarré avec des mesures de temps de réponse avant et après.

Si le noyau est mis à jour et qu’un redémarrage est nécessaire pour utiliser réellement le nouveau noyau, la recette ne redémarre pas automatiquement. Elle affiche une carte de suivi que tu peux traiter plus tard.

Quand un redémarrage a effectivement lieu

Tout ce qui coupe la connexion SSH — systemctl reboot, redémarrage de sshd / dbus / networking — déclenche une bannière ambre fixe en haut du chat. Le chat se met en pause avec un message synthétique « Redémarrage lancé. Le chat restera silencieux pendant ~30 à 60 s… » ; l’envoi de messages est désactivé tant que la bannière est affichée.

En arrière-plan, une sonde retente une connexion SSH toutes les deux secondes avec les identifiants mis en cache par Server Manager lorsque tu t’es connecté. Quand le serveur répond, la bannière passe au vert (« Le serveur est de retour · uptime 8 s · reprise de la surveillance »), disparaît automatiquement après 5 secondes et la zone de saisie est réactivée. Pas besoin de rafraîchir le navigateur.

Le résumé et « Ce que tu dois faire »

Lorsque l’exécution se termine, Faro publie un message de clôture avec les gains chiffrés en premier et un tableau des métriques modifiées.

Le tableau n’inclut que les lignes pour lesquelles l’action sous-jacente a réellement été exécutée ET où le changement n’est pas nul : si tu as ignoré Docker, tu n’obtiens pas de ligne Docker. La colonne « Pourquoi c’est important » est rédigée en langage simple (« De la place pour les bases de données et les téléversements », « Vulnérabilités corrigées », « Moins de concurrence pour le CPU »), pas en jargon.

Si un redémarrage de charge de travail a produit une amélioration mesurable, tu verras aussi un tableau Temps de réponse des charges de travail pour chaque charge concernée — et seulement dans ce cas. La recette ne prétendra pas que « ton site est plus rapide » sur du bruit de mesure.

Cartes d’actions de suivi

Tout ce que le nettoyage n’a pas pu terminer seul — redémarrage en attente, services qui exécutent encore du code de bibliothèque obsolète, charges de travail que tu as refusé de redémarrer, volumes orphelins auxquels tu as répondu non — apparaît dans une section Ce que tu dois faire avec des cartes numérotées. Chaque carte propose deux façons de s’en occuper :

• Option A — demande-moi ici — un parcours en un clic dans le chat. Le texte de réponse de l’encadré apparaît sous forme de pastille cliquable au-dessus de la zone de saisie, pour t’éviter de remonter dans la conversation.
• Option B — via la console de ton fournisseur — étapes adaptées au fournisseur, clic par clic, pour effectuer la même action (par exemple « DigitalOcean → Droplet → Power → Reboot »). Pratique si tu préfères le faire volontairement toi-même.
• Compromis — une phrase par carte qui explique quand chaque méthode est la plus pertinente.

La bande de pastilles épinglée au-dessus de la zone de saisie reflète ces cartes sous forme de suivis ☐ en attente. Clique sur une pastille → son texte de réponse remplit la zone de saisie → appuie sur Envoyer. Pendant que Faro s’en occupe, la pastille passe en ⏳ en cours ; quand c’est terminé, elle est barrée avec ✓ puis disparaît automatiquement après 5 secondes. Chaque pastille possède aussi un petit bouton × pour l’ignorer si tu as décidé de ne pas traiter ce suivi ; ce masquage persiste jusqu’à la fin de la session du navigateur.

Cas particuliers fréquents

« Aucun volume orphelin trouvé » — l’action par élément l’indique simplement et passe à la suite. Ce n’est pas une erreur ; la liste était vide.

Le redémarrage était déjà requis avant le nettoyage — c’est fréquent lorsque quelqu’un d’autre, ou une exécution précédente, a installé des mises à jour sans encore redémarrer. La recette vérifie /var/run/reboot-required à la fois lors de l’instantané et après apt upgrade. S’il était déjà présent, la carte de suivi « Redémarrer le serveur » apparaît même si ce nettoyage n’a rien installé de nouveau : c’est toujours la bonne action.

Mes sites sont derrière Traefik / nginx / Apache — la recette ne touche pas à la configuration de ton serveur web. Elle redémarre les conteneurs sous-jacents (ou les unités systemd) des sites qu’elle peut identifier depuis l’inventaire ; le proxy continue de fonctionner normalement. Si le reverse-proxy d’une charge de travail se trouve devant des conteneurs que Server Manager ne connaît pas (une configuration personnalisée non gérée), elle est ignorée discrètement : pas d’URL de sonde, donc pas de redémarrage mesurable.

Snap n’est pas installé sur ce serveur — l’étape « Supprimer les révisions snap désactivées » indique simplement « Snap n’est pas installé — étape ignorée. » et continue. La cocher sur un serveur sans snap est sans danger.

**apt autoremove supprimerait quelque chose que je veux garder** — chaque étape autoremove est précédée d’une simulation qui affiche « Would remove: pkg-a, pkg-b, … ». Si la liste te semble incorrecte, réponds non : l’exécution réelle n’a lieu qu’après ta confirmation.

J’ai dit oui à une étape et je veux revenir en arrière en cours de route — appuyer sur Esc arrête l’agent. Les commandes déjà en cours ne sont pas interrompues (elles se terminent), mais la boucle s’arrête. Tu peux demander à Faro de revenir plus tard sur ce qui a été ignoré.

Le chat semble bloqué pendant le redémarrage d’un service — tout redémarrage de sshd, dbus ou de la pile réseau déclenche la même bannière qu’un redémarrage complet (dans une variante de courte durée). Si la bannière est affichée, le chat est volontairement en pause ; si elle ne s’affiche pas et que le chat semble vraiment figé, consulte Récupérer l’accès quand SSH cesse de fonctionner.

Le rapport final : ce qu’il faut regarder

Le message de résumé suit volontairement toujours la même structure pour que tu puisses le parcourir rapidement :

1. Titre — une ligne en gras : « 🧹 6,2 Go récupérés et 14 mises à jour de sécurité appliquées. » C’est le gain. Les chiffres qui n’ont pas bougé ne sont pas mentionnés.
2. Précision en une ligne — la plus grande amélioration concrète en langage simple (le plus gros gain d’espace disque, les correctifs de sécurité appliqués, moins de services en échec — selon ce qui a le plus changé).
3. Tableau « Ce qui a changé » — Avant / Après / Changement / Pourquoi c’est important, une ligne par métrique qui a réellement évolué. Lignes possibles : espace disque libre (Go et %), inodes libres (%), utilisation disque de Docker, taille des logs système, mises à jour de sécurité en attente, services en échec, mémoire disponible, charge en arrière-plan.
4. Tableau « Temps de réponse des charges de travail » (uniquement si tu as choisi les redémarrages ET qu’il y a eu un gain mesurable) — avant / après / changement pour chaque charge de travail.
5. Section « Ce que tu dois faire » (uniquement s’il y a des suivis) — les cartes numérotées décrites plus haut.
6. Pied de message « Ignoré : … » (uniquement si tu as refusé des étapes) — la liste des libellés d’actions, pour pouvoir relancer plus tard et les réexaminer.

Si le serveur était déjà propre et qu’il n’y avait rien à faire, Faro termine par « Ton serveur est déjà propre. Rien à faire. » : pas de tableau de résumé inventé, pas de rapport rempli artificiellement.

Référence

Ce qui est préautorisé et ce qui demande encore confirmation

Stockage de tes cases cochées — ta sélection (ainsi que l’interrupteur de redémarrage des charges de travail) est enregistrée dans le localStorage de ton navigateur, avec le nom d’hôte du serveur comme clé. Effacer les données du navigateur réinitialise les cases à la sélection par défaut.

Fonctionnement des suivis et du contournement au redémarrage — lorsque la recette de nettoyage est active, les scripts d’instantané en lecture seule de la recette et toutes les commandes de niveau sûr que tu as cochées dans la fenêtre contournent le classificateur de commandes destructrices : c’est ce qui évite les demandes « Approuver cette commande ? » en double. Les niveaux Prudence et Par élément redemandent toujours confirmation. Le contournement tient compte du contenu (chaque segment de commande est validé par rapport à une liste d’autorisation en lecture seule) et les motifs interdits comme rm -rf / sont toujours bloqués, quoi qu’il arrive.