Reprendre un serveur configuré par un prestataire disparu, sans aucune documentation d’astreinte

systemctl list-units --type=service --state=running : cette commande, lancée en tout premier lieu sur ce serveur repris sans la moindre note de passation, a révélé six services actifs, dont deux dont le rôle exact restait totalement mystérieux au premier regard. Le prestataire qui avait configuré cette machine avait cessé toute activité plusieurs mois auparavant, sans qu’aucun document ni contact ne subsiste pour éclairer les choix effectués.

Ce retour d’expérience détaille la méthode suivie pour reconstituer, service par service, une configuration héritée sans documentation, en évitant l’écueil classique qui consiste à modifier ou désactiver un élément avant d’en avoir compris le rôle réel.

Premier réflexe : cartographier avant de toucher à quoi que ce soit

Avant toute intervention, un inventaire complet des services actifs, des ports ouverts et des tâches planifiées a permis d’établir une photographie fidèle de l’état du serveur, sans supposer que la configuration visible correspondait nécessairement à ce qui fonctionnait réellement :

systemctl list-units --type=service --state=running
ss -tulnp
crontab -l -u www-data
crontab -l -u root
ls -la /etc/cron.d/

Cette cartographie initiale a révélé une tâche planifiée dans /etc/cron.d/, exécutée chaque nuit sous un utilisateur système dédié, dont le script associé ne portait aucun commentaire ni nom explicite.

Recouper chaque service avec ses fichiers de configuration réels

Pour chacun des services identifiés, l’étape suivante a consisté à localiser son fichier de configuration effectivement chargé, plutôt que de se fier à un emplacement par défaut qui aurait pu être modifié :

nginx -T | grep "configuration file"
php-fpm -tt 2>&1 | head -n5

Cette vérification a permis de découvrir qu’un des deux services non identifiés correspondait en réalité à une instance Redis, configurée pour servir de cache d’objets à WordPress, mais jamais référencée explicitement dans le fichier wp-config.php du site principal : une extension tierce, installée puis probablement partiellement désactivée, gardait encore une trace de connexion active vers ce service.

L’historique shell, une source souvent plus parlante que la configuration elle-même

Sur cette machine, l’historique des commandes exécutées par le compte root restait accessible, faute d’avoir été purgé par le prestataire sortant. Sa lecture, bien que fastidieuse, a fourni des indices précieux sur la chronologie des décisions prises :

cat /root/.bash_history | grep -n "iptables\|ufw\|systemctl"

Cette lecture a mis en lumière une série de règles de pare-feu ajoutées manuellement, jamais persistées dans un fichier de configuration versionné, qui expliquaient pourquoi certains ports restaient ouverts sans qu’aucune règle explicite ne l’indique dans la configuration standard du pare-feu.

Reconstituer la logique du script cron non documenté

Le script exécuté chaque nuit, une fois ouvert et analysé ligne par ligne, s’est révélé être une synchronisation des médias du site vers un espace de stockage distant, vraisemblablement mise en place en remplacement d’une solution de sauvegarde plus classique jamais réellement finalisée. Cette découverte a changé la lecture initiale de la situation : ce qui ressemblait à un vestige inutile constituait en réalité l’unique mécanisme de sauvegarde effectif du serveur, seul rempart contre une perte de données en cas d’incident.

• Ne jamais désactiver un service ou une tâche planifiée avant d’avoir compris son rôle réel, même s’il semble à première vue superflu.
• Consigner chaque découverte au fur et à mesure, dans un document qui deviendra la première documentation réelle du serveur.
• Tester chaque hypothèse sur son rôle avant de la considérer comme acquise, en observant le comportement du service sur plusieurs jours si nécessaire.

Ce que cette reconstitution a produit au final

Au terme de ce travail, les six services actifs ont chacun reçu une fiche descriptive précise : rôle, fichier de configuration réel, dépendances avec les autres services du serveur, et raison probable de sa mise en place initiale. Cette documentation, absente au départ, constitue désormais la base de toute intervention future sur cette machine.

Un serveur orphelin ne ment jamais complètement : ses fichiers de configuration, son historique de commandes et ses tâches planifiées racontent, ensemble, ce que personne n’a pris le temps d’écrire.

Ce que cette reprise n’a pas encore traité

Cette phase de reconstitution méthodique de la configuration existante précède volontairement toute décision de migration vers un nouveau serveur : migrer une configuration mal comprise revient à transporter les mêmes zones d’ombre sur une nouvelle machine, une étape ultérieure qui suppose que cette compréhension soit d’abord acquise.

En résumé

Reprendre un serveur sans documentation d’astreinte demande de résister à la tentation de nettoyer ou de simplifier avant de comprendre. Sur les six services actifs recensés ici, les deux non documentés se sont révélés porter des fonctions critiques, un cache d’objets Redis et l’unique mécanisme de sauvegarde du serveur, que leur désactivation prématurée aurait rendu invisibles jusqu’au premier incident.