Host del parco¶
Traduzione automatica dell'originale francese.
Pagina di riferimento. Non fornisce informazioni, ma indica i valori esatti e quelli che scadono.
Tabella degli host¶
| Host | Tipo | Ruolo |
|---|---|---|
| Mac Pro | macchina fisica | Obsidian principale, sincronizzazione del vault – non ospita più alcuna VM dal 2026-09-05 |
| vm-compute-02 | mini-PC, hypervisor Proxmox | ospita le quattro VM del parco |
| vm-claude | VM (KVM) | VM di sviluppo, vault attivo, senza Docker |
| vm-docker | VM (KVM) | circa 100 container: reverse proxy, SSO, forge, database |
| vm-addons | VM (KVM) | circa 30 container: gateway MCP e piccoli servizi provenienti dall'host GPU |
| vm-agents | VM (KVM) | ambiente sandbox per gli agenti IA del team – nessun segreto del parco è memorizzato qui |
| vm-compute-01 | macchina fisica | circa 85 container, GPU, inferenza locale, domotica |
| NAS Synology | NAS | NFSv4, edge WAN, fonte di verità del vault, circa 35 container |
| pi-bao | Raspberry Pi, senza Docker | dedicato al vault dei segreti delle macchine (OpenBao), niente di più |
| vps-fr-ovh | VPS | unico host al di fuori della rete locale, circa 15 container |
| paw-01 | laptop con Linux | stazione di amministrazione; inaccessibile = in modalità di sospensione fino a prova contraria |
I container sono stati identificati il 06-10-2026: cambiano ogni settimana, la data indica quando sono stati creati.
Gli indirizzi non sono qui, ed è intenzionale
Questa documentazione è pubblica. Il piano degli indirizzi, gli account e le porte di accesso risiedono nel vault privato – non sono pubblicati né necessari per capire come è strutturato il parco. In ogni pagina, una macchina è identificata dal suo ruolo e l'accesso tramite un marchio del tipo <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-pn'é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 ospitato su un'istanza auto-gestita). Tutte le indirizzi della rete sono stati modificati in quella data. Un indirizzo rilevato prima di quella data è diventato non valido, e non ci sono indicazioni al riguardo – da cui la regola: un inventario di indirizzi deve indicare la data di rilevamento, altrimenti non ha alcun valore.
Basi di dati e peculiarità docker¶
| Host | Base di dati | Invocazione docker |
|---|---|---|
| vm-docker | /opt/docker/<stack>/ |
docker diretto |
| vm-compute-01 | /opt/docker/<stack>/ |
docker diretto |
| NAS Synology | /volume3/docker/<stack>/ |
sudo -n /usr/local/bin/docker — percorso assoluto obbligatorio |
| vm-addons | /opt/docker/<stack>/ |
docker diretto |
| vps-fr-ovh | /opt/docker/<stack>/ |
docker diretto, senza sudo |
Conseguenza pratica: qualsiasi script che cerca i file Compose sotto /opt/docker/ su tutti gli host fallisce nel trovare il NAS senza generare errori.
Posizione fisica¶
Dal 27 agosto 2026, il NAS e i suoi due DX517 si trovano nel seminterrato, nella stanza ventilata che ospita già vm-compute-01. Due effetti misurati il giorno del trasferimento:
- temperatura dei dischi: HDD 40–44 → 34–40 °C, SSD 39 → 31–32 °C, NVMe 50/55 → 45 °C;
- la rete Gigabit tra le due stanze è scomparsa —
rtx → nasmisurata a 2354/1583 Mbit/s,rtx → vm-dockera 2209/2348, rispetto a 940/940 quattro giorni prima.
Su questi percorsi, ~940 Mbit/s è ora un'anomalia, più che la norma.
Le 5 settembre 2026, entrambe le VM sono state disconnesse dal Mac: da allora, girano sull'hypervisor Proxmox, anche in un ambiente sotterraneo, insieme a vm-addons (creata lo stesso giorno) e vm-agents (2 ottobre 2026). Il Mac ora contiene solo Obsidian e la sincronizzazione. L'indirizzo IP delle VM non è cambiato: è statico nell'ambiente guest, quindi lo accompagna con il disco: una migrazione dell'host non invalida né i webhook di terze parti, né i proxy inversi. Il nome dell'interfaccia, invece, è cambiato (deriva dal percorso PCI): tutti gli script che nominavano l'interfaccia sono diventati errati in quel momento, silenziosamente.
Un host inattivo non è un host guasto¶
Il Mac si mette inattivo quando il sistema lo decide, in qualsiasi momento. Non viene riattivato per essere monitorato, e questo è il comportamento desiderato. Ciò ha tre conseguenze per qualsiasi sonda che lo monitora:
- Un timeout è uno stato indefinito, non un guasto. Si possono trarre conclusioni su questa macchina solo quando è attiva;
- Nessuna guardia basata sull'orario. Una finestra "di notte" permette di ignorare un falso allarme ogni volta che il sistema si riposa e nasconde un vero guasto notturno. La guardia si basa sulla causa (l'host non è raggiungibile) o sulla durata, mai sull'ora;
- Non riattivare l'host per monitorarlo. Una sonda che riattiva il suo soggetto misura la propria intrusione.
Prima di attribuire un guasto notturno a una sospensione, è necessario verificarlo:
# 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
Due sessioni hanno erroneamente attribuito un guasto del sistema di file a questa notte: il Mac non era inattivo, l'ambiente guest non aveva problemi time-jumped, e la diagnosi ha richiesto nove ore. Un timeout notturno può essere diagnosticato, non è intrinsecamente spiegabile.
Dernière vérification de cette page : 2026-10-06