[linux]Zdalny-dostep-do-srodowiska-graficznego.pdf

dla początkujących

Zdalny dostęp

do środowiska

graicznego

Piotr Machej

komputera z zainstalowanym

Linuksem jest proste, o ile jest

na nim uruchomiony serwer

SSH , ale nie wszystko da się zrobić w trybie

tekstowym. Może zdarzyć się, że mamy

jakiś problem, który nie jest łatwo opisać

słowami. W takim przypadku dobrym

rozwiązaniem byłoby udostępnienie bar-

dziej doświadczonemu znajomemu (lub np.

administratorowi naszej sieci) naszego pul-

pitu – wtedy nie tylko moglibyśmy uzy-

skać pomoc, ale i zobaczyć, co ten znajomy

zrobił. To wszystko jest możliwe, a z niniej-

szego artykułu dowiecie się, jak możecie

skonigurować Linuksa w celu udostępnia-

nia swojego biurka lub uzyskiwania dostę-

pu do zdalnego pulpitu. Zawarte w nim

informacje dotyczą szczególnie dystrybucji

Aurox i Fedora , ale większość z nich może

być wykorzystana również przez użytkow-

ników innych dystrybucji Linuksa.

X11vnc . Od tej pory po odebraniu zgło-

szenia wyświetla sobie w okienku pulpit

użytkownika mającego problem i zazwy-

czaj jest w stanie naprawić usterkę bez

ruszania się z serwerowni. Zaoszczędzony

czas podobno poświęca na testowanie prze-

pustowości sieci z użyciem znakomitej gry

America's Army .

FreeNX

Stosunkowo nowa technologia NX, roz-

wijana przez irmę NoMachine , zdobywa

sobie coraz więcej fanów. Wynika to głów-

nie z tego, że zastosowano w niej bardzo

wydajną metodę kompresji. Dzięki temu

nawet posiadacze antycznych już mode-

mów 9600 bps mogą dosyć komfortowo

pracować ze zdalną sesją graiczną. Co

więcej, sesja jest szyfrowana z użyciem

SSH , co powinno zapewnić nam wystar-

czający poziom bezpieczeństwa. Ponieważ

cena udostępnianego przez NoMachine ser-

wera NX jest dosyć wysoka, skorzystamy

z bezpłatnej alternatywy, czyli dostępnego

na licencji GPL serwera FreeNX . Jako klien-

ta wykorzystamy oryginalnego (i bez-

płatnego) klienta stworzonego przez No-

Machine .

Przykład z życia

Posiadanie jednego mocnego komputera

i jednego (lub więcej) słabszych ma swoje

zalety i wady. Z oczywistych względów

najbardziej lubię pracować na tym naj-

lepszym, ale czasem rodzina mnie z niego

wygania (np. aby pooglądać ilmy na

DVD ). Zamiast przenosić wtedy wszyst-

kie materiały do pracy na drugi kompu-

ter, po prostu słabszy sprzęt wykorzy-

stuję jako terminal. Rodzinka może sobie

wtedy spokojnie oglądać ilm, a ja mogę

pracować z OpenOfice.org Writerem na tym

samym komputerze, korzystając z klawia-

tury i monitora słabszego sprzętu.

W nieco inny sposób radzi sobie w irmie

mój znajomy. Zmęczony ciągłym bieganiem

do użytkowników zgłaszających problemy

zainstalował na wszystkich komputerach

DVD

Po uruchomieniu Linux+ Live

DVD możesz skorzystać z SSH,

VNC, FreeNX-a oraz Krfb.

Instalacja i testowanie klienta

Zaczniemy od instalacji klienta, gdyż

zanim zainstalujemy serwer, możemy

przetestować jakość NX na serwerach

udostępnionych przez NoMachine . Wcho-

dzimy na stronę http://www.nomachine.com/

download_client_linux.php i pobieramy pa-

kiet odpowiedni dla naszej dystrybucji.

Po zapisaniu go na dysku instalujemy go

w taki sam sposób, jak inne pakiety (np.

w Fedorze poleceniem rpm -Uvh nxclient-

1.5.0-113.i386.rpm ). Oczywiście, do insta-

lowania pakietów potrzebujemy upraw-

Na płycie CD/DVD

Na płycie CD/DVD znajdują się

