Hosts van het park

Machinevertaling van het Franse origineel.

Deze pagina is een referentiepagina. Hij geeft geen informatie, maar geeft de exacte waarden en geeft aan welke waarden verlopen.

Tabel van de hosts

Host	Type	Rol
Mac Pro	fysiek apparaat	Hoofd Obsidian, synchronisatie van de vault – hostt sinds 2026-09-05 geen VM's meer
vm-compute-02	mini-PC, Proxmox hypervisor	Hostt de vier VM's van het park
vm-claude	VM (KVM)	Ontwikkel VM, vault is ingesteld, geen Docker
vm-docker	VM (KVM)	~100 containers: reverse proxy, SSO, forge, databases
vm-addons	VM (KVM)	~30 containers: MCP gateway en kleine services van de GPU host
vm-agents	VM (KVM)	Sandbox voor de AI-agenten van het team – geen geheimen van het park worden hier opgeslagen
vm-compute-01	fysiek apparaat	~85 containers, GPU, lokale inferentie, domotica
NAS Synology	NAS	NFSv4, edge WAN, bron van de vault, ~35 containers
pi-bao	Raspberry Pi, zonder Docker	Bestemd voor de vault van machine geheimen (OpenBao), verder niets
vps-fr-ovh	VPS	Enkel host buiten het lokale netwerk, ~15 containers
paw-01	Laptop onder Linux	Administratie station; onbereikbaar = in sluimerstand tot het tegenovergestelde bewezen is

De containers zijn op 2026-10-06 geregistreerd: ze veranderen elke week, de datum geeft aan wanneer ze van kracht zijn.

De adressen staan hier niet, en dat is opzettelijk

Deze documentatie is openbaar. Het adresplan, de accounts en de poorten staan in de private vault – ze worden niet gepubliceerd en zijn niet nodig om te begrijpen hoe het park is opgebouwd. In deze pagina's wordt een machine aangeduid door zijn rol en een toegang via een merk zoals <user>@<hôte> -p <port-ssh>.

Twee eigenschappen verdienen het om genoemd te worden, omdat ze:

• SSH-poorten zijn niet de standaard. Eenssh <hôte> zonder-p faalt niet noodzakelijk: het gaat in een timeout, wat lijkt op een uitgeschakelde machine;
• De netwerkconfiguratie van het mesh-netwerk is veranderd (van een gehoste service naar een zelf gehoste instantie). Alle adressen van het mesh-netwerk zijn op die dag veranderd. Een adres dat vóór die datum is vastgesteld, is verlopen, en er wordt hier niets over gezegd – vandaar de regel: een inventaris van adressen heeft een datum van vaststelling, anders is het waardeloos.

Basis en bijzonderhedendocker

Host	Basis	Aanroepdocker
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 pad vereist
vm-addons	/opt/docker/<stack>/	docker direct
vps-fr-ovh	/opt/docker/<stack>/	docker direct, geen sudo

Praktische consequentie: elk script dat op/opt/docker/ naar de basisbestanden zoekt op alle hosts, mist het NAS zonder een foutmelding.

Fysieke locatie{ #emplacement-physique }

Vanaf 2026-08-27 bevinden zich het NAS en de twee DX517 in de kelder, in de ruimte met ventilatie die al vm-compute-01 herbergt. Twee effecten werden gemeten op de dag van de verplaatsing:

• Temperatuur van de schijven: HDD 40–44 → 34–40 °C, SSD 39 → 31–32 °C, NVMe 50/55 → 45 °C;
• De 1 Gbit/s verbinding tussen de twee ruimtes is verdwenen –rtx → nas gemeten op 2354/1583 Mbit/s,rtx → vm-docker op 2209/2348, in vergelijking met 940/940 vier dagen eerder.

Op deze verbindingen is ~940 Mbit/s nu een afwijking, en geen normaal fenomeen.

Beide virtuele machines zijn op 2026-09-05 van de Mac vertrokken: ze draaien nu op de Proxmox hypervisor, ook in de kelder, en zijn verbonden met vm-addons (die op dezelfde dag zijn aangemaakt) en vm-agents (2026-10-02). De Mac bevat nu alleen Obsidian en synchronisatie. Het IP-adres van de virtuele machines is niet veranderd – het is statisch in de gast, dus het volgt het schijf: een hostmigratie ongeldigkt geen derden-webhooks of reverse proxies. De naam van de interface is wel veranderd (het is afgeleid van het PCI-pad): alle scripts die de interface noemden, zijn op die dag stil.

Een virtuele machine die slaapt is geen defecte virtuele machine

De Mac gaat in slaap wanneer het systeem dat besluit, op elk moment. Er wordt niets gedaan om hem te meten, en dat is de gewenste situatie. Dit heeft de volgende gevolgen voor elke monitor die hem probeert te meten:

1. Een timeout is een onbepaalde toestand, geen defect. Je kunt alleen conclusies trekken wanneer de machine actief is;
2. Geen tijdgebonden controles. Een "nacht"-controle laat een valse melding door voor elke dagelijkse dut en verbergt tegelijkertijd een echte nachtelijke storing. De controle richt zich op de oorzaak (de host is niet bereikbaar) of op een duur, nooit op de tijd;
3. De doelwit niet wakker maken om te meten. Een monitor die zijn doelwit wakker maakt, meet zijn eigen activiteit.

Voordat je een nachtelijke storing toeschrijft aan een probleem, moet je dit controleren:

# 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

Twee sessies hebben per ongeluk een bestandssysteem-defect aan deze machine toegeschreven: de Mac was niet in slaap, de gast had geen time-jumped, en de diagnose kostte negen uur. Een timeout 's nachts kan worden gediagnosticeerd, het is niet vanzelfsprekend.

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