background image

dla początkujących

50

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

51

www.lpmagazine.org

Zdalny dostęp 

do środowiska 

graficznego

Piotr Machej

U

zyskanie zdalnego dostępu do 
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 
skonfigurować 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.

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ć  filmy  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ć  film,  a  ja  mogę 
pracować z OpenOffice.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 firmie

mój znajomy. Zmęczony ciągłym bieganiem
do  użytkowników  zgłaszających  problemy
zainstalował  na  wszystkich  komputerach

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  firmę  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ą  graficzną.  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
.

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. 
Fedorze poleceniem 

rpm -Uvh nxclient-

1.5.0-113.i386.rpm

). Oczywiście, do insta-

lowania  pakietów  potrzebujemy  upraw-

 DVD

Po uruchomieniu Linux+ Live 

DVD możesz skorzystać z SSH, 

VNC, FreeNX-a oraz Krfb.

Na płycie CD/DVD

Na płycie CD/DVD znajdują się 

pakiety FreeNX-a oraz 

klienci VNC.

background image

dla początkujących

50

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

51

www.lpmagazine.org

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 konfigura-
cyjnym możemy zadecydować, czy ikona 
połączenia ma pojawić się na pulpicie oraz 
czy mają być wyświetlone zaawansowane 
opcje konfiguracji. 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.

Konfiguracja serwera

Opis  instalacji  i  konfiguracji  serwera 
FreeNX jest bardzo ściśle związany z dys-
trybucjami  Aurox  i  Fedora.  W  przypadku 

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?

Konfiguracja klienta

Podstawowe  konfigurowanie  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 skonfigurowaną sesję w 
kliencie, to w celu dodania nowej sesji uru-
chamiamy klienta poleceniem 

nxclient  --

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

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-

Rysunek 1. 

Klienta NX możemy 

wypróbować na testowym serwerze 
udostępnionym przez NoMachine

background image

dla początkujących

52

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

53

www.lpmagazine.org

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.

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-

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:

ssh -C -L 5901:localhost:5900

S

 

   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-

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  konfigura-
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 konfi-
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-

Rysunek 2. 

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

wyświetlane tylko raz

background image

dla początkujących

52

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

53

www.lpmagazine.org

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

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.

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  firmie)  takie  rozwiązanie  może 
okazać  się  bardzo  dobre.  W  dodatku, 
odpowiednie  skonfigurowanie  Linuksa 
okazuje się być bardzo proste.

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 graficznym, 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 GDMKDM lub 
XDM – może to być uzależnione od kon-
figuracji 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-

ficzny,  czy  tekstowy  ekran  logowania, 
w  przypadku  dystrybucji  Aurox  (a  także

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  graficznym,  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

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  skonfigurować  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 graficznego. Opiera się 
na protokole RFB (Remote FrameBuffer), 
odpowiadającym za zdalny dostęp do gra-
ficznego 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  graficznych.  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.

background image

dla początkujących

54

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

55

www.lpmagazine.org

menedżer logowania, można po prostu zmie-
nić tę linię tak, aby miała np. treść:

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

Bardziej poprawną metodą jest pozostawie-
nie tej linii w spokoju, a zamiast tego doko-
nanie zmiany w pliku /etc/sysconfig/desktop
gdzie powinna znaleźć się linia o treś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 konfiguracji.

Konfiguracja

Wciąż korzystając z uprawnień administra-
tora  zaczynamy  od  edycji  pliku  /etc/X11/
xdm/xdm-config
.  Odnajdujemy  linię  (za-
zwyczaj jest ona ostatnia) o treści:

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:

! 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:

#*   # any host can get a login window

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

192.168.0.15   # only host 
192.168.0.15 can get a login window

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:

Enable=true
Port=177

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/config/kdm/kdmrc  lub  /opt/kde2/
share/config/kdm/kdmrc
.

Na koniec musimy jeszcze zadbać, aby

nasza zapora sieciowa (firewall) 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:

iptables -A INPUT -i eth1

S

 

   -p udp -d 192.168.0.1

S

 

   --destination-port 177 -j REJECT

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.

Korzystanie

Po  odpowiednim  skonfigurowaniu  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.

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

Instalacja

W przypadku dystrybucji Red HatAurox 
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

).

Korzystanie

Z lokalnego komputera musimy połączyć 
się  (np.  za  pośrednictwem  SSH)  ze  zdal-

Rysunek 3. 

Dzięki SSH możemy 

swobodnie uruchamiać zdalnie pojedyncze 
programy

background image

dla początkujących

54

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

55

www.lpmagazine.org

nym komputerem (w naszym przykładzie 
stojącym w pracy) i zalogować się na konto 
użytkownika,  który  uruchomił  system 
X  Window.  Teraz  wystarczy  uruchomić 
polecenie 

x11vnc -display :0

. Jeśli się po-