pakiety FreeNX-a oraz

klienci VNC.

50 styczeń 2006

U zyskanie zdalnego dostępu do

zdalny dostęp do pulpitu

dla początkujących

nień administratora, które możemy uzy-

skać wydając polecenie su - i podając ha-

sło użytkownika root .

Jeśli chcemy przetestować, jak NX spra-

wuje się na naszym łączu, możemy wejść

na stronę http://www.nomachine.com/testdrive.

php . Należy tu wypełnić krótki formularz.

Najpierw wybieramy serwer, który chcemy

wykorzystać do testów (np. testdrive.no-

machine.com , umieszczony we Włoszech).

Oprócz tego, należy podać swoje imię i naz-

wisko oraz działający adres e-mail. Chwilę

po wciśnięciu przycisku Send na wskaza-

nym koncie pocztowym powinien pojawić

się list z danymi potrzebnymi do podłącze-

nia się do serwera.

Zaopatrzeni w te informacje możemy

uruchomić klienta poleceniem nxclient .

Na ekranie Session wpisujemy nazwę

sesji (np. Test Drive ) oraz nazwę kompu-

tera podaną w liście (np. testdrive.noma-

chine.com ). Numer portu pozostawiamy

w spokoju i wybieramy tylko typ nasze-

go połączenia z Internetem. Na następ-

nym ekranie z rozwijalnej listy wybieramy

Unix i środowisko (w przypadku testowe-

go serwera dostępne są KDE i GNOME ).

Ponadto, wybieramy odpowiadający nam

rozmiar pulpitu. Możemy również zazna-

czyć opcję powodującą szyfrowanie całości

transmisji. W ostatnim ekranie konigura-

cyjnym możemy zadecydować, czy ikona

połączenia ma pojawić się na pulpicie oraz

czy mają być wyświetlone zaawansowane

opcje koniguracji. Na razie nie będziemy

przeglądać zaawansowanych opcji, więc

po prostu wciskamy przycisk Finish .

Teraz pozostaje nam już tylko w wy-

świetlonym okienku wpisać nazwę użyt-

kownika i hasło dostarczone w liście oraz

z rozwijalnego spisu wybrać odpowiednią

nazwę sesji (w naszym przykładzie – Test

Drive ). W czasie nawiązywania pierwsze-

go połączenia ze zdalnym serwerem może

pojawić się pytanie o zaakceptowanie

klucza RSA . Należy go zatwierdzić, a po

chwili zobaczymy okno z wyświetlonym

pulpitem zdalnego komputera. Konto

testowe przyznane przez NoMachine jest

aktywne przez 7 dni, więc daje to dosyć

czasu na przetestowanie jakości transmisji

przy różnych warunkach obciążenia sieci.

Jeśli nas to zadowoli, możemy przejść

do zakładania własnego serwera.

innych popularnych dystrybucji, zgodnie

z informacjami zawartymi na stronie do-

mowej projektu ( http://openfacts.berlios.de/

index-en.phtml?title=FreeNX_distro_inte-

gration ), serwer ten jest zawarty od razu

w dystrybucjach lub we wskazanych na

stronie repozytoriach. Z tego powodu

instalacja w przypadku tych dystrybu-

cji ( Mandriva , Gentoo , Ubuntu , Debian ) nie

powinna sprawić kłopotu.

Jak zwykle, przed instalacją nowego

oprogramowania powinniśmy zadbać o

aktualność systemu. W związku z tym

wydajemy (z uprawnieniami administra-

tora) polecenie yum update . Po uaktual-

nieniu pakietów instalujemy potrzebne

pakiety poleceniem yum install expect

nc . Teraz musimy pobrać odpowiednie

pakiety FreeNX i NX . Niestety, w tej chwili

nie są jeszcze dostępne w repozytorium

Fedora Extras , więc będziemy musieli ścią-

gnąć je "ręcznie".

Pobieramy pakiet http://fedoranews.org/

contributors/rick_stout/freenx/freenx-0.4.4-

1.fdr.0.noarch.rpm . Jest on przeznaczony

dla dystrybucji Fedora Core 2 i nowszych,

a także innych korzystających z X.org . Jeśli

nadal używamy dystrybucji Fedora Core 1 ,

Red Hat 9 lub innej korzystającej z XFree86 ,

