Állomások

Csak tények. A mögöttük lévő modellhez lásd: Állomások és elszigetelt környezetek; egy gép megnyitásához kövesse az útmutatót.

Felületek és háttérrendszerek

Felület	Mit vezérel	Háttérrendszer	Érték	Elszigetelt kimenő forgalom
Terminál (exec)	Shell a VM exec-csatornáján	microVM	smolvm	Igen
Böngésző	Headless Chromium (CDP), Firefox (WebDriver BiDi) vagy WebKit (W3C WebDriver)	microVM	smolvm	Igen
Számítógép	X11-es asztal: bemenet a hypervisoron keresztül, rögzítés a vendéggép ügynökén keresztül	QEMU	qemu-hvf (macOS), qemu-kvm (Linux), qemu-tcg (gyorsítás nélküli tartalék, soha nem választódik automatikusan)	Igen
Android	Android ADB-n keresztül	A Google emulátora	android-emulator	Nem – az emulátor maga kezeli a hálózatát
iOS	iOS-szimulátor WebDriverAgenten keresztül	CoreSimulator	ios-simulator	Nem – a hálózat a gazdagép Macet követi

A terminál és a computer_use felület ugyanazt a computer felületértéket használja; a terminált az exec-képe jelölője különbözteti meg, és soha nem hasznosul újra vezérelhető asztalként (és fordítva). Egy beszélgetés egy terminálgépet használ újra.

Böngészőmotorok

Motor	Érték	Protokoll	Élő nézet	Állóképek
Chromium	chromium (alapértelmezett)	Chrome DevTools Protocol	Képernyőközvetítés – a böngésző képkockákat küld, ahogy az oldal újrarajzolódik	JPEG
Firefox	firefox	WebDriver BiDi	Lekérdezéssel gyűjtött állóképek (a BiDi-nek nincs képernyőközvetítése), legfeljebb 6 fps	JPEG
WebKit	webkit	W3C WebDriver (klasszikus)	Lekérdezéssel gyűjtött állóképek, a gazdagép ffmpeg-je által transzkódolva	PNG

Egy állomás a teljes élettartama alatt egyetlen motort futtat. Egy beszélgetés motoronként egy állomást tarthat, és éppen ez teszi lehetővé az egymás melletti összehasonlítást: a „Firefox (VM)” és a „Chromium (VM)” egymás mellé nyitása két gép, és az egyik bezárása nem érinti a másikat.

Adja át az engine paramétert a rig.open számára vagy a browser_use eszköznek. Az ismeretlen nevet nem cseréljük alapértelmezésre, hanem elutasítjuk – ha valaki egy böngészőt kér, és csendben egy másikat kap, az egy kompatibilitási kérdésre ad rossz választ.

A motorokra jellemző korlátok, kimondva ahelyett hogy megkerülnénk őket:

• A Firefoxnak nincs gyorsítótárat megkerülő újratöltése (a BiDi ignoreCache paraméterét egyenesen elutasítja), így a kemény újratöltés egy hétköznapi újratöltés.
• A WebKitnek szintén nincs gyorsítótárat megkerülő újratöltése, és nincs konzolcsatornája sem (a kimenetet úgy rögzíti, hogy minden navigáció után beköt a console.*-ba, így a betöltés közben naplózott sorok elvesznek – minden konzolkinyerés ezt is mondja), az élő nézetéhez pedig ffmpeg kell a gazdagépen.
• Egyik sem tár fel platformszintű kisegítőlehetőség-fát a protokollján keresztül, így az extract (a11y) egy DOM-ból származtatott közelítést ad vissza, amelyet annak is jelöl meg.
• Egyik sem fogad valódi fájlejtést; egy fájlbemenet ettől még ráirányítható a gépen belüli elérési utakra.

Gépképek

