Távoli executorok

Adj egy ügynöknek valódi számítógépet a munkához – Linuxon, macOS-en vagy Windowson.

Mi az a távoli executor

A Nessie-ügynöknek nincs számítógépe. Olvashatja, ami a Nessie-ben van, beszélhet az emberekkel, és hálózaton keresztül hívhat meg összekapcsolt eszközöket — de nem tud megnyitni fájlt egy laptopon, nem tud parancsot futtatni, és nem tud megnézni olyan oldalt, amely csak valakinek a bejelentkezése mögött létezik. A távoli executor az a mód, ahogyan egy ügynöknek gépet adhatsz, amelyen dolgozhat.

Az executor egy kis démon, amelyet olyan számítógépre telepítesz, amely felett te rendelkezel. Kifelé párosodik a Nessie-példányoddal, egy olyan kulccsal igazolja, hogy melyik gép ő, amely soha nem hagyja el a gépet, majd egy rögzített, megnevezett műveletkészletet kínál fel — mást nem. A munka egyedi, aláírt parancsokként érkezik; az eredmények korlátos, strukturált nyugtákként térnek vissza. A gép soha nem fogad el bejövő kapcsolatot a Nessie-től.

Pontosan kell tudni, mi nem az executor, mert a legtöbb távoli hozzáférést biztosító eszköz valamelyik ilyen dolog, az executor pedig szándékosan egyik sem. Nincs SSH, nincs általános távoli shell, nincs csatlakozás egy már megnyitott terminálmultiplexerhez, nincs felhőoldali szabványos bemenet és nincs általános helyi hálózati proxy. Nem MCP-szerver, és nem konténer vagy felhőbeli végrehajtási környezet — a Nessie-nek ezek már megvannak, és más dolgok. Az executor egy képességet hordozó végpont zárt műveletlistával, és ez a lista jelenti a teljes felületet.

Kihez tartozik az executor

Minden executor pontosan egy hatókörrel jön létre, amelyet utólag nem lehet megváltoztatni. Ez dönti el, ki hívhatja meg az executort, és ki adminisztrálhatja.

A privát executornak mindig legalább egy aktív emberi adminisztrátora kell legyen. Az utolsó eltávolítása közvetlenül sikertelen; ha egy kilépési tranzakció nem hagyna egyet sem, az executor nem fogad új munkát, kiüríti, ami nála van, és visszavonja önmagát. Egy szervezettulajdonos csak visszavonásra használható vészhelyzeti úton vonhat vissza olyan executort, amelyet egyébként nem kezel, anélkül hogy megmutatná neki a privát listáját, a munkameneteit vagy a tartalmát — a privát hozzáférés soha nem száll át csendben valaki másra.

Mit tud ténylegesen csinálni vele egy ügynök

A műveletek szókincse kódba van égetve, nem telepítésenként állítható. Két részre oszlik, és ez dönti el, mit kell telepíteni: egyes műveleteket a démon a saját ideiglenes könyvtárából szolgál ki virtuális gép nélkül, a többihez gazdagépen munkamenetenként egy vendég VM kell.

A vendéget nem igénylő műveletek alkotják a munkaterület-csomagot. Az a gép, amely nem tud vendéget indítani, nem elromlott executor: normálisan párosodik, a homokozó háttérprogramját none-ként jelenti, és a munkaterület-csomagot hirdeti, mást nem. Ebbe az állapotba kerül egy Hyper-V nélküli Windows-kiadás vagy egy olyan Linux-gép, amelynek felhasználója nem használhatja a /dev/kvm-et, és a felület ezt megnevezi, ahelyett hogy homályosan meghibásodna.

Böngészős munkát soha nem az ügynök kezdeményez a saját kezdeményezésére. Az egyedi műveleti kötési útvonal kifejezetten megtagadja a browser.open és a browser.observe műveletet; böngészőfuttatást egy személy indít egy csatornából, egy friss futtatás négy műveletből álló csomagjaként, és utólag már nem lehet hozzáadni további kötést. A kezelt kódolási munkamenetek ugyanígy működnek.