to powinniśmy pobrać pakiet http://

fedoranews.org/contributors/rick_stout/freenx/

freenx-0.4.4-1.rh.0.noarch.rpm . Oprócz tego,

pobieramy pakiet http://fedoranews.org/

contributors/rick_stout/freenx/nx-1.5.0-

0.FC4.1.i386.rpm . Jak można rozpoznać

po nazwie, jest on przeznaczony dla dys-

trybucji Fedora Core 4 . Użytkownicy wcze-

śniejszych wersji mogą użyć w nazwie,

zamiast FC4, odpowiednio FC3 , FC2 lub

FC1 . Ta ostatnia wersja jest przeznaczo-

na również dla użytkowników Red Hat 9

i innych korzystających z XFree86 .

Po pobraniu pakietów instalujemy je

poleceniem rpm -Uvh freenx-0.4.4-1.fdr.

0.noarch.rpm nx-1.5.0-0.FC4.1.i386.rpm .

Na tym kończy się instalacja serwera. Praw-

da, że proste?

wizard . Później możemy postępować zgod-

nie ze wspomnianym opisem, ale na końcu

będziemy musieli sięgnąć po ustawienia

zaawansowane. Wynika to z tego, że w

celu poprawnego uwierzytelnienia musimy

klientowi dostarczyć poprawny klucz pry-

watny. Znajduje się on w pliku /etc/nxserver/

client.id_dsa.key na komputerze, gdzie insta-

lowaliśmy serwer FreeNX . Musimy go sko-

piować (czy to z pomocą dyskietki, czy

komendą scp /etc/nxserver/client.id_

dsa.key user@192.168.1.15:~/ – przy zało-

żeniu, że korzystamy z konta user na kom-

puterze o adresie 192.168.1.15 ) na nasz kom-

puter z klientem. Wtedy w opcjach zaawan-

sowanych sesji wciskamy przycisk Key , a w

następnym oknie przycisk Import . Po wska-

zaniu skopiowanego pliku client.id_dsa.key

zatwierdzamy operację przyciskiem Save i

jeszcze raz Save .

Gdybyśmy później chcieli zmienić

opcje (np. rozmiar pulpitu lub środowi-

sko), możemy po uruchomieniu klienta

wybrać odpowiednią sesję z listy i wcisnąć

przycisk Conigure .

Po zakończeniu pracy ze środowi-

skiem wylogowujemy się z niego, tak

jak zwykle. Możemy też zamknąć okno

klienta, a wtedy uzyskamy możliwość

zawieszenia sesji ( Suspend ). Przy ponow-

nym łączeniu się z serwerem zobaczymy

spis zawieszonych sesji, z których można

wybrać tą, którą chcemy wznowić.

Serwer FreeNX ma wiele zalet, ale na

razie nie we wszystkich zastosowaniach do-

brze się sprawdza. Przykładowo, nie poz-

wala na podłączenie się do działającej już

sesji lub współdzielenie pulpitu z innym

użytkownikiem. Jeśli zależy nam na takich

funkcjach, musimy wypróbować inne pro-

gramy, opisane w dalszych rozdziałach.

Zdalny pulpit w GNOME

Prędzej czy później możemy znaleźć się

w sytuacji, w której chcielibyśmy, aby zna-

Koniguracja klienta

Podstawowe konigurowanie klienta opi-

saliśmy już wcześniej. Jeśli nie zakładali-

śmy testowego konta, to możemy kiero-

wać się opisem umieszczonym w rozdzia-

le Instalacja i testowanie klienta . Oczywiście,

zamiast danych serwera NoMachine podaje-

my dane naszego serwera. Jeśli założyliśmy

już konto i mamy skonigurowaną sesję w

kliencie, to w celu dodania nowej sesji uru-

chamiamy klienta poleceniem nxclient --

Koniguracja serwera

Opis instalacji i koniguracji serwera

FreeNX jest bardzo ściśle związany z dys-

trybucjami Aurox i Fedora . W przypadku

Rysunek 1. Klienta NX możemy

wypróbować na testowym serwerze

udostępnionym przez NoMachine

www.lpmagazine.org

dla początkujących

jomy administrator nieco nam pomógł.

Najprościej byłoby go zaprosić, aby móc

obserwować, co robi i uczyć się od niego.

