[🛠] IT Operations #2: Pour le serveur Linux de l’entreprise, j’ai conçu l’exploitation avant d’installer les services

✨ Résumé de GPT-5.6 Sol

Le récit de la configuration du disque, du SSH interne et d’une adresse stable sur un Ubuntu Server dédié, de la séparation des droits entre personnes, AI Cells et runtimes d’automatisation, puis de la documentation du réseau entier comme socle d’exploitation que Codex peut reprendre.

J’ai enfin monté un serveur Linux dédié aux services de l’entreprise.

Mais je n’ai pas simplement construit un ordinateur capable de démarrer Ubuntu. Il s’agissait plutôt d’un socle d’exploitation conçu pour que des personnes, des IA et des services d’automatisation puissent fonctionner simultanément sur le même serveur sans empiéter sur les droits ni l’état des autres.

Lorsque j’ai obtenu le SSD, mon raisonnement était simple : installer Linux sur un PC Windows, m’y connecter en SSH, et voilà un serveur. Je me suis aussitôt interrogé sur l’interface graphique. Est-ce que je n’allais pas regretter de m’obstiner à utiliser seulement la CLI pour faire « vrai serveur » le jour où j’aurais besoin d’une connexion par navigateur ou de Computer Use ?

En examinant chaque point, j’ai compris que le serveur ait besoin d’une GUI et que j’aie besoin d’utiliser une GUI étaient deux questions totalement différentes. Si OAuth ou une connexion à Codex est nécessaire, je peux ouvrir dans le navigateur du MacBook l’URL affichée dans la session SSH. Si Computer Use est nécessaire, je peux l’exécuter sur mon Mac ou un appareil professionnel, tout en gardant Linux comme Runtime où le résultat sera déployé.

Un serveur n’est pas une machine qui affiche un écran. C’est un environnement qui continue de fonctionner.

UEFI, GPT et LVM pour préserver le disque Windows

Même la clé USB d’installation m’a dérouté. Je pensais que si la clé Ventoy utilisait MBR, Ubuntu serait lui aussi installé en MBR. Lorsque UEFI: USB, Partition 2 est apparu dans le menu de démarrage, je ne savais même pas si c’était le bon chemin.

Le partitionnement de la clé USB et celui du SSD qui reçoit Ubuntu sont indépendants. Il suffisait de lancer l’installateur par l’entrée UEFI et de sélectionner précisément le bon SSD. Je n’ai pas touché au NVMe Windows existant et j’ai créé l’EFI System Partition, /boot, LVM et le root filesystem uniquement sur le nouveau SSD de 250 Go.

Le plus effrayant n’était pas la difficulté de Linux, mais le risque d’effacer le mauvais disque. En voyant même la partition Windows Réservé au système, elle paraissait presque supprimable. J’ai de nouveau comparé les modèles et les capacités dans l’installateur, puis choisi uniquement le SSD réservé à Ubuntu. Le disque Windows est resté intact.

J’ai choisi l’installation standard d’Ubuntu Server 24.04.4 LTS, ni minimized ni Desktop image. Sans GUI, il ne restait qu’une base centrée sur SSH et systemd, prête à accueillir ensuite un Docker Runtime.

Réservation DHCP et SSH interne avant l’adresse fixe

Pendant l’installation, le réseau filaire a immédiatement reçu une adresse par DHCP. Au départ, je pensais que Create bond améliorerait la connexion SSH ou fixerait l’adresse. Mais un bond agrège plusieurs NIC pour la redondance ou l’addition de bande passante. Cela n’a rien à voir avec l’adresse d’une seule NIC filaire.

Au lieu d’inscrire une static IP arbitraire dans le serveur, j’ai associé l’adresse MAC de la NIC à une IP interne grâce à une réservation DHCP sur le routeur principal. Le serveur reste un DHCP client, mais reçoit la même adresse après chaque redémarrage. Le routeur permet aussi de vérifier les conflits avec les autres appareils réservés.

Je n’ai pas non plus exposé SSH à Internet. J’ai créé une clé Ed25519 réservée au MacBook, comparé la host key du serveur avec la console, puis l’ai épinglée à l’adresse du réseau interne. Je n’ai créé aucun forwarding externe du port 22 sur le routeur.

Juste après l’installation, ssh.service apparaissait comme disabled, et j’ai cru un instant que SSH avait été mal installé. En réalité, ssh.socket était actif et écoutait sur le port 22 ; le public-key login a continué à réussir après redémarrage. Socket activation peut démarrer le service correspondant à l’arrivée d’une requête : il ne fallait donc pas diagnostiquer une panne à partir d’une seule ligne d’état du service.¹