Felület	Kép	Letöltés
Terminál	ubuntu:24.04, digesttel rögzített	Automatikusan az első indításkor, a gép saját kapuzott hálózatán keresztül
Böngésző (Chromium, Firefox, WebKit)	debian:trixie-slim, digesttel rögzített, valamint a motor saját csomagjai	Automatikusan az első indításkor, majd előmelegített csomagként gyorsítótárazva
Számítógép	Egy qcow2 asztali kép Chromiummal, Firefoxszal, WebKitkel és ugyanazzal a GitHub által üzemeltetett runnerhez hasonló parancssori alapszinttel, amelyet a terminál melegít elő	Importálás a Beállítások → Szerver → Állomások alatt (ahol elérhető, ellenőrzőösszeggel rögzített letöltések)
Android	A Google rendszerképei	Az Android SDK-n keresztül
iOS	Egy Xcode-szimulátor futtatókörnyezet, valamint ellenőrzőösszeggel rögzített WebDriverAgent	A futtatókörnyezet az Xcode-on keresztül; az automatizálási híd a Beállítások → Szerver → Állomások alatt

Miután minden microVM-fajta először elindult, a szerver egy előre kicsomagolt másolatot gyorsítótáraz az adatkönyvtárban, és minden későbbi gépet abból indít – beleértve azokat az előmelegített képeket is, amelyekben a csomagok már telepítve vannak. A terminál egy GitHub által üzemeltetett runnerhez hasonló parancssori eszközkészletet melegít elő (git, gcc, python3, jq, rsync, archiváló eszközök és az apt alapszint többi eleme; nem a Docker és nem a nyelvi eszköz-gyorsítótárak). A Számítógép qcow2 képe ugyanezeket a parancssori neveket már a kép buildelésekor beégeti, az XFCE és a három böngésző mellé. Minden böngésző előmelegíti a saját motorját. Mindhárom motor ugyanazt a Debian-alapot használja, de soha nem osztoznak egy csomagon: a gyorsítótár kulcsa a kép, a motor és egy hangrevízió (audio-v1-<engine>), mert egy adott motorhoz – vagy még azelőtt, hogy a PulseAudio és az ffmpeg a munkaterhelés része lett volna – előmelegített gépen a másikból semmi sincs benne. A terminálcsomag kulcsa ugyanezen okból egy eszközkészlet-revízió (tools-v1): egy olyan csomag, amely még azelőtt melegedett elő, hogy a fordító a kép része lett volna, nem szolgálhat ki egy olyan gépet, amelynek állítólag van fordítója.

Nincs olyan beégetett automatizálási kép, amelyet érdemes lenne átvenni – a Chromium chromedp/headless-shell képe az ALSA-t és a PulseAudio-t is kikompilálja, így soha nem tud hangot kiadni; az egyetlen gondozott Firefox-kép a Debian-alap 33×-osa, és még mindig nem tartalmaz socat-ot; gondozott WebKit-kép pedig egyáltalán nincs. Ezért minden motor az első indításkor telepíti magát (chromium, firefox-esr vagy webkit2gtk-driver), és közben eléri a Debian csomagtárait (deb.debian.org, security.debian.org, cloudfront.debian.net). A Chromium a disztribúció binárisa, amelyet a chromium --headless=new parancs indít el.

Munkaterületenkénti egyéni képek

Beállításkulcs	Mit ír felül
rigs.smolvm.execImage	A Terminál (VM) képét
rigs.smolvm.browserImage	A Chromium Böngésző (VM) képét

Az adminisztrátori kapuval védett munkaterület-beállítástáron keresztül íródik (Beállítások → Szerver → Állomások → Egyéni képek (ez a munkaterület)). Az értéknek registryhivatkozásnak kell lennie – a helyi elérési utakat, archívumokat és kapcsolószerű sztringeket elutasítjuk, mind a mezőnél, mind pedig újra indításkor. Az érvénytelen tárolt értéket hangosan figyelmen kívül hagyjuk, és helyette az alapértelmezett indul el. A kép saját registryje (valamint a Docker Hub, a GHCR, a Quay, a GitLab és a GCR ismert blob-CDN-társai) a letöltéshez a kimenőforgalmi kapun keresztül kap beengedést.

Terminálkép-szerződés – bash jelen van; a git, a curl és a socat előre telepítve vagy egy Debian/Ubuntu apt-alap (a környezet az első indításkor telepíti azt a hármat, valamint egy GitHub által üzemeltetett runnerhez hasonló parancssori eszközkészletet: fordítók, Python 3, jq, archiváló eszközök, rsync. A nyelvi eszköz-gyorsítótárak és a Docker nem települnek).

