Screen szerű program X-re. (Xpra)

Pont azért, mert az ssh forwarding "elszakadhat". Ahhoz, hogy egy X kliens (= X-es kimenetű program) életben maradjon, kell hozzá egy szerver; bármi, ami tud vele X protokollon beszélgetni (request-eket fogadni, válaszokat küldeni, ill. notification-öket küldeni). Ugyanez a helyzet a screen programmal; ahhoz, hogy egy TTY-t használó alkalmazás futni tudjon, kell alája egy (fizikai vagy pszeudo-)terminál.

Amikor ssh-val parancssorilag bejelentkezel, akkor az sshd létrehoz egy pszeudo-terminált a távoli gépen. Amit az ott futó program ír/olvas a terminálról (ami a pszeudo-terminál slave oldala), azt az sshd olvassa/írja a pszeudo-terminál master oldalán. Az sshd ezt a forgalmat OpenSSL és TCP socket felett továbbítja az ssh kliensnek, amely a helyi gépeden ezt a forgalmat a normál terminálodra írja / arról olvassa. Ez a normál helyi terminál lehet pl. linux vt, vagy pszeudo-terminál slave fele (az rendelkezik terminál-jellemzőkkel), melynek master felén lehet mondjuk helyi xterm (amelyik rajzolja a betűket, meg a ^C X11 eseményt kezeli).

helyi xterm -- helyi pty master -- helyi pty slave -- ssh -- sshd -- távoli pty master -- távoli pty slave -- mc

Ugyanez screen-nel, távoli gépen:

helyi xterm -- helyi pty master -- helyi pty slave -- ssh -- sshd -- távoli pty master -- távoli pty slave -- screen kliens -- screen szerver -- pty master -- pty slave -- mc

Azt kell látni, hogy az ssh-sshd kapcsolat megszakadhat. Az mc-nek viszont mindenképpen kell egy terminál, amelyre írhat (pty slave). A pty slave-nek kell egy pty master oldal, amihez meg kell egy processz, ami nyitva tartja. Ez a processz a screen server, ami robusztus, nem patkol el, és ami a lényeg, a screen server és az mc közötti teljes útvonal a teljes gépen belül van, tehát nem függ a hálózattól.

Ugyanez X-re. A helyi X így néz ki:

helyi X szerver -- unix domain socket v. shm -- helyi X kliens 

A nem biztonságos (ma már nem használt) TCP feletti kapcsolat ugyanez, csak unix domain socket helyett TCP socket van (és nincs shm).

helyi X szerver -- TCP socket -- távoli X kliens

Az ssh forwarding:

helyi X szerver -- unix domain socket -- ssh (mint helyi X kliens) -- sshd (mint távoli X szerver) -- unix domain socket -- távoli X kliens.

A távoli X kliens az sshd-t az ott beállított DISPLAY változó alapján találja meg. Az X autentikáció pedig úgy működik (ha jól emlékszem), hogy az sshd a távoli gépen belépéskor lefuttatja az xauth-ot, ami legenerál egy cookie-t a ~/.Xauthority file-ba, ahhoz a DISPLAY-hez, amely az sshd-re mutat. Amikor a távoli kliens elindul és autentikálja magát az ~/.Xauthority-ból, akkor az sshd (ha jól tudom) ezt ellenőrzi. A helyi gépen (ahol az igazi X szerver fut) pedig az ssh (mint helyi X kliens) csatlakozik a helyi ~/.Xauthority használatával a helyi X szerverhez.

Ez jó, csak meg tud szakadni. A következő lépés az, amit a screen is csinál: kell egy X szerver, ami a távoli gépen van, hogy a teljes (pontosabban, egy teljes) szerver-kliens út meglegyen a távoli gépen.

Az egyik lehetőség erre az Xvnc, amely tokkal vonóval csinál egy X szervert a távoli gépen, és teljesen önálló VNC protokollon érhető el.

helyi X szerver -- vnc kliens (mint helyi X kliens is!) -- távoli VNC szerver (mint távoli X szerver is!) -- távoli X kliens

Ebben az a cumi, hogy a VNC szerver egy "root window"-val rendelkező displayt valósít meg, így eleve kell neki egy önálló WM is, és ezért látszik külön dobozban a helyi gépen.

Az xpra ehelyett azt csinálja (ha jól értem), hogy

helyi X szerver -- xpra kliens (mint helyi X kliens is) -- távoli xpra szerver (mint speciális (= WM) távoli X kliens) \
                                                                                                                        \
                                                           távoli X kliens 1                                           -- távoli Xvfb
                                                           távoli X kliens 2                                            /

A compositing window manager (ami egy speciális X kliens) a többi kliens ablakának a belsejét is megkapja (ezért tudná pl. OpenGL-lel kockára renderelni), nem csak a "new window mapping request"-eket meg ilyeneket. Ebben az esetben az xpra szerver ezt a stuffot visszanyomja az xpra kliensnek. A használt protokoll egyedi, és nem root window bitmap szintű (mint a VNC-nél), hanem "compositing" szintű. Az xpra kliens ezeket az ablakokat megnyitogatja (helyi X kliensként) a helyi X szerveren, amelyet a helyi speciális X kliens (WM) fog elrendezgetni.

Arra lennék nagyon kíváncsi, hogy ha az xkill-lel lenyomsz egy ablakot, amelyet az xpra kliens nyitott, akkor az összes ilyen ablak (amelyek esetleg más távoli alkalmazásokhoz tartoznak) is becsukódik-e.

Az ssh forwarding esetében ugye minden egyes távoli alkalmazáshoz az ssh kliens (mint helyi X11 kliens) új kapcsolatot hoz látre a helyi X11 szerverrel (a unix domain socket-en). Ebből a szempontból (is) az ssh speciális X11 kliens; a legtöbb X kliens nem hoz létre egynél több kapcsolatot a szerverrel. Az xkill hatására az X szerver lerúgja az érintett kapcsolatot, amitől azonban az ssh-nak még n-1 kapcsolata megmarad (a maradék távoli alkalmazás forwardjai).

Az az érdekes, hogy az xpra, mint egyetlen távoli X kliens, elég okos protokollal bír-e ahhoz, hogy a távoli, különböző alkalmazások ablkait alkalmazásoknak megfelelő X11 kapcsolatokba csoportosítsa. Teszem azt, a távoli gépen elindul a firefox 2 ablakkal, meg egy xterm. (Ez az Xpra szerver (mint wm) szemében 3 külön ablak.) Ennek elvileg az xpra kliens és a helyi X11 szerver között összesen 2 kapcsolatot kellene megfeleltetni (a unix domain socket-en), hogy amikor az xkill-lel belebök valaki az egyik firefox ablakba, akkor a firefox elpukkanjon (a másik ablakával együtt), az xterm azonban ne.

Hát ez hosszú lett.