Park Hosts

Machine translation of the French original.

This is a reference page. It doesn't explain anything; it simply provides the exact values and highlights those that expire.

Host Table

Host	Type	Role
Mac Pro	Physical machine	Primary Obsidian server, vault synchronization – no longer hosts any VMs since 2026-09-05
vm-compute-02	Mini-PC, Proxmox hypervisor	Hosts the four VMs in the park
vm-claude	VM (KVM)	Development VM, vault mounted, no Docker
vm-docker	VM (KVM)	~100 containers: reverse proxy, SSO, Forge, databases
vm-addons	VM (KVM)	~30 containers: MCP gateway and other services running on the GPU host
vm-agents	VM (KVM)	Sandbox for the team's AI agents – no secrets from the park are stored here
vm-compute-01	Physical machine	~85 containers, GPU, local inference, home automation
NAS Synology	NAS	NFSv4, edge WAN, vault source of truth, ~35 containers
pi-bao	Raspberry Pi, without Docker	Dedicated to the machine secrets vault (OpenBao), nothing else
vps-fr-ovh	VPS	Only host outside the LAN, ~15 containers
paw-01	Laptop running Linux	Administration workstation; inaccessible = in sleep mode until proven otherwise

Container accounts were last updated on 2026-10-06. They are updated weekly, and the date indicates when they were last updated.

Addresses are not here, and that is intentional

This documentation is public. The address plan, accounts, and access ports are stored in the private vault – they are not published or necessary to understand how the park is set up. Throughout these pages, a machine is identified by its role, and access is granted using a label of the type <user>@<hôte> -p <port-ssh>.

Two properties that are worth noting, because they explain certain failures:

• The SSH ports are not the default ones. A ssh <hôte> without -p will not fail outright; it will simply time out, which looks like the machine is turned off;
• The network mesh control plan has changed (moving from a hosted service to a self-hosted instance). All the addresses in the mesh changed on that day. An address that was recorded before that date is invalid, and there is no indication of this – hence the rule: an address inventory must have its recording date, or it is worthless.

Base Compose and peculiarities docker

Host	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 — absolute path required
vm-addons	/opt/docker/<stack>/	docker direct
vps-fr-ovh	/opt/docker/<stack>/	docker direct, no sudo

Practical consequence: any script that searches for Compose files under /opt/docker/ on all hosts will fail to find the NAS without raising an error.

Physical location

Since 2026-08-27, the NAS and its two DX517 are in the basement, in the ventilated room that already hosts vm-compute-01. Two effects were observed on the day of the move:

• Disk temperature: HDD 40–44 → 34–40 °C, SSD 39 → 31–32 °C, NVMe 50/55 → 45 °C;
• The 1 Gbit/s ceiling between the two rooms disappeared – rtx → nas measured at 2354/1583 Mbit/s, rtx → vm-docker at 2209/2348, compared to 940/940 four days earlier.

On these paths, ~940 Mbit/s is now an anomaly, rather than the norm.

Both VMs left the Mac on 2026-09-05: They have been running on the Proxmox hypervisor, also in the basement, along with vm-addons (created on the same day) and vm-agents (2026-10-02). The Mac now only runs Obsidian and synchronization. The IP address of the VMs has not changed – it is static within the guest, so it travels with the disk: a host migration does not invalidate any third-party webhooks or reverse proxies. The name of the interface, however, has changed (it derives from the PCI path): all scripts that named the interface became invalid on that day, silently.

A sleeping host is not a faulty host

The Mac goes to sleep when the system decides, at any time. Nothing wakes it up to measure it, and this is the desired state. This has three consequences for any probe that targets it:

1. A timeout is an undefined state, not a failure. We only conclude that the machine is faulty when it is awake;
2. No time-based monitoring. A "night" window allows a false alarm to occur every daytime nap and masks a real nighttime failure. The monitoring focuses on the cause (the host is unreachable) or on a duration that is never based on the time;
3. Do not wake the target to measure it. A probe that wakes its target measures its own intrusion.

Before attributing a nighttime anomaly to a suspension, verify it:

# 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

Two sessions incorrectly attributed a file system failure to this machine: the Mac had not slept, the guest had no time-jumped, and the diagnosis cost nine hours. A nighttime timeout can be diagnosed, it does not require explanation.

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