wiedzie,  to  otrzymamy  odpowiedni 
komunikat,  podający  nazwę,  jaką  mamy 
wpisać do klienta VNC oraz numer portu 
(zazwyczaj  5900).  Podobnie  jak  w  po-
przednich  przypadkach,  pozostaje  nam 
wydać  polecenie 

vncviewer

  jako  argu-

ment  podając  nazwę  lub  adres  kompute-
ra w pracy.

Po  zamknięciu  klienta  VNC  program 

X11vnc  automatycznie  zakończy  działa-
nie. Jeśli nie odpowiada nam takie zacho-
wanie, możemy uruchomić X11vnc z opcją 
-forever.  W  każdym  z  tych  przypadków 
warto pomyśleć o zabezpieczeniu dostępu 
do  pulpitu  hasłem.  W  tym  celu  najlepiej 
utworzyć plik, w którym w pierwszej i dru-
giej linii będą podane dwa hasła. Pierwsze 
z  nich  będzie  pozwalało  na  podglądanie 
i  kontrolowanie  pulpitu,  a  drugie  tylko 
na  podglądanie.  Plik  ten  (o  przykłado-
wej  nazwie  ~/pass.txt)  należy  zabezpie-
czyć  przed  dostępem  osób  postronnych 
wydając polecenie 

chmod 600 ~/pass.txt

Dzięki  temu  tylko  właściciel  pliku 
będzie mógł go odczytać i modyfikować. 
Uruchomienie  X11vnc  z  użyciem  pliku 
z  hasłami  odbywa  się  po  wydaniu  pole-
cenia:

x11vnc -display :0 -forever 
   -passwdfile ~/pass.txt

Uwagi  umieszczone  w  rozdziale  o  zdal-
nym pulpicie w GNOME odnośnie zapory 
sieciowej i przesyłania transmisji tunelem 
SSH  odnoszą  się  również  do  X11vnc.  W 
tym  przypadku  możemy  nawet  jednym 
poleceniem równocześnie utworzyć tunel 
i uruchomić X11vnc:

ssh -L 5901:localhost:5900 
user@192.168.1.1 'x11vnc 
   -localhost -display :0'

Oczywiście,  w  takim  przypadku  klien-
ta  uruchamiamy  poleceniem 

vncviewer 

localhost:5901

.

Tunelowanie po SSH

Jeśli  potrzebujemy  tylko  uruchomić  poje-
dynczy program ze zdalnego komputera, 
to często nie ma sensu łączyć się z całym 
pulpitem.  Zamiast  tego  możemy  skorzy-
stać  z  pewnej  opcji  SSH,  która  pozwa-

la  na  przesyłanie  połączeń  X11  bezpiecz-
nym  kanałem.  Wystarczy  połączyć  się  ze 
zdalnym  komputerem  (w  naszym  przy-
kładzie  o  adresie  192.168.1.1)  za  pomocą 
polecenia:

ssh -X user@192.168.1.1

Po podaniu hasła użytkownika user zalo-
gujemy  się  tradycyjnie  na  nasze  konto, 
ale dzięki opcji -X będziemy mieli więk-
sze  możliwości.  Jeśli  uruchomimy  jakiś 
program  z  interfejsem  graficznym  (np. 
przeglądarkę  obrazków  poleceniem 

gqview

 lub kalkulator poleceniem 

kcalc

), 

to  aplikacja  wyświetli  się  na  naszym 
ekranie. W ten sposób możemy pracować 
z tymi programami, które akurat są nam 
potrzebne.

Zakończenie

Jest wiele scenariuszy, w których koniecz-
ne  lub  co  najmniej  przydatne  może  się 
okazać  zdalne  korzystanie  ze  środowi-
ska  graficznego.  Jak  widać  z  niniejszego 
artykułu,  do  praktycznie  każdego  zasto-
sowania można dopasować odpowiednie 
narzędzie. Oprócz omawianego w artyku-
le klienta Vncviewer można znaleźć rów-
nież wiele innych klientów (np. TightVNC 
i  RealVNC),  często  rozprowadzanych 
razem  z  innymi  serwerami  VNC.  Wy-
bór  jednego  z  nich  to  w  dużej  mierze 
kwestia  gustu.  Większość  klientów  bez-
problemowo  działa  z  różnymi  serwera-
mi VNC

W Internecie:

•   Strona domowa FreeNX:

http://freenx.berlios.de/

•    Strona domowa NoMachine:

http://www.nomachine.com/

•   Strona domowa X11vnc:

http://www.karlrunge.com/x11vnc/

•   Angielska Wikipedia o VNC:

http://en.wikipedia.org/wiki/VNC

•    Angielska Wikipedia o XDMCP:

http://en.wikipedia.org/wiki/XDMCP

•   Angielska Wikipedia o NX:

http://en.wikipedia.org/wiki/
NX_technology

•   Strona domowa TightVNC:

http://www.tightvnc.com/

•    Strona domowa RealVNC:

http://www.realvnc.com/