Po co jednak mamy go fatygować, skoro

nasze komputery są połączone w sieć?

Spróbujmy udostępnić mu nasz pulpit tak,

aby mógł na nim pracować, a równocze-

śnie abyśmy mogli go obserwować.

W nowszych wersjach GNOME taka

funkcjonalność jest dostępna od razu

(dzięki programowi Vino ). Po uruchomie-

niu programu vino-preferences (dostęp-

nego w pakiecie vino ) możemy określić,

czy chcemy zezwalać innym użytkowni-

kom na podgląd naszego pulpitu. Oprócz

tego, można pozwolić zdalnym użytkow-

nikom na kontrolowanie naszego pulpitu.

Opcję tę należy zaznaczać bardzo ostroż-

nie – o ile będziemy mieli możliwość

obserwowania poczynań gościa, o tyle

w razie zapomnienia o włączonym ser-

werze możemy zostawić szeroko otwar-

te drzwi dla włamywacza. Aby tego unik-

nąć, mamy do dyspozycji jeszcze dwie

opcje. Pierwsza z nich powoduje wyświe-

tlenie okienka z prośbą o potwierdzenie za

każdym razem, gdy ktoś podłącza się do

naszego pulpitu. Druga pozwala na okre-

ślenie hasła, które będzie musiał podać

gość, zanim otrzyma możliwość oglądania

lub kontrolowania naszego pulpitu.

Gość może podglądać nasz pulpit wyda-

jąc np. polecenie vncviewer 192.168.1.1:

0 . Oczywiście, zamiast 192.168.1.1 podaje

adres lub nazwę naszego komputera. Pro-

gram Vncviewer jest częścią pakietu vnc .

rów, z których spodziewamy się połączeń

z naszym pulpitem. Może to być tylko sieć

lokalna (komputery w pracowni szkolnej)

lub określony jeden komputer (np. należą-

cy do naszego znajomego administratora).

Oprócz tego, warto pamiętać o tym,

aby udostępniać możliwość połączenia z

naszym pulpitem tylko wtedy, gdy jest to

konieczne, a w pozostałym czasie mieć ją

wyłączoną.

Nawet przy zachowaniu tych zasad

bezpieczeństwa można zwrócić uwagę na

jeszcze jeden fakt. Transmisja podglądu

pulpitu nie jest szyfrowana, więc może

być podsłuchana – szczególnie, jeśli łączy

się z nami ktoś z Internetu. Na szczęście,

możliwe jest zastosowanie SSH do szyfro-

wania takiej transmisji. W tym celu należy

utworzyć tunel. Służy do tego polecenie

postaci:

nia i podaniu naszego hasła zalogujemy się

poprzez SSH na nasze konto na zdalnym

komputerze. Równocześnie, na czas trwa-

nia tego połączenia, zostanie utworzony

tunel pomiędzy portem 5901 na kompute-

rze, gdzie ma być uruchomiony Vncviewer ,

a portem 5900 na komputerze z podgląda-

nym pulpitem.

Teraz już wystarczy uruchomić Vncviewer

poleceniem vncviewer localhost:5901 ,

a cała transmisja będzie szyfrowana. Nale-

ży zwrócić uwagę, że w takiej konigura-

cji przy pytaniu o potwierdzenie możliwo-

ści podglądania pulpitu zostanie wyświe-

tlona nazwa komputera lokalnego (tego,

na którym pulpit jest uruchomiony), a nie

zdalnego (tego, gdzie uruchamiany jest

Vncviewer ).

Zdalny pulpit w KDE

Podobnie jak GNOME , środowisko KDE

również posiada swoje narzędzie do

współdzielenia pulpitu. Jest to program

Krfb, zawarty w pakiecie kdenetwork . Ma

on nawet większe możliwości niż Vino ,

o czym możemy się zorientować po jego

uruchomieniu poleceniem krfb .

Od razu na pierwszym ekranie zoba-

czymy przycisk prowadzący do opcji koni-

guracyjnych (zajmiemy się nimi za chwilę)

oraz trzy przyciski dotyczące zaproszeń.

Pierwszy z z tych trzech pozwala na wyge-

nerowanie osobistego zaproszenia. Po jego

wciśnięciu zobaczymy takie informacje,

jak nazwę komputera i hasło, które powin-