La différence entre DHCP lease, reservation et IP–MAC binding, apprise quelques jours plus tôt en réparant la panne Internet du routeur de l’entreprise, a directement servi à construire ce socle serveur. Recevoir une adresse et pouvoir administrer une machine de manière sûre par cette adresse sont deux choses différentes.

Personnes, AI Cells et services séparés d’un compte unique

Dès que SSH a fonctionné, j’ai failli installer comme d’habitude Oh My Zsh, Powerlevel10k et mes alias personnels. Puis je me suis de nouveau arrêté.

Le premier compte créé pendant l’installation appartient à l’entreprise et sert au bootstrap et à la récupération. Regrouper mon shell quotidien, le AI Runtime et Operations Automation dans ce compte serait pratique. Mais il deviendrait impossible de distinguer qui a exécuté quoi avec quels droits, et tout s’emmêlerait lorsqu’un autre responsable arriverait ou qu’il faudrait révoquer un compte.

J’ai donc commencé par séparer les comptes selon ces règles.

administrateur bootstrap
└─ utilisé uniquement pour l’installation et la récupération

usr-<person>
└─ compte utilisé par une personne pour SSH, sudo et le développement

aio-cell-<person>
└─ compte sous lequel un AI Cell personnel fonctionne en continu

svc-<domain>-<purpose>
└─ Runtime d’application, importer de données ou broker d’opérations restreintes

Ne pas inclure le nom de l’entreprise ni le métier dans le username était également intentionnel. Une personne reste la même même si son rattachement et son rôle changent. Il vaut mieux que le Linux login ne représente qu’une identité stable, tandis que les droits d’administrateur, de développeur ou de participant à un projet évoluent séparément par groups et RBAC.

J’ai décidé de conserver OMZ, P10K et mes alias uniquement dans le compte humain. Les AI Cells et service accounts ne liront pas la configuration de l’interactive shell ; ils seront exécutés par des systemd units fixes, des EnvironmentFiles et des chemins absolus. Un beau prompt améliore ma productivité, mais n’a aucun rapport avec la stabilité du service.

Je n’ai pas encore créé tous ces comptes dans la précipitation. J’ai d’abord fixé leurs noms, la propriété des fichiers, l’autorisation de connexion et les limites d’accès à sudo et Docker. Définir ces frontières quand le serveur est vide est bien plus simple que de tout séparer après l’avoir mélangé dans un seul compte.

La frontière d’un AI Cell s’étend jusqu’à UID, HOME et OAuth

Le plus grand changement dans ma compréhension cette fois concernait les systèmes multi-utilisateurs.

Lorsqu’on ne voit que les GUI de bureau, on a l’impression que l’utilisateur affiché sur l’écran de connexion occupe tout l’ordinateur. Sous Linux, l’écran de connexion visible et les utilisateurs dont les processus tournent sont deux notions différentes. Plusieurs utilisateurs peuvent se connecter en SSH en même temps, et les processus de service accounts non connectés peuvent continuer à fonctionner sous systemd.

Cette structure était particulièrement importante pour étendre à Linux le modèle d’AI Cell que j’avais redéfini par utilisateur macOS. Un AI Cell n’était pas un simple nom de process.

1 AI Cell
= 1 ensemble Linux UID et HOME
= 1 ensemble OAuth et CODEX_HOME
= 1 ensemble Gateway et Port
= 1 ensemble Session, Memory et Workspace
= 1 ensemble systemd unit et cgroup budget

Lorsque le Cell de chaque personne possède son propre UID et HOME, l’authentification, la mémoire et l’espace de travail se séparent naturellement. Chaque Cell fonctionne sur un port ou un Unix socket différent, et systemd le maintient actif après le démarrage même si l’utilisateur n’est pas connecté en SSH. Plusieurs Cells peuvent coexister sur un serveur sans que l’OAuth ou la Memory de l’un serve de fallback à un autre.

En revanche, j’ai décidé de ne pas donner aux AI Cells sudo, un mount complet du NAS, les credentials d’administrateur de la DB de production ni le Docker socket. La documentation officielle de Docker avertit aussi que le group docker accorde des privilèges de niveau root.² Ajouter par commodité les comptes humains, IA et service à ce group effacerait en pratique les frontières que je venais de tracer.

Les opérations Docker seront effectuées explicitement par un administrateur humain avec sudo, ou par un helper limité appartenant à root et une systemd unit n’acceptant que des opérations prédéfinies. L’IA pourra coordonner un déploiement, mais ne disposera pas directement d’un shell arbitraire ni de tous les droits Docker.

Le NAS comme ingress, Linux comme application Runtime

Le serveur Linux n’est pas consacré au seul AI Orchestration. Le Web, l’API et la DB d’Operations Automation doivent également fonctionner dessus dans un Docker Runtime. Cela ne signifie pas tout placer dans un seul compte, un seul Compose project et une seule network.

Les connexions externes continueront d’utiliser le HTTPS et le reverse proxy déjà gérés par le NAS. Linux exécutera les applications elles-mêmes.

utilisateur externe
→ HTTPS 443
→ routeur de l’entreprise
→ TLS et hostname reverse proxy du NAS
→ frontend Linux
→ API interne Docker
→ DB interne Docker

Il n’est pas nécessaire d’exposer directement à Internet le port d’administration du NAS, le SSH Linux ni les ports de l’API et de la DB. Le NAS reste l’ingress qui gère hostnames et certificats, ainsi qu’un point de storage et de backup ; Linux prend en charge l’application Runtime. Je ne jette pas le chemin HTTPS externe créé en migrant l’automatisation des congés vers le NAS : seul le backend final sera déplacé vers le serveur dédié.

J’ai également séparé le déploiement du code de l’import des données RH depuis le NAS.

code
→ vérifier release et artifact hash
→ deploy helper restreint
→ health check et rollback

données RH
→ dossier read-only approuvé sur le NAS
→ staging, validation et preview
→ approbation
→ DB transaction et audit

AI Orchestration peut analyser un changement et demander une approbation. Le déploiement réel et l’import de données seront toutefois exécutés séparément par un broker et un importer qui n’acceptent que des opérations définies. Le MacBook peut servir au développement, au dry-run, au contrôle des previews et au lancement d’un travail approuvé, mais ne sera pas le point de canonical mutation de la DB de production.

Le serveur Linux n’a pas encore Docker ni d’application DB. Je ne l’ai donc pas appelé production backend simplement parce que la réservation DHCP et SSH fonctionnaient. Le target du reverse proxy NAS ne pourra changer qu’une fois prêts le frontend port exact, le health check, backup et restore, et rollback.

Un Codex Skill qui conserve toute la topology du réseau

La continuité avec la conversation suivante comptait autant que la configuration du serveur elle-même.

J’ai mis à jour un Codex Skill dédié au réseau de l’entreprise et son inventaire détaillé avec les relations entre le routeur, les deux NAS, le Mac Runtime existant, le nouveau serveur Linux, le HTTPS externe et le SSH interne. Il ne s’agit pas d’une simple liste d’IP : il distingue le rôle de chaque équipement ainsi que l’origine, les hops intermédiaires et le Runtime final de chaque flux de traffic.

Le Skill ne mélange pas non plus les faits accomplis avec la structure future.

• L’installation et le redémarrage d’Ubuntu, ainsi que le SSH interne, sont terminés.
• Les identities multi-utilisateurs et les limites de droits sont définies, mais les comptes ne sont pas encore créés.
• Docker, les AI Cells et Operations Automation ne sont pas encore déployés sous Linux.
• Le reverse proxy du NAS ne basculera vers Linux qu’après la mise en place de health et rollback.

Désormais, même dans une nouvelle session Codex, je n’ai plus besoin de commencer par expliquer : « Quelle était l’IP du serveur ? », « Le NAS exécute-t-il l’application ? » ou « Pourquoi le service SSH était-il disabled ? ». Le Skill transmet ensemble la topology réelle, les frontières de sécurité, l’état vérifié et ce qui reste inachevé.

Ce serveur n’est donc pas encore un production server achevé, mais ce n’est pas non plus un SSD vide sur lequel seul Ubuntu est installé. La prochaine étape consiste à mettre réellement en service les comptes humains, les AI Cells et l’Operations Automation Runtime dans les frontières déjà définies.

Désormais, chaque fois que j’installerai quelque chose, je pense que je demanderai d’abord : « Sous quel compte cela s’exécutera-t-il ? », « Quels HOME et credentials possédera-t-il ? » et « Quels ports et data flows seront autorisés ? ». Plus que d’avoir construit un serveur, j’ai le sentiment d’avoir d’abord défini les règles qui permettront de l’agrandir sans le casser sans cesse.

Références

1. Une socket unit systemd peut surveiller un socket et activer le service correspondant à l’arrivée d’incoming traffic. Manuel officiel de systemd.socket ↩

2. Le group docker, qui peut accéder au Unix socket du Docker daemon, accorde des privilèges de niveau root. Étapes après l’installation de Docker Engine sous Linux ↩