Bonjour à tous, aujourd’hui je vais vous parler de Codex en Remote SSH et d’un vieux script de backup qui traînait sur mon serveur. Vous savez, le genre de script qu’on a écrit quelques années plus tôt, qui a toujours plus ou moins fait le boulot et qu’on évite de regarder de trop près tant que les sauvegardes semblent tomber quelque part…
Sauf qu’entre-temps, j’ai migré le serveur de Debian 12 vers Debian 13 (Cf. Crowdsec), quelques containers ont disparu, d’autres ont changé, et j’avais finalement très peu retouché au script de sauvegarde d’origine. Un retour aux sources après ma série sur Docker et Portainer, en quelque sorte. Il était donc temps de vérifier si ce machin sauvegardait encore réellement quelque chose.
Pour le coup, je n’ai pas commencé par ouvrir une console SSH et modifier le Bash au petit bonheur. J’ai ouvert le serveur directement dans VS Code avec l’extension Remote SSH, puis j’ai travaillé avec Codex de manière interactive sur la machine.
L’objectif n’était pas de demander à une IA : « fais-moi un script de backup ». L’objectif était de lui faire auditer l’existant, confronter ses hypothèses au vrai serveur, proposer une nouvelle version, puis la tester sous contrôle. La nuance est importante, surtout quand on travaille en root, hein.
Codex en Remote SSH : le serveur devient le workspace
Avec l’extension Remote SSH de VS Code, VS Code n’édite pas une copie approximative du projet sur mon poste. Le dossier ouvert, les fichiers, le terminal et les commandes exécutées sont ceux du serveur distant.
L’extension Codex pour l’IDE travaille donc avec le même contexte : je sélectionne un chemin dans l’ancien script, je lui demande si celui-ci reste valide après la migration, et il peut inspecter le fichier puis vérifier l’état réel de la machine. Utiliser Codex en Remote SSH de cette manière évite surtout de décrire de mémoire une infrastructure qui a déjà changé plusieurs fois.
Dans mon cas, cela voulait dire comparer le script avec :
- les containers Docker réellement présents ;
- les volumes encore utilisés ;
- les répertoires disponibles sous root ;
- les outils de dump installés dans les images de bases de données ;
- les tâches cron ou les timers systemd déjà configurés ;
- et même l’espace disque restant, parce qu’un backup de 3 To sur un disque plein reste un concept assez théorique.
Dit comme ça, cela paraît évident. Mais c’est justement là que l’approche devient intéressante : le code n’est plus analysé tout seul, hors-sol. Chaque hypothèse peut être vérifiée immédiatement sur son environnement d’exécution.
Commencer par regarder, pas par réécrire
Ma première demande était simplement de contrôler la validité de l’ancien script. Codex a donc commencé en lecture seule : syntaxe Bash, commandes disponibles, version de Debian, chemins référencés et état de Docker.
Premier détail intéressant, la session Remote SSH utilisait mon compte standard, pas root. Elle ne pouvait donc ni lire certains répertoires ni interroger le socket Docker. Au lieu d’en déduire que tout avait disparu, Codex m’a indiqué que les résultats étaient non concluants et a demandé l’autorisation d’effectuer un contrôle privilégié, toujours en lecture seule.
C’est un bon exemple du fonctionnement que je recherchais. L’IA peut préparer et expliquer une commande, mais l’élévation de privilèges reste visible et soumise à mon approbation. Je garde la main sur le moment où elle passe la frontière.
Une fois l’audit privilégié autorisé, le vieux script a commencé à raconter sa vie :
- le répertoire de destination des sauvegardes n’existait plus ;
- le container Nextcloud référencé avait disparu ;
- le container MariaDB n’exposait plus mysqldump, mais mariadb-dump ;
- un PostgreSQL utilisé par Guacamole n’était pas sauvegardé du tout ;
- plusieurs chemins historiques étaient encore présents, d’autres non ;
- aucune tâche cron ou systemd ne lançait le script ;
- et les mots de passe des bases étaient écrits directement dedans (oui je sais… mais trust me, c’était secure 🙂 sur ce coup là)
Bref, la migration Debian s’était bien passée, mais le backup était resté sur l’ancien serveur dans sa tête. Le vieux container Nextcloud venait par exemple de la configuration décrite dans mon article Nextcloud avec Docker : le lien était logique historiquement, mais plus du tout dans l’état actuel du serveur.
Faire produire une v2 à partir des constats
À partir de là, j’ai demandé une seconde version. Pas une réécriture « moderne » pour le plaisir de changer trois syntaxes, mais une version directement dérivée des problèmes observés.
Le nouveau script crée son répertoire de destination, s’arrête dès qu’une étape critique échoue, nettoie ses fichiers temporaires et empêche deux exécutions de se chevaucher. Il récupère les informations d’authentification depuis l’environnement des containers au lieu de conserver les mots de passe dans le fichier.
Il réalise également deux dumps logiques : MariaDB pour WordPress et PostgreSQL pour Guacamole. Les volumes bruts de ces bases sont exclus de l’archive. C’est plus propre et surtout plus portable que de compresser des fichiers de base de données en cours d’utilisation en espérant très fort que tout se passe bien.
Pour les autres volumes Docker, le script peut mettre brièvement les containers en pause pendant la création de l’archive. Enfin, l’archive est vérifiée avant d’être déclarée valide, les anciennes sauvegardes sont supprimées selon une vraie politique de rétention et le fichier de statut contient désormais une date réelle. L’ancienne version écrivait littéralement filedate…. Mais l’intention y était !
Tester le backup avec Codex en Remote SSH
C’est probablement la partie la plus importante de l’expérience. Une fois le script créé et validé syntaxiquement, Codex ne l’a pas exécuté tout seul. Il m’a expliqué qu’un test complet allait écrire plusieurs gigas sur le disque et mettre temporairement les containers en pause. J’ai donné mon accord, puis nous avons lancé le backup.
Et il a échoué presque immédiatement. L’image MariaDB avait évolué, mais les tables système provenaient encore d’une ancienne version. L’option chargée d’exporter les procédures stockées interrogeait une table dont le schéma n’était plus celui attendu. C’est exactement le genre de problème qu’une revue statique ne peut pas deviner complètement. Le point positif, c’est que l’échec est arrivé avant la mise en pause des containers. Le script s’est arrêté, a supprimé les fichiers temporaires et n’a laissé aucune archive derrière lui.
Du coup, Codex a choisi de ne pas exporter les routines et événements, retiré les options concernées puis relancé le test. Le décalage des tables système reste une dette technique à traiter avec mariadb-upgrade ; il n’a pas été discrètement enterré sous un joli message vert.
Cette fois, le test complet est allé au bout :
- 14 containers mis en pause puis relancés correctement ;
- environ trois minutes de pause pendant la copie des volumes ;
- les dumps MariaDB et PostgreSQL présents ;
- les contrôles gzip et tar réussis ;
- aucun fichier temporaire abandonné ;
- aucun container resté en pause.
Quelques sockets Unix ont été ignorés par tar. C’est normal : ce sont des points de communication créés à l’exécution, pas des données à restaurer. Là encore, l’intérêt est de distinguer un warning attendu d’une vraie sauvegarde incomplète.
Planifier en root… mais pas n’importe comment
Dernière étape : lancer le backup chaque nuit. Codex a proposé un service et un timer systemd, plus faciles à superviser qu’une ligne perdue dans une crontab.
La première tentative d’installation a été refusée par le garde-fou de sécurité. Le service root pointait vers le script situé dans mon workspace, donc modifiable par mon compte utilisateur. Autrement dit, mon compte aurait pu remplacer le contenu du script et attendre tranquillement que root l’exécute à 2 heures du matin. Une élévation de privilèges planifiée, c’est pratique, mais pas vraiment dans le sens prévu.
La solution a été de déployer une copie appartenant à root dans /usr/local/sbin, puis de faire pointer le service systemd vers celle-ci. Le timer a ensuite été activé et sa prochaine date d’exécution contrôlée sans déclencher une seconde sauvegarde dans la foulée.
C’est un détail que j’aurais pu rater en allant trop vite. Et c’est aussi un bon rappel : un assistant utile n’est pas seulement celui qui écrit la commande demandée. C’est celui qui bloque quand l’enchaînement crée une faille évidente, explique pourquoi, puis propose une alternative propre.
Alors, l’IA a migré mon backup toute seule ?
Non. Et c’est justement pour ça que la méthode me plaît.
J’ai fourni le contexte, choisi ce qui devait être sauvegardé, autorisé les contrôles privilégiés, accepté la courte interruption des services et validé le passage en production. Codex a fait le travail assez long d’inventaire, de relié le contenu du script à l’état du serveur, et de proposé les modifications et a exécuté les vérifications.
La boucle ressemblait plutôt à ça :
- je décris l’objectif et les contraintes ;
- Codex inspecte ce qu’il peut sans modifier la machine ;
- il expose les écarts et les risques ;
- je valide une direction ;
- il produit une modification vérifiable ;
- nous testons sur le vrai environnement ;
- l’erreur observée devient l’entrée de l’itération suivante.
Codex en Remote SSH rend cette boucle particulièrement fluide. Je garde sous les yeux le fichier, les modifications proposées et le terminal du serveur. Je ne copie-colle pas quinze morceaux de contexte dans une conversation séparée et je ne demande pas à un chatbot de deviner la moitié de mon infrastructure.
Évidemment, travailler directement sur un serveur demande davantage de discipline. Il faut commencer en lecture seule, limiter les privilèges, annoncer les impacts, protéger les secrets et tester les chemins d’échec.
Une IA branchée sur un terminal root sans validation humaine, c’est juste un moyen très rapide de faire une bêtise très proprement formatée.
Ce que je retiens de cette migration interactive
Je partais d’un script ancien que je pensais avoir très peu à adapter après le passage à Debian 13. En réalité, le système d’exploitation était presque le sujet le moins important. Les vrais écarts venaient de la vie du serveur : containers supprimés, nouvelle base de données, outils renommés dans les images, credentials historiques, absence de planification et changement de version MariaDB.
L’intérêt de Codex en Remote SSH n’a donc pas été de générer du Bash plus vite (enfin si, en fait, il dev 200x fois plus vite que moi, la migration + upgrade du script a du me prendre 1h là où si j’avais du le faire à la main c’était 1/2 journée). Il a été de maintenir une conversation technique reliée en permanence aux faits : le fichier ouvert, les containers actifs, les permissions, les erreurs du test et l’état final des services.
Bon voilà, mon backup tourne maintenant tous les jours, l’archive est testée en conditions réelles et je sais aussi ce qu’il me reste à corriger côté MariaDB. Ce n’est pas de la magie, c’est une boucle d’administration système assistée, avec des contrôles et un humain au milieu. Et pour le coup, c’est de la folie furieuse quand on repense à comment on faisait de l’administration système avant.
Dernier bonus, l’article que vous venez de lire, c’est Codex qui en a écrit 80% pour raconter ce qu’il a fait… en se basant sur une « skill » que je lui ai fait créé à partir des anciens articles que j’ai écrit sur le site. J’ai juste relu, modifié quelques tournures, etc. Vous aviez repéré que c’était pas moi ?
Bref, Geekez bien !