ssh -C -L 5901:localhost:5900

user@192.168.1.1

Wydaje się je na komputerze, na którym

będzie uruchomiony Vncviewer . Zamiast

5901 można użyć innego nieużywanego

numeru portu. Zamiast user i 192.168.1.1

należy podać nazwę użytkownika i adres

lub nazwę komputera, z którym chcemy

się połączyć w celu obejrzenia pulpitu.

Nazwa użytkownika dotyczy naszego

konta na tamtym komputerze – nie musi

to być nazwa użytkownika, którego pulpit

chcemy obejrzeć. Po wydaniu tego polece-

Bezpieczeństwo

Uruchomienie dodatkowej usługi, która

pozwala na łączenie się z komputerem,

zawsze wiąże się z pewnym zagrożeniem.

Korzystając z Vino , pozwalamy na połą-

czenia na port 5900 TCP naszego kompu-

tera. Najlepiej, aby tylko wybrane osoby

miały możliwość połączenia się z nim.

Wynika to z kilku przyczyn. Po pierw-

sze, może okazać się, że w oprogramo-

waniu jest jakiś błąd, który sprytny wła-

mywacz może wykorzystać do uzyska-

nia dostępu do naszego komputera. Po

drugie, ktoś złośliwy może nam utrud-

niać pracę co chwila próbując połączyć się

z naszym pulpitem. Nawet jeśli ustawili-

śmy konieczność potwierdzenia połącze-

nia, to ciągle wyskakujące okienka mogą

być bardzo uciążliwe. Z tego powodu

powinniśmy ustawić naszą zaporę sie-

ciową tak, aby akceptowała połączenia

na port 5900 TCP tylko z tych kompute-

Rysunek 2. Hasło z zaproszenia trzeba od razu zapisać lub przekazać, gdyż jest

wyświetlane tylko raz

52 styczeń 2006

zdalny dostęp do pulpitu

dla początkujących

ny być użyte do połączenia z naszym pul-

pitem, a także datę ważności zaproszenia.

Informacje te możemy przekazać osobie,

której chcemy udostępnić pulpit. Ważne,

aby być pewnym, że przekazujemy je

odpowiedniej osobie, tzn. że nikt tej wia-

domości nie podsłucha ani nie przechwyci.

Dodatkowym zabezpieczeniem jest wspo-

mniany już termin ważności zaprosze-

nia – ze względów bezpieczeństwa jest on

ograniczony do jednej godziny.

Drugi przycisk pozwala wygenero-

wać zaproszenie i od razu wysłać je za

pośrednictwem poczty elektronicznej.

Umieszczone w nim będą wspomniane

już informacje. Należy zwrócić uwagę,

że e-mail nie jest zbyt bezpiecznym spo-

sobem na przekazywanie wiadomości o

hasłach, więc powinniśmy z niego korzy-

stać tylko wtedy, gdy korzystamy z szyfro-

wania wiadomości.

Ostatni przycisk służy do zarządza-

nia udzielonymi zaproszeniami. Na spisie

można sprawdzić, kiedy zostały udzielo-

ne zaproszenia i kiedy kończy się ich waż-

ność. Można wskazać pojedyncze z nich i

skasować je, skasować wszystkie, a także

skorzystać z dwóch przycisków mających

te same funkcje, co wspomniane już przy-

ciski na głównym ekranie.

Korzystanie z zaproszeń jest najbez-

pieczniejsze, gdyż upoważnia zdalnego

użytkownika tylko do jednego logowa-

nia – przydzielone hasło jest wykorzysty-

wane tylko raz. Nie oznacza to jednak, że

nie można logować się w ten sposób, jak

w Vino , czyli podając jedno, stałe hasło.

Byłaby to wielka strata, gdyż taka możli-

wość przydaje się, gdy gdzieś wyjeżdżamy

i chcemy coś sprawdzić na naszym pulpi-

cie uruchomionym w domu. Ponieważ

domyślnie można logować się tylko z uży-

ciem zaproszeń, w celu zmiany tej opcji

musimy skorzystać z przycisku otwierają-

cego okno koniguracji.

Mamy tam do dyspozycji trzy zakład-

ki. Interesująca nas opcja, pozwalająca

na połączenia bez zaproszenia, znajdu-

