Un executor remoto e' un executor Metnos che non viene lanciato sul server, ma su un dispositivo registrato della stessa casa: un PC Windows, un portatile Linux, in futuro altri sistemi. Il server resta il centro di decisione: sceglie se l'azione e' ammessa, firma il payload, riceve il risultato e scrive l'audit.
0.2.7, con join dalla UI, Job Object, timeout con kill dell'albero,
lock single-instance e revoca via 403. Il dettaglio di progetto esteso
resta nel documento interno internal/design/remote-executors.html.
Metnos nasce come sistema domestico: molti dati sono sul server, ma non tutti. Un documento puo' stare sul portatile, una cartella di lavoro su un PC Windows, uno schermo o un'applicazione possono esistere solo li'. Gli executor remoti servono a portare una parte controllata del catalogo dove i dati vivono davvero, senza trasformare ogni macchina in un secondo Metnos.
L'asimmetria e' intenzionale: il dispositivo esegue, ma non decide. Il server
mantiene policy, Vaglio, scelta dell'executor, firma, registro dei device e audit.
Il client remoto, metnos-client, fa polling verso il server, verifica
la firma del lavoro ricevuto, esegue nel contenimento disponibile per il suo OS e
restituisce un risultato firmato.
Ogni dispositivo ha una propria identita' Ed25519. L'ingresso avviene con un codice monouso generato dal server: il client lo consuma, registra la chiave pubblica del dispositivo e riceve la chiave pubblica del server da pinning. Da quel momento il dispositivo non e' "un browser aperto": e' una macchina nota, revocabile e riconoscibile.
Il flusso dettagliato vive in pairing, cap. 13. La parte essenziale e': token breve, consumo una volta sola, impronta del device unica, heartbeat periodico, revoca esplicita dal pannello admin.
Un executor non diventa remoto per accidente. Il loader guarda il manifest: piattaforme ammesse, capability, firma, eventuale sezione di placement. Solo se il contratto e' compatibile il runtime puo' assegnare il lavoro a un dispositivo. In caso contrario l'executor resta locale o viene rifiutato con un errore onesto.
| Controllo | Perche' conta |
|---|---|
platforms | Evita di mandare a Windows un executor scritto solo per Linux, o viceversa. |
| firma server | Il client esegue solo codice che corrisponde a cio' che il server ha firmato. |
| capability | Policy e Vaglio restano server-side; il device non amplia i permessi. |
| placement | Indica se il lavoro puo' stare sul server o richiede un dispositivo specifico. |
La tabella qui sopra dice se un executor puo' uscire dal server. Resta la
domanda pratica: su quale macchina finisce, allora, un comando che scrivi
in chat? Metnos risponde senza pannelli e senza scelte manuali: lo capisce dalla
frase. Chiamiamo destinazione la macchina dove verra' eseguito il prossimo
comando — il server (la macchina .33 dove vive Metnos) oppure uno
dei PC che hai appaiato, cioe' registrato una volta con la procedura di
pairing. Ogni PC appaiato ha un nome scelto da te (per esempio
PORTATILE-UFFICIO) e appartiene a un utente: il server sa quali device
sono tuoi.
Il colloquio qui sotto mostra la stessa chat che cambia destinazione turno dopo turno. A destra, i tre passi con cui Metnos decide dove eseguire, le due garanzie e uno schema del bivio server / PC.
127.0.0.1, e da Telegram non c'e' alcun PC dietro il messaggio. Per questo
l'ancora e' il nome del device — confrontato con i nomi reali dei tuoi PC appaiati
— e non l'impronta della rete. Un nome citato a meta' frase, senza una
preposizione di luogo che lo ancori, non sposta la destinazione.
Il punto operativo naturale e' /admin/devices: il server mostra i
device registrati e puo' emettere un link di adesione. Se l'utente apre la UI
direttamente sul server, non c'e' nulla da installare: gli executor locali sono
gia' disponibili. Se invece la UI gira su un PC diverso dal server, la pagina puo'
proporre l'installer adatto alla piattaforma e mostrare lo stato di avanzamento
della registrazione.
Il click non concede privilegi speciali al browser: su Windows scarica
MetnosClientSetup.cmd, che installa e avvia metnos-client
come processo persistente del sistema operativo. La UI osserva il join: token
emesso, client registrato, heartbeat vivo, versione client, ultimo errore.
Sul server Linux la sandbox canonica e' bwrap. Su un dispositivo
remoto il contenimento e' scelto dal client in base al sistema operativo, ma
l'interfaccia resta una sola: esegui questo payload con questi limiti e restituisci
stdout, stderr, codice di uscita, timeout e metadati di contenimento.
| Sistema | Contenimento attuale | Nota |
|---|---|---|
| Linux | bwrap lato client quando disponibile | Isolamento forte su filesystem e rete, coerente col modello server. |
| Windows | Job Object + limiti di processo | Utile per timeout e kill dell'albero; non e' ancora isolamento completo di filesystem/rete. |
| macOS | Backend previsto | Da abilitare solo quando il contenimento sara' verificato. |
Vedi sandbox, cap. 10 per il dettaglio per-OS e per il motivo per cui Windows AppContainer resta il prossimo passo di irrobustimento.
Il canale e' costruito per una rete domestica imperfetta. Il client fa polling,
quindi non richiede porte aperte sul PC. Ogni invocazione ha idempotenza e una
deadline: se la rete cade, il server puo' distinguere fra lavoro non ancora preso,
lavoro in corso e risultato gia' consegnato. Se un client resta appeso, il lock
locale impedisce una seconda istanza concorrente; se un job supera il timeout, il
client spegne l'albero dei processi. Dal client 0.2.7 il heartbeat
gira in un task separato, quindi il dispositivo resta osservabile anche mentre
sta preparando il proprio ambiente di esecuzione.
La revoca e' server-side: il dispositivo revocato riceve errore al polling o al heartbeat e smette di ricevere lavoro. Il server non deve fidarsi del fatto che il vecchio client "si comporti bene": smette semplicemente di assegnargli payload.