Távoli Linux desktop elérése Windowsról
a (→VNC: olvasószerkesztés) |
a (→XRDP: olvasószerkesztés) |
||
138. sor: | 138. sor: | ||
A debianos csomag az előbb taglalt vnc4servert használja, így a fentiek segíthetnek a testre szabásban. |
A debianos csomag az előbb taglalt vnc4servert használja, így a fentiek segíthetnek a testre szabásban. |
||
− | Ugyancsak előny, hogy az RDP-ben a titkosítás adott, így nincs szükség tunnelre vagy VPN-re. Egyes netes források szerint a sima VNC-s kapcsolatnál gyorsabb, azzal az indoklással, hogy a VNC protokoll, ami lassabb az RDP-nél, csak lokálisan játszik szerepet, míg a valódi hálózati forgalomhoz az RDP protokoll szerint történik. Én ezt se cáfolni, se megerősíteni nem tudom, mindenestre nekem nem volt lassabb a sima VNC-nél. Az RDP valóban egy nagyon gyors protokoll két Windows között, ebben nagy szerepet játszik az, hogy szorosan együtt tud működni az operációs rendszerekkel, ami itt ilyen szinten nem valósul meg. |
+ | Ugyancsak előny, hogy az RDP-ben a titkosítás adott, így nincs szükség tunnelre vagy VPN-re. Egyes netes források szerint a sima VNC-s kapcsolatnál gyorsabb, azzal az indoklással, hogy a VNC protokoll, ami lassabb az RDP-nél, csak lokálisan játszik szerepet, míg a valódi hálózati forgalom az RDP protokoll szerint történik. Én ezt se cáfolni, se megerősíteni nem tudom, mindenestre nekem nem volt lassúbb a sima VNC-nél. Az RDP valóban egy nagyon gyors protokoll két Windows között, ebben nagy szerepet játszik az, hogy szorosan együtt tud működni az operációs rendszerekkel, ami itt ilyen szinten nem valósul meg. |
− | Egyébként csináltak egy VNC nélküli, valódi XRDP szerver is X11rdp néven, de erről nincs sok információ, és nincs könnyen elérhető/installálható formában. |
+ | Egyébként csináltak egy VNC nélküli, valódi XRDP szerver is X11rdp néven, de erről nincs sok információ, és nem hozzáférhető könnyen elérhető/installálható formában. |
== Hibrid megoldások == |
== Hibrid megoldások == |
A lap 2012. november 8., 15:13-kori változata
Írta: Pálinkás Endre
Utolsó jelentős módosítás: 2012. november
Néha felmerülhet, hogy Linux operációs rendszeren futó, grafikus kezelőfelülettel rendelkező programjainkat egy távoli, Windows alapú rendszerről irányítsuk. Ez a szócikk erre a feladatra gyűjt össze pár megoldást, leírja a velük szerzett tapasztalataimat és segítséget nyújt a beállításukhoz.
Sokféle megközelítés képzelhető el; fontosnak tartottam a minimalista megoldások feltérképezését. Kell nekünk egy Desktop Environment (pl. Gnome), ha grafikus programokat akarunk futtatni? És hol is kell futnia az X-szervernek?
Ehhez hasonló kérdésekre keresi a cikk választ, és feltérképezi, hogy mely megoldásoknál mely komponensek és lépések elengedhetetlenek. Hasznos lehet tehát a cikk azoknak, akik erősen limitált VPS-en szeretnénk grafikus programokat futtatni, illetve azoknak, akik kicsit meg szeretnék érteni az egyes megoldások működését, és azt, hogy azok miben különböznek egymástól.
Tartalomjegyzék |
1 Az X Window System alapjai
Ahhoz, hogy a témával foglalkozni tudjunk, és kiválasztani a sok távoli asztal elérés megoldás közül a nekünk megfelelőt, nem árt megismerni az X Window System-et, legalábbis annak egy szeletét.X Window Sytemnek hívják a protokollok egy halmazát, amelyek a Unix/Linux rendszerekre épülő elterjedt GUI-j működésének alapjait fektetik le. Emellett hívhatunk X Window Systemnek egy ezekre az alapokra épített konkrét rendszert is. Az X Window Systemet röviden X-nek, illetve X11-nek is szokták nevezni (a 11-es szám a rendszer ma aktuális verziószáma). Az X Window System kliens-szerver alapú: lehetővé teszi azt, hogy a grafikus felhasználói interfész máshol jelenjen meg, mint ahol a programok futnak. Érdemes kitérni a terminológiára, mert elsőre kicsit szokatlan.
- X Server: Az alkalmazások és a felhasználó között van, a kimenetért és bemenetért felelős. Megjeleníti a felhasználónak a grafikát, és továbbítja az alkalmazások felé a felhasználó bemenetét (billentyűleütések, egérmozgatás).
- X Client: Az alkalmazások.
- X Session Manager: Azért felelős, hogy a grafikus asztal állapotát el tudjuk menteni, később ugyanonnan folytatni (nem biztos, hogy kell nekünk ilyen).
- X Display Manager: Bejelentkeztetés, session indítása. Bejelentkező ablakot ad felhasználónév/jelszót kérve, és elindít egy sessiont. (Szintén nem biztos, hogy kell.)
- X Window Manager: Egy speciális kliens, ami az ablakok kinézetét, mozgatását, méretezését teszi lehetővé. (Szintén nem mindig kell.)
- Desktop Environment (DE): Egy adott teljes, nagyjából egységes megjelenésű grafikus felület. Rendszerint saját X Session Manager + X Display Manager + X Window Manager van benne, emellett egyéb dolgok a grafikus felülethez, pl. ikonok, desktop widgetek, háttérképek, stb. Desktop environment pl. a Gnome, a KDE, a Fluxbox, az Xfce stb.
Elmondhatjuk, hogy ha csak távoli gépről akarjuk a grafikus linuxos programokat használni, nem feltétlenül van szükségünk desktop environment installálására, se a 3 fent felsorolt managerre. X Servert is futtathatunk a windowsos gépünkön, tehát akár úgy is elkezdhetünk dolgozni, hogy a linuxos gépre csak a futtatandó program van telepítve, bárminemű körítés nélkül.
2 A tesztkörnyezet
A teszthez használt linuxos rendszer Debian disztribúciót futtatott, de más disztribúciót futtató felhasználóknak is segítség lehet a szócikk, hiszen nagy eltérések nincsenek. A lentiek közül egyes megoldások a Linuxon kívül más UNIX-alapú rendszereken is léteznek, erre a szócikk csak néha tér ki, említés szintjén.
3 X Server a windowsos gépen
Ha egy linuxos gép előtt ülünk, és a grafikus felületen dolgozunk billentyűzettel, egérrel, akkor az X Server a Linuxon fut. Ha csak távolról, a windowsos gépünkről akarjuk a grafikus felülettel rendelkező linuxos programokat irányítani, az X Server akár a windowsos gépen is futhat, és a linuxos gépre nem feltétlenül kell semmit telepíteni a futtatandó programon kívül. Ez nagy előny lehet, ha minimalista megoldást keresünk (pl. mert a linuxos gépen kevés a memória, gyenge a processzor és/vagy nem akarunk sok tárhelyet használni).
Hátránya ennek a megoldásnak, hogy az elindított linuxos programok (X kliensek) rendszerint meghalnak, ha elveszítik a kapcsolatot a távoli X Serverrel. Tehát ha megszakad a helyi hálózati/internetes kapcsolat a két gép között, a használt program lehal, és a munkánk is elveszhet. Ettől még a megoldás alkalmazható olyan esetekben, ahol stabil a kapcsolat, vagy ha az alkalmazás váratlan kilépése nem okoz különösebb bajt.
3.1 Xming X Server
- Szükséges hozzá:
- Windows: Xming X Server (Putty Link-et is felteszi a könyvtárba)
- Linux: sshd
Az Xming egy pár perc alatt összehozható megoldás, melynél az X Server a windowsos gépen fut. Az Xming X Server most már donationware, tehát adakozni kell a szoftver készítőjének, ha a legújabb változatokat szeretnénk letölteni. A régi változatok is tökéletesen működnek, elérhetők az Xming SourceForge-ról.
Miután elindítottuk az Xming X Server programot a Windows-on, SSH-n keresztül (pl. Puttyval) kell a Linuxhoz csatlakozni, X11 Forwarding (putty beállítás) segítségével a localhost:0 display-t a Windowsra irányítva. Ezek után elindítunk egy GUI-s programot a linuxos gépen - pl. "iceweasel" böngészőt. Mivel az adott SSH sessionben a display forwardolva van a Windowsra, az ablak a windowsos gépen fog megnyílni, az Xming gyermekeként.
A fentiek segítik megérteni a működést, de valójában egyszerűbb a dolgunk, nem kell a puttyval bűvészkednünk. Az Xming X Serverhez tartozik egy XLaunch alkalmazás, melyben begépelhetjük a linuxos gép elérhetőségét (IP, felhasználónév, jelszó), és a futtatandó programot, és már meg is jelenik az alkalmazás ablaka a gépünkön. Nem gond, ha speciális SSH paramétereket szeretnénk (pl. privát kulcsfájl), egy mentett putty session-re is hivatkozhatunk a nevével. Az XLaunch ugyancsak lehetőséget nyújt arra, hogy beállítsuk, hogyan jelenjenek meg a windowson a linuxos alkalmazások. A lehetőségek:
- Multiple Windows: minden alkalmazás külön Windows ablakban nyíljon meg
- One Window: egy főablak, és azon belül jelenik meg minden alkalmazás
- One Window Without Titlebar: mint az előző, csak nem lesz ablakkerete az Xming főablaknak
- Fullscreen: teljes képernyős megjelenítés
Az első lehetőséget leszámítva (ahol minden alkalmazásnak külön Windows ablaka lesz), minden elindított linuxos alkalmazás ugyanabba az Xming főablakba kerül, alapból egymást eltakarva, a méretezés és mozgatás lehetősége nélkül. Ha több alkalmazást futtatunk e 3 megjelenítési mód egyikében, és szeretnénk ablakokat méretezni, mozgatni, kell egy külső window managert is futtatnunk, akár a (vagy egy másik!) linuxos, akár a windowsos gépen. A Desktop Environmenteknek (Gnome, KDE, Xfce stb.) mindnek van Window Managere, ha fent van az egyik, használhatjuk azt. De egyáltalán nincs szükségünk egy teljes desktop environment telepítésére a linuxunkra, elegendő egy fapados window manager, mint például a twm. Természetesen vannak szebbek is: nézzünk körül pl. a Wikipédián.
Ha megvan a window managerünk, két lehetőségünk van:
- Indítsuk el a window managert, ugyanúgy, mint bármely más alkalmazást, melynek a kimenetét a Windows-on szeretnénk látni. Máris tudjuk az ablakokat mozgatni az Xming főablakon belül. (Érdemes a háttérben indítani, "twm &".)
- XDMCP-mód. Ekkor egy speciális, UDP-alapú protokollal (XDMCP-vel) kommunikál az X Server és a távoli X Display Manager. Ezt a módot az Xming fejlesztője problémás esetnek titulálja: a protokoll alapból nem titkosított, ráadásul X Display Manager telepítésére is szükségünk lenne. Az XDMCP-vel itt nem foglalkozunk részletesebben.
3.1.1 Megjegyzések
- A tesztnél először az Xming Server csak adminisztrátorként futtatva volt hajlandó működni, és a putty-t sem irányította jól az XLauncher. Egy reboot után rejtélyes módon minden tökéletesen működött.
- Az XLaunch a putty mellett a Cygwin-féle ssh.exe-t is tudja használni.
3.2 Cygwin/X
- Szükséges hozzá:
- Windows: Cygwin (ejtsd: "szigvin") környezet a szükséges Cygwin csomagokkal
- Linux: sshd
Míg az Xming X Server egy kompakt, Windows felhasználóknak nem annyira idegen élményt nyújtó program, a Cygwin egy sokkal robosztusabb megoldás. Fel kell telepítenünk Windowsra a Cygwint, ami egy teljes, Unix-szerű környezetet épít fel egy könyvtárba. Több a lehetőségünk, de összetettebb a beállítás is, és ha a felhasználó csak a távoli asztal elérésére akarja használni a Cygwin-t, nem túl vonzó ötlet egy 260 megabájtos Cygwin környezet feltelepítése. A mérleg másik oldalon viszont az áll, hogy a lehetőségünk is több, és ha valaki már amúgy is használja a Cygwint, akkor külön program feltelepítése nélkül hozzáadhatja a pár szükséges X Server csomagot.
A Cygwin telepítése pár perc, ha szélessávú internet-kapcsolattal rendelkezünk. Ki kell választanunk, hogy mely programcsomagokat akarjuk telepíteni.
A Cygwin/X-es megoldáshoz ezekre van szükség az alapcsomagokon kívül:
- xorg-server
- xinit
- openssh
- opcionálisan még: xorg-docs, X-start-menu-icons
Elindíthatjuk az X servert. Először a Cygwin shell-t kell elindítani Windowsban (cygwin.bat). A Cygwin shellből a Cygwin-es X Server a 'startxwin' paranccsal indítható. Ez a fenti Multiple-Windows módnak felel meg.
Ha egyetlen windowsos Cygwin X Server ablakon belül szeretnénk látni minden linuxos alkalmazást, akkor a "startx" parancsot használjuk. Bővebb információ itt.
Csatlakozáshoz, X11 Forwardinghoz és programindításhoz használhatjuk a korábban bemutatott putty-s módszert, vagy a Cygwin SSH kliensét is:
ssh -X user@ip:port
Az így megnyitott linuxos shellben ellenőrizzük, hogy a DISPLAY változónk a localhostra mutat-e; ha nem, elképzelhető, hogy nincs engedélyezve az X11 forwarding a Linuxon, vagy hogy nincs fent az xauth program.
Ha a DISPLAY rendben van, indítható az X-es program, és a Windowsunkban jelenik meg.
Ha egy ablakba szeretnénk belezsúfolni a linuxos desktopunkat, itt is szükségünk lesz egy külső window manangerre. Az Xminggel ellentétben itt már három választásunk is van.
- ssh-val futtatni egy linuxos window managert;
- XDMCP mód, ekkor kell X Display Manager is, és ez futtatja a Window Managert a linuxos gépen;
- plusz lehetőség: egy Cygwin-es window managert futtatni a windowsos gépen - pl. twm, mwm (lesstif package része), fvwm2, openbox, aewm++, WindowMaker, icewm.
Személyes véleményem az, hogy a cygwines megoldás kényelmetlenebb az Xmingesnél. Esetleg jól jöhet, ha még több terhet le akarunk venni a linuxos gép válláról, és egy esztétikus Window Managert használni a Windowst futtató gépen.
4 X Server a linuxos gépen
Ha az X szerver ugyanazon a gépen fut, ahol az X kliens, akkor az X Window System helyett valami más fog felelni a távoli gépek közötti kommunikációért. Ilyen megoldás a VNC.
4.1 VNC
A VNC technológiát az angol Olivetti & Oracle Research Labban, röviden ORL-ben fejlesztették ki, eredetileg ingyenes, open source megoldásként. Célja a platformfüggetlen, egyszerű távoli asztal elérés. Az ORL 2002-ben bezárt, és az eredeti fejlesztők egy része megalapította a RealVNC Ltd. céget, amely ingyenes és extra funkciókkal ellátott fizetős változatokat ad ki.
Az utóbbi években megjelent új verziókhoz forráskód már nem került kiadásra, és most már az 5-ös verziószámnál tart a RealVNC. Az ingyenes változat binárisként továbbra is elérhető Debian, Redhat, Solaris, HP-UX, AIX rendszerekre. Emellett van egy generikus Linux csomag, binárisokkal, és persze egy Windows- és Mac-változat is. Ha a hivatalos binárisokat akarjuk használni, szükségünk lesz egy ingyenes licencre is. Mi néhány licenct nem igénylő változatot fogunk bemutatni.
A VNC programok mind az RFB protokollt használják, amely távoli hozzáférést biztosít a GUI-khoz. Mivel a framebuffer szintjén működik, platformfüggetlen. Az RFB protokollt az ORL-ben fejlesztették ki, de a bezárása után is fejlődött. Az aktuális protokoll-specifikáció elérhető a RealVNC honlapján.
4.1.1 vnc4server
A utolsó nyílt forráskódú változat a 4.1.3, mely VNC Open néven elérhető a RealVNC honlapján. Például a debianos vnc4server csomag is innen származik, a 4.1.1 verzióból.
Ha feltelepítjük, kapunk egy speciális X Servert, az Xvnc-t. Ha elindítjuk a VNCServert, elindul ez az X Server is, tehát itt, a címnek megfelelően, a linuxos gépen fog futni az X Server, a távoli kommunikációért pedig a VNC Server felel. Első indításkor be kell állítanunk egy jelszót, ezután egy windowsos kliensről már csatlakozhatunk is. Bármely VNC kliens használható, hiszen mind az RFB protokollt használja. Az 1-es display-hez a 6901-es port tartozik, és így tovább. Ezek után ha beállítottuk a default display-t (export DISPLAY=localhost:1.0), a futtatott programok már a VNC-s X szerverre küldik a képüket, és irányíthatjuk őket Windowsról. Direktbe is küldhetünk egy programot adott display-re ( "DISPLAY=localhost:1 iceweasel &").
Alapból a rendszer alapértelmezett ablakkezelője indul el a VNC-s X-Serverben. Ezen a home könyvtárban lévő .vnc/xstartup konfig fájlban változtathatunk - az "x-window-manager &" sort átírhatjuk egy másik Window managerre, pl. Openbox (openbox &), de elindíthatunk egy teljes Desktop Environment-et is, Gnome-os desktopunkat (gnome-session &), KDE-set (startkde &), Xfce-t (startxfce4 &), stb. VNC esetében az X-Server a linuxos gépen fut, így bármikor le-föl csatlakozhatunk, és folytathatjuk a munkát, ahol abbahagytuk. Ha le szeretnénk lőni a VNC szervert és vele a VNC-s X-Server-t, így tehetjük meg az 1-es display esetén: "vncserver -kill :1".
Ha más felbontással szeretnénk elindítani az VNC-s X-Servert, a következőképpen indítsuk: "vnc4server -geometry 1280x960".
Sajnos az ingyenes RealVNC változatok nem adnak titkosítást az adatforgalomra, csak a jelszó elküldésére. Ezt orvosolni tudjuk egy VPN létrehozásával, vagy egy SSH tunnellel pl. puttyban. Ennek a menete: pl. 1-es display esetén a windowsos 5901-es portot SSH-n keresztül a távoli gépen lévő localhost:5901-re forwardoljuk. E puttys SSH kapcsolat létrehozása után már a VNC klienssel localhost:5901-re kapcsolódhatunk. Ekkor már SSH tunnelen át, titkosított adatforgalommal érhetjük el a linuxos gépet. Érdemes SSH tömörítéssel, és nélküle is próbálkozni, a kapcsolatunk sebessége szerint lehet az egyik, vagy másik gyorsabb.
Még megemlítjük, hogy a VNC beállítható úgy, hogy XDMCP segítségével egy Display Manager login képernyőt is adjon, és HTTP szerverként is tud üzemelni, ekkor a megfelelő portra csatlakozva a távoli felhasználó böngészővel be tud lépni az asztalra, egy Java Applet segítségével.
4.1.2 TightVNC
A tightvncserver ugyanúgy működik, mint az előbb tárgyalt vnc4server - ugyanúgy a RealVNC nyílt forrású változatán alapul. Vannak benne TightVNC-specifikus részek, amelyek elvileg meggyorsíthatnák a kapcsolatot. Az én környezetemben nem tapasztaltam észrevehető különbséget - lassú kapcsolattal rendelkező szerver esetén lehet, hogy van. Mindenesetre TightVNC szerver esetén érdemes a TightVNC klienst használni, amely megvalósítja a TightVNC protokoll-bővítéseit.
4.1.3 x11vnc
Az előbb bemutatott két VNC-variáns virtuális X Servert futtat, amit távolról elérhetünk. Ha már van egy X Serverünk, amelyet szoktunk lokálisan is használni (értsd: monitor, billentyűzet, egér a linuxos gép előtt), és ezt a már meglévő desktopot szeretnénk távolról elérni, az x11vnc egyszerű megoldást nyújt.
A legegyszerűbb futtatási módja, ha egyenesen a grafikus desktopból indítjuk el egy shellből - ekkor nem fordulhat elő, hogy az x11vnc jogosultságproblémák miatt nem tud kapcsolódni az X-szerverünkhöz.
Egyébként a fenti kettőhöz hasonlók a beállítási lehetőségeink, és a kapcsolat titkosítását magunknak kell megoldanunk.
4.2 XRDP
A Microsoft Remote Desktop RDP protokollját használó szerver - ennek a segítségével a windowsos felhasználók a megszokott remote desktop kliensükkel tudnak egy linuxos asztalhoz csatlakozni. A helyzet azonban nem ennyire egyszerű - az XRDP valóban megvalósít egy RDP szervert, de kell alá egy futó VNC szerver is, ezzel kommunikál a Linux oldalon. Így tulajdonképpen felfogható egy proxyként is egy RDP kliens és VNC szerver között (tehát tulajdonképpen a következő felépítés valósul meg: RDP kliens <------> hálózat <-----> RDP szerver - VNC szerver - X szerver - X kliens).
Debianban meglepően gyorsan működésre lehet bírni, az 'xrdp' csomagot installálva azonnal csatlakozhatunk a microsoftos klienssel. Az XRDP szerverhez való csatlakozáskor először egy session manager ugrik be, itt kell kiválasztanunk a VNC szervert, beírni az ip-t (localhost), portot, és a jelszót. Tehát az XRDP szerver egy meglévő VNC szerver mellé is gyorsan odarakható.
A debianos csomag az előbb taglalt vnc4servert használja, így a fentiek segíthetnek a testre szabásban.
Ugyancsak előny, hogy az RDP-ben a titkosítás adott, így nincs szükség tunnelre vagy VPN-re. Egyes netes források szerint a sima VNC-s kapcsolatnál gyorsabb, azzal az indoklással, hogy a VNC protokoll, ami lassabb az RDP-nél, csak lokálisan játszik szerepet, míg a valódi hálózati forgalom az RDP protokoll szerint történik. Én ezt se cáfolni, se megerősíteni nem tudom, mindenestre nekem nem volt lassúbb a sima VNC-nél. Az RDP valóban egy nagyon gyors protokoll két Windows között, ebben nagy szerepet játszik az, hogy szorosan együtt tud működni az operációs rendszerekkel, ami itt ilyen szinten nem valósul meg.
Egyébként csináltak egy VNC nélküli, valódi XRDP szerver is X11rdp néven, de erről nincs sok információ, és nem hozzáférhető könnyen elérhető/installálható formában.
5 Hibrid megoldások
Az előzőekben bemutatott pár megoldásnál is előjött már, hogy az X Server ugyanazon a gépen fut, ahol az X Client, egy másik protokoll valósítja meg a hálózati kommunikációt (VNC-nél RFB, Microsoft Remote Desktopnál RDP). A következőben bemutatott NX technológia is hasonló, de olyan szempontból hibrid, hogy itt a másik oldalon is van egy X Server. Tehát megfogalmazható úgy, hogy az X Server klasszikus munkáját megfelelően elosztják a két egymástól távoli gépen található két különböző X Server között.
5.1 NoMachine NX
Az NX technológiát Gian Filippo Pinzari fejlesztette ki, az olasz NoMachine cégnél. Az X kliens - szerver architektúrára épül, de azon továbblép. Az X felépítése lehetővé teszi, hogy különböző gépeken fusson az X szerver és kliens. A klasszikus felállásnál sok a roundtrip üzenet - pl. a kliens üzen valamit a szervernek, de választ is szeretne tőle. Ha az X kliens és szerver távol helyezkedik el egymástól, ez nem szerencsés, nagyban lassítja a működést. Többek között ezt orvoslandó az NX három új részvevőt iktat be az X kliens és szerver közé:
- NXAgent: egy mini X szerver arra a gépre, ahol az X kliens van
- Local NX Proxy, Remote NX Proxy: egy proxy pár, a két gép között ezek felelősek a hálózati forgalomért
A következőket tudták így megvalósítani:
- X forgalom hatékony tömörítése
- Cache mechanizmus, mely csökkenti a hálózati forgalmat
- X roundtrip üzenetek nagy részének kiküszöbölése, csak lokálisan történnek meg, az X Client és az NXAgent között
- lazy encoding algoritmus, mely azért felelős, hogy lassú hálózat esetén adott pillanatban mindig csak a fontos képernyő frissítéseket küldjük át a hálózaton, ezzel a reakcióidő javul
Az összes felsorolt megoldás közül utolsóként próbáltam ki a NoMachine NX-et. Míg az előző technológiáknál számszerű mérések nélkül nem sikerült sebességbeli különbséget észrevennem, a NoMachine NX-es távoli asztalon így is érződött, hogy gyorsabban reagál. Talán kimondható, hogy ez a leggyorsabb technológia, ha távolról szeretnénk elérni a Linux asztalunkat.
Emelett előny, hogy funckiókban is nagyon gazdag a program, mondhatni mindent megvalósít, amiről a korábbiakban szó volt: teljes Desktop Environment futtatása, belépés már futó X sessionbe, egy alkalmazás futtatása egy windowsos ablakban. RDP és VNC sessionökhöz is csatlakozhatunk, és még sok más extra funckió van.
Ami ugyancsak tetszetős, hogy belépve egy NoMachine NX-es gépre, megkapjuk a futó NX session-ök listáját, és válogathatunk, hogy melyikre akarunk belépni. Kilépéskor pedig dönthetünk, hogy le szeretnénk-e lőni a session-t, vagy később vissza akarunk-e csatlakozni. Persze a session kezelés a többi esetben is megoldható, de itt nagyon egyszerűen, rögtön elérhető.
A titkosítás beépített SSH klienssel történik, a sima linuxos user/jelszó párosunkat használhatjuk, ami igen kényelmes.
Még pár szó a licenszelésről. A NoMachine NX-nek van egy ingyenes, closed source változata, amivel maximum 2 user tud távolról csatlakozni. A fő Linux disztribúciókra, és Solaris letölthető a nomachine.com honlapon. Három csomagot kell telepíteni - a csomagok egymásra épülnek, így a szerver gépünkre is szükséges egy nxclient nevű csomag:
- nxclient
- nxnode
- nxserver
A telepítés után már fut is a szerverünk, a másik gépre a windowsos klienst letöltve már csatlakozhatunk is.
Mi az ingyenes változatokat taglaljuk, de megjegyzendő, hogy az üzleti NoMachine szoftverekkel komolyabb szolgáltatások is elérhetők, pl. NX Szerverek egy blokkjának egybeni menedzselése, eloszott hálózati működés, load balancing.
6 Konklúzió
Megbízhatóság szempontjából egyik megoldással sincs probléma, mind megvalósítja azt, amit ígér. Ezután véleményem szerint a sebesség, a desktop reakcióideje mondható a legfontosabb szempontnak, és ebben a NoMachine NX viszi a pálmát. Kezelhetőség, funkciók szempontjából is kiváló. Hátránya talán, hogy ha kezdő felhasználó elé tesszük a Windows klienst, megijedhet a sok beállítástól. Szerencsére elmenthetők a kapcsolat beállítások, így egy kis segítséggel ez sem okoz gondot. Ha valakit zavar a zárt forráskód, vagy az ingyenes változat 2 useres limitje, próbálkozhat a "FreeNX", "neatx", illetve "x2go"-val, melyek ugyancsak az NX technológiára épülnek.
Ha nincs sok jogosultságunk a linuxos gépen, nagyon jól jöhet a sima távoli X Serveres megoldás, hiszen ekkor nem kell semmit telepítenünk. Ehhez a Windows oldalon az Xming Servert ajánlom.
Egyébként a VNC is egy teljesen jó megoldás, ha a nyújtott sebesség megfelelő számunkra. Ha a disztribúciónkra van előre elkészített csomag, két perc alatt üzembe hozhatjuk, de a titkosítás megoldása még egy kis plusz munka.