je się na pierwszej. Jeśli zdecydujemy się

ją zaznaczyć, powinniśmy również roz-

ważyć zaznaczenie opcji sprawiającej, że

każde połączenie bez zaproszenia musi

zaakceptować użytkownik korzystający z

pulpitu. Warto też podać hasło wymaga-

ne od łączącego się użytkownika. Opcję

pozwalającą użytkownikom łączącym się

bez zaproszenia na kontrolowanie pulpi-

tu należy zaznaczać bardzo ostrożnie. Na

drugiej i trzeciej zakładce mamy do dyspo-

zycji po jednej opcji. Pierwsza z nich powo-

duje wyłączenie tapety podczas sesji zdal-

nej (może to nieco zwiększyć wydajność,

szczególnie w przypadku bardzo koloro-

wej tapety), natomiast druga pozwala na

wybranie portu wykorzystywanego przez

serwer (lub skorzystanie z przydzielania

automatycznego). Domyślnie wykorzysty-

wany jest port 5900, podobnie jak w przy-

padku Vino .

Umieszczone w poprzednim rozdzia-

le informacje o zaporze sieciowej i szyfro-

waniu sesji dotyczą również przypadku

korzystania z Krfb .

Fedora i podobnych) decyduje wpis w pli-

ku /etc/inittab . Jeśli znajduje się tam linia

o treści id:5:initdefault: , to system

uruchomi się w trybie graicznym, nato-

miast trybowi tekstowemu odpowiada

linia id:3:initdefault: . Odpowiedniej

zmiany można dokonać dowolnym edy-

torem (np. gedit /etc/inittab ) po uzy-

skaniu uprawnień administratora (wyda-

jąc polecenie su - i podając hasło użyt-

kownika root ).

W tym samym pliku możemy znaleźć

linię o treści podobnej do poniższej:

x:5:respawn:/etc/X11/prefdm -nodaemon

XDMCP

(słabszy komp jako terminal)

W dzisiejszych czasach sprzęt kompute-

rowy starzeje się coraz szybciej. Często

zdarza się, że w celu unowocześnie-

nia komputera trzeba wymienić więk-

szość komponentów lub po prostu zaku-

pić nowy komputer. Pozostaje problem,

co zrobić ze starszym sprzętem, któ-

rego często nikt nie chce kupić. Dzięki

Linuksowi (a właściwie dzięki protokoło-

wi XDMCP ) nawet dość antyczny sprzęt

wciąż możemy wykorzystać choćby jako

terminal. W sieci lokalnej (czy to w domu,

czy w irmie) takie rozwiązanie może

okazać się bardzo dobre. W dodatku,

odpowiednie skonigurowanie Linuksa

okazuje się być bardzo proste.

Taka linia oznacza, że w piątym pozio-

mie uruchomieniowym jako menedżer

logowania będzie użyty program wska-

zany przez skrypt /etc/X11/prefdm . Należy

usunąć z niej parametr -nodaemon , w rezul-

tacie uzyskując linię o treści: x:5:respawn:

/etc/X11/prefdm .

Dzięki temu nasz menedżer logowania bę-

dzie mógł służyć nie tylko do obsługi lokal-

nego logowania, ale będzie też czekał na

połączenia nadchodzące z innych kom-

puterów (oczywiście, zanim tak się stanie,

musimy skonigurować jeszcze kilka rze-

czy). Jeśli chcielibyśmy przy okazji zmienić

Co znaczą te skróty?

W artykule jest użytych kilka skrótów, które

mogą wymagać bliższego wyjaśnienia.

VNC ( Virtual Network Computing ) to

system pozwalający na zdalne kontrolo-

wanie środowiska graicznego. Opiera się

na protokole RFB ( Remote FrameBuffer ),

odpowiadającym za zdalny dostęp do gra-

icznego interfejsu użytkownika.

XDMCP ( X Display Manager Control

Protocol ) to protokół, z użyciem które-

go komunikuje się menedżer logowania.

Dzięki niemu użytkownik może spraw-

dzić, które komputery w sieci przyjmują

połączenia, a nawet uzyskać podstawowe

informacje o tych komputerach. Może też

po prostu bezpośrednio podłączyć się do

zdalnego menedżera logowania.

NX to zestaw technologii i narzędzi

