Un executor remoto è un executor Metnos che non viene lanciato sul server, ma su un dispositivo registrato dello stesso utente, per esempio un PC Windows o un portatile Linux. Il server resta il centro di decisione: sceglie se l'azione è ammessa, firma i dati della richiesta, riceve il risultato e ne conserva la traccia.
Il client supporta l'associazione guidata dall'interfaccia, l'esecuzione contenuta su Linux e Windows, la terminazione dell'albero dei processi alla scadenza, il riavvio controllato se la sandbox non restituisce il controllo, il blocco delle istanze concorrenti e la revoca dal server.
Metnos nasce come sistema domestico: molti dati sono sul server, ma non tutti. Un documento può stare sul portatile, una cartella di lavoro su un PC Windows, uno schermo o un'applicazione possono esistere solo lì. 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 è intenzionale: il dispositivo esegue, ma non decide. Il server
mantiene regole, Vaglio, scelta dell'executor, firma, registro dei dispositivi e tracciabilità.
Il client remoto, metnos-client, interroga 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 identità Ed25519. L'ingresso avviene con un codice monouso generato dal server: il client lo consuma, registra la chiave pubblica del dispositivo e registra in modo vincolante la chiave pubblica del server. Da quel momento il dispositivo non è "un browser aperto": è una macchina nota, revocabile e riconoscibile.
Il flusso dettagliato è descritto nella guida Identità e associazioni, cap. 6. La parte essenziale è: token breve, consumo una volta sola, impronta del dispositivo unica, controllo periodico della connessione e revoca esplicita dal pannello di amministrazione.
Un executor non diventa remoto per accidente. Il caricatore legge il manifest:
piattaforme ammesse, capacità, firma, eventuale sezione di collocazione
(placement). Solo se il contratto è compatibile il runtime può
assegnare il lavoro a un dispositivo.
In caso contrario l'executor resta locale o viene rifiutato con un errore
esplicito.
| Controllo | Perché conta |
|---|---|
platforms | Evita di mandare a Windows un executor scritto solo per Linux, o viceversa. |
| firma del server | Il client esegue solo codice che corrisponde a ciò che il server ha firmato. |
| capacità | Regole e Vaglio restano sul server; il dispositivo non amplia i permessi. |
| collocazione | Indica se il lavoro può stare sul server o richiede un dispositivo specifico. |
Un'integrazione con un fornitore selezionato è sempre legata al server: rete, directory delle
credenziali e collocazione derivano dalla stessa capacità effettiva
provider:access. Un servizio locale dello stesso executor non eredita quel
vincolo e resta eleggibile al dispositivo quando placement.device_ok lo
consente.
Le autorità browser, credenziali e condivisione ACL sono distinte nel registro
canonico: network:sites limita la sessione alle origini autorizzate,
auth.password_storage limita la lettura all'ambito delle credenziali e
drive:permissions identifica una concessione remota critica. Gli
executor *_sites restano collocati solo sul server.
Le risorse amministrate da Metnos usano inoltre autorità separate:
metnos:read, metnos:write,
metnos:create e il vincolo
metnos:credentials_metadata_only. Quest'ultimo impedisce agli
executor del vault di restituire segreti al pianificatore.
Nei flussi composti la presentazione segue l'operazione terminale: se una ricerca
si conclude creando un archivio, la chat restituisce una ricevuta con cartella e
artefatti, non la tabella tecnica di compress_files. Le tabelle
legittime restano contenute nella bolla e scorrono orizzontalmente quando un percorso
o un URL non può essere spezzato senza perdere informazione.
La tabella qui sopra dice se un executor può uscire dal server. Resta la
domanda pratica: su quale macchina finisce un comando che scrivi
in chat? Metnos ricava la destinazione dalla frase, senza imporre una scelta
manuale a ogni turno. Chiamiamo destinazione la macchina dove verrà
eseguito il prossimo comando — il server su cui vive Metnos oppure uno
dei PC che hai associato. Ogni PC associato ha un nome scelto da te (per esempio
PORTATILE-UFFICIO) e appartiene a un utente: il server sa quali
dispositivi 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.
Riconoscimento del dispositivo. Il PC bersaglio si riconosce dal suo nome, non da dove arriva la connessione. Riconoscerlo dall'origine di rete (l'indirizzo IP) sarebbe inaffidabile: attraverso un tunnel pubblico il server può vedere soltanto l'indirizzo del punto di ingresso, e da Telegram non c'è alcun PC dietro il messaggio. Per questo l'ancora è il nome del dispositivo — confrontato con i nomi reali dei tuoi PC associati — e non l'impronta della rete. Un nome citato a metà frase, senza una preposizione di luogo che lo ancori, non sposta la destinazione.
Il punto operativo naturale è /admin/devices: il server mostra i
dispositivi registrati e può emettere un collegamento di adesione. Se l'utente apre l'interfaccia
direttamente sul server, non c'è nulla da installare: gli executor locali sono
già disponibili. Se invece l'interfaccia gira su un PC diverso dal server, la pagina può
proporre il programma di installazione adatto alla piattaforma e mostrare lo stato di avanzamento
della registrazione.
La selezione non concede privilegi speciali al browser: su Windows scarica
MetnosClientSetup.cmd, che installa e avvia metnos-client
come processo persistente del sistema operativo. L'interfaccia mostra lo stato
dell'associazione: codice emesso, client registrato, connessione recente,
versione del client e ultimo errore.
/admin/devices) e scegli l'utente
proprietario del PC.Il collegamento è temporaneo e destinato a una sola associazione. Se il PC è già presente, verifica il dispositivo esistente prima di generarne uno nuovo.
Sul server Linux la sandbox canonica è bwrap. Su un dispositivo
remoto il contenimento è scelto dal client in base al sistema operativo, ma
l'interfaccia resta una sola: esegui questi dati con i limiti indicati e restituisci
uscita ordinaria, uscita diagnostica, codice di uscita, superamento del tempo
massimo e metadati di contenimento.
| Sistema | Contenimento attuale | Nota |
|---|---|---|
| Linux | bwrap lato client quando disponibile | Spazi dei nomi dei montaggi e PID, file system ristretto e rete separata quando non richiesta. Non usa Landlock o seccomp personalizzati. |
| Windows | AppContainer dentro un Job Object | ACL mirate per percorsi assoluti; se un percorso relativo non è ancorabile prima dell'avvio, declassamento dichiarato a Job Object senza tentare ACL ambigue. |
| macOS | Nessuna sandbox nativa | Il percorso Unix comune esegue senza involucro del sistema operativo e dichiara sandbox:"none". |
Vedi sandbox, cap. 10 per il dettaglio per-OS. Il risultato remoto riporta sempre il contenimento realmente applicato; un controllo separato termina il client, affidandone il riavvio al supervisore, se la sandbox non restituisce il controllo entro la scadenza più un margine limitato.
Il canale è costruito per una rete domestica imperfetta. Il client interroga periodicamente il server, quindi non richiede porte aperte sul PC. Ogni invocazione ha un'identità stabile e una scadenza: se la rete cade, il server può distinguere fra lavoro non ancora preso, lavoro in corso e risultato già consegnato. Se un client resta bloccato, il vincolo locale impedisce una seconda istanza concorrente; se un lavoro supera il tempo massimo, il client spegne l'albero dei processi. Il battito del client gira in un compito separato, quindi il dispositivo resta osservabile anche mentre sta preparando il proprio ambiente di esecuzione.
La revoca avviene sul server: il dispositivo revocato riceve errore quando interroga il server o manda il battito, e smette di ricevere lavoro. Il server non deve fidarsi del fatto che il vecchio client "si comporti bene": smette semplicemente di assegnargli richieste.
Gli executor remoti non significano «esegui qualunque codice sul PC». Significano: esegui solo executor firmati, compatibili con la piattaforma, ammessi dalle regole e sufficientemente contenuti dal client. Gli executor mutanti ammessi (scrittura e spostamento file) includono l'annullamento: l'operazione inversa viene eseguita sullo stesso dispositivo, mai sul server. Anche la cancellazione remota è ammessa: il backup (blob) viene scritto sul dispositivo prima della rimozione e l'annullamento lo ripristina sullo stesso dispositivo.
none non va descritta come isolata.