Böngészőkép-szerződés – egy Debian/Ubuntu apt-alap (vagy a már telepített csomagok) bash-sal és socat-tal, valamint egy chromium bináris, amelyet a szerver maga indít el chromium --headless=new formában, a DevTools a vendéggép loopback 9223-án, a vendéggép 9222 portjára továbbítva. A PulseAudio és az ffmpeg az első indításkor települ a hangsávhoz. Ne építsen FROM chromedp/headless-shell alapot: a felsőbb szintű headless.gn az ALSA-t és a PulseAudio-t is kikompilálja, így az a bináris nem tud hangot kiadni. A felülbírálás csak Chromium-állomásokra vonatkozik – az általa indított munkaterhelés-parancs a Chromiumé, és ha a Firefoxnak vagy a WebKitnek adnánk át, egy nem létező binárist indítana el. A Firefox- vagy WebKit-állomás hangosan figyelmen kívül hagyja, és a rögzített képét indítja el.

Automatizálási portok – minden böngészőgép pontosan egy gazdagép-loopback portot továbbít a vendéggép 9222 portjára. Mögötte: a Chromium DevTools-a és a Firefox távoli ügynöke a vendéggép loopback 9223-án ül, előttük egy socat továbbító (mindkettő feltétel nélkül a loopbackhez kötődik); a WebKit illesztőprogramja egy --host paramétert vesz át, és maga köti a vendéggép hálózati kártyáját. A Firefox emellett a Host fejlécet a saját portjához validálja, így a kliens a vendég oldali authorityt küldi, nem pedig azt, amelyet felhívott.

Műveleti igék

Minden művelet feldolgozása teljes: a hibás szerkezetű payload egy, a mezőt megnevező üzenetet ad vissza, soha nem kivételt. A megfigyelő igék (○ jelöléssel) akkor is engedélyezettek maradnak, amikor egy ember tartja a vezérlést; a módosító igéket elutasítjuk.

computer_use

screenshot○, cursor_position○, mouse_move, left_click, right_click, middle_click, double_click, triple_click, left_mouse_down, left_mouse_up, left_click_drag, scroll, key, hold_key (0–60 s), type, wait○ (0–60 s), set_display, clipboard_read○, clipboard_write.

A koordináták a vendéggép aktuális módjában értendő vendégpixelek; minden képernyőkép megadja a kijelző méretét. A billentyűkombinációk X11-es írásmódot használnak (ctrl+s, alt+Tab, Return).

A clipboard_read egy selection paramétert vesz át: clipboard (amit a ctrl+C megtölt, ez az alapértelmezett), primary (X11 kijelöléssel másolás) vagy xdnd (egy folyamatban lévő húzás). Az üres eredmény mindhárom esetben normális válasz. A clipboard_write csak text paramétert vesz át – a képek és a fájlok a fájlsávon utaznak, mert egy művelet argumentumai bekerülnek az auditnaplóba, és a képbájtoknak ott nincs keresnivalójuk. A vágólap tartalma nem megbízható adatként, elhatárolva érkezik vissza.

browser_use

navigate (csak http/https), reload (hard opcionális), stop_loading, click (szelektor vagy koordináta), fill, type, key (DOM-kulcsnevek), scroll, mouse_move, drag, left_mouse_down, left_mouse_up, extract○ (a11y | dom | console), screenshot○ (full_page opcionális), set_viewport (min. 320×240), history, wait_for○ (szelektor, 0,1–30 s), clipboard_read○, clipboard_write.

A kinyert oldaltartalom nem megbízható adatként, elhatárolva érkezik vissza.

A böngészőnek pontosan egy vágólapja van, így a clipboard_read nem vesz át selection paramétert. Mindkét vágólapige biztonságos környezetet igényel: a sima http://-n kiszolgált oldalnak egyáltalán nincs vágólap API-ja, és az ige ezt ki is mondja ahelyett, hogy üres vágólapot jelentene – ilyenkor használja a type-ot, amely a kurzornál szúr be, anélkül hogy a vágólapot használná.

mobile_use

tap, swipe (50–5000 ms), type, key (aliasok: back, home, recents, enter, delete, backspace, tab, escape, search, menu, volume_up, volume_down, power, vagy bármely KEYCODE_*), screenshot○, ui_dump○, install_apk (az állomás worktree-jére és a szerver adatkönyvtárára korlátozva), start_app, stop_app, clear_app_data, uninstall_app, open_url és shell. A shell egy argv-listát vesz át, és az Androidon belül fut, soha nem egy gazdagép-shellen keresztül; lefedi a fejlesztői diagnosztikát, például a logcat, dumpsys és pm grant használatát.