mających na celu ułatwienie i uprzyjem-

nienie korzystania ze zdalnego dostępu

do środowisk graicznych. Jego główną

częścią jest wyjątkowo skuteczny proto-

kół kompresji, pozwalający na wygodny

dostęp do zdalnego pulpitu nawet na sto-

sunkowo wolnych łączach.

Czynności wstępne

Na początku musimy upewnić sie, że

mamy do dyspozycji dwa komputery

połączone w sieć. Najlepiej, aby znajdowa-

ły się one w jednym segmencie sieci lokal-

nej – zarówno ze względu na bezpieczeń-

stwo (mniejsza szansa na podsłuch), jak

i wydajność. Ten z komputerów, który

ma pełnić rolę serwera, powinien urucha-

miać się w środowisku graicznym, a nie

tekstowym. Jeśli po uruchomieniu kom-

putera widzimy ładny ekran logowania,

w którym możemy podać nazwę użyt-

kownika i hasło, to jest to właśnie to, o co

nam chodzi. Za wyświetlenie tego ekranu

odpowiada menedżer logowania, którym

najprawdopodobniej jest GDM , KDM lub

XDM – może to być uzależnione od kon-

iguracji naszej dystrybucji. Drugi kompu-

ter (będziemy go nazywać terminalem lub

klientem) może się uruchamiać w trybie

tekstowym.

O tym, czy komputer przedstawi gra-

iczny, czy tekstowy ekran logowania,

