Executori la distanță
Oferiți unui agent un calculator real cu care să lucreze, pe Linux, macOS sau Windows.
Ce este un executor de la distanță
Un agent din Nessie nu are calculator. Poate citi ce există în Nessie, poate vorbi cu oamenii și poate apela instrumente conectate prin rețea, dar nu poate deschide un fișier de pe un laptop, nu poate rula o comandă și nu poate vedea o pagină care există doar în spatele unui cont al cuiva. Un executor de la distanță este modul în care îi oferiți un calculator pe care să lucreze.
Un executor este un daemon mic pe care îl instalați pe un calculator pe care îl controlați. Se conectează spre exterior la instanța dvs. Nessie, dovedește ce mașină este cu ajutorul unei chei care nu părăsește niciodată gazda și apoi oferă un set fix, denumit, de operații — nimic altceva. Lucrul ajunge sub formă de comenzi semnate individual; rezultatele se întorc sub formă de confirmări structurate și limitate. Mașina nu acceptă niciodată o conexiune de intrare din partea Nessie.
Merită să fiți precis în privința a ceea ce un executor nu este, pentru că majoritatea instrumentelor de acces la distanță sunt unul dintre aceste lucruri, iar un executor nu este deliberat niciunul dintre ele. Nu există SSH, nu există un shell de la distanță permanent, nu există atașare la un multiplexor de terminal pe care îl aveți deja deschis, nu există intrare standard din cloud și nu există un proxy general pentru rețeaua locală. Nu este un server MCP și nu este un container sau un mediu de execuție în cloud — Nessie are deja asemenea lucruri, iar ele sunt altceva. Un executor este un punct final care poartă o capabilitate, cu o listă închisă de operații, iar această listă reprezintă întreaga suprafață.
Cui aparține un executor
Fiecare executor este creat cu exact un domeniu, iar acel domeniu nu mai poate fi schimbat ulterior. Domeniul decide cine poate invoca executorul și cine îl poate administra.
| Domeniu | Cine îl poate invoca | Cine gestionează accesul |
|---|---|---|
| Privat | Persoana care face solicitarea și agentul invocat exact trebuie amândoi să fie desemnați ca responsabili. Nici unul singur nu este suficient. | Un administrator uman desemnat. Agenții pot folosi un executor privat, dar nu îl pot administra. |
| Proiect | O persoană care are drepturi asupra proiectului exact și doar dintr-o rulare din acel proiect. | Un manager al organizației, sau un proprietar ori administrator al proiectului. |
| Organizație | O persoană cu drepturi la nivelul organizației. | Un manager al organizației. |
Un executor privat trebuie să aibă întotdeauna cel puțin un administrator uman activ. Eliminarea directă a ultimului eșuează; dacă o tranzacție de offboarding ar lăsa niciunul, executorul nu mai acceptă lucrări noi, își încheie lucrul pe care îl are și se revocă singur. Un proprietar al organizației are o cale de urgență doar pentru revocare, care încheie un executor pe care nu îl administrează altfel, fără să îi arate lista sa privată de membri, sesiunile sau conținutul — accesul privat nu este transferat niciodată în tăcere altcuiva.
Ce poate face efectiv un agent cu el
Vocabularul de operații este fixat în cod, nu este configurat pe fiecare instalare. Se împarte în două, iar această împărțire decide ce trebuie instalat: unele operații le servește daemonul din propriul director temporar, fără nicio mașină virtuală, iar restul au nevoie de o mașină virtuală oaspete per sesiune, pe gazdă.
| Operație | Ce face | Mașină virtuală oaspete |
|---|---|---|
file.list, file.read | Listează și citește fișiere din rădăcina de lucru unică aleasă la asociere. | Nu |
file.write | Scrie într-o ciornă copy-on-write a acelei rădăcini de lucru. Nu deschide niciodată rădăcina reală pentru scriere. | Nu |
workspace.review | Raportează ce a modificat ciorna — până la 100 de căi relative, cu tip și dimensiune în octeți, plus un digest al manifestului. Nu conține conținutul fișierelor. | Nu |
sandbox.stop | Dezafectează sesiunea pe care o deține rularea. | Nu |
command.run | Rulează o singură comandă ca vector de argumente fără shell, într-un oaspete fără acces la rețea. Pe această cale nu există nicăieri un șir de shell. | Da |
browser.open, browser.observe, browser.act | Conduce un browser din interiorul oaspetelui, pe o listă de origini configurată pe mașină. Observarea returnează un arbore de accesibilitate limitat și, opțional, o imagine redusă; acțiunile sunt navigare, clic, tastare, apăsare și derulare, aplicate asupra unui nod pe care agentul tocmai l-a observat — niciodată un selector, o coordonată sau un script. | Da |
coding.launch, coding.observe | Pornește o sesiune Codex gestionată în oaspete și citește starea tipizată a ciclului de viață. Nu există atașare la terminal și nici canal de prompturi: agentul află dacă sesiunea rulează, nu ce apare pe ecranul ei. | Da |
workspace.promote | Aplică o ciornă revizuită la spațiul de lucru real. Aceasta este singura operație care scrie pe gazdă și, deliberat, nu este oferită deloc modelelor. | Nu |
Operațiile care nu au nevoie de oaspete formează pachetul de spațiu de lucru. O gazdă care nu poate porni un oaspete nu este un executor defect: se asociază normal, raportează backend-ul de sandbox ca none și anunță doar pachetul de spațiu de lucru, nimic altceva. Aceasta este starea în care ajunge o ediție Windows fără Hyper-V sau o mașină Linux al cărei utilizator nu poate folosi /dev/kvm, iar interfața o numește în loc să eșueze confuz.
Lucrul cu browserul nu este niciodată ceva pe care un agent îl pornește din proprie inițiativă. Ruta obișnuită de asociere a unei singure operații refuză explicit browser.open și browser.observe; o rulare de browser este lansată de o persoană dintr-un canal, ca un pachet de patru operații pe o rulare nouă, iar după aceea nu mai poate fi adăugată nicio asociere suplimentară. Sesiunile de programare gestionate funcționează la fel.
Există încă două grupuri în cod, care sunt intenționat indisponibile. Operațiile pentru controlul unei file Chrome în care sunteți deja autentificați au o implementare locală completă și o extensie cu mesagerie nativă, dar planul de control refuză să le anunțe până când serverul poate dovedi că conversația de origine a fost privată și poate înregistra cine a dezvăluit ce — fundația este inertă intenționat, iar extensia nu este livrată în niciunul dintre instalatoare. Și mai multe operații de programare — atașare, prompt, întrerupere și închidere — sunt numite în schemă, dar nu au implementare, deci nu pot fi acordate.
Cum funcționează
Conexiunea este întotdeauna de ieșire
Daemonul deschide conexiuni HTTPS și WSS de ieșire către API-ul dvs. Nessie și către nimic altceva. Nessie nu se conectează niciodată la un laptop, nu deține nicio adresă pentru acesta și nu tratează niciodată un punct final din catalog ca transport către o mașină. De aceea un executor funcționează dintr-o rețea de acasă, în spatele NAT, pe un VPN corporativ, fără redirecționare de port și fără regulă de firewall pentru intrare — și de aceea oprirea daemonului înseamnă o deconectare completă și imediată.
Originea API-ului trebuie să fie HTTPS. Singura excepție este o adresă loopback pentru persoanele care rulează Nessie pe propria mașină, printr-o variabilă de mediu separată; niciun indicator obișnuit nu transformă o origine de producție în HTTP simplu.
Asocierea dovedește o mașină, iar o persoană o confirmă
Asocierea este o dovadă cu două părți. O persoană cu drepturi creează executorul în Nessie cu domeniul său, iar Nessie emite o înscriere: o provocare aleatoare de 256 de biți, din care stochează doar un verificator SHA-256, valabilă zece minute și folosibilă o singură dată.
Pe mașină, daemonul generează o pereche de chei Ed25519, o stochează într-un spațiu protejat de sistemul de operare, accesibil doar proprietarului, și scrie pe disc cererea semnată exactă înainte de a face orice apel de rețea — astfel încât un răspuns pierdut poate fi reîncercat cu aceeași cheie pregătită, nu asociat din nou în tăcere. Apoi trimite identificatorul înscrierii, provocarea, cheia publică și o semnătură de dovadă. Nessie stochează cheia publică și amprenta ei. Niciodată nu stochează cheia privată.
Nessie arată apoi amprenta respectivă unei persoane, care o confirmă. Până la această confirmare și o dovadă ulterioară a deținerii cheii, executorul rămâne offline. Asocierea nu poate fi finalizată niciodată dintr-un text de chat sau dintr-o transcriere de terminal: necesită o acțiune umană deliberată în interfața web sau desktop.
O mașină care își pierde cheia nu își poate recupera înregistrarea de executor. Aceasta este revocată și înscrisă din nou ca executor nou. Rotirea cheii, în schimb, este o singură tranzacție semnată atât cu vechea cheie, cât și cu cea nouă.
Descriptorul este declarația semnată a mașinii despre sine
Un daemon asociat publică un descriptor: o declarație semnată, revizuită monoton, despre fapte strict structurale — ce scheme de operații acceptă, limitele sale de resurse și de rețea, platforma și un digest al politicii sale locale. Nu conține căi de pe gazdă și nu creează nicio autoritate în cloud.
O revizie nouă nu se activează niciodată la sosire. Este stocată în așteptarea revizuirii, iar o persoană cu drepturi trebuie să o vadă și să o confirme înainte ca ea să poată afecta ce este disponibil. Aceasta împiedică o reîmprospătare a capabilităților să acorde în tăcere putere nouă: o operație nou anunțată începe refuzată.
Fiți clar în privința a ce dovedește semnătura. Un descriptor semnat de o cheie de executor asociată dovedește că acea cheie a făcut declarația. Nu dovedește că gazda nu este compromisă, iar interfața este obligată să spună acest lucru.
Distribuirea: candidat, asociere, comandă, confirmare
Un agent nu numește niciodată un executor. Înainte ca o rulare să poată folosi unul, Nessie rezolvă operația logică într-un candidat de disponibilitate opac și de scurtă durată. Răspunsul nu conține niciun identificator de executor; baza de date păstrează doar un digest al mânerului, împreună cu cine și pentru ce a fost rezolvat. Modelele și clienții primesc un mâner, nu o mașină pe care să o poată alege.
Disponibilitatea este un singur rezolvator, folosit identic de API, de worker, de interfață și de asistent:
available(operation, human, agent, immutableRunContext) =
human may discover executor
∩ exact executor-agent-operation grant allows operation
∩ stable logical tool grant allows operation
∩ scope matches immutable run context
∩ executor is online and descriptor is approved
∩ local policy permits operationConsumarea candidatului creează o asociere sub un blocaj al bazei de date, care verifică din nou fiecare dintre aceste porți și avansează un contor monoton. Distribuirea le verifică din nou. Consecința este că o permisiune retrasă, o politică restrânsă sau un executor revocat între doi pași opresc lucrul, în loc să fie observate abia după aceea — iar o reîncercare nu poate ajunge niciodată pe o altă mașină decât cea de care era legată rularea.
Comanda în sine circulă prin coada obișnuită a Nessie și prin ciclul de viață al apelului de instrument, nu printr-o a doua coadă proprie. Daemonul interoghează pentru lucru prin canalul său de control autentificat; nu i se trimite niciodată nimic. O comandă trece prin patru confirmări și nicio altă stare:
leased → accepted → started → result-acknowledgedFiecare cadru leagă identificatorul comenzii, proveniența rulării, contorul de asociere, revizia capabilității, o expirare, o cheie de idempotență și digesturile atât ale argumentelor, cât și ale conținutului. Daemonul refuză o nepotrivire, o politică învechită, o reluare sau un al doilea rezultat pentru o comandă pe care a finalizat-o deja. Argumentele și rezultatele finale sunt criptate cu AES-256-GCM în repaus; baza de date păstrează text cifrat mărginit și digesturi canonice, nu conținut.
Dacă o confirmare se pierde, Nessie nu presupune succes. Comanda este înregistrată ca rezultat necunoscut, iar rularea urmează calea normală de recuperare; daemonul, care înregistrează local fiecare comandă livrată înainte de a începe lucrul, nu va repeta efectul secundar. O confirmare târzie poate rezolva totuși ambiguitatea, fără a ascunde nimic.
Granița de încredere
| Principal | Poate | Nu poate |
|---|---|---|
| Persoană | Asociază un executor, îl administrează atunci când are drepturi, confirmă accesul și modificările de politică. | Lărgește o politică pe care mașina însăși o refuză sau acționează fără drepturi actuale. |
| Agent, inclusiv asistentul personal | Invocă o operație deja disponibilă pentru el; pregătește o modificare propusă a accesului pentru persoana care a cerut-o. | Administrează accesul, își aprobă singur cererea, alege o mașină, schimbă politica locală sau aplică o modificare pe care a pregătit-o. |
| Planul de control Nessie | Rezolvă disponibilitatea, asociază o rulare, acordă comenzi în leasing, păstrează fapte de audit redactate. | Sună mașina, lărgește politica locală, ajunge la credențialele gazdei sau tratează textul de terminal ca autorizare ori ca rezultat. |
| Daemonul executorului | Aplică politica locală, se asociază spre exterior, rulează oaspetele și gateway-ul, confirmă comenzile. | Își extinde propriul domeniu, acceptă lucru învechit sau reluat, expune direct spațiul de lucru sau credențialele gazdei ori trimite date locale brute în registrul de audit. |
| Mașina virtuală oaspete și instrumentele din ea | Lucrează într-un sandbox copy-on-write, ajungând la rețea doar prin gateway. | Ajunge la fișierele gazdei, la credențialele gazdei, la rețea sau DNS direct ori promovează o modificare de pe gazdă. |
Instalarea și asocierea unui executor
Instalați CLI-ul pentru Mac cu Homebrew, aplicațiile pentru Mac cu cask-uri Homebrew, CLI-ul pentru Linux prin APT sau DNF, sau executorul pentru Windows prin WinGet. Fiecare echipă asociată are permisiuni separate, stocate pe calculator. Nessie controlează accesul în cadrul echipei; nu poate schimba resursele locale.
Ghidul de instalare și asociere conține comenzile exacte, fluxul celor opt cifre confirmate în două părți, setările locale, pornirea, actualizările și dezinstalarea.
Cât de bine a fost dovedită fiecare platformă
Starea celor trei sandbox-uri oaspete diferă, iar diferența este semnificativă. macOS este backend-ul cu o cale oaspete funcțională și testată. Backend-ul Firecracker de pe Linux și backend-ul Hyper-V de pe Windows sunt implementate și acoperite de teste pe partea gazdei — secvența de lansare, imaginile de disc, transporturile de control și de ieșire, protocolul de ciorne — dar niciun oaspete nu a pornit încă pe hardware real în integrarea continuă a acestui proiect, deoarece pentru asta este nevoie de o mașină cu KVM sau Hyper-V, iar joburile care ar dovedi acest lucru nu au avut niciodată una. Pachetul de spațiu de lucru, care nu are nevoie de oaspete, este testat cap-coadă pe Windows, împotriva unei bucle de control reale. Tratați operațiile cu oaspete pe Linux și Windows ca nedovedite până când le dovediți pe propriul hardware. Ecranul de asociere din Nessie spune același lucru, cu propriile cuvinte.
Securitate și izolare
O singură rădăcină de spațiu de lucru, iar calea ei rămâne pe mașină
Asocierea selectează exact o rădăcină de spațiu de lucru canonică: un singur director, nu un set de dosare și niciodată cel mai apropiat părinte comun al acestora. Nessie află numele de bază al rădăcinii, astfel încât o persoană să poată recunoaște granița în interfață; calea completă rămâne în starea mașinii, accesibilă doar proprietarului, și nu este încărcată niciodată. Schimbarea rădăcinii este posibilă, dar doar după ce au fost eliminate toate ciornele și sandbox-urile locale, și produce o nouă revizie de descriptor, care trece prin aceeași revizuire umană ca orice altă modificare de politică. Nu se poate lărgi niciodată în tăcere până la un director părinte.
Operațiile cu fișiere acceptă doar căi relative. Respinge traversarea și orice componentă de legătură simbolică, reverifică faptul că rădăcina configurată este încă un director obișnuit și returnează rezultate structurate mărginite, fără nicio cale de pe gazdă.
Scrierile merg într-o copie, iar doar o persoană le promovează
Un agent nu scrie niciodată în fișierele dvs. file.write creează un arbore copy-on-write mărginit în directorul de stare al daemonului, legat de rulare, iar citirile și listările ulterioare pentru acea rulare văd ciorna. Lucrul în oaspete, inclusiv sesiunile de programare, folosește același spațiu temporar copy-on-write.
Aplicarea unei ciorne în spațiul de lucru real este o singură operație — workspace.promote — și este singura scriere pe gazdă din sistem. Nu are deloc o schemă destinată modelelor: niciun agent, niciun asistent și nicio cale furnizată de apelant nu poate transforma o ciornă într-o scriere pe gazdă. În schimb, o persoană deschide Your reviewed drafts, apasă Review promotion și confirmă cu parola curentă. Serverul verifică apoi din nou digestul revizuirii confirmat, digestul manifestului, rularea de origine, utilizatorul și agentul, revizia autorizării, permisiunea operației și politica locală activă, înainte să creeze comanda. Pe mașină, daemonul reconstruiește singur manifestul și refuză un digest care s-a schimbat — astfel încât o editare făcută după revizuire nu poate intra cu aprobarea revizuirii.
Aplicarea propriu-zisă se bazează pe descriptori și este înregistrată în jurnal. Asistentul nativ primește rădăcina spațiului de lucru și ciorna ca descriptori de directoare deja deschise, nu ca simple căi; validează fiecare componentă cu operații fără urmărirea legăturilor, refuză legăturile simbolice, legăturile fizice, fișierele speciale și traversarea punctelor de montare și păstrează un jurnal totul-sau-nimic cu recuperare, astfel încât o cădere fie finalizează manifestul validat, fie restaurează originalul înainte de orice altceva.
Oaspetele nu are rețea, iar ieșirea este forțată
Atunci când o operație are nevoie de un oaspete, acesta este un micro-VM Linux per sesiune, fără directorul de start al gazdei, fără socket Docker, fără agent SSH, fără mediu moștenit și fără nicio montare a gazdei în afara partajării spațiului de lucru. Montarea runtime-ului executabil este doar în citire; montarea spațiului de lucru care poate fi scris interzice execuția, deci ceea ce rulează vine din payload-ul de runtime verificat, nu din ceva scris de un agent. Oaspetele trece pe o identitate fără privilegii înainte să deschidă vreun socket, iar o partajare aflată în proprietatea root face să eșueze pornirea, în loc să lase o sarcină privilegiată în funcțiune.
Cel mai important lucru: oaspetele nu are nicio interfață de rețea. Pe Linux, secvența de lansare nu configurează niciodată una și nu se creează niciun dispozitiv TAP; pe Windows, adaptorul de rețea virtual pe care Hyper-V îl adaugă implicit este eliminat în timpul instalării. Singura ieșire a oaspetelui de pe mașină este un proxy loopback din interiorul lui, tunelat printr-un socket virtual către un pod de pe gazdă, care predă octeții gateway-ului propriu al daemonului — un ascultător de socket local, accesibil doar proprietarului, fără listener TCP și fără mod general de redirecționare. Acel gateway este locul unde se aplică politica pentru HTTP, CONNECT, WebSocket, redirecționări, origini, descărcări și încărcări, folosind mecanismul existent de pinned-fetch al Nessie, nu o a doua implementare a acelorași reguli. Nu există punte NAT și nici rezolvator DNS direct: DNS alternativ, TCP brut, QUIC și ocolirea proxy-ului sunt toate refuzate.
Lista de origini pe care o aplică acel gateway este configurată pe mașină, de proprietarul ei, și nu este încărcată niciodată. Interfața numește această absență, în loc să pretindă că Nessie este un editor de politici de origine: ca să știți ce poate atinge un executor de browser, întrebați persoana care deține mașina.
Credențiale
Niciun depozit de credențiale al gazdei nu este montat într-un oaspete. Nici lanțul de chei, nici ~/.codex sau ~/.claude, nici un token global al CLI, nici o variabilă de mediu care transportă o cheie API. Singura autentificare acceptată pentru o sesiune de programare gestionată este un fișier de autentificare privat al proprietarului, al cărui conținut este citit doar de constructorul de initrd controlat de proprietar — niciodată de Nessie, niciodată de descriptor, niciodată de un jurnal sau de un argument de comandă — și mutat o singură dată într-un director privat din oaspete, care este distrus odată cu VM-ul. Acel oaspete poate ajunge exact la o singură origine.
Executorul de browser este și mai strict: fiecare sesiune primește un profil de browser privat, proaspăt, și refuză unul pregătit de spațiul de lucru, astfel încât pornește fără cookie-uri, fără extensii și fără nicio stare de autentificare moștenită.
Datele locale brute pot ajunge la un furnizor de model doar în interiorul unei rulări explicite și mărginite. Ce persistă Nessie sunt manifeste redactate, digesturi ale argumentelor și politicii, digesturi ale rezultatelor și stare structurată. Conținutul fișierelor, ieșirea terminalului, DOM-ul browserului, credențialele și factorii de autentificare sunt interzise în înregistrările bazei de date, în intrările de audit, jurnale, evenimentele în timp real și rapoartele de erori.
Ce acordă un operator și cum le retrage
Permisiunea de a folosi un executor nu este un singur comutator. Un agent poate invoca o operație doar dacă deține o permisiune pentru exact acel executor și pentru exact acea operație, și politica logică obișnuită a instrumentului o permite, și domeniul rulării se potrivește, și politica locală a mașinii o permite. Acordarea unei operații unui executor nu autorizează nimic pe altul, iar o reîmprospătare a capabilităților nu poate lărgi nimic, pentru că operațiile noi sosesc refuzate.
Accesul agenților și partajarea iau efect imediat, direct pe pagină, fără continuare prin aprobare, fără solicitare de parolă și fără pas de reautentificare. Pe fila Agents a executorului, un manager activează sau dezactivează direct accesul unui agent la mașină; pe Sharing acordă unei persoane drept de utilizare sau de administrare ori extinde utilizarea la un proiect sau la toți cei din echipa curentă, în același mod. În conversația dvs. cu asistentul personal — doar acolo, niciodată într-un canal comun, într-o sarcină programată sau într-o rulare a altui agent — asistentul poate pregăti în schimb o modificare a accesului agentului sau a atribuirii, care afișează un card de confirmare în acea conversație; nimic nu se schimbă până nu apăsați Allow access pe el, iar textul din chat nu este niciodată o confirmare.
Trei modificări cer încă să vă reintroduceți parola curentă în momentul confirmării: activarea unei revizii de descriptor; o atribuire pregătită de asistent care îi dă unei persoane, nu unui agent, mașina; și o politică permanentă care permite colegilor să pornească pe ea comenzi în calitate de proprietar, politica de lucru neasistat pe tichete. Deconectarea sau ștergerea unei mașini nu cere deliberat niciuna dintre acestea, deoarece un comutator de oprire de urgență nu trebuie să fie mai greu de atins decât ceea ce oprește. Promovarea unei ciorne revizuite cere întotdeauna parola. Jurnalul de audit înregistrează separat persoana care a acționat și implicarea asistentului.
Un executor trece printr-un set mic și explicit de stări:
pending_pairing → online ↔ offline
│ ↓
└──────────→ draining → revoked
↓
errorMeniul Computer din antet este locul unde un manager pregătește fiecare schimbare a ciclului de viață: o pune pe pauză, o reia când este pe pauză, o deconectează sau o șterge. Pauza lasă executorul online, dar îl oprește din a mai accepta comenzi. Deconectarea invalidează certificatele sale de client și fiecare mâner de candidat în așteptare și nu poate fi anulată — un executor deconectat este reasociat ca unul nou. Ștergerea face același lucru și scoate în plus executorul din listă; spre deosebire de deconectare, este oferită indiferent de starea executorului, inclusiv pentru cele aflate în așteptarea asocierii sau deja deconectate, pentru că este singurul mod în care cineva iese din listă. Drenarea — terminarea lucrului pe care îl are deja înainte de a mai primi altul — este o a treia stare reală în protocol, iar interfața poate arăta o mașină în această stare, dar nimic din interfață nu o pornește: doar un apel direct la API. Fiecare modificare confirmată a accesului, revizuire de descriptor și tranziție de ciclu de viață, inclusiv drenarea, avansează și epoca de conexiune a daemonului, astfel încât următoarea sa interogare de control — cel mult o secundă mai târziu — eșuează în mod închis și oprește fiecare oaspete activ înainte ca acesta să se poată reconecta. Revocarea este o cerere pe care mașina nu o poate ignora.
Operarea unui executor
Verificarea funcționării
Răspunsul propriu al Nessie este vitalitatea. Un daemon semnează un semnal de viață, iar un executor a cărui ultimă activitate autentificată este mai veche de șaizeci de secunde este marcat durabil ca offline înainte să poată fi listat, selectat sau ținta distribuirii. Un executor care apare online și-a dovedit starea în ultimul minut.
Pe mașină nu există niciun punct final de sănătate — daemonul nu ascultă pe niciun port orientat spre operator, intenționat. Pe macOS și Linux, întrebați direct CLI-ul:
nessie-executor status # every paired executor, plus linger state
nessie-executor status <executorId>
systemctl --user status nessie-executor@<executorId>Pe macOS, starea raportează agentul launchd al fiecărei echipe. Comanda systemctl este doar pentru Linux. Pe Windows, pictograma din tavă este răspunsul rapid, meniul ei numește motivul, iar jurnalul serviciului conține detaliile. Pe orice platformă, fila Overview a executorului din Nessie arată profilurile sale aprobate, limita datelor, când a fost văzut ultima dată și orice propunere locală de politică în așteptarea revizuirii.
Jurnale
| Platformă | Unde |
|---|---|
| Linux | journalctl --user -u nessie-executor@<executorId>; daemonul nu păstrează un fișier de jurnal propriu |
| Windows | %ProgramData%\Nessie Executor\logs\service.log, pe care îl deschide Open logs folder din meniul pictogramei din tavă |
Acolo ajunge fiecare refuz pe care o persoană îl poate remedia: un runtime nesemnat sau alterat, un director de stare care nu s-ar putea securiza, un executor care nu a pornit la pornirea sistemului. Acolo nu ajunge niciodată o provocare de asociere, o cheie sau ieșirea unui proces copil. Nu există un nivel de jurnalizare de ridicat, pentru că nu există nimic mai detaliat de activat.
CLI-ul pentru Mac scrie jurnalul serviciului fiecărei echipe în ~/Library/Logs/NessieExecutor/<executorId>.log.
Actualizarea
Actualizați CLI-ul prin Homebrew, APT sau DNF, apoi reporniți serviciul fiecărei echipe cu disable urmat de enable. WinGet actualizează executorul pentru Windows. Instalatoarele directe ale Nessie Desktop oferă actualizări semnate în aplicație; instalările MSI și Debian folosesc managerul lor de pachete. Asocierile și permisiunile locale supraviețuiesc actualizărilor.
Oprirea și eliminarea
Oprirea este o cale grațioasă pe care o gestionează daemonul, nu o ucidere forțată. Daemonul primește un semnal de terminare, oprește fiecare sesiune de oaspete, eliberează leasing-ul și iese. Pe Linux, unitatea așteaptă cincisprezece secunde pentru un buget de dezafectare de zece secunde și nu escaladează niciodată la o ucidere care nu poate fi interceptată — pentru că un daemon ucis în mijlocul dezafectării lasă un micro-VM și un overlay de spațiu de lucru fără niciun proces care să le curețe. O oprire care se blochează este deci vizibilă în systemctl --user status, nu tăcută, iar escaladarea este o decizie umană explicită.
Pentru a elimina pachetul Linux:
nessie-executor disable <executorId> # stops and disables the service
sudo apt remove nessie-executor
loginctl disable-linger # only if your user manager should stop running at boot tooPe Windows, msiexec /x oprește și elimină serviciul, intrările sale de registru și intrarea de pornire a pictogramei din tavă. Pe ambele platforme, starea asociată rămâne intenționat în urmă — ~/.local/state/nessie-executor/ pe Linux și %ProgramData%\Nessie Executor pe Windows. O asociere este o cheie a mașinii și o revizie semnată de politică, iar dezinstalarea unui program nu înseamnă o cerere de a le distruge; reinstalarea le găsește unde erau. Ștergeți directorul manual ca să uitați o asociere și revocați executorul în Nessie ca să îl încheiați și din cealaltă parte.
Pictograma din tavă Windows și companionul desktop oferă ambii acțiunea de prim rang Forget pairing on this computer: oprește daemonul local, elimină cheia mașinii și selecția de dosar și șterge definitiv copiile locale ale ciornelor după o singură confirmare nativă — lăsând executorul de pe server și istoricul său de audit pentru ca un proprietar să le păstreze sau să le revoce.
Erori frecvente
| Simptom | Ce înseamnă |
|---|---|
| Executorul se asociază, dar oferă doar operații cu fișiere | Gazda nu a raportat un backend de sandbox utilizabil. Pe Linux, verificați dacă puteți citi și scrie în /dev/kvm și dacă sunteți în grupul kvm — după ce vă adăugați acolo, ieșiți din sesiune și intrați din nou. Pe Windows, ediția nu are Hyper-V; este o ediție, nu o setare. |
| Lipsesc complet comenzile executorului | Build-ul nu provine verificabil de la editorul așteptat. Pe Linux, runtime-ul trebuie să aparțină root și să nu aibă bit de scriere pentru grup sau pentru toți; pe Windows și macOS, semnătura trebuie să corespundă editorului sau echipei fixate în build. Fiecare dintre acestea refuză în cuvinte și numește remediul, în loc să ascundă comenzile. |
| Serviciul rulează, dar nu pornește niciun daemon și refuză orice comandă | Ceva din instalare a fost înlocuit după împachetare. Acesta este comportamentul intenționat: o instalare alterată răspunde cu motivul, în loc să dispară, pentru că un serviciu oprit ar face ca pictograma din tavă să indice remediul greșit. |
| O rulare se încheie cu un rezultat necunoscut | O confirmare terminală s-a pierdut. Nessie nu raportează un rezultat pe care nu l-a primit: comanda este marcată ca necunoscută, rularea urmează calea de recuperare, iar efectul secundar nu se repetă. O confirmare târzie de la daemon poate totuși să rezolve situația. |
| O operație care a funcționat ieri este refuzată azi | O poartă s-a schimbat între asociere și distribuire, iar verificările se repetă la fiecare pas: o permisiune retrasă, o revizie de descriptor în așteptarea revizuirii, o politică locală restrânsă, un domeniu care nu mai corespunde rulării sau o revocare. Refuzul numește care dintre ele. |
| Un agent cere un browser și i se spune că nu poate | Lucrul cu browserul și cel de programare sunt lansate de o persoană dintr-un canal, ca un pachet întreg pe o rulare nouă. Ruta obișnuită de asociere le refuză intenționat, iar nicio operație de browser nu poate fi adăugată unei rulări care face deja altceva. |