A mobile_use-nak nincsenek vágólapigéi. Az Android 10 óta csak a fókuszált alkalmazás olvashatja a vágólapot.

ios_use

tap, swipe (50–5000 ms), type, key (enter, backspace, tab, escape, nyílbillentyűk vagy egy nyomtatható karakter; opcionális command, control, option és shift módosítók), home, lock, unlock, screenshot○, ui_dump○, install_app (egy szimulátor .app könyvtár, az állomás worktree-jére vagy a szerver adatkönyvtárára korlátozva), start_app, stop_app, uninstall_app, open_url és spawn. A spawn argv-t vesz át, és a szimulátoron belül, a simctl-en keresztül hajtja végre; soha nem hív gazdagép-shellt.

A koordináták iOS-képernyőpontok, nem képernyőkép-pixelek. Az élő adatfolyam megtartja a szimulátor rögzített méretét, és fekete sávokkal illeszti be ahelyett, hogy átméretezné az eszközt. A gazdagép és a szimulátor közötti, mindkét irányú szöveges vágólapátvitel ugyanazt a felhasználónkénti, irányonkénti engedélyszabályzatot használja, mint a többi állomás; a fájlokat és a képeket az iOS vágólapsávja nem fogadja el.

Minden állomás egy saját tulajdonú CoreSimulator-eszközt és WebDriverAgent-munkamenetet hoz létre. Bezárásakor leállítja a WebDriverAgentet, leállítja és törli azt az eszközt, valamint eltávolítja a nyilvántartási bejegyzését. Az iOS-állomások csak Xcode-dal, telepített iOS futtatókörnyezettel és a rögzített automatizálási híddal rendelkező macOS-szerveren futnak. Nem kínálnak hangot, mikrofont, fájlejtést, gazdagép-shellt vagy elszigetelt hálózati garanciát.

Kezelőeszközök

Eszköz	Leírás
rig_list	Egy munkaterület állomásainak listázása felülettel, állapottal, kijelzővel és vezérlővel
rig_close	Egy állomás megsemmisítése és a lemezének eldobása

Életciklus

Fázis	Jelentés
provisioning	Indul; az állapot részletei szó szerint hozzák az aktuális lépést
ready	Elérhető, és fogadja a műveleteket
parked	Tétlenség miatt parkolva: a vCPU-k leállítva, a RAM továbbra is rezidens; a következő művelet felébreszti
closing	Leállás alatt
closed	Eltűnt; a sor megmarad az auditnyomhoz
failed	Elpusztult, vagy soha nem indult el; megkülönböztethető, hogy a felület újrapróbálkozást kínálhasson

Lezárás oka	Mikor következik be
requested	Egy ember vagy ügynök kérte
idleTimeout	A tétlenségi időablak kétszeresén túli tétlenség, vagy memória miatti kilakoltatás
ttlExpired	A kemény élettartam lejárt
conversationEnded	A tulajdonos beszélgetés véget ért
workspaceGone	A munkaterületet törölték, vagy megszűnt a tagság
serverShutdown	A szerver leáll
backendFailure	Alatta elpusztult a hypervisor

Alapértékek és felső korlátok

Érték	Terminál	Böngésző	Számítógép	Mobil
Memória	512 MB	2048 MB (Chromium); 2560 MB (Firefox, WebKit)	4096 MB	4096 MB
vCPU-k	2	2	4	4
Kemény TTL	8 óra	2 óra	2 óra	2 óra
Tétlenségi időablak	45 perc	15 perc	15 perc	15 perc
Indítási kijelző	—	1280×800	1280×800	1080×1920

• Az ügynöki sáv állóképei 1280×800-ra vannak korlátozva; az emberi sáv 2560×1600-ig tárgyal fel.
• A gazdagép összes állomásra vonatkozó rezidensmemória-kerete alapértelmezés szerint 12 GB, rezidens megabájtban számolva (egy parkolt VM továbbra is fogja a RAM-ját). A kilakoltatás a legrégebben használt gépet érinti, és soha nem visz el olyan gépet, amelyet éppen vezetnek, néznek, vagy amelyben nyitva van egy terminál.
• Egy nyitott terminál vagy figyelősáv hozzákötözi az állomást, megakadályozva a parkolást és a tétlenségi begyűjtést; a kemény TTL ettől függetlenül érvényes.