w przypadku dystrybucji Aurox (a także

www.lpmagazine.org

dla początkujących

Usuwamy znak komentarza ( # ) z począt-

ku linii. Dzięki takiemu zapisowi dowol-

ny komputer będzie mógł połączyć się

z naszym serwerem za pomocą XDMCP .

Ze względów bezpieczeństwa niekoniecz-

nie jest to najlepszy pomysł. Jeśli chcemy,

aby mogły się łączyć tylko komputery

z naszej sieci lokalnej, to najlepiej podać jej

adres (np. 192.168.0.* dla sieci 192.168.0.0

o masce 255.255.255.0 ). Gdy wystarczy

nam, jeśli może się łączyć tylko jeden kon-

kretny komputer (np. o adresie 192.168.

0.15 ), to również możemy ograniczyć mo-

żliwość połączeń tylko do niego, zmienia-

jąc powyższą linię na taką:

Po ponownym uruchomieniu syste-

mu (bardziej doświadczeni użytkowni-

cy mogą się ograniczyć do zrestartowa-

nia Xinit , menedżera logowania i ustawień

zapory sieciowej) powinno już być możli-

we nawiązanie połączenia z terminali.

Rysunek 3. Dzięki SSH możemy

swobodnie uruchamiać zdalnie pojedyncze

programy

Korzystanie

Po odpowiednim skonigurowaniu ser-

wera możemy wreszcie przesiąść się na

nasz terminal i zacząć pracę. Po zalogo-

waniu się do systemu wpisujemy tylko

jedno polecenie: X -query 192.168.1.1 .

Oczywiście, zamiast 192.168.1.1 używa-

my adresu (lub nazwy) naszego serwe-

ra. Po chwili powinien pojawić się mene-

dżer logowania, gdzie możemy wpisać

nazwę użytkownika i hasło, z jakiego

korzystamy na serwerze. Jeśli już mamy

uruchomioną sesję tego użytkownika na

serwerze, to zostaniemy ostrzeżeni, ale mo-

żemy spokojnie wymusić rozpoczęcie sesji.

I to wystarczy – widzimy teraz na ekranie

dokładnie to, co byśmy widzieli po zalogo-

waniu się bezpośrednio na serwerze.

menedżer logowania, można po prostu zmie-

nić tę linię tak, aby miała np. treść:

x:5:respawn:/usr/bin/gdm

192.168.0.15 # only host

192.168.0.15 can get a login window

Bardziej poprawną metodą jest pozostawie-

nie tej linii w spokoju, a zamiast tego doko-

nanie zmiany w pliku /etc/sysconig/desktop ,

gdzie powinna znaleźć się linia o treści:

Ostatnie zmiany zależą od tego, z którego

menedżera logowania korzystamy. W razie

braku pewności, zawsze możemy wprowa-

dzić wszystkie.

W przypadku korzystania z GDM edy-

tujemy plik /etc/X11/gdm/gdm.conf . W sekcji

[xdmcp] powinniśmy zadbać o to, aby

następujące opcje nie były zakomentowa-

ne (linie nie mogą zaczynać się od znaku # )

i aby miały wskazane poniżej wartości:

DISPLAYMANAGER="GNOME"

W takim przypadku preferowanym mene-

dżerem logowania będzie GDM . Jeśli wo-

limy KDM , to zamiast GNOME wpisuje

my KDE . Miłośnicy klasycznego XDM wpi-

sują XDM (sic!).

Gdy spełnimy już powyższe warunki,

możemy przejść do właściwej koniguracji.

X11vnc

Omówiliśmy dotąd sytuacje, gdy siedzi-

my przy komputerze i chcemy komuś

udostępnić nasz pulpit. Co zrobić w sytu-

acji, gdy wyszliśmy z pracy zapominając

zamknąć jakiś program, który nie powi-

nien już działać? Powrót do irmy często

nie wchodzi w rachubę, a zwlekanie do

następnego dnia może się dla nas skoń-

czyć naganą. O ile tylko mamy dostęp do

naszego komputera przez SSH , to możemy

sobie w takiej sytuacji poradzić. Z pomocą

przychodzi X11vnc , który pozwala na pod-

łączenie się do działającej już sesji X .

Enable=true

Port=177

Koniguracja

Wciąż korzystając z uprawnień administra-

tora zaczynamy od edycji pliku /etc/X11/

xdm/xdm-conig . Odnajdujemy linię (za-

zwyczaj jest ona ostatnia) o treści:

Użytkownicy KDM takie same zmiany

powinni wprowadzić w pliku /etc/kde/kdm/

kdmrc . Plik ten w niektórych dystrybucjach

może znajdować się w innym katalogu,

np.: /usr/share/conig/kdm/kdmrc lub /opt/kde2/

share/conig/kdm/kdmrc .

Na koniec musimy jeszcze zadbać, aby

nasza zapora sieciowa ( irewall ) nie dopusz-

czała połączeń przechodzących z Internetu

na port 177 UDP , a równocześnie, aby

pozwalała na takie połączenia z kompute-

rów, które mają służyć jako terminale.

Sposób uzyskania takiego efektu zależy od

konstrukcji naszej zapory sieciowej. Wyko-

nanie tej czynności nie jest bezwzględnie

konieczne, ale z pewnością zredukuje ryzy-

ko związane z uruchomieniem nowej usłu-

gi. Przykładowa regułka blokująca dostęp

z zewnątrz do komputera o adresie 192.

168.0.1 poprzez interfejs sieciowy eth1 może

wyglądać tak:

DisplayManager.requestPort: 0

Powoduje ona, że menedżer logowania

nie oczekuje zapytań XDMCP . Aby to

zmienić, musimy usunąć tę linię lub po

prostu zamienić ją na komentarz. W tym

drugim przypadku wystarczy na począt-

ku linii dodać wykrzyknik, aby wygląda-

ła tak:

Instalacja

W przypadku dystrybucji Red Hat , Aurox

i Fedora program X11vnc można pobrać

z repozytorium DAG . Jeśli korzystamy

z programu Yum i mamy dodane repozy-

torium DAG , to instalacja ogranicza się do

wydania polecenia yum install x11vnc .

W innym przypadku musimy pobrać

odpowiedni pakiet dla naszej dystrybucji

(np. x11vnc-0.7.2-1.1.fc3.rf.i386.rpm ) ze stro-

ny http://dag.wieers.com/packages/x11vnc/ ,

a następnie zainstalować go (np. polece-

niem rpm -Uvh x11vnc-0.7.2-1.1.fc3.rf.

i386.rpm ).

! DisplayManager.requestPort: 0

Po zapisaniu zmian zajmujemy się edycją

pliku /etc/X11/xdm/Xaccess . Wśród wielu

linii komentarza znajdujemy linię o

treści:

--destination-port 177 -j REJECT

-p udp -d 192.168.0.1

Korzystanie

Z lokalnego komputera musimy połączyć

się (np. za pośrednictwem SSH ) ze zdal-

#* # any host can get a login window

54 styczeń 2006

iptables -A INPUT -i eth1

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: