Zdalne executory

Daj agentowi prawdziwy komputer do pracy — z Linuksem, macOS lub Windows.

Czym jest zdalny executor

Agent w Nessie nie ma własnego komputera. Może odczytać to, co znajduje się w Nessie, rozmawiać z ludźmi i wywoływać podłączone narzędzia przez sieć, ale nie może otworzyć pliku na laptopie, uruchomić polecenia ani zajrzeć na stronę, która istnieje tylko za czyimś logowaniem. Zdalny executor to sposób, w jaki dajesz mu maszynę, na której może pracować.

Executor to mały demon, który instalujesz na komputerze, nad którym masz kontrolę. Paruje się na zewnątrz z twoją instancją Nessie, potwierdza swoją tożsamość kluczem, który nigdy nie opuszcza hosta, a potem oferuje stały, nazwany zestaw operacji — i nic poza nim. Zadania przychodzą jako pojedyncze podpisane polecenia; wyniki wracają jako ograniczone, ustrukturyzowane potwierdzenia. Maszyna nigdy nie przyjmuje połączeń przychodzących z Nessie.

Warto precyzyjnie określić, czym executor nie jest, bo większość narzędzi do zdalnego dostępu to jedna z tych rzeczy, a executor celowo nie jest żadną z nich. Nie ma tu SSH, nie ma zdalnej powłoki działającej w tle, nie ma podłączania się do multipleksera terminala, który już masz otwarty, nie ma standardowego wejścia po stronie chmury ani ogólnego proxy sieci lokalnej. Nie jest serwerem MCP ani kontenerem czy chmurowym środowiskiem wykonawczym — Nessie ma już takie rzeczy, a to coś innego. Executor to punkt końcowy oparty na uprawnieniach, z zamkniętą listą operacji, i ta lista stanowi całą jego powierzchnię.

Do kogo należy executor

Każdy executor tworzy się z dokładnie jednym zakresem, którego nie da się później zmienić. Zakres decyduje, kto może uruchamiać executor, a kto może nim administrować.

Prywatny executor musi zawsze mieć co najmniej jednego aktywnego administratora-człowieka. Usunięcie ostatniego wprost się nie powiedzie; jeśli transakcja odłączenia pracownika zostawiłaby zero administratorów, executor przestaje przyjmować nowe zadania, dokańcza to, co ma w toku, i sam cofa swoją rejestrację. Właściciel organizacji ma awaryjną ścieżkę break-glass, która wyłącznie odwołuje dostęp i kończy executor, którym inaczej nie zarządza — bez pokazywania mu prywatnej listy osób, sesji ani treści. Dostęp prywatny nigdy po cichu nie przechodzi na kogoś innego.

Co agent faktycznie może z nim zrobić

Słownik operacji jest zapisany w kodzie, a nie konfigurowany dla każdego wdrożenia. Dzieli się na dwie grupy, a podział decyduje o tym, co trzeba zainstalować: niektóre operacje demon obsługuje ze swojego katalogu roboczego bez żadnej maszyny wirtualnej, a reszta wymaga osobnej maszyny wirtualnej gościa na hoście, uruchamianej dla każdej sesji.

Operacje, które nie potrzebują gościa, tworzą pakiet przestrzeni roboczej. Host, który nie może uruchomić gościa, nie jest uszkodzonym executorem: paruje się normalnie, zgłasza swój backend piaskownicy jako none i ogłasza wyłącznie pakiet przestrzeni roboczej. W tym stanie znajduje się wydanie Windows bez Hyper-V albo maszyna z Linuksem, której użytkownik nie może korzystać z /dev/kvm. Interfejs nazywa ten stan wprost, zamiast zawieść w niejasny sposób.

Praca w przeglądarce nigdy nie zaczyna się z inicjatywy agenta. Zwykła trasa powiązania pojedynczej operacji całkowicie odrzuca browser.open i browser.observe. Uruchomienie przeglądarki zaczyna człowiek z kanału, jako jeden pakiet czterech operacji w nowym uruchomieniu, i nie da się do niego potem dodać kolejnych powiązań. Zarządzane sesje kodowania działają tak samo.

W kodzie istnieją jeszcze dwie grupy operacji, które są celowo niedostępne. Operacje sterowania kartą Chrome, w której jest już aktywna sesja logowania, mają kompletną implementację lokalną i rozszerzenie native-messaging, ale płaszczyzna sterowania ich nie ogłasza, dopóki serwer nie potrafi udowodnić, że rozmowa, z której pochodzi żądanie, była prywatna, i zapisać, kto co ujawnił. Fundament jest celowo nieaktywny, a rozszerzenie nie jest dołączone do żadnego z instalatorów. Kilka operacji kodowania — podłączenie, prompt, przerwanie i zamknięcie — jest wymienionych w schemacie, ale nie ma ich implementacji, więc nie da się ich przyznać.

Jak to działa

Połączenie zawsze jest wychodzące

Demon nawiązuje wychodzące połączenia HTTPS i WSS wyłącznie z twoim API Nessie i z niczym innym. Nessie nigdy nie łączy się z laptopem, nie przechowuje jego adresu i nigdy nie traktuje żadnego punktu końcowego z katalogu jako transportu do maszyny. Dzięki temu executor działa z domowej sieci, za NAT, w firmowym VPN, bez przekierowania portów i bez reguły przychodzącej w zaporze — a zatrzymanie demona oznacza pełne i natychmiastowe rozłączenie.

Origin API musi działać przez HTTPS. Jedynym wyjątkiem jest adres loopback dla osób, które uruchamiają Nessie na własnym komputerze, włączany osobną zmienną środowiskową; żadna zwykła flaga nie zmienia produkcyjnego originu w zwykły HTTP.

Parowanie potwierdza maszynę, a człowiek ją zatwierdza

Parowanie to dowód dwustronny. Uprawniona osoba tworzy executor w Nessie wraz z jego zakresem, a Nessie wystawia rejestrację: losowe wyzwanie 256-bitowe, z którego przechowuje tylko weryfikator SHA-256. Rejestracja jest ważna dziesięć minut i można jej użyć tylko raz.

Na maszynie demon generuje parę kluczy Ed25519, zapisuje ją w magazynie chronionym przez system, dostępnym wyłącznie dla właściciela, i zapisuje na dysku dokładnie podpisane żądanie zanim wykona jakiekolwiek połączenie sieciowe. Dzięki temu zgubioną odpowiedź można ponowić tym samym przygotowanym kluczem, zamiast po cichu sparować się dwa razy. Następnie wysyła identyfikator rejestracji, wyzwanie, swój klucz publiczny i podpis dowodowy. Nessie zapisuje klucz publiczny i jego odcisk. Klucza prywatnego nigdy nie zapisuje.

Nessie pokazuje ten odcisk osobie, która go potwierdza. Dopóki nie nastąpi to potwierdzenie i późniejszy dowód posiadania klucza, executor pozostaje offline. Parowania nigdy nie da się dokończyć z tekstu czatu ani z zapisu terminala: wymaga celowego działania człowieka w interfejsie webowym lub desktopowym.

Maszyna, która zgubi klucz, nie może odzyskać swojego rekordu executora. Jest odwoływana i rejestrowana ponownie jako nowy executor. Rotacja klucza natomiast to jedna transakcja podpisana zarówno starym, jak i nowym kluczem.

Deskryptor to podpisane oświadczenie maszyny o samej sobie

Sparowany demon publikuje deskryptor: podpisane, monotonicznie rewidowane oświadczenie wyłącznie o faktach strukturalnych — jakie schematy operacji obsługuje, jakie ma limity zasobów i sieci, na jakiej platformie działa oraz jaki jest skrót jego lokalnej polityki. Nie zawiera ścieżek hosta i nie tworzy żadnych uprawnień w chmurze.

Nowa rewizja nigdy nie jest aktywowana od razu po dotarciu. Zapisuje się jako oczekująca na przegląd, a uprawniona osoba musi ją zobaczyć i potwierdzić, zanim zacznie wpływać na to, co jest dostępne. Dzięki temu odświeżenie możliwości nie nada po cichu nowych uprawnień: nowo ogłoszona operacja zaczyna jako odmówiona.

