Na ogół pracując zdalnie na systemie *nix wykorzystujemy konsolę w trybie tekstowym i łączymy się poprzez SSH. W zdecydowanej większości przypadków jest to wystarczające. Ba! na serwerze najczęściej nie ma środowiska graficznego, bo jest zupełnie zbędne.
Są jednak przypadki, kiedy okienka muszą zostać wyświetlone (np. instalacja Oracle). Co wtedy zrobić? Z reguły leniwy administrator raczej nie ma ochoty ruszać się z miejsca, by pracować na serwerze lokalnie, zwłaszcza gdy w serwerowni panuje nieprzyjemny chłód i hałas, a tym bardziej, gdy maszyna znajduje się w odległej lokalizacji. W takim przypadku dobrze jest znać budowę systemu X i wiedzieć jak można ją wykorzystać.
Otóż system X działa w architekturze klient – serwer, co oznacza, że składa się z dwóch elementów – z serwera wyświetlającego okna i klienta czyli oprogramowania, które do serwera przesyła informacje o zmianie okna. Obsługą klawiatury i myszy zajmuje się serwer.
Z tego krótkiego opisu teoretycznego domyśleć można się, że programy znajdują się na naszej zdalnej maszynie, a serwer X musi być uruchomiony na komputerze lokalnym. Przekierowania wyświetlania dokonać możemy podając parametr -display przy wywołaniu programu (standardowy parametr dla programów pisanych pod X) lub ustawiając zmienną środowiskową DISPLAY, np.:
server ~ # xterm -display 192.168.1.74:0.0
lub
server ~ # DISPLAY=192.168.1.74:0.0 xterm
Oczywiście po drugiej stronie, czyli na komputerze, przy którym siedzimy, uruchomiony musi być serwer X nasłuchujący połączeń. Domyślny port to 6000, z reguły wyłączony za pomocą przełącznika -nolisten tcp (trzeba uruchomić bez niego). Dodatkowo musimy zezwolić na połączenie dodając zdalną maszynę do listy za pomocą xhost:
localhost ~ # xhost +192.168.1.254
Wywołanie xhost bez parametru wyświetli aktualną listę.
Można również dla bezpieczeństwa tunelować połączenie klienta do serwera korzystając z SSH. W tym celu serwer SSH (na maszynie zdalnej) musi być odpowiednio skonfigurowany (X11Forwarding yes w pliku sshd_config dla OpenSSH), program xauth dostępny na serwerze, a uruchamiając klienta podać należy przełącznik -X (lub wpisać ForwardX11 na stałe do pliku z parametrami konfiguracyjnymi klienta SSH).
Powyższy opis jest poprawny, jeśli pracujemy wykorzystując system *nix. Co w przypadku, gdy na naszej stacji zainstalowane mamy okienka z Microsoft? Spokojnie, istnieją implementacje X Window System dla systemów z rodziny Microsoft Windows. Jedną z nich jest bezpłatny Xming. Ale możemy sprawdzić również płatne WinaXe lub X-Win32, które testowo pozwalają na 30 min pracy.
Najpopularniejszy klient SSH – PuTTY również pozwala na tunelowanie połączeń (Category -> Connection -> SSH -> X11 -> Enable X11 forwarding).
Jeśli chodzi o wydajność wspomnianych rozwiązań, to raczej nie powinien być to kluczowy argument przy wyborze, niemniej wykonałem proste testy za pomocą x11perf i wynik wygląda następująco (względem serwera X i wyświetlania lokalnego; im wyższy tym lepszy; dwa środowiska testowe):
- WinaXe + SSH X11Forwarding – 3%, 54%
- WinaXe – 15%, 153%
- X-Win32 + SSH X11Forwarding – 2,9%, 49%
- X-Win32 – 8,3%, 152%
- Xming + SSH X11Forwarding – 3,2%, 54%
- Xming – 14%, 153%
Środowiska testowe mocno się różniły – pierwsze to zwirtualizowany system w Microsoft Virtual PC, drugi, to system zainstalowany bezpośrednio na maszynie. Niemniej jednak pomiędzy omawianymi implementacjami X Servera dużych różnic nie ma.
Jak mówi slogan: „Skoro nie widać różnicy, to po co przepłacać”. Jeśli nie wykorzystujemy specyficznych cech danego programu, w dodatku używamy go sporadycznie, to darmowa wersja Xming zupełnie wystarczy.
oceń artykuł (4 gł., średnia: 5,00)
Loading ...
z narzędzi do pracy zdalnej w trybie graficznym, mogę jeszcze polecić od siebie NoMachine NX http://www.nomachine.com/, co prawda nie wiem na jakim etapie produkt jest teraz, ale kiedyś sprawował się świetnie ;-)
Hehe „instalacja Oracle”. Chyba jedyna sytuacja, kiedy byłem do tego zmuszony, bo zazwyczaj każdy normalny producent typu Bea, IBM, Tibco dostarczał instalator w CLI :)
Fakt, forwardowanie X11 mi też zawsze kojarzy się z instalacją Oracle’a ;-)
Co do NX to normalna wersja ma ograniczenia na 2 polaczenia :/ kiedys rozwijal sie darmowy odlam freenx http://freenx.berlios.de/ ale jakos przestal zyc :/ Obecnie jest http://code.google.com/p/neatx/ ktory powiedzmy sobie dziala ale czesc rzeczy nie chce na nim dzialac (wisza zalegle sesje i nie da sie ich z poziomu klienta skasowac) jak powinno :/ Moze Ubuntu zmieni sytuacje tego rozwiazania szczegolnie ze mozna za pomoca NX zobaczyc ich nowy system po przez strone www http://www.ubucentrum.net/2011/02/przetestuj-nowe-edubuntu-i-ubuntu-1104.html. Jest to ciekawy sposob dostarczania caly desktopow koncowym usera.
Oczywiście Oracle da się zainstalować bez X’ów, korzystając z tzw. response file, ale nie znalazłem lepszego przykładu. Sam robię zrzuty ekranu / nagrywam filmy z własnych programów uruchamianych na tak słabych maszynach, że same zrzucić niczego nie potrafią.
Z innych implementacji:
Mocha X Server http://www.mochasoft.dk/freeware/x11.htm
WeirdX http://sourceforge.net/projects/weirdx/
[...] w serwisie varlog.pl opublikowany został mój artykuł Praca zdalna na systemach *nix w trybie graficznym. Zapraszam do lektury. To drugi mój artykuł, który tam się ukazał (poprzednio: Nagios tips [...]
a co się stanie gdy podczas działającej sesji X-ów zmieni się hostnejm maszyny na której uruchomiony jest serwer? tzn odpalasz xsy na lokalnym sprzęcie i zmieniasz hostnejm ? i dlaczego?, jako ciekawostkę mogę powiedzieć iż istnieje wiele systemów klienckich opartych o x-serwer, działających na zasadzie cienkiego klienta(np wypożyczalnie samochodów i inne bazodanówki które dziś zwykle realizuje sie przez web), tzn, masz serwer/klienta x-ów na windowsowej czy dowolnej innej maszynie, odpowiednio skonfigurowanego, klikasz sobie ikonke aplikacji, no i pojawia ci się „windowsowe” okienko z sesją menedzera okien z serwera(aplikacji) tj-> login usera (np normalnego usera systemu linuksowego) -> automatyczne odpalenia aplikacji klienckiej i w sumie zwykły user nie ma pojęcia o tym iż jego program działa sobie hen hen na serwerze a tak naprawde ma wyeksportowane jedynie okienko, dlatego chyba ów system nazywa się x-serwer i taki był główny zamysł twórców, ale takie rozwiązania to chyba już przeszłość :), zaletą takiego rozwiązania w stosunku do serwisów webowych jest większa niezależność od softu zainstalowanego w kliencie, (w przeciwienstwie do rozwiązań webowych możesz napisać swój program w dowolnym języku/ach, i nie interesuje cię to jaką klient ma przeglądarkę itp), do tego może być to bezpieczeństwo z racji unikalności takiego rozwiązania (przynajmniej w naszym kraju bo się tutaj z czymś takim nie spotkałem).
a nie prosciej ssh -X?!?
@Marcin: ?
cytując tajemny manual ssh
X11 FORWARDING
If the ForwardX11 variable is set to „yes” (or see the description of the
-X, -x, and -Y options above) and the user is using X11 (the DISPLAY
environment variable is set), the connection to the X11 display is auto-
matically forwarded to the remote side in such a way that any X11 pro-
grams started from the shell (or command) will go through the encrypted
channel, and the connection to the real X server will be made from the
local machine. The user should not manually set DISPLAY. Forwarding of
X11 connections can be configured on the command line or in configuration
files.
@Marcin: nadal nie wiem do czego ten komentarz. Brakuje tego w artykule, jest źle czy jak?
Potrzebowałem dzisiaj po zalogowaniu się po SSH na usera odpalić aplikację jako root. Po zmianie usera (su -), niestety przekierowanie nie działa.
Znalazłem coś takiego:
ssh -X user@hostname
su –
xauth merge /home/user/.Xauthority
Ostatnia linijka rozwiązuje problem.
W Debianie jest jeszcze pakiet „sux” – czyli takie „su” z zadbaniem o prawidłowy forward Xów :)
Spróbuj su bez `-’ czy `-l’.
Zawsze można też ręcznie przepisać $DISPLAY dla root
@Bartłomiej Samo su, bez tego xautha nic nie da. DISPLAY może być ustawiony prawidłowo, a i tak nie będzie działało ;)
wasyl@worker ~ $ ssh -Y wasyl@kvm143.vpn
wasyl@kvm143 ~ $ echo $DISPLAY
localhost:10.0
wasyl@kvm143 ~ $ gedit
[działa]
wasyl@kvm143 ~ $ su -
Hasło:
kvm143 ~ # echo $DISPLAY
localhost:10.0
kvm143 ~ # gedit
[działa]
Działanie zapewnia parametr -Y.
Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.
Polecam również x11vnc do zdalnej pracy na desktopie miast odpalania
tylko pojedynczych aplikacji.
[...] wirtualizacji (choć może być też np. VirtualBox czy coś od VMWare). A do tego jakiś serwer X (opisywałem kilka na varlog.pl, polecam Xming). Jako zwirtualizowany system polecam Tiny Core Linux, na którym możemy [...]