Praca zdalna na systemach *nix w trybie graficznym

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.

  • 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 ;-)

  • Anno

    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ą.

  • Pingback: /var/log się zapełnia! « guzik()

  • pluto

    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).

  • Marcin

    a nie prosciej ssh -X?!?

  • @Marcin: ?

  • 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 [email protected]
    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 ;)

  • Scyld de Fraud

    [email protected] ~ $ ssh -Y [email protected]
    [email protected] ~ $ echo $DISPLAY
    localhost:10.0
    [email protected] ~ $ gedit
    [działa]
    [email protected] ~ $ 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.

  • Pingback: Prawie jak Qubes OS « guzik()

  • Jedna poprawka, xhost + bez żadnego adresu wyłącza całkiem filtrowanie :)

  • Pingback: Monitorowanie procesów Java « guzik()