Warto wiedzieć, co dowodzi podpis. Deskryptor podpisany kluczem sparowanego executora dowodzi, że to ten klucz złożył oświadczenie. Nie dowodzi, że host jest nienaruszony, a interfejs musi to mówić wprost.

Wysłanie zadania: kandydat, powiązanie, polecenie, potwierdzenie

Agent nigdy nie wskazuje executora. Zanim uruchomienie może z niego skorzystać, Nessie zamienia logiczną operację w nieprzejrzysty, krótkotrwały kandydat dostępności. Odpowiedź nie zawiera identyfikatora executora; baza przechowuje tylko skrót uchwytu wraz z tym, kto i do czego go rozwiązał. Modele i klienci dostają uchwyt, a nie maszynę do wyboru.

Dostępność rozstrzyga jeden resolver, używany tak samo przez API, workera, interfejs i asystenta:

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 operation

Wykorzystanie kandydata tworzy powiązanie pod blokadą bazy danych, która po raz drugi sprawdza wszystkie te warunki i przesuwa monotoniczny licznik (fence). Wysłanie sprawdza je jeszcze raz. W efekcie uprawnienie cofnięte, polityka zawężona lub executor odwołany między dwoma krokami zatrzymuje pracę, zamiast zostać zauważone dopiero później — a ponowienie nigdy nie trafi na inną maszynę niż ta, z którą powiązano uruchomienie.

Samo polecenie korzysta ze zwykłego zadania w kolejce Nessie i z cyklu życia wywołania narzędzia, a nie z własnego, drugiego mechanizmu. Demon odpytuje o pracę przez uwierzytelniony kanał sterowania; nigdy nie jest do niego wypychana. Polecenie przechodzi przez cztery potwierdzenia i żadne inne:

leased → accepted → started → result-acknowledged

Każda ramka wiąże identyfikator polecenia, pochodzenie uruchomienia, licznik powiązania, rewizję możliwości, termin ważności, klucz idempotentności oraz skróty argumentów i ładunku. Demon odrzuca niezgodność, nieaktualną politykę, powtórkę albo drugi wynik dla polecenia, które już zakończył. Argumenty i wyniki końcowe są szyfrowane w spoczynku algorytmem AES-256-GCM; baza przechowuje ograniczony szyfrogram i kanoniczne skróty, a nie treść.

Jeśli potwierdzenie zginie, Nessie nie zakłada sukcesu. Polecenie zapisuje się jako wynik nieznany, a uruchomienie idzie normalną ścieżką odzyskiwania. Demon zapisuje każde dostarczone polecenie w lokalnym dzienniku, zanim zacznie pracę, więc nie powtórzy skutku ubocznego. Późne potwierdzenie nadal może uczciwie rozstrzygnąć tę niejednoznaczność.

Granice zaufania

Instalacja i parowanie executora

Zainstaluj CLI dla Maca przez Homebrew, aplikacje dla Maca przez Homebrew cask, CLI dla Linuksa przez APT lub DNF, a executor dla Windows przez WinGet. Każdy sparowany zespół ma osobne uprawnienia zapisane na komputerze. Nessie kontroluje dostęp w obrębie zespołu, ale nie może zmieniać lokalnych zasobów.

Przewodnik instalacji i parowania zawiera dokładne polecenia, dwustronny przepływ z ośmiocyfrowym kodem, ustawienia lokalne, uruchamianie, aktualizacje i usuwanie.

Na ile sprawdzono każdą platformę

Stan trzech piaskownic dla gości różni się, a różnica jest istotna. macOS to backend z działającą, przetestowaną ścieżką gościa. Backend Firecracker na Linuksie i backend Hyper-V na Windows są zaimplementowane i objęte testami po stronie hosta — sekwencją uruchamiania, obrazami dysków, transportami sterowania i ruchu wychodzącego, protokołem wersji roboczych — ale w ciągłej integracji tego projektu żaden gość jeszcze nie uruchomił się na prawdziwym sprzęcie. Wymaga to maszyny z KVM lub Hyper-V, a zadania, które miałyby to potwierdzić, nigdy takiej maszyny nie miały. Pakiet przestrzeni roboczej, który nie wymaga gościa, jest sprawdzany od początku do końca na Windows w działającej pętli sterowania. Operacje z gościem na Linuksie i Windows traktuj jako niepotwierdzone, dopóki nie sprawdzisz ich na własnym sprzęcie. Ekran parowania w Nessie mówi to samo własnymi słowami.

Bezpieczeństwo i izolacja

Jeden katalog główny przestrzeni roboczej, a jego ścieżka zostaje na maszynie

Parowanie wybiera dokładnie jeden kanoniczny katalog główny przestrzeni roboczej: jeden katalog, a nie zbiór folderów i nigdy ich najbliższy wspólny katalog nadrzędny. Nessie dostaje nazwę końcową tego katalogu, aby osoba mogła rozpoznać granicę w interfejsie; pełna ścieżka pozostaje w stanie maszyny dostępnym tylko dla właściciela i nigdy nie jest wysyłana. Zmiana katalogu głównego jest możliwa, ale dopiero po usunięciu wszystkich lokalnych wersji roboczych i piaskownic. Tworzy ona nową rewizję deskryptora, która przechodzi ten sam ludzki przegląd co każda inna zmiana polityki. Nigdy nie poszerza się po cichu do katalogu nadrzędnego.

Operacje na plikach przyjmują wyłącznie ścieżki względne. Odrzucają przechodzenie katalogów oraz każdy składnik będący dowiązaniem symbolicznym, ponownie sprawdzają, czy skonfigurowany katalog główny nadal jest zwykłym katalogiem, i zwracają ograniczone, ustrukturyzowane wyniki bez ścieżki hosta.

Zapisy trafiają do kopii, a zastosować je może tylko człowiek

Agent nigdy nie zapisuje w twoich plikach. file.write tworzy ograniczone drzewo copy-on-write w katalogu stanu samego demona, powiązane z uruchomieniem, a późniejsze odczyty i listowania dla tego uruchomienia widzą wersję roboczą. Praca w gościu, w tym sesje kodowania, korzysta z tego samego tymczasowego obszaru copy-on-write.

Zastosowanie wersji roboczej w prawdziwej przestrzeni roboczej to jedna operacja — workspace.promote — i jedyny zapis na hoście w całym systemie. Nie ma dla niej żadnego schematu dla modeli: żaden agent, asystent ani ścieżka podana przez wywołującego nie może zamienić wersji roboczej w zapis na hoście. Zamiast tego osoba otwiera Twoje sprawdzone wersje robocze, naciska Sprawdź zastosowanie i potwierdza aktualnym hasłem. Serwer następnie ponownie sprawdza zatwierdzony skrót przeglądu, skrót manifestu, uruchomienie źródłowe, użytkownika i agenta, rewizję autoryzacji, uprawnienie do operacji oraz aktywną lokalną politykę, zanim utworzy polecenie. Na maszynie demon sam odbudowuje manifest i odrzuca skrót, który się zmienił — dzięki temu zmiana wprowadzona po przeglądzie nie może przejść na zatwierdzenie tego przeglądu.

Samo zastosowanie opiera się na deskryptorach i jest zapisywane w dzienniku. Natywny pomocnik dostaje katalog główny przestrzeni roboczej i wersję roboczą jako już otwarte deskryptory katalogów, nigdy jako ścieżki. Sprawdza każdy składnik operacjami bez podążania za dowiązaniami, odrzuca dowiązania symboliczne, dowiązania twarde, pliki specjalne i przekroczenia punktów montowania, i prowadzi dziennik typu wszystko-albo-odtworzenie, tak aby awaria albo dokończyła zweryfikowany manifest, albo przywróciła oryginał, zanim zacznie się cokolwiek innego.

Gość nie ma sieci, a ruch wychodzący jest wymuszany

Gdy operacja naprawdę wymaga gościa, jest to mikromaszyna wirtualna Linux, uruchamiana dla każdej sesji, bez katalogu domowego hosta, bez gniazda Dockera, bez agenta SSH, bez dziedziczonego środowiska i bez punktu montowania hosta innego niż udział przestrzeni roboczej. Montowanie środowiska wykonawczego jest tylko do odczytu; zapisywalne montowanie przestrzeni roboczej zabrania wykonywania, więc wszystko, co się uruchamia, pochodzi ze zweryfikowanego ładunku środowiska wykonawczego, a nie z czegoś, co zapisał agent. Gość przechodzi na nieuprzywilejowaną tożsamość, zanim otworzy jakikolwiek gniazdo, a udział należący do roota powoduje błąd uruchamiania zamiast pozostawienia działającego uprzywilejowanego procesu.

Najważniejsze: gość nie ma interfejsu sieciowego. Na Linuksie sekwencja uruchamiania celowo nigdy go nie konfiguruje i nie powstaje żadne urządzenie TAP; na Windows wirtualna karta sieciowa, którą Hyper-V dodaje domyślnie, jest usuwana podczas instalacji. Jedyna trasa gościa poza maszynę to lokalny proxy loopback wewnątrz niego, tunelowany przez gniazdo wirtualne do mostka na hoście, który przekazuje bajty do własnej bramy demona — lokalnego nasłuchu gniazda dostępnego tylko dla właściciela, bez nasłuchu TCP i bez ogólnego trybu przekazywania. To właśnie tam egzekwuje się politykę HTTP, CONNECT, WebSocket, przekierowań, źródeł, pobierania i wysyłania, korzystając z istniejącego w Nessie mechanizmu pinned-fetch, a nie z drugiej implementacji tych samych reguł. Nie ma mostu NAT ani bezpośredniego resolvera DNS: alternatywny DNS, surowe TCP, QUIC i omijanie proxy są wszystkie zablokowane.

Listę originów, którą egzekwuje brama, konfiguruje na maszynie jej właściciel i celowo nigdy nie jest ona wysyłana. Interfejs mówi o tym braku wprost, zamiast udawać, że Nessie jest edytorem polityki originów: aby sprawdzić, do czego może sięgać executor przeglądarki, zapytaj osobę, która jest właścicielem maszyny.

Poświadczenia

Żaden magazyn poświadczeń hosta nigdy nie jest montowany w gościu. Ani pęk kluczy, ani ~/.codex czy ~/.claude, ani globalny token CLI, ani zmienna środowiskowa z kluczem API. Jedyne obsługiwane logowanie do zarządzanej sesji kodowania to plik uwierzytelniający prywatny dla właściciela, którego treść odczytuje wyłącznie zarządzany przez właściciela budowniczy initrd — nigdy Nessie, nigdy deskryptor, nigdy dziennik ani argument polecenia — i który raz przenosi się do prywatnego katalogu domowego wewnątrz gościa, niszczonego razem z maszyną wirtualną. Taki gość może dotrzeć dokładnie do jednego originu.

Executor przeglądarki jest jeszcze ściślejszy: każda sesja dostaje świeży, prywatny profil przeglądarki i odrzuca profil przygotowany przez przestrzeń roboczą, więc startuje bez ciasteczek, bez rozszerzeń i bez żadnego zalogowania w tle.

Surowe dane lokalne mogą trafić do dostawcy modelu wyłącznie w jawnym, ograniczonym uruchomieniu. Nessie zapisuje trwale zanonimizowane manifesty, skróty argumentów i polityk, skróty wyników oraz ustrukturyzowany status. Treści plików, wyjście terminala, DOM przeglądarki, poświadczenia i czynniki uwierzytelniania są zabronione w rekordach bazy danych, wpisach audytu, dziennikach, zdarzeniach w czasie rzeczywistym i raportach błędów.

Co operator przyznaje i jak to cofa

Uprawnienie do korzystania z executora nie jest jednym przełącznikiem. Agent może wywołać operację tylko wtedy, gdy ma przyznanie dla dokładnie tego executora i dokładnie tej operacji, oraz pozwala na to ogólna polityka narzędzi, oraz zakres uruchomienia pasuje, oraz własna lokalna polityka maszyny na to zezwala. Przyznanie jednemu executorowi operacji nie daje więc nic na innym, a odświeżenie możliwości niczego nie poszerza, bo nowe operacje przychodzą jako odmówione.

Dostęp agenta i udostępnianie działają od razu na samej stronie, bez kroku zatwierdzenia, bez monitu o hasło i bez ponownego uwierzytelniania. Na zakładce Agenci executora menedżer włącza lub wyłącza dostęp agenta do maszyny bezpośrednio; na Udostępnianiu nadaje osobie uprawnienie Może używać albo Administrator, albo rozszerza używanie na projekt lub na wszystkich w bieżącym zespole, w ten sam sposób. W twojej własnej rozmowie z asystentem — tylko tam, nigdy we wspólnym kanale, w zaplanowanym zadaniu ani w uruchomieniu innego agenta — asystent może zamiast tego przygotować zmianę dostępu agenta lub przypisania. Publikuje ona kartę potwierdzenia w tej rozmowie; nic się nie zmienia, dopóki nie naciśniesz na niej Zezwól na dostęp, a tekst czatu nigdy nie jest potwierdzeniem.

Trzy zmiany nadal wymagają ponownego wpisania aktualnego hasła w chwili potwierdzenia: aktywacja rewizji deskryptora; przypisanie przygotowane przez asystenta, które daje maszynę osobie, a nie agentowi; oraz stała polityka pozwalająca współpracownikom uruchamiać na niej polecenia w imieniu jej właściciela — polityka pracy nad zgłoszeniami bez nadzoru. Odłączenie lub usunięcie maszyny celowo o nic nie pyta, bo wyłącznik awaryjny nigdy nie może być trudniejszy do uruchomienia niż to, co zatrzymuje. Zastosowanie sprawdzonej wersji roboczej zawsze wymaga hasła. Dziennik audytu zapisuje osobno osobę działającą i udział asystenta.

Executor przechodzi przez niewielki, jawny zestaw stanów:

pending_pairing → online ↔ offline
        │             ↓
        └──────────→ draining → revoked
                         ↓
                       error

W menu Komputer w nagłówku menedżer przygotowuje każdą zmianę cyklu życia: wstrzymanie, wznowienie po wstrzymaniu, odłączenie albo usunięcie. Wstrzymanie zostawia executor online, ale zatrzymuje przyjmowanie poleceń. Odłączenie unieważnia jego certyfikaty klienta i każdy wydany uchwyt kandydata i nie da się go cofnąć — odłączony executor paruje się ponownie jako nowy. Usunięcie robi to samo i dodatkowo usuwa executor z listy; w przeciwieństwie do odłączenia jest dostępne niezależnie od stanu executora, także gdy parowanie wciąż trwa lub executor jest już odłączony, bo to jedyny sposób, by zniknął z listy. Opróżnianie — dokończenie pracy, którą już ma, zanim przestanie przyjmować kolejną — jest w protokole prawdziwym trzecim stanem, a interfejs może pokazać w nim komputer, ale nic tutaj go nie uruchamia: robi to wyłącznie bezpośrednie wywołanie API. Każda potwierdzona zmiana dostępu, przegląd deskryptora i przejście cyklu życia, łącznie z opróżnianiem, podnosi też epokę połączenia demona. Jego następne odpytanie o sterowanie, najpóźniej po upływie sekundy, kończy się więc w trybie odmowy i zatrzymuje każdego działającego gościa, zanim demon zdąży się połączyć ponownie. Odwołanie to nie jest prośba, którą maszyna może zignorować.

Obsługa executora

Sprawdzanie, czy działa prawidłowo