Portok és fejlesztői tartományok

Port	Hol	Mire fenntartva
7911	Terminál vendéggép	A portmultiplexer, amelyen minden továbbítás halad
9222, 9223	Böngésző vendéggép	Az automatizálási továbbító és végpont (a WebKit közvetlenül a 9222-t köti, és nem használ továbbítót)
80, 443	Böngésző vendéggép loopbackje	A fejlesztői tartomány HTTP/HTTPS sávjai

• A felderítés szerveroldalon körülbelül 4 másodpercenként lekérdezi a terminál vendéggépének figyelt TCP-portjait.
• Állomásonként legfeljebb 16 port továbbítódik automatikusan; a többiek megjelennek a naplóban, de nem kerülnek továbbításra.
• A gazdagép oldali továbbítás a loopbackhez kötődik, előnyben részesítve a vendéggép saját portszámát; a Megosztás a helyi hálózaton hozzáad egy operációs rendszer által kiosztott LAN-portot.
• A fejlesztői tartományoknak meg kell felelniük a name.test vagy a name.localhost mintának (kisbetűs, legfeljebb 63 karakteres címke). Egy tartomány egy portra képeződik.
• A fejlesztői tartomány HTTPS-e egy szerveren helyi hitelesítésszolgáltatót használ (EC P-256, a <dataDir>/rigs/tls/ alatt, 0600 jogosultságú kulcsokkal, amelyek soha nem kerülnek a vendéggépbe), egyetlen helyettesítő karakteres levéltanúsítvánnyal a *.test / *.localhost számára. Ha a gazdagépen nincs openssl, nincs HTTPS-sáv; a sima HTTP továbbra is működik.

A kimenő forgalom alapértékei

Felület	Alapértelmezett engedélylista
Terminál	A homokozó fejlesztői alapszintje (kódhosztok, csomagregisztrációk, modellszolgáltatók) + az Ubuntu apt-tükrök + magának a worktree-nek a kódhosztja
Böngésző	usectrl.dev (a termék oldala) – plusz a Debian csomagtárai minden motor első indításakor, amíg az telepíti a csomagjait. A kezdőlap egy helyi file:// dokumentum, amelyhez nem kell kimenő forgalom
Számítógép	Üres – mindent megtagad –, amíg egy hívó gazdagépeket nem engedélyez
Mobil	Nincs kikényszerítve (az emulátor kezeli a hálózatot)

Minden microVM emellett megkapja a képe registrygazdagépeit, kizárólag a letöltéshez. A hitelesítőadat-közvetítő engedélyezett gazdagépeinek halmaza ugyanabból az engedélylistából származik: nem készül token olyan gazdagéphez, amelyet a vendéggép nem ér el.

Vágólap és fájlátvitel

A másolás/beillesztés mindkét iránya, valamint a fájlok be- és kihúzása. Egy állomást vezérlő ember számára elérhető; egy ügynök a vágólapot a fenti igéken keresztül kapja meg, fájlátvitelt pedig egyáltalán nem (hiszen már van egy shelle az elszigetelt környezetben).

A vágólap átlépése felhasználónként és irányonként szabályozott. Az állomásra beillesztés alapértelmezés szerint engedélyezett; az állomásról kifelé másolás rákérdez (tízperces engedély, vagy mindig engedélyezés a Beállítások → Szerver → Állomások → Vágólap-hozzáférés alatt). A két választás független egymástól, és soha nem munkaterületi beállítás.

Sáv	Útvonal	Mit szállít
Vágólap	GET/POST /rig/clipboard/<rigId>	Szöveg, egy PNG/JPEG (≤16 MB), valamint a vágólapon lévő fájlok vendéggépbeli elérési útjai
Fájlok	POST /rig/files/<rigId>	Legfeljebb 64 fájl, egyenként ≤256 MB és ejtésenként ≤512 MB, opcionális vendégpixel-ejtési ponttal
Fájlok	GET /rig/files/<rigId>?p=<base64url path>	Egy fájl bájtjai, kifelé