A kódban két további csoport létezik, és szándékosan nem elérhetők. A már bejelentkezett Chrome-lap vezérléséhez tartozó műveletekhez teljes helyi megvalósítás és egy natív üzenetküldő bővítmény tartozik, de a vezérlősík nem hirdeti őket, amíg a szerver nem tudja bizonyítani, hogy az eredeti beszélgetés privát volt, és nem tudja rögzíteni, ki mit hozott nyilvánosságra — az alap szándékosan inaktív, a bővítményt pedig egyik telepítő sem tartalmazza. Több kódolási művelet — csatolás, prompt, megszakítás és lezárás — a sémában szerepel, de nincs megvalósításuk, így nem adhatók meg.

Hogyan működik

A kapcsolat mindig kimenő

A démon kimenő HTTPS- és WSS-kapcsolatokat nyit a Nessie API-dhoz, másikhoz nem. A Nessie soha nem csatlakozik laptophoz, nem tárol hozzá címet, és egyetlen katalógusvégpontot sem kezel gépi átvitelként. Ezért működik az executor otthoni hálózatból, NAT mögött, vállalati VPN-en, port-továbbítás és bejövő tűzfalszabály nélkül — és ezért jelent a démon leállítása teljes és azonnali lecsatlakozást.

Az API-originnek HTTPS-nek kell lennie. Az egyetlen kivétel egy loopback-cím azoknak, akik a Nessie-t saját gépükön futtatják, egy saját környezeti változón keresztül; semmilyen szokásos kapcsoló nem alakítja át az éles originet sima HTTP-vé.

A párosítás igazolja a gépet, egy személy pedig megerősíti

A párosítás kétoldalú bizonyítás. Egy jogosult személy létrehozza az executort a Nessie-ben a hatókörével, a Nessie pedig regisztrációt állít ki: egy 256 bites véletlen kihívást, amelynek csak egy SHA-256 ellenőrzőkódját tárolja, tíz percig érvényes, és egyszer használható.

A gépen a démon Ed25519 kulcspárt generál, azt csak a tulajdonos számára olvasható, operációs rendszer által védett tárolóban tárolja, és a pontos aláírt kérést lemezre írja, mielőtt bármilyen hálózati hívást tenne — így egy elveszett válasz az előkészített kulccsal újrapróbálható, és nem párosodik csendben kétszer. Ezután beküldi a regisztrációs azonosítót, a kihívást, a nyilvános kulcsát és egy aláírást. A Nessie a nyilvános kulcsot és annak ujjlenyomatát tárolja. A privát kulcsot soha nem tárolja.

A Nessie ezt az ujjlenyomatot megmutatja egy személynek, aki megerősíti. Amíg ez a megerősítés és a későbbi birtoklási bizonyítás meg nincs, az executor offline marad. A párosítást soha nem lehet csevegőszövegből vagy terminál-átiratból befejezni: szándékos emberi tettet igényel a webes vagy asztali felületen.

Az a gép, amely elveszíti a kulcsát, nem igényelheti vissza az executor-rekordját. Visszavonják, és új executorként regisztrálják újra. A kulcscsere ezzel szemben egyetlen tranzakció, amelyet a régi és az új kulccsal is alá kell írni.

A leíró a gép aláírt állítása magáról

Egy párosított démon leírót tesz közzé: aláírt, monoton módon felülvizsgált állítást kizárólag a szerkezeti tényekről — mely műveletsémákat támogatja, mekkora az erőforrás- és hálózati korlátja, mi a platformja, és mi a helyi szabályzatának digestje. Nem tartalmaz gazdagépi útvonalakat, és nem hoz létre jogosultságot a felhőben.

Új revíziót érkezéskor soha nem aktiválnak. Függőben tárolják, amíg egy jogosult személy meg nem nézi és meg nem erősíti; csak utána befolyásolhatja, mi érhető el. Ez akadályozza meg, hogy egy képességfrissítés csendben új jogosultságot adjon: a frissen hirdetett műveletet alapból megtagadják.

