Hôtes du parc

Page de référence. Elle ne raconte rien : elle donne les valeurs exactes, et signale celles qui se périment.

Tableau des hôtes

Hôte	Nature	Rôle
Mac Pro	machine physique	Obsidian principal, synchronisation du vault — n'héberge plus aucune VM depuis le 2026-09-05
vm-compute-02	mini-PC, hyperviseur Proxmox	porte les quatre VM du parc
vm-claude	VM (KVM)	VM de développement, vault monté, pas de Docker
vm-docker	VM (KVM)	~100 conteneurs : reverse proxy, SSO, forge, bases
vm-addons	VM (KVM)	~30 conteneurs : passerelle MCP et petits services sortis de l'hôte GPU
vm-agents	VM (KVM)	bac à sable des agents IA de l'équipe — aucun secret du parc n'y est déposé
vm-compute-01	machine physique	~85 conteneurs, GPU, inférence locale, domotique
NAS Synology	NAS	NFSv4, edge WAN, source de vérité du vault, ~35 conteneurs
pi-bao	Raspberry Pi, sans Docker	dédié au coffre des secrets machines (OpenBao), rien d'autre
vps-fr-ovh	VPS	seul hôte hors LAN, ~15 conteneurs
paw-01	portable sous Linux	poste d'administration ; injoignable = en veille jusqu'à preuve du contraire

Comptes de conteneurs relevés le 2026-10-06 : ils bougent chaque semaine, la date dit de quand ils datent.

Les adresses ne sont pas ici, et c'est volontaire

Cette documentation est publique. Le plan d'adressage, les comptes et les ports d'accès vivent dans le vault privé — ils ne sont ni publiés, ni nécessaires pour comprendre comment le parc est bâti. Partout dans ces pages, une machine est désignée par son rôle et un accès par une marque du type <user>@<hôte> -p <port-ssh>.

Deux propriétés méritent quand même d'être connues, parce qu'elles expliquent des pannes :

• les ports SSH ne sont pas ceux par défaut. Un ssh <hôte> sans -p n'échoue pas franchement : il part en timeout, ce qui ressemble à une machine éteinte ;
• le plan de contrôle du réseau maillé a changé (passage d'un service hébergé à une instance auto-hébergée). Toutes les adresses du maillage ont changé ce jour-là. Une adresse relevée avant cette date est périmée, et rien dans sa forme ne le dit — d'où la règle : un inventaire d'adresses porte sa date de relevé, ou il ne vaut rien.

Bases Compose et particularités docker

Hôte	Base Compose	Invocation docker
vm-docker	/opt/docker/<stack>/	docker direct
vm-compute-01	/opt/docker/<stack>/	docker direct
NAS Synology	/volume3/docker/<stack>/	sudo -n /usr/local/bin/docker — chemin absolu obligatoire
vm-addons	/opt/docker/<stack>/	docker direct
vps-fr-ovh	/opt/docker/<stack>/	docker direct, pas de sudo

Conséquence pratique : tout script qui cherche les fichiers Compose sous /opt/docker/ sur tous les hôtes rate le NAS sans lever d'erreur.

Emplacement physique

Depuis le 2026-08-27, le NAS et ses deux DX517 sont à la cave, dans la pièce ventilée qui héberge déjà vm-compute-01. Deux effets mesurés le jour du déplacement :

• température des disques : HDD 40–44 → 34–40 °C, SSD 39 → 31–32 °C, NVMe 50/55 → 45 °C ;
• le plafond de 1 Gbit/s entre les deux pièces a disparu — rtx → nas mesuré à 2354/1583 Mbit/s, rtx → vm-docker à 2209/2348, contre 940/940 quatre jours plus tôt.

Sur ces chemins, ~940 Mbit/s est désormais une anomalie, plus la normale.

Les deux VM ont quitté le Mac le 2026-09-05 : elles tournent depuis sur l'hyperviseur Proxmox, en cave elles aussi, rejointes par vm-addons (créée le même jour) et vm-agents (2026-10-02). Le Mac ne porte plus qu'Obsidian et la synchronisation. L'IP des VM n'a pas bougé — elle est statique dans l'invité, donc elle voyage avec le disque : une migration d'hôte n'invalide ni les webhooks tiers, ni les upstreams du reverse proxy. Le nom de l'interface, lui, a changé (il dérive du chemin PCI) : tout script qui nommait l'interface est devenu faux ce jour-là, en silence.

Un hôte qui dort n'est pas un hôte en panne

Le Mac s'endort quand le système le décide, à n'importe quelle heure. Rien ne le réveille pour le mesurer, et c'est le régime voulu. Trois conséquences pour toute sonde qui le vise :

1. un timeout est un état indéterminé, pas une panne. On ne conclut sur cette machine que lorsqu'elle est éveillée ;
2. aucune garde par plage horaire. Une fenêtre « la nuit » laisse passer une fausse alerte à chaque sieste diurne et masque une vraie panne nocturne. La garde se pose sur la cause (l'hôte est injoignable) ou sur une durée longue, jamais sur l'heure ;
3. ne pas réveiller la cible pour la mesurer. Une sonde qui réveille son sujet mesure sa propre intrusion.

Avant d'attribuer une anomalie nocturne à une suspension, la vérifier :

# L'hôte a-t-il dormi ?
ssh -p <port-ssh> <user>@mac "pmset -g log | grep 'Entering Sleep' | tail -3"

# L'invité a-t-il sauté dans le temps ?
sudo journalctl -k --since '2026-08-24 00:00' | grep time-jumped

Deux sessions ont attribué à tort une panne de système de fichiers à cette veille : le Mac n'avait pas dormi, l'invité n'avait aucun time-jumped, et le diagnostic a coûté neuf heures. Un timeout nocturne se diagnostique, il ne s'explique pas d'avance.

Dernière vérification de cette page : 2026-10-06