• HTTP, nem RPC. Az RPC-socket lezárja a kapcsolatot, ha egy bejövő keret meghaladja a 256 KB-ot – ez egy DoS-védelem, amely helyes a JSON-parancsoknál, és végzetes egy beillesztett képernyőképnél. A bájtok ugyanolyan útvonalon haladnak, mint az állomásképkockák és a megbeszélés hangja.
• A hitelesítés a rig-files:<workspaceId>/<rigId> aláírt cél plusz a munkaterületi tagság – ez saját cél, így egy gép megnézésére kiállított URL nem tud fájlokat is írni bele.
• Az átvétel érvényesül. A vágólap írása és a fájlok ejtése módosító művelet, ezért elutasításra kerül, amíg más tartja a vezérlést; a vágólap olvasása és egy fájl kiolvasása megfigyelés, ezért nem.
• Hová kerülnek az ejtett fájlok: ~/Drops (asztal), ~/drops (terminál – a worktree mellett, soha nem benne, így egy ejtés soha nem jelenik meg követetlen változásként), /tmp/cc-drops (böngésző). A könyvtárat a szerver választja; a hívó nem nevezheti meg. A meglévő fájlok soha nem íródnak felül – egy ütköző név 2-name.ext formában kerül be.
• Mit tud meg a vendéggép: a böngészőoldal egy valódi drop eseményt kap a kért ponton (Input.dispatchDragEvent); az asztal a fájlokat és azok URI-jait kapja meg a vágólapján, mert egyetlen gazdagép sem tud XDND-húzást szintetizálni egy tetszőleges eszközkészletbe privilegizált, vendégen belüli démon nélkül. A válasz megmondja, melyik történt meg a kettő közül.
• A kifelé húzás csak asztali gépen működik, és a vendéggép XdndSelection-jét olvassa, amíg egy húzás él. Az a payload, amely azonos azzal, amit a vendéggép már tartott a lenyomás kezdetekor, egy befejezett húzás elavult kijelöléseként kezelendő, nem újként – az X-nek nincs „a húzás véget ért” lépése.
• Képkövetelmények: az asztali képnek 2-es vagy újabb protokollt kell használnia (a vágólaptámogatás megérkezése után épült). Egy régebbi kép 404-gyel válaszol, és az alkalmazás azt mondja, hogy újra kell építeni, ahelyett hogy hibás gépként jelentené.
• Az auditnapló az alakot rögzíti, soha nem a tartalmat: a clipboard_read, clipboard_write, drop_files és read_file sorok darabszámokat, méreteket és elérési utakat hordoznak. A vágólap az a hely, ahol a hitelesítő adatok néhány másodpercre megfordulnak, és ebből semmi sem íródik le.

Korlátok, események, tárolás

• Az állománeszközök a enclosureControl műveletosztályt deklarálják (valamint a networkEgress és a processSpawn osztályt a használati eszközökön; a mobile_use és az ios_use a packageInstall osztályt is deklarálja). A rig_close a enclosureControl osztályt deklarálja; a rig_list egyet sem. Alapértelmezés szerint engedélyezett; a csak olvasható módok teljes egészében megtagadják; a térenkénti autonómiatárcsa „előbb kérdez” szintre sorolhatja le.
• Domainesemények: RigClosedEvent (a lezárás okával), RigControlChanged (átvétel / visszaadás), RigReaped (tétlenségi, TTL- vagy memóriakiürítés, a vezérlő ügynökkel). Egy állomás megnyitása nem esemény. Lásd: domainesemények.
• Tárolás: rig_sessions és rig_action_log minden munkaterület adatbázisában. A műveletnapló minden bemeneti eseményt rögzít a végrehajtó szereplővel és egy állomásonkénti monoton sorszámmal; a beírt szöveget írás előtt a hosszára és egy hashre cseréljük.
• Adatkönyvtár: rigs/images/ (importált qcow2 képek), rigs/smolvm/ (állomásonkénti futásidejű állapot), rigs/smolvm-packs/ (előre kicsomagolt gépcsomagok), rigs/tls/ (a fejlesztői tartomány hitelesítésszolgáltatója), rigs/run/ (QEMU overlay rétegek és seedek).
• Útvonalak: az élő nézet egy fül egy térben vagy egy PR-oldalon; a /settings/server/rigs az Állomások beállításképernyő.