Legyünk egyértelműek abban, mit bizonyít az aláírás. Egy párosított executor kulcsával aláírt leíró azt bizonyítja, hogy ez a kulcs tette az állítást. Nem bizonyítja, hogy a gazdagép nincs kompromittálva, és a felületnek ezt ki kell mondania.

Kiosztás: jelölt, kötés, parancs, nyugta

Egy ügynök soha nem nevez meg executort. Mielőtt a futtatás használhatna egyet, a Nessie a logikai műveletet átlátszatlan, rövid életű elérhetőségi jelöltté alakítja. A válasz nem tartalmaz executor-azonosítót; az adatbázis csak a fogantyú digestjét tárolja, azzal együtt, hogy kinek és mire oldották fel. A modellek és a kliensek fogantyút kapnak, nem választható gépet.

Az elérhetőség egy feloldó, amelyet az API, a worker, a felület és az asszisztens azonosan használ:

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

A jelölt felhasználása egy kötést hoz létre adatbázis-zárolás alatt, amely mindegyik kaput másodszor is ellenőriz, és egy monoton határt léptet. A kiosztás újra ellenőrzi őket. Ennek az a következménye, hogy egy visszavont jogosultság, egy szűkített szabályzat vagy egy visszavont executor két lépés között megállítja a munkát, ahelyett hogy utólag vennék észre — és egy újrapróbálkozás soha nem juthat másik gépre, mint amelyhez a futtatás kötve volt.

Maga a parancs a Nessie szokásos sorfeladatán és eszközhívás-életciklusán fut, nem egy saját második sorban. A démon az azonosított vezérlőcsatornáján kérdezi le a munkát; soha nem kap push-üzenetet. Egy parancs négy nyugtán megy keresztül, mást nem:

leased → accepted → started → result-acknowledged

Minden keret kötődik a parancs-azonosítóhoz, a futtatás eredetiségéhez, a kötési határhoz, a képességrevízióhoz, a lejárathoz, az idempotencia-kulcshoz, valamint az argumentumok és a payload digestjéhez. A démon visszautasítja az eltérést, az elavult szabályzatot, az újrajátszást vagy egy második eredményt olyan parancsra, amelyet már befejezett. Az argumentumok és a végeredmények nyugalmi állapotban AES-256-GCM-mel titkosítottak; az adatbázis korlátos titkosszöveget és kanonikus digesteket tárol, tartalmat nem.

Ha egy visszaigazolás elvész, a Nessie nem feltételezi a sikert. A parancsot ismeretlen kimenetelűként rögzíti, a futtatás pedig a szokásos helyreállítási úton halad; a démon, amely minden kézbesített parancsot helyben naplóz, mielőtt munkába kezdene, nem ismétli meg a mellékhatást. Egy később érkező nyugta még őszintén feloldhatja a kétértelműséget.

Bizalmi határ

Executor telepítése és párosítása

Telepítsd a Mac-es CLI-t Homebrew-val, a Mac-alkalmazásokat Homebrew cask-okkal, a Linux CLI-t APT-n vagy DNF-en keresztül, a Windows executort pedig WinGet-tel. Minden párosított csapatnak külön jogosultságai vannak, amelyek a számítógépen tárolódnak. A Nessie a csapaton belül szabályozza a hozzáférést; a helyi erőforrásokat nem tudja megváltoztatni.

A telepítési és párosítási útmutató pontos parancsokat, a kétoldalú, nyolcjegyű kódos folyamatot, a helyi beállításokat, az indítást, a frissítéseket és az eltávolítást tartalmazza.

Mennyire bizonyított az egyes platformokon