Odpowiedzią Nessie jest sprawdzenie żywotności (liveness). Demon podpisuje sygnał życia (heartbeat), a executor, którego ostatnia uwierzytelniona aktywność jest starsza niż sześćdziesiąt sekund, zostaje trwale oznaczony jako offline, zanim da się go wyświetlić, wybrać lub do niego wysłać zadanie. Executor pokazany jako online potwierdził swoją obecność w ciągu ostatniej minuty.

Na maszynie nie ma punktu końcowego kondycji — demon celowo nie nasłuchuje na żadnym porcie dla operatora. Na macOS i Linuksie zapytaj bezpośrednio CLI:

nessie-executor status                # every paired executor, plus linger state
nessie-executor status <executorId>
systemctl --user status nessie-executor@<executorId>

Na macOS status pokazuje agenta launchd każdego zespołu. Polecenie systemctl działa tylko na Linuksie. Na Windows ikona w zasobniku daje odpowiedź od razu, jej menu podaje powód, a dziennik usługi zawiera szczegóły. Na obu platformach zakładka Przegląd executora w Nessie pokazuje zatwierdzone profile, granicę danych, czas ostatniego kontaktu i każdą oczekującą lokalną propozycję polityki czekającą na przegląd.

Dzienniki

Tam trafia każda odmowa, na którą człowiek może zareagować: niepodpisane lub zmodyfikowane środowisko wykonawcze, katalog stanu, którego nie da się zabezpieczyć, executor, który nie uruchomił się przy starcie systemu. Nigdy tam nie trafia wyzwanie parowania, klucz ani wyjście procesu potomnego. Nie ma poziomu logowania do podniesienia, bo nie ma nic bardziej szczegółowego do włączenia.

CLI dla Maca zapisuje dziennik usługi każdego zespołu w ~/Library/Logs/NessieExecutor/<executorId>.log.

Aktualizacja

Zaktualizuj CLI przez Homebrew, APT lub DNF, a następnie uruchom ponownie usługę każdego zespołu, najpierw poleceniem disable, a potem enable. WinGet aktualizuje executor dla Windows. Bezpośrednie instalatory Nessie Desktop oferują podpisane aktualizacje w aplikacji; instalacje MSI i Debian korzystają ze swojego menedżera pakietów. Parowania i lokalne uprawnienia przetrwają aktualizację.

Zatrzymywanie i usuwanie

Zatrzymanie to łagodna ścieżka, którą zarządza demon, a nie zabicie procesu. Demon dostaje sygnał zakończenia, zatrzymuje każdą sesję gościa, zwalnia dzierżawę i kończy działanie. Na Linuksie jednostka czeka piętnaście sekund na budżet zamknięcia wynoszący dziesięć sekund i celowo nigdy nie eskaluje do niezłapanego zabicia — bo demon zabity w trakcie zamykania zostawia mikromaszynę wirtualną i nakładkę przestrzeni roboczej bez żadnego procesu, który by je posprzątał. Zawieszone zatrzymanie jest więc widoczne w systemctl --user status, a nie ciche, a eskalacja to jawna decyzja człowieka.

Aby usunąć pakiet dla Linuksa:

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 too

Na Windows msiexec /x zatrzymuje i usuwa usługę, jej wpisy w rejestrze oraz wpis autostartu zasobnika. Na obu platformach stan parowania celowo zostaje — ~/.local/state/nessie-executor/ na Linuksie i %ProgramData%\Nessie Executor na Windows. Parowanie to klucz maszyny i podpisana rewizja polityki, a odinstalowanie programu nie jest prośbą o ich zniszczenie; ponowna instalacja znajdzie je tam, gdzie były. Aby zapomnieć parowanie, usuń katalog ręcznie, a aby zakończyć je od drugiej strony, odwołaj executor w Nessie.

Zasobnik Windows i aplikacja towarzysząca na pulpicie oferują Zapomnij parowanie na tym komputerze jako pełnoprawne działanie: zatrzymuje lokalnego demona, usuwa klucz maszyny i wybór folderu oraz trwale kasuje lokalne kopie wersji roboczych po jednym natywnym potwierdzeniu. Executor po stronie serwera i jego historia audytu zostają dla właściciela, który może je zachować albo odwołać.

Typowe błędy