Download: SysadminWorkshop

SYSADMIN
Warsztat administratora
Sztuczki i kruczki: X Window System
MISTER X11
Dzięki zautomatyzowanemu procesowi wykrywania sprzętu administrator
rzadko bywa zmuszony do samodzielnej konfiguracji systemu X. Jeśli
jednak kogoś interesują doskonałe możliwości sieciowe systemu X11 oraz
jego zaawansowane opcje dostrajania, z pewnością przyda mu się nieco
więcej wiedzy teoretycznej.
MARC ANDRÉ SELIG
L
inux wytrwale rozprzestrzenia się również wśród użytkowników, którzy dotychczas znali tylko Windowsa. Głównym czynnikiem sukcesu Linuksa jest dostępność łatwych w użytkowaniu środowisk graficznych i aplikacji. Ta obfitość oprogramowania oznacza, że administratorzy muszą poświęcać więcej czasu na konfigurację narzędzi obsługujących mysz, klawiaturę czy funkcje graficzne tych aplikacji.
X serwer jest elementem systemu, który
obsługuje prawie wszystkie funkcje wyjścia
graficznego we współczesnych systemach Linux. Jedynymi wyjątkami od tej zasady są
konsola i SVGA-lib [2], biblioteka obsługująca bezpośrednie wyjście danych na kartę graficzną. Sam X Serwer udostępnia prymitywne mechanizmy obsługi wyświetlania hierarchii okien, prostą akcelerację sprzętową oraz
obsługę myszy i klawiatury.
Jeśli ktoś nie czuje się pewnie w architekturach typu klient-serwer, szczegóły protokołu
X mogą go jeszcze bardziej zmieszać, ponieważ tutaj serwer X11 to niezbyt silna stacja robocza znajdująca się pod biurkiem użytkownika, natomiast klient to najczęściej potężna
maszyna ulokowana gdzieś w serwerowni.
Klient i serwer zamieniają
się rolami
W pomieszanym świecie X-ów serwer to program komunikujący się bezpośrednio z użytkownikiem. To serwer rysuje na ekranie wid-
60
NUMER 20 PAŹDZIERNIK 2005
gety (elementy graficzne interfejsu) i rejestruje działania użytkownika (np. dane z klawiatury i myszy). Klient tej architektury wykorzystuje serwer do rysowania na ekranie,
nie robi tego samodzielnie. Oznacza to
w praktyce, że klient nie musi mieć dostępu
do sprzętu graficznego, lecz o obsługę funkcji graficznych po prostu poprosi serwer. Typowi klienci X to procesory tekstu, przeglądarki WWW czy emulatory terminali.
Jeśli klient i serwer X działają na różnych
maszynach, serwer X prawie zawsze znajduje
się na maszynie użytkownika. Taka sytuacja
zachodzi również w przypadku typowych
„cienkich klientów” z Linuksem, które zawierają kompletny serwer X. Nie ma w praktyce żadnej różnicy, gdzie znajduje się klient.
Przy odpowiednio szybkim połączeniu sieciowym klient może znajdować się w serwerowni kilka metrów dalej lub po drugiej stronie globu. Najczęściej jednak klienty działają na tej samej maszynie co serwer.
Przykładem serwera X działającego na jednej maszynie z jednym tylko programem
klienckim są tak zwane systemy kioskowe
(kiosk system), które można znaleźć w kawiarenkach internetowych czy szpitalach w postaci przeglądarek obrazów rentgenowskich.
Aby skonfigurować prosty system kioskowy, potrzebne są dwa polecenia. Administrator musi po pierwsze uruchomić serwer,
a następnie odpowiedniego klienta lub klienty. W poniższym przykładzie opcja :3 oznacza, że serwer będzie uruchomiony na czwar-
WWW.LINUX-MAGAZINE.PL
tym (licząc od zera) lokalnym ekranie (ang.
display) serwera X (nie chodzi tu o monitor,
lecz o tzw. ekran wirtualny):
X :3 < /dev/null > §§
/dev/null 2>&1 &
exec firefox -display :3 &
Powyższe wywołanie jest przekazywane
programowi xinit, który w odpowiedni sposób obsługuje jego składnię. Poniższy przykład uruchamia serwer X, a następnie
Xterm, chyba że w pliku .xinitrc w katalogu
domowym użytkownika znajdą się inne
opcje:
xinit -fn 9x13 – :3 > §§
/dev/null 2>&1 &
Głównym plikiem konfiguracyjnym każdego środowiska X jest plik /etc/X11/XF86Config-4. W zależności od wersji i dystrybucji serwera X może jednak mieć nazwę xorg.conf lub
podobną. W tym pliku znajduje się konfiguracja dla wszystkich urządzeń współpracujących z serwerem X.
Linux poczynił niesamowite postępy
w dziedzinie detekcji sprzętu, zatem administratorzy nie mają potrzeby modyfikowania konfiguracji serwera X, a jeśli już, to
w niewielkim stopniu. Istnieją programy,
które automatycznie tworzą plik konfiguracyjny: xf86cfg, xf86config, a w Suse są to Sax
lub Sax 2.
Warsztat administratora
SYSADMIN
Plik konfiguracyjny jest z reguły specyficzny nie tylko dla danego typu komputera
lub karty graficznej, lecz również dla danego
monitora. Zatem zanim wymieni się monitor
lub kartę graficzną, warto zadbać o alternatywny sposób dostępu do komputera (na
przykład za pośrednictwem sieci lub konsoli)
na wypadek, gdyby nowy sprzęt nie zadziałał
poprawnie z istniejącymi ustawieniami i serwer X po prostu nie uruchomi się.
Menedżery okien
Pozostawiony samemu sobie serwer X nie
jest szczególnie użyteczny ani przyjazny
użytkownikowi, objawia się to najmocniej
wtedy, gdy użytkownik chce pracować jednocześnie z większą liczbą okien i aplikacji. Potrzebny staje się element porządkujący
i upraszczający pracę ze stacją roboczą. Jednym z mechanizmów tego typu są menedżery
okien, które dodają paski tytułowe poszczególnym oknom, dzięki czemu można je łatwiej zidentyfikować, oraz ramkę umożliwiającą zmianę rozmiarów okien. Rysunek
1 przedstawia TWM, jeden z najstarszych
menedżerów okien.
TWM pozwala użytkownikom przesuwać
okna, a nawet potrafi je sortować. Menedżer
ten obsługuje też proste menu służące do
uruchamiania programów i minimalizowania okien do ikon. Starsze menedżery okien,
jak TWM czy FVWM, mają niewielkie rozmiary i są wydajne, oferując przy tym sporo
wygody użytkowania. Nawet budowane obecnie konfiguracje cienkich klientów, jak również wiele systemów wykorzystujących starsze komputery, nadal stosuje te menedżery
okien.
Aby uruchomić sesję X z menedżerem
TWM i przeglądarką Firefox, potrzeba trzech
dodatkowych elementów wywołania serwera X:
X :3 < /dev/null > §§
/dev/null 2>&1 &
twm -display :3 &
exec firefox --display :3 &
Większość współczesnych użytkowników
preferuje w pełni wyposażone środowiska
biurkowe (ang. desktop environment), jak
KDE czy Gnome. Te środowiska pracy
oprócz menedżera okien zawierają narzędzia, aplikacje i liczne biblioteki. Biblioteki
upraszczają programowanie GUI, dzięki nim
programy charakteryzują się jednolitym wyglądem i zasadami działania i mogą wzajemnie wymieniać się danymi.
Rysunek 1: Choć menedżer okien TWM zapewnia minimalną funkcjonalność, jest łatwy w obsłudze i stosunkowo wygodny.
Nowoczesne środowiska biurkowe menedżery okien uzupełniają dodatkowym mechanizmem noszącym nazwę menedżera sesji (ang. session manager). Zarówno KDE jak
i Gnome posiadają menedżery sesji o zaawansowanych możliwościach.
Graficzny ekran logowania
sko. Jeśli zachodzi taka potrzeba, do zalogowania się można wykorzystać mechanizmy sieciowe środowiska X. Dzięki temu menedżer
ekranu nie musi być uruchamiany na tym samym komputerze co serwer X. Menedżer ekranu uruchamia prosty program kliencki, dzięki
któremu serwer X uruchomiony na innym
komputerze przeprowadza z nim komunikację
za pomocą protokołu XDMCP.
Administrator może w konfiguracji wpisać
adres hosta menedżera ekranu lub uruchomić go w trybie rozgłaszania pakietów, aby
umożliwić serwerom X jego automatyczną
lokalizację. Służy do tego polecenie X -broadcast. Aby wykorzystać taki menedżer ekranu
działający na dedykowanym hoście, należy
w systemie z serwerem X wywołać polecenie
X -query host.
Serwer X obsługuje funkcje odczytu danych
z klawiatury, myszy itp., jak i wyświetlanie
interfejsu na ekranie monitora, menedżer
okien zarządza wieloma oknami. Pozostaje
jedynie załatwić sprawę logowania użytkownika do takiego graficznego systemu, najlepiej również z zastosowaniem graficznego
ekranu logowania. Niewielu zostało już użytkowników, którzy nadal wolą logować się
w oknie tekstowym tylko
po to, żeby natychmiast
„ręcznie” uruchomić środowisko graficzne.
Rozwiązaniem jest tu
menedżer ekranu (ang. display manager). Program
tego typu uruchamia serwer X i otwiera okno dialogowe podobne do przedstawionego na Rysunku 2. Po
uwierzytelnieniu użytkownika menedżer ekranu automatycznie uruchamia
Rysunek 2: Menedżer ekranu KDM pozwala użytkownikowi wyskonfigurowane środowibrać środowisko biurkowe lub zatrzymać system.
WWW.LINUX-MAGAZINE.PL
NUMER 20 PAŹDZIERNIK 2005
61
SYSADMIN
Warsztat administratora
Listing 1: Import
ciasteczek sesji
#mas:~$ xauth nextract myxkey :0
#mas:~$ chmod 640 myxkey
#mas:~$ su unsafe
#Password:
#unsafe:/home/mas$ firefox
#Xlib: connection to „:0.0”U
refused by server
#Xlib: No protocol specified
#
#(firefox-bin:3086): Gtk-WARNINGU
**: cannot open display: :0
#unsafe:/home/mas$ xauth nmergeU
myxkey
#unsafe:/home/mas$ firefox
Wszystkie nowoczesne dystrybucje Linuksa instalują menedżer ekranu wraz z odpowiednią konfiguracją przy okazji instalacji
środowiska X11. Te elementy systemu najłatwiej odnaleźć za pomocą programu locate
[3], podając nazwę poszukiwanego menedżera. Można znaleźć wersje menedżerów ekranu dla większości popularnych środowisk:
XDM, KDE (KDM) (Rysunek 2) oraz Gnome (GDM).
Kontrola ekranów
Nie jesteśmy ograniczeni do uruchamiania
tylko jednego serwera X na jednej maszynie.
Dzięki terminalom wirtualnym można jednocześnie obsługiwać większą liczbę serwerów. Serwery i klienty działają niezależnie od
siebie i nie muszą nawet pracować w tym samym systemie, musi być więc sposób na
wskazanie klientom, na który ekran mają wysyłać swoje dane. Służy do tego zmienna środowiskowa DISPLAY.
Wartość tej zmiennej może opcjonalnie
zawierać nazwę hosta, numer ekranu (display) i numer wyświetlacza (screen):
(Host):Ekran (.Wyświetlacz). Numer wyświetlacza z reguły nie jest niezbędny, za wyjąt-
Listing 2: Tunel dla
połączeń X11 za
pomocą SSH
#mas@ishi:~$ ssh -X kanat.pair.com
#[...]
#mas@kanat:$ echo $DISPLAY
#localhost:10.0
#mas@kanat:$ firefox &
62
NUMER 20 PAŹDZIERNIK 2005
kiem środowisk Xinerama, gdzie pojedynczy
serwer X może kontrolować kilka wyświetlaczy (fizycznych monitorów). Jeśli w zmiennej DISPLAY nie zostanie podana nazwa hosta, klient automatycznie przyjmie, że chodzi
o system lokalny, wykorzystując do komunikacji gniazdo plikowe zamiast portu TCP
(wykorzystywanego przez X11 do połączeń
sieciowych).
Gdy użytkownik zaloguje się za pomocą
menedżera ekranu, odpowiednia wartość
zmiennej DISPLAY jest ustawiana automatycznie. Aby uruchomić program środowiska
X na innym ekranie, należy wskazać mu,
gdzie to ma być. Następujące polecenie służy
do uruchomienia przeglądarki Firefox w systemie lokalnym, której interfejs będzie wyświetlany na pierwszym ekranie (czyli o numerze 0) maszyny sun14:
export DISPLAY=sun14:0
firefox &
Jeśli połączenia X11 są wykonywane za pośrednictwem sieci, należy pamiętać o kilku
sprawach. Po pierwsze, serwery nie przyjmują połączeń od wszystkich chętnych klientów
– taka konfiguracja stanowi zbyt duże ryzyko. Po drugie, w domyślnej konfiguracji strumień danych nie jest szyfrowany. Z tego powodu potencjalni napastnicy mają uproszczone zadanie podsłuchiwania ruchu sieciowego i przechwytywania sesji.
Prawie każdy nowoczesny serwer X obsługuje mechanizm kontroli dostępu. Istnieją
dwa alternatywne systemy dla Linuksa:
Xhost, który służy do przyznawania dostępu
dla wybranych komputerów (ta opcja nie jest
bardzo bezpieczna) oraz Xauth wykorzystujący zaszyfrowane ciasteczka (cookie)
i umożliwiający kontrolę na o wiele wyższym
poziomie szczegółowości.
Te schematy zabezpieczeń są ważne, ponieważ klienty X wykorzystują szeroki zakres protokołów i mogą mieć wpływ na działanie serwera i innych klientów. Na przykład
bardzo prostym zadaniem jest śledzenie naciśnięć klawiszy. Z tego powodu należy zadbać o to, aby do serwera miały dostęp tylko
zaufane programy.
Kontrola dostępu oparta
na ciasteczkach
Mechanizm Xauth przechowuje tak zwane
ciasteczka sesji w pliku noszącym nazwę
.Xauthority zapisanym w katalogu domowym
użytkownika. Gdy uruchamiany jest klient,
WWW.LINUX-MAGAZINE.PL
odczytuje zawartość tego pliku i wykorzystuje odpowiednie ciasteczko do uwierzytelnienia się na serwerze X. Jeśli sesja jest uruchamiana z innej maszyny lub bez odpowiednich danych uwierzytelniających (ang. credentials), należy najpierw zaimportować odpowiednie ciasteczko do swojego pliku .Xauthority (Listing 1). Polecenie xauth nextract
zapisuje ciasteczko w pliku, natomiast xauth
nmerge importuje jego zawartość do pliku
.Xauthority.
Mechanizm kontroli dostępu Xhost ma
sens w środowiskach, gdzie serwer X i klienty
działają w tym samym systemie i trzeba całkowicie zablokować dostęp z zewnątrz do tej
konfiguracji. Polecenie xhost + pozwala dowolnemu klientowi z dowolnego hosta połączyć się z tym serwerem X, polecenie xhost włącza z powrotem kontrolę dostępu.
Xauth kontroluje jedynie, kto ma dostęp
do serwera X – nie zabezpiecza jednak w ogóle przesyłanych danych. Jeśli więc ktoś wykorzysta do kontroli dostępu mechanizm
przedstawiony na Rysunku 1, powinien mieć
świadomość, że nie zabezpiecza to danych
przed podsłuchem.
Zabezpieczeniem przed tym niebezpieczeństwem okazuje się popularny protokół
SSH. Pozwala on tunelować sesję X w bezpiecznym, szyfrowanym połączeniu. Program zapewnia szyfrowanie, konfiguruje odpowiednie wartości zmiennych środowiska
i wykorzystuje Xauth do wygenerowania odpowiedniej zawartości pliku .Xauthority
w zdalnym systemie.
Tunelowanie sesji X
przez SSH
Aby skonfigurować tunnel, należy w plikach
/etc/ssh/sshd_config oraz /etc/ssh/ssh_config
ustawić opcję X11Forwarding na wartość yes.
Jeśli użytkownik zastosuje opcję -X programu ssh, utworzy tunel dla sesji X w połączeniu SSH (Listing 2). SSH tworzy wirtualny
serwer X na zdalnej maszynie (najczęściej na
ekranie :10). Klienty uruchomione w tym połączeniu będą wyświetlać swoją zawartość na
lokalnym serwerze X. ■
INFO
[1] X.org: http://www.x.org/
[2] SVGA-Lib: http://www.svgalib.org
[3] Marc André Selig, „Admin Workshop:
Finding Files”: Linux Magazine 02/05, p. 62.