A három vendéghomokozó állapota eltér, és ez a különbség lényeges. A macOS a működő, kipróbált vendégutat használó háttérprogram. A Linuxon futó Firecracker-háttérprogram és a Windowson futó Hyper-V-háttérprogram implementált, és gazdagép-oldali tesztek fedik őket — az indítási sorrend, a lemezképek, a vezérlő- és kimenő átvitelek, a piszkozat-protokoll —, de a projekt folyamatos integrációjában még nem bootolt le vendég valódi hardveren, mert ehhez KVM- vagy Hyper-V-s gép kell, és a bizonyító feladatok soha nem futottak ilyenen. A munkaterület-csomag, amelynek nincs szüksége vendégre, Windowson, valódi vezérlőhurok ellen végig kipróbált. Kezeld a Linuxon és Windowson vendéggel futó műveleteket bizonyítatlanként, amíg a saját hardveredén be nem bizonyítottad. A Nessie párosítási képernyője ugyanezt a saját szavaival mondja.

Biztonság és elszigetelés

Egyetlen munkaterület-gyökér, és az útvonala a gépen marad

A párosítás pontosan egy kanonikus munkaterület-gyökeret választ ki: egy könyvtárat, nem könyvtárak halmazát, és soha nem a legközelebbi közös szülőt. A Nessie-nek a gyökér alapnevét mondják meg, hogy a személy felismerhesse a határt a felületen; a teljes útvonal a tulajdonos számára olvasható helyi állapotban marad, és soha nincs feltöltve. A gyökér megváltoztatható, de csak miután minden helyi piszkozatot és homokozót eltávolítottak, és ez ugyanazon emberi átnézésen megy át, mint bármely más szabályzatváltozás, új leíró-revíziót eredményezve. Soha nem szélesedhet csendben a szülőkönyvtárra.

A fájlműveletek csak relatív útvonalakat fogadnak el. Elutasítják a könyvtárbejárást és minden szimbolikus link komponenst, újraellenőrzik, hogy a beállított gyökér még sima könyvtár-e, és korlátos, strukturált eredményt adnak vissza, amely nem tartalmaz gazdagépi útvonalat.

Az írások másolatba mennek, és csak egy személy alkalmazhatja őket

Egy ügynök soha nem ír a fájljaidba. A file.write korlátos, másolat-írásos (copy-on-write) fát hoz létre a démon saját állapotkönyvtárában, a futtatáshoz kötve, és a későbbi olvasások és listázások az adott futtatáshoz a piszkozatot látják. A vendégben futó munka, a kódolási munkamenetek is beleértve, ugyanazt a másolat-írásos ideiglenes tárolót használja.

A piszkozat valódi munkaterületre alkalmazása egyetlen művelet — workspace.promote —, és ez a rendszer egyetlen gazdagépi írása. Egyáltalán nincs modellnek szánt sémája: sem ügynök, sem asszisztens, sem hívó által megadott útvonal nem tudja piszkozatot gazdagépi írássá alakítani. Ehelyett egy személy megnyitja az Átnézett piszkozataid menüpontot, megnyomja az Alkalmazás átnézése gombot, és a jelenlegi jelszavával megerősíti. A szerver ezután újraellenőrzi a visszaigazolt átnézési digestet, a manifeszt digestjét, az eredeti futtatást, a felhasználót és az ügynököt, az engedélyezési revíziót, a művelet-jogosultságot és az aktív helyi szabályzatot, mielőtt létrehozza a parancsot. A gépen a démon maga építi újra a manifesztet, és visszautasítja, ha a digest megváltozott — így az átnézés után tett szerkesztés nem juthat be az átnézés jóváhagyásával.

Maga az alkalmazás leíró-alapú és naplózott. A natív segédprogram a munkaterület-gyökeret és a piszkozatot már megnyitott könyvtárleírókként kapja, soha nem útvonalként; minden komponenst nem követő (no-follow) műveletekkel ellenőriz, elutasítja a szimbolikus és kemény linkeket, a speciális fájlokat és a csatlakoztatási határokat, és egy mindent-vagy-helyreállítás naplót tart, így egy összeomlás vagy befejezi az érvényesített manifesztet, vagy visszaállítja az eredetit, mielőtt bármi más futna.

A vendégnek nincs hálózata, és a kimenő forgalom kényszerített

Ha egy művelethez vendég kell, az munkamenetenként egy Linux mikro-VM, amelynek nincs gazdagépi home-ja, nincs Docker-socketje, nincs SSH-ügynöke, nincs örökölt környezete, és a munkaterület-megosztáson kívül nincs gazdagépi csatolása. A futtatható futtatókörnyezet csatolása csak olvasható; az írható munkaterület-csatolás tiltja a végrehajtást, így minden, ami fut, az ellenőrzött futtatókörnyezeti csomagból származik, nem egy ügynök által írt fájlból. A vendég egy jogosulatlan azonosítóra vált, mielőtt bármilyen socketet megnyitna, és egy root tulajdonában lévő megosztás meghiúsítja az indítást ahelyett, hogy privilegizált terhelést hagyna futni.

A legfontosabb: a vendégnek nincs hálózati interfésze. Linuxon az indítási sorrend szándékosan soha nem konfigurál hálózatot, és nem jön létre TAP-eszköz; Windowson a Hyper-V alapértelmezett virtuális hálózati adaptert a telepítés során eltávolítja. A vendég egyetlen kijárata a gépről egy loopback-proxy a vendégen belül, amely virtuális socketen alagutazik a gazdagép egyik hídjához, az pedig a bájtokat a démon saját átjárójának adja át — ez egy csak a tulajdonos számára elérhető helyi socket-figyelő, TCP-figyelő és általános továbbítási mód nélkül. Az átjáró érvényesíti a HTTP, a CONNECT, a WebSocket, az átirányítás, az origin, a letöltés és a feltöltés szabályait a Nessie meglévő, rögzített lekérési mechanizmusával, nem ugyanazon szabályok második megvalósításával. Nincs NAT-híd és nincs közvetlen DNS-feloldó: az alternatív DNS, a nyers TCP, a QUIC és a proxy megkerülése mind tiltott.

Az origin-listát, amelyet az átjáró érvényesít, a gép tulajdonosa állítja be a gépen, és szándékosan soha nem töltik fel. A felület ezt a hiányt megnevezi, ahelyett hogy úgy tenne, mintha a Nessie origin-szabályzat-szerkesztő volna: ha tudni akarod, mit érhet el egy böngészős executor, kérdezd meg a gép tulajdonosát.

Hitelesítő adatok

Gazdagépi hitelesítő-tároló soha nincs csatolva vendéghez. Sem a kulcstartó, sem a ~/.codex vagy a ~/.claude, sem globális CLI-token, sem API-kulcsot hordozó környezeti változó. Egy kezelt kódolási munkamenet egyetlen támogatott bejelentkezése a tulajdonos számára privát hitelesítési fájl, amelynek tartalmát kizárólag a tulajdonos által vezérelt initrd-építő olvassa — soha nem a Nessie, nem a leíró, nem egy napló vagy egy parancsargumentum —, és egyszer egy privát home-ba kerül a vendégen belül, amelyet a VM-mel együtt megsemmisítenek. Az a vendég pontosan egy originhez férhet hozzá.

A böngészős executor ennél is szigorúbb: minden munkamenet kap egy friss, privát böngészőprofilt, és visszautasítja a munkaterület által előkészítettet, így sütik, bővítmények és örökölt bejelentkezés nélkül indul.

Nyers helyi adat csak egy explicit, korlátos futtatáson belül juthat el egy modellszolgáltatóhoz. A Nessie által tárolt adatok redaktált manifesztek, argumentum- és szabályzat-digestek, eredmény-digestek és strukturált állapot. Fájltartalom, terminálkimenet, böngésző-DOM, hitelesítő adat és azonosítási tényező nem kerülhet adatbázis-rekordba, audit-bejegyzésbe, naplóba, valós idejű eseménybe vagy hibajelentésbe.

Mit ad egy üzemeltető, és hogyan vonja vissza

Az executor-használati jogosultság nem egyetlen kapcsoló. Egy ügynök csak akkor hívhat meg műveletet, ha birtokolja a jogosultságot pontosan arra az egzakt executorra és pontosan arra az egzakt műveletre, és a szokásos logikai eszközszabályzat engedi, és a futtatás hatóköre egyezik, és a gép saját helyi szabályzata engedi. Egy executornak adott műveleti jog tehát semmit nem enged egy másikon, a képességfrissítés pedig nem szélesíthet semmit, mert az új műveletek alapból megtagadottan érkeznek.

Az ügynök-hozzáférés és a megosztás is azonnal érvényesül magán az oldalon, nincs jóváhagyási folytatás, jelszókérés vagy újrahitelesítési lépés. Az executor Ügynökök fülén a kezelő közvetlenül be- vagy kikapcsolja egy ügynök gépi hozzáférését; a Megosztás fülön ugyanígy adhatnak egy személynek Használhatja vagy Adminisztrátor jogot, vagy bővíthetik a használatot egy projektre, illetve a jelenlegi csapat minden tagjára. Csak a saját asszisztens-beszélgetésedben — soha megosztott csatornában, ütemezett feladatban vagy másik ügynök futtatásában — az asszisztens előkészíthet ügynök-hozzáférési vagy hozzárendelési változtatást; ez egy megerősítő kártyát tesz ki abban a beszélgetésben, és semmi nem változik, amíg meg nem nyomod rajta a „Hozzáférés engedélyezése” gombot. A csevegőszöveg soha nem számít megerősítésnek.

Három változtatáshoz még mindig újra be kell írnod a jelenlegi jelszavadat a megerősítés pillanatában: egy leíró-revízió aktiválásához; egy asszisztens által előkészített hozzárendeléshez, amely személynek — nem ügynöknek — ad gépet; és egy állandó szabályzathoz, amely lehetővé teszi a kollégák számára, hogy tulajdonosként parancsokat indítsanak rajta, az úgynevezett felügyelet nélküli jegymunka-szabályzathoz. A gép leválasztása vagy törlése szándékosan nem kér egyiket sem, mert a vészkapcsolónak soha nem lehet nehezebben elérhetőnek lennie, mint amit leállít. Az átnézett piszkozat alkalmazása mindig kéri. Az audit-napló külön rögzíti a cselekvő személyt és az asszisztens részvételét.

Az executor egy kis, explicit állapotkészleten halad végig:

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

A fejléc Számítógép menüjében a kezelő előkészíti az egyes életciklus-változtatásokat: szüneteltetheti, szüneteltetés után folytathatja, leválaszthatja vagy törölheti. A szüneteltetés az executort online hagyja, de leállítja a parancsfogadását. A leválasztás érvénytelenít minden kliens-tanúsítványt és minden kiadott jelölt-fogantyút, és nem vonható vissza — a leválasztott executort új executorként kell újra párosítani. A törlés ugyanezt teszi, és emellett eltávolítja az executort a listából; a leválasztással ellentétben az executor állapotától függetlenül felajánlják, még függőben lévő párosítással és már leválasztott állapotban is, mert ez az egyetlen mód, hogy valaki kikerüljön a listából. A kiürítés — a már meglévő munka befejezése, mielőtt több munkát vesz fel — a protokoll valódi harmadik állapota; a felület mutathat ilyen gépet, de ezt semmi itt nem indítja el: csak egy közvetlen API-hívás. Minden megerősített hozzáférés-változtatás, leíró-átnézés és életciklus-átmenet, a kiürítés is beleértve, megemeli a démon kapcsolati korszakát is, így a következő vezérlési lekérdezése — legfeljebb egy másodpercen belül — meghiúsul, és leállítja az összes élő vendéget, mielőtt újracsatlakozhatna. A visszavonás olyan kérés, amelyet a gép nem hagyhat figyelmen kívül.

Executor üzemeltetése

Az egészség ellenőrzése

A Nessie saját válasza az élettartam-ellenőrzés. A démon aláírt életjelet küld, és az az executor, amelynek utolsó hitelesített tevékenysége hatvan másodpercnél régebbi, tartósan offline-ként van megjelölve, mielőtt listázni, kiválasztani vagy neki munkát küldeni lehetne. Az az executor, amely online-ként látszik, az elmúlt egy percen belül bizonyította magát.

A gépen nincs állapotvégpont — a démon szándékosan egyetlen üzemeltetői portot sem hallgat. macOS-en és Linuxon kérdezd meg közvetlenül a CLI-t:

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

macOS-en a státusz csapatonként jelenti a launchd-ügynököt. A systemctl parancs csak Linuxon érvényes. Windowson a tálcaikon az első pillantásra adott válasz, a menüje megnevezi az okot, a szolgáltatásnapló pedig a részleteket tartalmazza. Mindkét platformon a Nessie-ben az executor Áttekintés fülén látszik a jóváhagyott profilok, az adatok határa, mikor látták utoljára, és minden függőben lévő helyi szabályzat-javaslat, amely átnézésre vár.

Naplók

Minden olyan elutasítás, amelyre egy személy tehet valamit, itt jelenik meg: egy aláíratlan vagy megváltoztatott futtatókörnyezet, egy állapotkönyvtár, amelyet nem lehet biztonságosan beállítani, egy executor, amely indításkor nem indult el. Soha nem kerül ide párosítási kihívás, kulcs vagy gyermekfolyamat kimenete. Nincs naplószint-beállítás, amelyet fel lehetne emelni, mert nincs ennél részletesebb mód.

A Mac CLI minden csapat szolgáltatásnaplóját a ~/Library/Logs/NessieExecutor/<executorId>.log helyre írja.

Frissítés

A CLI-t Homebrew, APT vagy DNF segítségével frissítsd, majd minden csapat szolgáltatását indítsd újra először disable, majd enable paranccsal. A WinGet a Windows-executort frissíti. A közvetlen Nessie Desktop telepítők aláírt, alkalmazáson belüli frissítéseket kínálnak; az MSI- és a Debian-telepítések a csomagkezelőjüket használják. A párosítások és a helyi jogosultságok túlélik a frissítéseket.

Leállítás és eltávolítás

A leállítás a démon által kezelt, szabályos út, nem kényszerített leállítás. Megkap egy leállító jelet, minden vendégmunkamenetet leállít, felszabadítja a bérletét, és kilép. Linuxon az egység tizenöt másodpercet vár egy tízmásodperces lebontási keretre, és szándékosan soha nem kényszerít fel megszakíthatatlan leállítást — mert egy lebontás közben megölt démon egy mikro-VM-et és egy munkaterület-átfedést hagy árván, olyan folyamat nélkül, amely megtisztítaná őket. Egy elakadt leállás ezért látszik a systemctl --user status kimenetében, nem csendben, és a leállítás kikényszerítése kifejezett emberi döntés.

A Linux-csomag eltávolításához:

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

Windowson az msiexec /x leállítja és eltávolítja a szolgáltatást, a rendszerleíró-bejegyzéseit és a tálca indítási bejegyzését. Mindkét platformon a párosított állapot szándékosan megmarad — Linuxon a ~/.local/state/nessie-executor/, Windowson a %ProgramData%\Nessie Executor helyén. Egy párosítás egy gépi kulcs és egy aláírt szabályzat-revízió, és egy program eltávolítása nem kérés ezek megsemmisítésére; újratelepítéskor ott találja őket, ahol voltak. A párosítás kézi törléséhez töröld a könyvtárat, a másik oldalról pedig a Nessie-ben vond vissza az executort.

A Windows-tálca és az asztali segédprogram is a Párosítás elfelejtése ezen a számítógépen műveletet kínálja elsőrangú funkcióként: leállítja a helyi démont, eltávolítja a gépi kulcsot és a mappaválasztást, és egyetlen natív megerősítés után véglegesen törli a helyi piszkozat-másolatokat — miközben a szerveroldali executort és annak audit-előzményeit az egyik tulajdonosnak meghagyja megtartásra vagy visszavonásra.

Gyakori hibák