01(25)/2014

LINUX


Urządzenia
Ta część poświęcona jest urządzeniom, które podłączyć można do systemu linuxowe-go - takim jak terminale, modemy i drukarki. Omawia problemy dotyczące dodawa-nia poszczególnych urządzeń i zarządzania nimi, jak również polecenia służące do te-go celu. Informacje przedstawione w tym rozdziale będą niezbędne w przypadku, jeśli chcesz, by system działał bez zarzutu. Nawet jeśli nie zamierzasz podłączać terminalu czy modemu, powinieneś wiedzieć co nieco o procesie uruchamiania systemu i o tym, jak obsługiwane są pliki konfiguracyjne.
Urządzenia znakowe i blokowe
Wszystko, co podłączone jest do komputera, traktowane jest przez Linuxa jednakowo - jako urządzenie. Nie ma znaczenia, czy jest to terminal, dysk twardy, drukarka czy modem. Wszystko, co potrafi wysyłać albo odbierać dane od systemu operacyjnego, jest urządzeniem. Koncepcja traktowania wszystkich urządzeń jednakowo przeniesiona została z systemów UNIX-owych. Każdy typ urządzenia posiada w jądrze systemu przeznaczony do jego obsługi kod, nazywany sterownikiem. Zawiera on wszystkie, potrzebne do komu-nikowania się z urządzeniem. Nowo opracowane urządzenie może być używane w sys-temie linuxowym dopiero po napisaniu odpowiedniego sterownika. Dzięki temu, że sterowniki urządzeń są zapisywane w osobnych plikach, mogą być one ładowane w razie potrzeby (w przypadku urządzeń używanych rzadko) lub przecho-wywane w pamięci przez cały czas pracy systemu. Jeśli urządzenia zostaną w jakiś sposób zmodyfikowane, możliwe jest również dołączenie do jądra odpowiednio dosto-sowanego sterownika, pozwalającego poprawić wydajność czy udostępniającego nowe możliwości. Kiedy aplikacja odwołuje się do urządzenia, jądro systemu nie musi martwić się szcze-gółami jego obsługi. Po prostu przekazuje żądanie dalej, do sterownika, pozwalając mu obsłużyć komunikację. Jeśli na przykład wpisujesz coś z klawiatury terminalu, jego sterownik przyjmuje informacje o naciśnięciach klawiszy, a następnie przekazuje je do powłoki czy innej aplikacji, filtrując po drodze wszystkie kody specjalne, z którymi ją-dro systemu nie umiałoby sobie poradzić i zastępując je kodami zrozumiałymi dla kernela. Pliki urządzeń przechowywane są w katalogu /dev. Wiąże się to z ogólnie przyjętą konwencją, ale można je przechowywać w dowolnym miejscu. Urządzenia mogą komunikować się z systemem na dwa sposoby: przesyłając infor-macje znak po znaku lub blokami. Terminale, drukarki i modemy asynchroniczne są urządzeniami znakowymi, tzn. wykorzystują pierwszy mechanizm komunikacji, prze-syłając jednorazowo tylko jeden znak, który jest odbierany przez urządzenie na dru-gim końcu połączenia. Dyski twarde i większość napędów taśmowych używa komuni-kacji blokowej, ponieważ pozwala ona na osiągnięcie większych prędkości przesyłania danych - są one nazywane urządzeniami blokowymi. Urządzenia znakowe można również odróżnić od blokowych rozpatrując sposób, w jaki buforowana jest transmisja danych. Urządzenia znakowe zwykle same dokonują buforowania. Urządzenia blokowe, które przeważ-nie przesyłają i odbierają dane w blokach po 512 lub 1024 bajty, wymaga-ją buforowania przez jądro systemu. Niektóre urządzenia mogą działać zarówno jako urządzenia blokowe, jak i znakowe - dotyczy to np. niektórych napędów taśmowych. Posiadają one wtedy dwa osobne sterowniki, a wybór trybu komunikacji zależy od użytkownika. Urządzenia blokowe i znakowe można rozróżnić wydając polecenie ls -l w katalogu /dev. W kolumnie zawierającej prawa dostępu pierwsza litera oznacza typ urządzenia: c - urządzenie znakowe, b - blokowe. Pliki urządzeń zwykle mają nazwy pozwalające na ich identyfikację (na przykład na-zwy terminali zaczynają się od liter tty, ang. teletype) i zawierające numer czy litery identyfikujące konkretne urządzenie (np. tty1, tty1A czy tty04). W połączeniu ze ścieżką dostępu /dev daje to pełne nazwy urządzeń, takie jak /dev/tty01 itp.
Główne i poboczne numery urządzeń
W systemie linuxowym może działać więcej niż jedno urządzenie danego typu - można na przykład zainstalować kartę multiport, do której podłączonych jest 10 terminali. Dla wszystkich tych terminali Linux może używać tego samego sterownika (zakładając, że są to terminale tego samego typu). Musi jednak istnieć metoda pozwalająca systemowi zorientować się, który z terminali chcesz zaadresować. Służą do tego numery urządzeń. Numer główny identyfikuje ste-rownik, którego należy użyć, natomiast numer poboczny jest numerem samego urzą-dzenia. Wszystkie terminale z powyższego przykładu będą więc posiadały taki sam numer główny, ale różne numery poboczne, dzięki czemu system będzie mógł je roz-różnić. Każde urządzenie w systemie ma przypisaną unikalną parę numer główny-numer po-boczny. Jeśli dwa urządzenia miałyby takie same numery, Linux nie potrafiłby komu-nikować się z nimi poprawnie. Niektóre sterowniki urządzeń wykorzystują jednak te numery w dość dziwaczny spo-sób. Przykładowo, sterowniki napędów taśmowych czasem używają numeru pobocz-nego, by zidentyfikować gęstość zapisu danych na taśmie. Pliki urządzeń tworzy się poleceniem mknod (ang. make node), a usuwa tak, jak nor-malne pliki - poleceniem rm.
Polecenie mknod
Polecenie mknod spełnia w systemie Linux kilka funkcji. Potrafi utworzyć kolejkę (ang. FIFO - first in, first out) oraz pliki urządzeń blokowych i znakowych. Jego składnia jest następująca:
mknod [opcje] urządzenie b|c|p|u nr_główny nr_poboczny
Opcje mogą przybierać następujące wartości:
--help: wyświetlenie krótkiej instrukcji obsługi i zakończenie programu,
-m: ustalenie praw dostępu do tworzonego pliku (domyślnie 0666 - dozwolona jest tylko notacja symboliczna),
--version: wyświetlenie informacji o wersji i zakończenie
Argument po nazwie urządzenia określa jego typ; dostępne wartości to: b - urządzenie blokowe, c - urządzenie znakowe, p - kolejka (FIFO) i u - niebuforowane urządzenie znakowe. Trzeba użyć dokładnie jednej z tych wartości. Następnie podać należy dwie liczby, określające główny i poboczny numer urządzenia. Oba te numery są wymagane w przypadku urządzeń znakowych, blokowych i niebu-forowanych. Nie trzeba ich podawać w przypadku tworzenia kolejki. Przykłady użycia tego polecenia pojawią się w dalszej części tego rozdziału, gdy omawiać będziemy dodawanie do systemu nowych urządzeń.
Drukarki
Drukarki są bardzo często używanymi urządzeniami i raczej nie sprawiają kłopotów administratorom. Łatwo je skonfigurować, o ile dostępne są dane techniczne sprzętu. Zarządzanie kolejkami drukowania również nie jest trudne, ale jak to często bywa w Linuxie, żeby system sprawował się bez zarzutu, trzeba znać kilka drobnych "sztu-czek". Linux oparty jest na wersji BSD systemu UNIX, która - niestety - nie była najlepiej rozwiązana, jeśli chodzi o obsługę drukowania. Mimo tego, ponieważ Linux rzadko używany jest w bardzo dużych sieciach posiadających wiele drukarek, administrowa-nie nimi można sprowadzić do niezbędnego minimum. Trzeba jednak zdawać sobie sprawę z faktu, że polecenia służące do administrowania drukarkami w systemie BSD UNIX uważane są za niespójne i generalnie niezbyt przyjemne.
lpd - rezydentny program drukujący
Drukowanie w systemie Linux obsługiwane jest przez program rezydentny lpd. Pod-czas uruchamiania systemu lpd odczytuje zawartość pliku /etc/printcap, szuka-jąc sekcji dotyczących drukarek podłączonych do systemu. Używa on dwóch innych procesów, listen i accept, które przyjmują zlecenia drukowania kopiując je do ka-talogu kolejki (ang. spool directory). W większości przypadków modyfikacja zachowania programu lpd nie jest konieczna. Może się jednak zdarzyć, że trzeba będzie go zrestartować. Należy wtedy zakończyć odpowiedni proces (za pomocą polecenia kill), a następnie uruchomić go ponownie poleceniem:
lpd [-l] [port]
Opcja -l załącza rejestrowanie wszystkich zleceń drukowania, co czasem przydaje się przy szukaniu błędów w systemie drukowania. Parametr port jest internetowym numerem portu, który należy podać, jeśli nie chcemy używać domyślnych ustawień systemowych. Najprawdopodobniej nigdy nie będziesz musiał użyć tych opcji. Rozmiar kolejek drukowania (każda drukarka posiada własny katalog, zawierający pliki do wydrukowania, nazywany po angielsku spool directory) jest określony w pli-kach o nazwie minfree zawartych w każdym z katalogów kolejek. Plik taki zawiera liczbę bloków dysku, które należy zarezerwować, dzięki czemu duże zadania druko-wania nie zapełniają dysku twardego. Plik minfree może być modyfikowany za po-mocą dowolnego edytora tekstów. Nie każdy użytkownik ma jednak prawo drukować. Program lpd sprawdza zawartość plików /etc/hosts.equiv i /etc/host.lpd; jeśli nazwa systemu, z którego loguje się użytkownik, nie jest wymieniona w żadnym z tych plików, żądanie drukowania zo-stanie zignorowane. Ponieważ nazwa systemu lokalnego zawsze znajduje się w pliku hosts.equiv, jego użytkownicy zawsze mogą drukować.
Proces drukowania
Prześledźmy proces drukowania, idąc tropem zlecenia wydruku. Jest ono generowane przez program lpr. Zbiera on razem dane przeznaczone do wydrukowania i kopiuje je do katalogu kolejki, w którym oczekują na obsłużenie przez program lpd. Program lpr jest jedynym programem, który może wstawiać pliki do ko-lejki drukowania. Wszystkie inne programy pozwalające na drukowanie działają w oparciu o ten program. Sposób, w jaki plik ma zostać wydrukowany, można określić w wierszu poleceń (po-dając odpowiednie opcje polecenia lpr) lub ustalając odpowiednie wartości zmien-nych środowiskowych - jeśli nie zostaną przekazane żadne argumenty i wartości od-powiednich zmiennych nie są zdefiniowane, użyte zostaną domyślne wartości syste-mowe. Program lpr wie, do której kolejki ma dołączyć plik do wydrukowania, dzięki oznaczeniu drukarki docelowej. Nazwę drukarki docelowej można podać w wierszu poleceń lub ustalając wartość odpowiedniej zmiennej środowiskowej. Po określeniu, do której drukarki skierowane jest żądanie wydruku, lpr szuka wpisu w pliku /etc/printcap zawierającego informacje o tejże drukarce, między innymi o ścieżce dostępu do jej ka-talogu kolejki (zwykle /usr/spool/nazwa_drukarki, na przykład /usr/spool/lp1). Następnie program lpr tworzy w katalogu kolejki dwa pliki. Nazwa pierwszego z nich zaczyna się od liter cf (ang. control file), po których następuje numer identyfikacyjny zlecenia drukowania. W tym pliku zawarte są informacje dotyczące zadania druko-wania, między innymi identyfikator użytkownika, który wydał zlecenie drukowania. Drugi plik ma nazwę zaczynającą się od liter df (ang. data file) i zawiera dane, które mają zostać wydrukowane. Po zakończeniu tworzenia pliku z danymi program lpr informuje program lpd o fakcie, że w kolejce czeka na obsłużenie nowe zadanie. Kiedy program lpd otrzymuje sygnał od lpr, sprawdza w pliku /etc/printcap, czy drukarka docelowa jest drukarką lokalną, czy sieciową. Jeśli jest to drukarka sieciowa, otwarte zostaje połączenie z systemem zdalnym, a następnie plik kontrolny i plik da-nych zostają przeniesione do tego systemu. Jeśli drukarka jest drukarką lokalną, lpd sprawdza, czy jest ona dostępna i aktywna, a następnie wysyła zlecenie drukowania do programu rezydentnego obsługującego daną kolejkę drukowania.
Plik /etc/printcap i katalogi kolejki
Zarówno program lpr, jak i lpd korzysta z danych zapisanych w pliku /etc/printcap. Plik ten zawiera informacje o wszystkich drukarkach dostępnych w systemie linuxowym. Format tego pliku jest prosty (i podobny do formatu pliku /etc/termcap, zawierają-cego informacje o terminalach). Oto przykładowy wpis:

# HP Laserjet
lp|hplj|laserjet-michal|HP LaserJet 4M w pokoju 425:\
:lp=/dev/lp0:\
:sd=/usr/spool/lp0:\
lf=/usr/spool/errorlog:\
mx#0:\
of=/usr/spool/lp0/hpjlp:\
Pierwsze pole każdego wpisu to lista nazw danej drukarki (nazwy te mogą być używa-ne zamiennie). Za pomocą tych nazw identyfikowana jest drukarka, która ma wydru-kować określone dane - nazwa taka może być użyta przy ustalaniu wartości jednej ze zmiennych środowiskowych lub jako jeden z argumentów polecenia lpr. Dostępne nazwy rozdzielane są kreską pionową. Zwykle każda drukarka posiada co najmniej trzy nazwy: krótką, składającą się z czte-rech lub mniej znaków (np. hplj), nieco dłuższą, zawierającą np. identyfikator jej właściciela (np. laserjet-michal), oraz pełną, opisową nazwę, zawierającą infor-macje niezbędne do zidentyfikowania urządzenia (np. HP LaserJet 4M w pokoju 425). Jeśli zlecenie drukowania nie zawiera informacji o drukarce docelowej, a informacja taka nie jest również dostępna poprzez zmienne środowiskowe, zadanie zostaje skierowane do drukarki o nazwie lp. Z tego powodu jedna z drukarek powinna posiadać nazwę (jedną z kilku) lp. W pliku /etc/printcap komentarze oznacza się znakiem # na początku wiersza. Po nazwie drukarki następuje zestaw dwuznakowych nazw parametrów i ich wartości. Format tych wpisów jest następujący:
NN wartość logiczna
NN=tekst     wartość tekstowa tekst;
NN#liczba   wartość numeryczna różna od liczby liczba.
Kiedy używana jest wartość logiczna (czyli po nazwie parametru nie występuje ani tekst, ani liczba), parametr przyjmuje wartość True (czyli zero). Jeśli wymagana jest wartość False (różna od zera), po prostu nie należy wyszczególniać danego parametru. Większość parametrów i ich wartości otoczonych jest dwukropkami, głównie dla zwiększenia przejrzystości pliku i ułatwienia przetwarzania go programom obsługi dru-kowania. Dozwolone są również przypisania puste, czyli dwa dwukropki obok siebie. Kilka parametrów wartych jest odnotowania ze względu na ich przydatność podczas administrowania systemem. Nie wszystkie mogą pojawić się przy definicji każdej dru-karki. Oto niektóre z nich.
sd     Określenie ścieżki dostępu do katalogu kolejki.
lf    Katalog, w którym rejestrowane będą komunikaty o błędach.
mx     Określenie typów plików, które mogą być drukowane.
af    Nazwa pliku, w którym mają być rejestrowane zadania drukowania.
of    Filtr wyjściowy, który ma być używany przy drukowaniu.
Każda drukarka powinna posiadać własny katalog kolejki. Katalog taki jest niezbędny zarówno dla drukarki lokalnej, jak i sieciowej. Jeśli dodajesz do systemu nową drukar-kę, to jest prawdopodobne, że o stworzenie takiego katalogu (poleceniem mkdir) bę-dziesz musiał zadbać sam. Prawa dostępu do takiego katalogu powinny mieć wartość 755. Właścicielem katalogu musi być użytkownik root lub daemon. Identyfikator grupy posiadającej ten katalog powinien również mieć wartość root lub daemon. W większości przypadków daemon jest lepszym rozwiązaniem (ze względów bezpieczeń-stwa), choć ustawienie root również jest poprawne. Plik, w którym rejestrowane będą informacje o błędach, umieścić można w dowolnym miejscu. Może on być wspólny dla wszystkich drukarek, ponieważ każdy wpis i tak zawiera nazwę drukarki. Plik, w którym rejestrowane są zlecenia drukowania, jest szczególnie przydatny w sys-temach, w których użytkownicy płacą za wydruki. Może być również użyty do celów statystycznych. Nowy wpis dodawany jest po zakończeniu drukowania. Wpisy mogą być wyświetlane za pomocą polecenia pac (więcej informacji na temat tego polecenia znajdziesz na stronach man). Parametr mx pozwala określić, jakiego typu pliki mogą być drukowane. Zwykle jego definicja ma postać mx#0, co oznacza zezwolenie na drukowanie wszystkich typów plików. Filtr wyjściowy modyfikuje format drukowanych danych, dostosowując je do wyma-gań drukarki. Przykładowo, niektóre drukarki laserowe nie mogą zmieścić na stronie 66 wierszy tekstu, więc filtr dzieli dokument na strony zawierające po 60 wierszy (wartość tę można zmienić). Czasem filtr jest również potrzebny, aby dodawać kody kontrolne, wymagane na przykład przy zmianie czcionki czy rodzaju papieru. W każdym katalogu kolejki mogą znajdować się jeszcze dwa pliki: status i lock. Oba zawierają tylko jeden wiersz i mogą być modyfikowane za pomocą edytora tek-stów. W plikach tych zapisana jest informacja o aktualnym stanie drukarki. Są one tworzone przez program lpd i używane przez niektóre programy do informowania o statusie drukarki.
Dodawanie drukarki za pomocą polecenia mknod
Linux obsługuje zarówno drukarki szeregowe, jak i równoległe. Drukarki obu typów są urządzeniami znakowymi. Niestety, większość wersji Linuxa nie zawiera programów pozwalających na łatwą konfigurację drukarki (programy takie są dostępne w więk-szości wersji UNIX-a), co pociąga za sobą konieczność ręcznego modyfikowania pli-ków systemowych. Drukarki równoległe zwykle nazywają się lp0, lp1, lp2 itd., zależnie od adresu portu, do którego są podłączone (najczęściej spotyka się pojedynczy port równoległy, podłą-czona do niego drukarka nazywa się wtedy lp0). Oto dostępne nazwy urządzeń, od-powiadające im adresy portów i nazwy używane w systemie DOS:
/dev/lp0    0x03bc     LPT1
/dev/lp1    0x0378     LPT2
/dev/lp2    0x0278     LPT3
Aby określić adres portu równoległego, możesz posłużyć się jakimś pro-gramem diagnostycznym (np. DOS-owym MSD.EXE). Niektóre wersje BIOS-u wyświetlają adresy portów równoległych podczas uruchamiania komputera. Jeśli nie jesteś pewny, próbuj po kolei, zaczynając od lp0 i sprawdzając, czy drukowanie jest możliwe. Pierwszy port równoległy w systemach PC ma zwykle adres 0x03bc. W systemie Linux do utworzenia pliku drukarki należy użyć polecenia mknod. Właści-cielem takiego pliku musi być użytkownik root lub daemon. Poniższe polecenia tworzą plik drukarki dołączonej do pierwszego portu równoległego (/dev/lp0):
mknod -m 620 /dev/lp0 c 6 0
chown root.daemon /dev/lp0
Prawa dostępu do nowo utworzonego pliku /dev/lp0 ustawiono na 620; plik ten jest plikiem urządzenia znakowego o numerze głównym 6 i pobocznym 0. Numery po-boczne urządzeń zwykle rozpoczynają się od zera i są zwiększane o jeden dla każdego nowego urządzenia. Ponieważ dodawaliśmy pierwszą drukarkę w systemie, przypisali-śmy jej numer poboczny 0. Właściciel root.daemon to specjalna składnia używana w systemie Li-nux dla programów rezydentnych uruchamianych przez użytkownika ro-ot. Wpis root.daemon nie pojawia się w pliku /etc/passwd. Pierw-sza część identyfikatora (do kropki) oznacza użytkownika, natomiast dru-ga - grupę. Jeśli konfigurujesz jeszcze inne urządzenia, muszą one mieć oczywiście różne nazwy, np.:
mknod -m 620 /dev/lp0 c 6 0
mknod -m 620 /dev/lp1 c 6 1
mknod -m 620 /dev/lp2 c 6 2
W powyższych poleceniach numer poboczny urządzenia zwiększany jest tak, by od-powiadał numerowi portu. Nie jest to wymagane, ale może pomóc w identyfikacji urządzenia. Po wydaniu powyższych poleceń dobrze jest jeszcze raz sprawdzić, czy właściciel pliku został ustawiony prawidłowo i czy utworzony został katalog kolejki. Jeśli katalog ko-lejki nie istnieje, trzeba założyć go ręcznie.
Zarządzanie drukarkami - program lpc
Drukarki kontrolowane są za pomocą programu lpc. Pozwala on między innymi na:
- wyświetlanie informacji o statusie drukarki,
- włączanie i wyłączanie drukarki,
- włączanie i wyłączanie obsługi kolejki drukowania,
- usuwanie wszystkich oczekujących zadań drukowania,
- przesuwanie zadań na początek kolejki,
- wprowadzanie zmian w konfiguracji programu lpd.
Program lpc nie może być używany do zarządzania drukarkami sieciowymi, a tylko do zmiany ustawień drukarek podłączonych bezpośrednio do Twojego komputera.
Musisz wiedzieć o tym, że lpc to jeden z najmniej przewidywalnych i stabilnych programów dostarczanych z systemem Linux. Potrafi zawiesić się bez żadnej widocznej przyczyny, zdarza mu się również wyświetlać błędne informacje o statusie drukarki. Czasem jedyną drogą naprawienia zepsutego w jakiś sposób systemu drukowania jest zresetowanie kompute-ra. Program lpc wywołany bez żadnych argumentów oczekuje na wydanie polecenia. Poniżej przedstawiamy kilka poleceń tego programu wraz z ich argumentami.
- abort nazwa_drukarki | all Powoduje natychmiastowe wstrzymanie drukowa-nia przez drukarkę o określonej nazwie (lub wszystkie drukarki, jeśli jego pa-rametrem jest słowo all). Przerwane zadania drukowania są wstawiane po-nownie do kolejki po uruchomieniu drukarki. Poza tym polecenie to działa podobnie do polecenia stop.
- clean nazwa_drukarki | all Usuwa wszystkie zadania drukowania, włącznie z aktywnymi. Często zdarza się jednak, że dokument, którego drukowanie się już rozpoczęło, drukowany jest do końca, ponieważ został już przesłany do programu lpd lub bufora drukarki. Jeśli użyty zostanie parametr all, wy-czyszczone zostaną kolejki wszystkich drukarek.
- disable nazwa_drukarki | all Wyłącza kolejkowanie zadań. Wszystkie zadania oczekujące na wydruk zostaną obsłużone, ale nowe zadania nie będą przyj-mowane - użytkownik próbujący wydrukować coś za pomocą takiej drukarki otrzyma komunikat informujący o tym, że drukarka jest wyłączona i zlecenie nie zostało przyjęte. Wyłączanie i włączanie kolejkowania sprowadza się do zmiany zawartości pliku lock.

- down nazwa_drukarki wiadomość To polecenie używane jest do całkowitego odłączenia drukarki. Jeśli dołączona jest wiadomość (o dowolnej długości), zostanie ona zapisana w pliku statusu drukarki (o nazwie status), dzięki czemu będzie wyświetlana przy próbach drukowania. Polecenia down używa się zwykle wtedy, gdy występują jakieś poważniejsze problemy z drukarką i będzie ona odłączona przez więcej niż jeden dzień.
- enable nazwa_drukarki | all Załącza kolejkowanie zadań dla danej drukarki lub wszystkich drukarek.
- exit Zakończenie pracy programu (polecenie to działa tak samo, jak polecenie quit).
- help lub ? Wyświetlenie listy wszystkich dostępnych poleceń. Jeśli jako argu-ment tego polecenia podana zostanie nazwa innego polecenia, wyświetlona zostanie krótka informacja na jego temat (np. help abort).
- quit Zakończenie pracy programu lpc (polecenie to działa tak samo jak po-lecenie exit).
- restart nazwa_drukarki | all Zrestartowanie rezydentnego programu obsługi drukarki. Używane zwykle, gdy program ten zakończy pracę bez wyraźnej przyczyny (co się czasem zdarza). Jeśli podany zostanie argument all, restar-towane są wszystkie programy obsługi drukarek.
- start nazwa_drukarki Polecenie to powoduje uruchomienie drukarki, pozwa-lając na wydrukowanie oczekujących dokumentów, oraz uruchomienie pro-gramu obsługującego kolejkowanie dla danej drukarki.
- status nazwa_drukarki Wyświetlenie nazwy drukarki, informacji o tym, czy kolejkowanie jest włączone, czy włączone jest drukowanie, liczby oczekują-cych dokumentów oraz statusu programu rezydentnego obsługującego dru-karkę. Jeśli w kolejce nie ma żadnych dokumentów, nie będą działać również programy rezydentne. Jeśli jednak program rezydentny nie działa mimo tego, że w kolejce oczekują na wydrukowanie jakieś dokumenty, należy go zrestar-tować (za pomocą polecenia restart).
- stop nazwa_drukarki Polecenie to powoduje zatrzymanie drukarki. Zadania drukowania są nadal kolejkowane, ale nie są drukowane. Jeśli rozpoczęto drukowanie dokumentu, zostanie ono dokończone. Polecenia start i stop powodują zmianę zawartości pliku lock w katalogu kolejki. Polecenie stop powoduje również zakończenie działania rezydentnego programu obsługi ko-lejkowania.
- topq nazwa_drukarki id_zadania Powoduje przesunięcie zadania drukowania o identyfikatorze id_zadania na początek kolejki.
- topq nazwa_drukarki id_użytkownika Przesunięcie wszystkich zadań, któ-rych właścicielem jest użytkownik o danym identyfikatorze, na początek ko-lejki (polecenie bardzo przydatne dla administratorów, którzy nie mają czasu czekać!).
- up nazwa_drukarki Używane do ponownego przyłączenia odłączonej pole-ceniem down drukarki.
Program lpc nie jest szczególnie przyjazny dla użytkownika, ale jego użycie jest w za-sadzie jedyną metodą zarządzania drukarkami i ich kolejkami w Linuxie. Zadania te mogą nieco ułatwić różne nakładki na ten program.
Zarządzanie kolejkami drukowania za pomocą programów lpq i lprm
Zamiast korzystać z programu lpc można czasem użyć innych, bardziej wyspecjali-zowanych poleceń. Najczęściej potrzebne są tylko dwa polecenia: jedno do wyświetla-nia zawartości kolejki i drugie, pozwalające usunąć z niej konkretne zadanie. Za pomocą polecenia lpq można uzyskać informacje o zleceniach oczekujących na wydrukowanie. Składnia tego polecenia jest następująca:
lpq [-l] [-Pnazwa_drukarki] [id_zadania ...] [id_użytkownika ...]
Jeśli program lpq zostanie uruchomiony bez żadnych argumentów, wyświetli infor-macje o kolejce aktywnej drukarki, takie jak identyfikator właściciela zlecenia, pozy-cję zadania w kolejce, nazwy plików, które oczekują na wydrukowanie i ich suma-ryczny rozmiar. Podając opcję -l, można uzyskać dodatkowe informacje o każdym zleceniu wydruku. Jeśli potrzebne są informacje dotyczące innej drukarki, należy podać jej nazwę po op-cji -P. Jeśli podany zostanie identyfikator zlecenia, wyświetlane będą tylko informacje go dotyczące, natomiast jeśli podany zostanie identyfikator użytkownika - wyświetlo-ne zostaną dane o wszystkich zleceniach, których jest on właścicielem. Ponieważ użytkownicy nie mają dostępu do katalogów kolejki, jedyną me-todą na anulowanie zlecenia drukowania jest użycie polecenia lprm. Jeśli jesteś administratorem systemu, warto od czasu do czasu przypomnieć o tym użytkownikom - dzięki temu mniej będzie "niechcianych" wydruków. Polecenie lprm służy do wycofania z kolejki zlecenia wydruku. Często zdarza się, że przez pomyłkę zamiast polecenia lprm wydawane jest polecenie lpr, które nie powo-duje usunięcia zlecenia z kolejki. Jeśli chcesz wycofać zlecenie drukowania, musisz znać jego identyfikator. Jeśli jesteś zalogowany jako root, możesz również usunąć wszystkie zlecenia. Składnia polecenia lprm jest następująca:
lprm [-Pnazwa_drukarki] [-] [id_zadania ...] [id_użytkowanika]
Argumentem polecenia lprm może również być pojedynczy myślnik - wówczas usu-wane są wszystkie zadania, których właścicielem jest użytkownik wydający polecenie. Jeśli jesteś zalogowany jako root, usunięte zostaną wszystkie zadania. Pliki oczekują-ce na wydrukowanie przez określoną drukarkę można usunąć podając opcję -P, na przykład polecenie:
lprm -Phplj -
powoduje usunięcie wszystkich zadań, których jesteś właścicielem, a które miały być wydrukowane na drukarce o nazwie hplj. Jeśli jesteś zalogowany jako root, łatwo usunąć przypadkowo wszystkie zadania drukowania. Uważaj więc, by nie popełnić jakiegoś błędu składniowego! Podanie identyfikatora zlecenia lub użytkownika powoduje usunięcie z kolejki okre-ślonego zlecenia lub wszystkich zleceń należących do określonego użytkownika. Jeśli nie zostaną podane żadne argumenty, usunięte zostanie zlecenie aktywne, którego właścicielem jest użytkownik wydający polecenie. Po wycofaniu zlecenia lprm wyświetla na ekranie krótki komunikat, ale jeśli danego pliku nie ma w kolejce, nic nie zostanie wyświetlone (i będziesz się pewno zastanawiał, co się właściwie stało). Jeśli użyjesz polecenia lprm z identyfikatorem zlecenia, które jest właśnie obsługiwa-ne, może zdarzyć się, że albo zostanie ono wydrukowane do końca (jeśli zostało już przesłane do bufora drukarki), albo przerwane. W drugim przypadku zdarzyć się może, że drukarka przestanie odpowiadać. Wtedy trzeba znaleźć identyfikator procesu ob-sługującego filtr wyjściowy (za pomocą polecenia ps) i zakończyć jego działanie. Jeśli drukarka przestanie odpowiadać i nie da się rozwiązać tego problemu za pomocą polecenia lpc, spróbuj zrestartować program lpd. Jeśli nawet to nie pomaga, prawdopodobnie jedynym rozwiązaniem będzie ponowne uruchomienie systemu.
Terminale
Większość systemów linuxowych korzysta tylko z jednej konsoli (klawiatury i ekranu komputera, w którym zainstalowany jest system). W takim przypadku nie są potrzeb-ne żadne dodatkowe zabiegi konfiguracyjne. Niektórzy administratorzy chcą jednak dodać kilka terminali tak, by możliwa była równoczesna praca wielu użytkowników (w końcu Linux jest systemem wielodostęp-nym). Można to zrobić na dwa sposoby: podłączając terminale do portu szeregowego z tyłu komputera lub do portu znajdującego się na karcie multiport.
Używanie kart multiport
Karty multiport to łatwy i efektywny sposób na dodanie do systemu wielu portów sze-regowych. Karty te dostarczane są przez wielu producentów w przeróżnych konfigura-cjach. Udostępniają od 2 do 32 dodatkowych portów szeregowych, mogą również wy-korzystywać różne typy gniazd (DB25, DB9 czy RJ11). Jeśli zamierzasz używać karty multiport, upewnij się najpierw, czy dostępne są dla niej sterowniki linuxowe. Nie można użyć bez modyfikacji wersji sterowników dla UNIX-a czy Xenix-a. Ze względu na ich złożoność, modyfikacja kodu źródłowego jest jednak poza możliwościami zwykłego śmiertelnika. Wraz z kartami multiport dostarczane są kompletne instrukcje dotyczące ich instalo-wania i konfigurowania terminali. Szczegóły tych operacji są zależne od sprzętu, dlate-go nie będziemy się nimi zajmować.
Dodawanie terminali podłączonych przez port szeregowy
Aby dodać do systemu terminal, możesz również wykorzystać port szeregowy zamon-towany w komputerze PC. Funkcję terminalu może pełnić prawdziwy terminal lub też inny komputer PC z działającym emulatorem terminalu. Rodzaj kabla łączącego terminal z komputerem PC zależy od gniazd zamontowanych w obu urządzeniach. W większości przypadków jest to kabel DTE-to-DTE (ang. Data Terminal Equipment), ale czasem wymagany jest kabel DCE (ang. Data Communica-tion Equipment). Ogólnie rzecz biorąc, terminale i inne komputery wymagają kabla DTE, natomiast modemy - DCE (kable DCE i DTE różnią się połączeniami). Kabel łączący terminal z komputerem powinien być typu null-modem (niektóre prze-wody są w nim skrzyżowane, inne zwarte). Działać poprawnie będzie już kabel trójży-łowy (sygnały send, receive i masa), choć Linux wykorzystuje również sygnał Carrier Detect do sprawdzania, czy terminal jest podłączony i aktywny. Kabel DCE (używany np. do podłączenia modemu - dlatego nazywany czasem ka-blem modemowym) łączy dwa gniazda bezpośrednio, tzn. styk nr 1 w jednej wtyczce odpowiada nr 1 w drugiej itd. Ważniejsze dla funkcjonowania połączenia DTE-to-DTE przewody.
Ponieważ większość użytkowników woli używać gotowych kabli, nie będziemy wda-wać się w szczegóły dotyczące ich montażu. Zamiast tego lepiej udać się do najbliż-szego sklepu komputerowego i wyjaśnić, jaki sprzęt chcemy połączyć, jaka jest wiel-kość (9 lub 25 styków) i rodzaj (męski - gdy na zewnątrz gniazda wystają styki, czy żeński - gdy nie ma styków) złącza. Jeśli nie jesteś pewien, czy powinieneś użyć kabla modemowego, czy null-modem, warto zaopatrzyć się w przejściówkę, w której następuje skrzyżo-wanie odpowiednich linii. Urządzenie takie zamienia więc kabel modemo-wy na null-modem i odwrotnie.
Proces logowania
Aby zrozumieć, jakie dane zawierają pliki używane do konfigurowania terminali, war-to najpierw zapoznać się z procesem logowania. Proces ten rozpoczyna się od uruchomienia programu /etc/init podczas uruchamiania systemu. Program init jest odpowiedzialny za uruchomienie procesu /etc/getty dla każdego terminalu podłączonego do systemu. Dane o tych termina-lach muszą być wpisane do plików /etc/ttys i /etc/inittab. Plik /etc/ttys za-wiera listę portów i typów terminali, które są do nich podłączone. W pliku /etc/inittab zapisana jest pełna lista terminali, wraz z wszystkimi ich parametrami. Obu tym plikom przyjrzymy się dokładniej nieco później, w podrozdziale "Pliki konfi-guracyjne terminalu: /etc/ttys i /etc/inittab". Jeśli z danych zapisanych w tych plikach wynika, że do danego portu podłączony jest terminal, proces init uruchamia dla niego proces /etc/getty, ustawiający parame-try komunikacji i wyświetlający komunikat login:. Gdy użytkownik loguje się używając określonego terminalu, proces getty wywołuje program login, który pobiera hasło. Program ten następnie sprawdza, czy identyfika-tor użytkownika i hasło są poprawne (na podstawie danych zawartych w pliku /etc/passwd); jeśli tak - wyświetlana jest zawartość pliku /etc/motd, a następnie uruchamiany jest domyślny dla danego użytkownika interpreter poleceń (również określony w pliku /etc/passwd). Na koniec ustawiana jest wartość zmiennej TERM i program login kończy działanie. Po zakończeniu logowania interpreter poleceń działa dalej, odczytując zawartość plików konfiguracyjnych, a następnie wyświetla znak zachęty i czeka na działania użyt-kownika. Jak widać, w proces logowania zamieszanych jest całkiem sporo plików przechowywanych w katalogu /etc. Przyjrzyjmy się najważniejszym z nich (z punktu widzenia konfiguracji terminalu).
/sbin/getty i /etc/gettydefs
Wzmianki o programie /sbin/getty (w niektórych systemach /etc/getty) poja-wiają się przy omawianiu problemów dotyczących terminali dość często, ale niewielu użytkowników zdaje sobie dokładnie sprawę z funkcji spełnianych przez ten program. Służy on generalnie do ustawiania parametrów transmisji danych pomiędzy termina-lem a systemem, takich jak prędkość, protokół itp. Program /sbin/getty wywoływany jest przez proces /etc/init. Po uruchomieniu otwiera on połączenie przez port szeregowy czy inny port, do którego podłączony jest terminal, a następnie ustawia parametry transmisji danych do i z terminalu zgodnie z informacjami zawartymi w pliku /etc/gettydefs. Następnie do terminalu wysyłany jest komunikat login:. Proces getty umożliwia podanie w wierszu poleceń wielu modyfikujących jego za-chowanie opcji, ale większość z nich nie jest szczególnie interesująca. Jeśli chcesz uzy-skać pełniejsze informacje na temat składni tego polecenia, zajrzyj do dokumentacji na stronach man. Plik /etc/gettydefs, zawierający parametry terminali używane przez program getty, składa się z wierszy o następującym formacie:
etykieta#parametry_startowe#parametry_końcowe#komunikat_login#następna_
ĺetykieta
etykieta powinna być unikalna, ponieważ na jej podstawie poszczególne wpisy są rozróżniane. parametry_startowe i parametry_końcowe pozwalają na kontrolo-wanie zachowania połączenia przed i po wykonaniu programu login. komunikat_login to tekst, który zostanie wyświetlony na ekranie terminalu. Zwykle ma on postać login:, ale można zażądać wyświetlania dowolnego tekstu. następna_etykieta to etykieta wpisu, do którego należy przejść, gdyby użycie usta-wień z wiersza bieżącego się nie powiodło. Takie rozwiązanie przydaje się przy połą-czeniach modemowych - próby nawiązania połączenia rozpoczyna się od najwięk-szych prędkości przesyłu danych (np. 9600 bodów), stopniowo zmniejszając prędkość (poprzez 4800 i 2400 do 1200 bodów), aż do nawiązania połączenia. Dla terminali po-le następna_etykieta wskazuje zwykle z powrotem na początek pliku. Przykładowy fragment tego pliku może mieć następującą postać:
console# B19200 OPOST ONCLR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY PARENB ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # B19200 OPOST ONCLR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY PARENB ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD #Console Login: #console
9600H# B9600 # B9600 SANE IXANY PARENB TAB3 HUPCL #Login: #4800H
4800H# B4800 # B4800 SANE IXANY PARENB TAB3 HUPCL #Login: #2400H
2400H# B2400 # B2400 SANE IXANY PARENB TAB3 HUPCL #Login: #1200H
1200H# B1200 # B1200 SANE IXANY PARENB TAB3 HUPCL #Login: #300H
300H# B300 # B300 SANE IXANY PARENB TAB3 HUPCL #Login: #9600H
Jeśli zajrzysz do pliku gettydefs znajdującego się w Twoim systemie, znajdziesz jeszcze wiele innych wpisów, ale wszystkie one mają taki sam format, jak przedstawione w przykładzie. Pięć ostatnich wierszy dotyczy połączeń modemowych; pierwszy z nich definiuje parametry połączenia przy prędkości 9600 bodów. Jedyny parametr startowy - B9600 - ustawia prędkość transmisji na 9600 bodów. Parametry końcowe określają zachowanie terminalu (na przykład powodują zastępowanie znaku tabulacji trzema spacjami). Wskaźnik do następnego wpisu prowadzi do połączenia z niższą prędkością przesyłania danych, co umożliwia połączenie z wolniejszymi modemami lub poprzez łącza słabej jakości. Pierwszy wiersz przykładu jest typowy dla wszystkich systemów - opisuje on zacho-wanie się konsoli "systemowej", czyli klawiatury i ekranu podłączonych bezpośrednio do komputera. Ponieważ są one podłączone na stałe, wskaźnik na następny wpis jest ustawiony tak, że następuje zapętlenie. Nie powinieneś raczej zmieniać ustawień w pliku gettydefs - o wiele łatwiej jest poszukać takiego wpisu, który odpowiada typowi terminalu, którego chcesz użyć. Jeśli jednak zmodyfikujesz jego zawartość, powinie-neś wydać polecenie getty -c, aby uaktywnić wprowadzone modyfi-kacje.
Pliki konfiguracyjne terminala: /etc/ttys i /etc/inittab
Dane o konfiguracji terminalu zapisane są w plikach /etc/ttys i /etc/inittab. Pliki te mogą być modyfikowane za pomocą dowolnego edytora tekstów. Dostępne są również programy pozwalające modyfikować te pliki w wygodniejszy sposób (np. za pomocą menu). Przed dokonaniem jakichkolwiek zmian w plikach konfiguracyjnych ter-minalu zrób ich kopię na wypadek, gdyby zmiany nie przyniosły oczeki-wanych efektów. W tym celu wystarczy skopiować te pliki do plików o na-zwach na przykład /etc/ttys.org i /etc/inittab.org. Plik /etc/ttys zawiera dwie kolumny danych. Pierwsza z nich określa typ terminalu, natomiast druga - nazwę urządzenia. Oto przykładowa zawartość takiego pliku:
console tty1
console tty2
console tty3
console tty4
console tty5
console tty6
vt100 ttyp0
vt100 ttyp1
vt100 ttyp2
vt100 ttyp3
Typ terminalu w pierwszej kolumnie jest używany przy ustawianiu wartości zmiennej środowiskowej TERM. Plik /etc/inittab zawiera informacje dotyczące zachowania każdego terminala. Je-go format jest następujący:
ID:runlevel:akcja:proces
ID to jedno lub dwuznakowy identyfikator, inny dla każdego wpisu. W większości przypadków odpowiada on w jakiś sposób nazwie urządzenia, np. identyfikator 1 może określać terminal tty1 itp. Parametr runlevel określa możliwości terminalu w różnych stanach systemu opera-cyjnego (może on przybierać wartości od 0 do 6 oraz A, B i C, jak również kombinacje tych wartości). Jeśli żadna wartość nie zostanie podana, obsługiwane będą wszystkie stany systemu. Zawartość pola akcja decyduje o tym, w jaki sposób obsłużyć następne pole (proces). Dostępne wartości to:
boot    uruchomienie przy pierwszym odczytaniu pliku inittab;
bootwait    uruchomienie przy pierwszym odczytaniu pliku inittab;
initdefault    ustawienie domyślnego stanu systemu (runlevel);
off    wyłączenie procesu, jeśli jest on aktywny;
once    jednokrotne uruchomienie procesu;
ondemand    uruchomienie procesu działającego przez cały czas (to samo co respawn);
powerfail    wykonanie gdy init otrzyma sygnał o awarii zasilania;
powerwait    wykonanie gdy init otrzyma sygnał o oczekiwaniu na zasilania;
sysinit    uruchomienie przed uzyskaniem dostępu do konsoli;
respawn    uruchomienie procesu działającego przez cały czas;
wait    jednokrotne uruchomienie procesu.
Pole akcja pozwala określić zachowanie terminalu podczas uruchamiania systemu i wtedy, gdy zostanie zakończony obsługujący go proces getty. Przykładowy plik /etc/inittab (zaczerpnięty co prawda z wcześniejszej wersji Linuxa, ponieważ w nowszych wersjach plik ten jest nieco bardziej skomplikowany) wyglą-da następująco:
#inittab for Linux
id:1:initdefault:
rc::bootwait:/etc/rc
1:1:respawn:/etc/getty 9600 tty1
2:1:respawn:/etc/getty 9600 tty2
3:1:respawn:/etc/getty 9600 tty3
4:1:respawn:/etc/getty 9600 tty4
Pierwsze dwa wiersze (po komentarzu) są używane podczas uruchamiania systemu. Drugi z nich nakazuje uruchomienie skryptu /etc/rc. Pozostałe powodują urucho-mienie procesów getty dla konsol od tty1 do tty4 z prędkością 9600 bodów.
Definicje terminali - plik /etc/termcap
Plik /etc/termcap (ang. terminal capabilities) zawiera instrukcje dotyczące komuni-kacji z większością typów terminali obsługiwanych przez system, w związku z tym jest on dość duży. Jeśli zamierzasz modyfikować ten plik, powinieneś najpierw wykonać jego kopię zapasową. Zawartość pliku termcap jest podobna do zawartości pliku /etc/printcap,w któ-rym znajdują się dane o poszczególnych typach drukarek. Każdy wpis określa kilka wariantów nazwy urządzenia oraz zestaw parametrów i odpowiadających im wartości odpowiednich dla różnych typów terminali. Ze względu na fakt, że niektóre bardziej rozbudowane terminale potrafią interpretować cały szereg symboli sterujących, po-szczególne wpisy mogą być dość obszerne. Przykładowe definicje prostych typów terminali - Vi550 i Vi603 - mogą mieć następującą postać:
vi550|visual 550 ansi x3.64:\
:li#33:\
:cl=\030\E[H\E[2J:tc=vi300:
vi603|visual603|visual 603:\
:hs:mi:\
:al=\E[L:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[J:\
:cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:dc=\E[P:dl=\E[M:\
:ds=\EP2;1~\E\\:ei=\E[4l:fs=\E\\:\
:i1=\E>\E[?3l\E[?4l\E[?7h\E[?8h\E[1;24r:im=\E[4h:\
:mb=\E[5m:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:\
:se=\E[27m:sf=\ED:so=\E[7m:sr=\EM:ts=\EP2~:ue=\E[24m:\
:up=\E[A:us=\E[4m:tc=vt100:
Znaczenie poszczególnych kodów nie jest zwykle przedmiotem zainteresowania prze-ciętnego użytkownika czy administratora systemu linuxowego. Informacje takie mogą być potrzebne dopiero wtedy, gdy trzeba skonfigurować nowy (nie obsługiwany przez system) typ terminalu. Charakterystyki terminali zawarte w pliku /etc/termcap są używane przez plik /etc/ttys. Pierwsza kolumna pliku /etc/ttys zawiera nazwę terminalu, na podsta-wie której ustalana jest wartość zmiennej środowiskowej TERM. Dokładniejsze dane o parametrach terminalu odczytywane są z pliku /etc/termcap poprzez odszukanie wpisu odpowiadającego danej nazwie terminalu. Większość terminali może emulować kilka różnych standardów. Jeśli nie potrafisz znaleźć w pliku /etc/termcap wpisu odpowiedniego dla terminalu, który chcesz podłączyć, poszukaj wpisu dla jednego z emulowanych typów terminali. Jest to na pewno rozwiązanie prostsze niż stworzenie nowego wpisu.
Dodawanie terminalu
Terminal można dodać do systemu linuxowego w taki sam sposób jak drukarkę - za pomocą polecenia mknod. Najpierw należy zdecydować, do którego portu będzie on podłączony. Porty szeregowe mają nazwy takie jak /dev/ttyS0 (port określany w systemie DOS jako COM1), /dev/ttyS1 (w systemie DOS - COM2) itd. Większość komputerów klasy PC wyposażona jest w dwa porty szeregowe, choć moż-liwe jest podłączenie dodatkowych dwóch (czyli od /dev/ttyS0 do /dev/ttyS3). Linux używa portów szeregowych w oparciu o ich adresy podawane przez BIOS. Zwy-kle są to następujące wartości:
ttyS0 (COM1) 0x03f8
ttyS1 (COM2) 0x02f8
ttyS2 (COM3) 0x03e8
ttyS3 (COM4) 0x02e8
Jeśli w systemie dostępny jest tylko jeden port szeregowy, prawie zawsze jest on skon-figurowany jako COM1. Jeżeli nie jesteś pewny ustawień w Twoim systemie, możesz sprawdzić odpowiednie wartości za pomocą jakiegoś programu użytkowego (np. MSD.EXE dla systemu DOS) lub po prostu ustalić je metodą prób i błędów, zaczynając od najniższych wartości. Aby utworzyć nowe urządzenie terminalu, trzeba użyć polecenia mknod (ang. make node; polecenie to opisane jest bardziej szczegółowo w podrozdziale "Polecenie mknod"), a następnie zmienić prawa dostępu do nowego pliku urządzenia tak, by mógł on być czytany i zapisywany przez użytkownika root lub daemqn. W większości sys-temów odpowiednie pliki urządzeń są konfigurowane już podczas instalacji. Polecenie, które należy wydać, aby utworzyć plik terminalu, ma postać:
mknod -m 660 /dev/ttyS0 c 4 64
Parametr -m 660 ustala odpowiednie prawa dostępu do pliku. /dev/ttyS0 to okre-ślenie portu szeregowego, odpowiadającego DOS-owemu portowi COM1. Parametr c określa, że urządzenie jest typu znakowego (większość terminali, za wyjątkiem bardzo szybkich modeli, pracuje jako urządzenia znakowe), a następujące po nim liczby defi-niują główny i poboczny numer urządzenia (w tym przypadku odpowiednio 4 i 64). Po-lecenia tworzące pliki urządzeń dla portów COM2 - COM4 miałyby postać:
mknod -m 660 /dev/ttyS1 c 4 65
mknod -m 660 /dev/ttyS2 c 4 66
mknod -m 660 /dev/ttyS3 c 4 67
Po wykonaniu polecenia mknod należy jeszcze zmienić identyfikator właściciela pliku, na przykład wydając polecenie
chown root.tty /dev/ttyS0
podstawiając za /dev/ttyS0 nazwę pliku urządzenia, do którego polecenie ma się odnosić. Właścicielem pliku będzie użytkownik root.tty. Należy również zmodyfi-kować odpowiednie wpisy w pliku /etc/ttys, ustawiając typ terminalu tak, aby proces jego inicjalizacji mógł przebiegać poprawnie. Plik /etc/inittab zawiera wpisy dla stan-dardowych portów szeregowych, możesz więc użyć ich jako szablonu i dopasować prędkość transmisji i inne parametry.
Polecenia stty oraz tset
Polecenie stty pozwala sprawdzić i ustawić opcje dotyczące obsługi terminalu. Jest ono bardzo złożone, posiada kilkadziesiąt różnych opcji modyfikujących działanie sterownika terminalu. Na szczęście tylko przy wyjątkowo "intensywnej" administracji będziesz musiał ich używać, więc w tym rozdziale po prostu zignorujemy większość szczegółów. Aby sprawdzić aktualne ustawienia terminalu, wystarczy wydać polecenie stty bez żadnych parametrów. Dzięki temu można zweryfikować, czy informacje zapisane w plikach konfiguracyjnych /etc/inittab i /etc/gettydefs zostały poprawnie od-czytane. Polecenie tset również jest dość skomplikowane, ale większość jego opcji używana jest bardzo rzadko (szczególnie jeśli nie masz do czynienia z jakimiś przedpotopowymi terminalami i niestandardowymi łączówkami). Polecenie to służy do inicjalizowania sterownika terminalu. Jeśli nazwa urządzenia nie zostanie określona jawnie jako pa-rametr tego polecenia, użyta zostanie nazwa wskazywana przez zmienną środowisko-wą TERM. Polecenie tset może zostać zapisane w jednym z plików inicjalizacyjnych przetwa-rzanych podczas logowania. Przykładowo użytkownik, który zawsze loguje się przez modem, może w pliku inicjalizacyjnym (.profile, .cshrc itp.) wpisać polecenie
tset -m dialup:vt100
Spowoduje ono ustawienie typu terminalu na vt100 za każdym razem, gdy loguje się on do systemu przez modem. Oczywiście typ terminalu zostanie ustawiony na vt100 nawet wtedy, jeśli w rzeczywistości użytkownik loguje się z terminalu innego rodzaju. Zapobiec takiej sytuacji można stosując polecenie:
tset -m dialup:?vt100
które spowoduje, że system zapyta o potwierdzenie typu terminalu:
TERM=(vt100)?
Po wciśnięciu klawisza Enter typ terminala zostanie ustawiony na vt100, ale możliwe jest również podanie innej wartości. Jak na razie polecenie to nie wygląda na szczególnie skomplikowane. Rogi pokazuje dopiero wtedy, gdy trzeba skonfigurować terminal podłączony na stałe. Przykładowo, jeśli trzeba uruchomić sterownik dla terminalu podłączonego przez port szeregowy, po-stać polecenia może być następująca:
eval `tset -s -Q -m dialup:?vt100 -m switch:z29`
Szczegóły składni tego polecenia nie są istotne dla większości administratorów. Jeśli jednak chcesz uzyskać dokładniejsze informacje na ten temat, zajrzyj na strony man dotyczące poleceń tset i stty.
Resetowanie terminalu
Od czasu do czasu zdarza się, że terminal podłączony przez port szeregowy przestaje zachowywać się poprawnie, bądź to nie wyświetlając znaku zachęty, bądź też wyświe-tlając różne "krzaczki". Istnieją dwa proste sposoby wyjścia z takiej sytuacji. Jeśli jed-nak nie zadziałają, terminal powinien zostać wyłączony, a następnie uruchomiony ponownie (możesz również być zmuszony do wyłączenia procesów uruchomionych z tego terminalu). Pierwszy sposób to wciśnięcie klawiszy Control+j, wpisanie polecenia stty sane, a następnie ponowne wciśnięcie Control+j. Terminal powinien zostać przywrócony do stanu używalności. Prawdopodobnie polecenie, które wpisujesz, nie zostanie wyświe-tlone na ekranie, więc wpisuj je uważnie. Jeśli terminal nadal nie zachowuje się jak należy, spróbuj wpisać reset, a następnie wcisnąć klawisz Enter lub Control+j. Jeśli to również nie pomaga, terminal zawiesił się i musi zostać zresetowany ręcznie.
Modemy
Proces dodawania modemu nie różni się zasadniczo od dodawania terminalu. W więk-szości przypadków można zastosować procedurę omówioną w podrozdziale "Termina-le". Modemy w systemach linuxowych używane są do łączenia się z siecią lub z innym systemem oraz do przyjmowania połączeń przychodzących. Jeśli modem służy do pod-łączenia zdalnego terminalu, procedura jego instalacji jest taka, jak opisano w części "Terminale"; różni się tylko tym, że trzeba wybrać inne wpisy z pliku /etc/inittab. W przypadku modemu należy odszukać blok wpisów określający pa-rametry połączeń z coraz mniejszymi prędkościami przesyłania danych. Jeśli modem ma służyć do łączenia się z innymi systemami, można go skonfigurować używając obsługiwanego za pomocą menu programu, wywoływanego z poziomu pro-gramu setup. Potrafi on automatycznie ustawić większość niezbędnych opcji.

Procesy
Każdy program działający w systemie linuxowym - uruchomiony przez użytkownika, przez systemu, czy też program rezydentny - jest procesem. Umiejętność zarządzania procesami jest dla administratora bardzo istotna (czasem nawet nieodzowna. Przyj-rzymy się bliżej temu problemowi. Nie będziemy oczywiście omawiać szczegółów technicznych przydzielania poszczególnym procesom czasu procesora czy pamięci operacyjnej. Omówimy jednak najważniejsze - z punktu widzenia administratora - zagadnienia, których znajomość jest niezbędna do zapewnienia bezawaryjnej pracy systemu. Przy opisie systemów wielozadaniowych często używa się pojęć proces i zadanie. Czę-sto mogą być one używane zamiennie, ale przez zadanie przeważnie rozumie się pro-ces uruchomiony przez interpreter poleceń (który może również zatrudniać inne proce-sy). Proces jest najmniejszą niepodzielną częścią programu, działającą w systemie Li-nux. Co trzeba wiedzieć o procesach Formalna definicja procesu brzmi: proces to program, który posiada własną wirtualną przestrzeń adresową. Oznacza to, że każdy program działający w systemie linuxowym jest procesem. Pojedyncze polecenie może uruchamiać wiele różnych procesów, szcze-gólnie jeśli użyty zostanie mechanizm przekierowania czy potoków (ang. pipe). Poniż-sze polecenie powoduje uruchomienie trzech procesów, po jednym dla każdego wywo-ływanego programu:
nroff -man ps.1 | grep kill | more
Typy procesów
W systemie Linux rozróżniane są trzy rodzaje procesów, posiadające nieco inne cechy i atrybuty. Są to:
- procesy interaktywne - uruchamiane poprzez powłokę i przez nią kontrolowa-ne; procesy takie mogą działać w tle lub na pierwszym planie;
- procesy wsadowe (ang. batch process), nie powiązane z żadnym terminalem, ale wstawiane do kolejki i wykonywane sekwencyjnie;
- procesy rezydentne - czyli demony (ang. daemons); są one zwykle uruchamia-ne podczas startu systemu i pracują w tle przez cały czas działania Linuxa.
Użycie polecenia ps
Najprostszym sposobem na sprawdzenie, jakie procesy działają aktualnie w systemie, jest użycie polecenia ps (ang. process status). Udostępnia ono sporo różnego typu op-cji, ale tylko kilka z nich wykorzystuje się w praktyce. Rozpoczniemy od przedstawie-nia najbardziej podstawowych informacji o tym poleceniu, a następnie omówimy nie-które z jego opcji. Polecenie ps jest dostępne dla wszystkich użytkowników systemu, ale dla użytkowni-ka root wyniki jego działania mogą być nieco inne niż dla zwykłego użytkownika. Jeśli jesteś zalogowany jako zwyczajny użytkownik (tj. nie jako root) i wydasz pole-cenie ps, wyświetlone zostaną informacje o wszystkich procesach, których jesteś wła-ścicielem. Możesz na przykład zobaczyć następujące dane:
$ ps
PID   TTY   STAT   TIME   COMMAND
229   2   S   0:00   /bin/login -- reksio
257   2   S   0:00   -bash
269    2   R   0:00    ps
Dane wyświetlane przez program ps
Dane wyświetlane przez program ps zawsze podawane są w kolumnach. Pierwsza ko-lumna ma nagłówek PID (ang. Process ID) i zawiera identyfikator procesu. Każdemu procesowi działającemu w systemie przypisany jest niepowtarzalny numer, dzięki któ-remu Linux może odróżnić go od innych procesów. Numerowanie procesów rozpoczy-na się od zera po uruchomieniu Linuxa, a maksymalna dopuszczalna wartość zależy od systemu (często jest to 65535). Po przekroczeniu wartości maksymalnej numero-wanie znów zaczyna się od zera, z pominięciem tych numerów, które zostały przydzie-lone wciąż aktywnym procesom. Zwykle najniższe numery przydzielone są procesom wchodzącym w skład jądra systemu i programom rezydentnym (demonom), urucha-mianym podczas startu systemu. Jeśli chcesz zrobić cokolwiek z procesem (na przy-kład zakończyć jego działanie), musisz znać jego identyfikator. Kolumna opisana jako TTY zawiera informację o tym, z której konsoli dany proces zo-stał uruchomiony. Jeśli jesteś zalogowany jako zwykły użytkownik, będzie to nazwa Twojego terminalu lub konsoli. Jeżeli jesteś zalogowany na kilku konsolach, zobaczysz dane o procesach uruchomionych na wszystkich konsolach. W kolumnie STAT znajduje się informacja o bieżącym stanie procesu. Najczęściej po-jawiają się tu litery S (ang. sleeping - proces uśpiony) i R (ang. running - aktywny). Stan procesu może zmieniać się z uśpionego na aktywny i odwrotnie wiele razy w ciągu sekundy. Kolumna TIME zawiera całkowitą ilość czasu procesora użytego przez proces do tej po-ry. Zwykle jest to wartość bardzo mała (większość procesów wykonuje się dość szyb-ko). Jest to czas, przez jaki proces miał dostęp do procesora, a nie czas, który upłynął od momentu jego uruchomienia. Ostatnia kolumna - COMMAND - zawiera polecenie, za pomocą którego proces został uruchomiony. Przeważnie jest to polecenie wpisane przez użytkownika z klawiatury terminalu, jednak ps na równych prawach traktuje też procesy wywołane przez inne procesy (nazywane procesami potomnymi - ang. child processes). Interpretery poleceń uruchamiane przy logowaniu Aby pomóc Ci odróżnić interpreter, który został uruchomiony podczas logowania, od pozostałych (uruchomionych później), jego nazwa poprzedzona jest myślnikiem, na przykład tak:
$ ps
PID   TTY   STAT   TIME   COMMAND
46   v01   S   0:01   -bash
75   v01   S   0:00   pdksh
96   v01   R   0:00   bash
123   v01   R   0:00   ps
W powyższym przykładzie widać, że interpreter poleceń o identyfikatorze 46 urucho-miony został przy logowaniu, natomiast inne interpretery (o identyfikatorach 75 i 96) zostały uruchomione później. Zauważ, że na liście procesów zawsze znajduje się polecenie ps; jest to oczywiste, jeśli wziąć pod uwagę fakt, że polecenie to było uruchomione w trakcie swojego działania.
Uwagi dla użytkownika root
Kiedy zwykły użytkownik wydaje polecenie ps, uzyskuje listę własnych procesów. Jeśli jesteś zalogowany jako root, zobaczysz w takiej sytuacji listę wszystkich procesów w systemie, ponieważ root jest właścicielem ich wszystkich. Lista taka może być bar-dzo długa, szczególnie w systemach, w których pracuje jednocześnie kilku użytkowni-ków. Powinieneś więc skierować ją do pliku albo na wejście polecenia more lub less, na przykład za pomocą jednego z poleceń:
ps | more
ps > /tmp/ps_out
Przydatne opcje programu ps
Po dołączeniu do polecenia ps opcji u uzyskujemy kilka nowych informacji. Oto wy-nik wykonania takiego polecenia przez zwykłego użytkownika:
$ ps u
USER   PID   %CPU   %MEM   SIZE   RSS   TTY   STAT   START   TIME   COMMAND
bill   281   0.2   3.0   1492   948   2   S   18:25   0:00   /bin/login -- ĺbill
bill   284   0.2   2.4   1180   768   2   S   18:26   0:00   -bash
bill   298   0.0   1.5   856   488   2   R   18:26   0:00   ps u
Najważniejsza nowość to kolumna USER, która pokazuje, kto uruchomił i posiada da-ny proces. Zamiast numerycznego identyfikatora użytkownika wyświetlany jest od-powiadający mu identyfikator tekstowy, odszukany przez polecenie ps w pliku /etc/passwd. Opcja u powoduje również wyświetlenie kolumn zawierających dane o procentowym zużyciu czasu procesora (kolumna %CPU) i pamięci (kolumna %MEM). Dane te mogą być użyteczne w przypadku, gdy z nieznanych bliżej powodów system zwolni działa-nie. Można wówczas odszukać "winowajcę" (w języku angielskim procesy konsumu-jące nadmierne ilości zasobów zwane są "memory hogs" i "CPU hogs") i sprawdzić, czy przypadkiem nie jest to proces, który wymknął się spod kontroli i pochłania zaso-by systemowe. Kiedy wydasz polecenie ps u, będąc zalogowany jako root, zobaczysz listę wszystkich procesów działających w systemie. Podobnie jak poprzednio, może zajść konieczność przesłania wyników polecenia do pliku lub na wejście programu more. W niektórych wersjach Linuxa po opcji u można również podać identyfikator użytkownika, co spo-woduje wyświetlenie tylko procesów do niego należących, na przykład:
ps u bill
Ta składnia polecenia ps jest dozwolona w wersjach dostarczanych wraz z System V, ale nie działa w większości rozprowadzanych z Linuxem wersji programu ps opartych o BSD (w tym w wersji dostępnej na załączonym do książki dysku CD). Inne wersje te-go polecenia dostępne są w węzłach FTP i BBS. Większość użytkowników może rów-nież użyć opcji u aby zobaczyć listę procesów uruchomionych przez innych użytkow-ników. Dzięki temu można sprawdzić, kto uruchamia procesy pochłaniające najwięcej zasobów, a administrator może łatwo zorientować się, jakie procesy uruchamiał użyt-kownik zgłaszający problemy z systemem. Zwykły użytkownik może również zobaczyć listę wszystkich procesów działających w systemie (a nie tylko procesów uruchomionych przez siebie), używając opcji a (jeśli zastosujesz tę opcję, gdy jesteś zalogowany jako root, wyświetlana lista oczywiście nie zmieni się). Oto przykładowy wynik działania polecenia ps a wydanego przez zwykłego użytkownika:
$ ps a
PID   TTY   STAT   TIME   COMMAND
228   1   S   0:00   /bin/login -- root
230   3   S   0:00   /sbin/mingetty tty3
231   4   S   0:00   /sbin/mingetty tty4
232   5   S   0:00   /sbin/mingetty tty5
233   6   S   0:00   /sbin/mingetty tty6
236   1   S   0:00   -bash
248   1   S   0:12   /usr/bin/mc -P
250   p0   S   0:00   bash -rcfile .bashrc
281   2   S   0:00   /bin/login -- bill
284   2   S   0:00   -bash
300   2   R   0:00   ps a
Tak krótki wydruk pochodzi z systemu, w którym w zasadzie nic się nie dzieje. Większość pozycji opisuje procesy systemowe. W powyższym przypadku nie można okre-ślić, kto uruchomił dany proces - ale można połączyć opcje a oraz u: $ ps au
USER   PID   %CPU   %MEM   SIZE   RSS   TTY   STAT   START   TIME   COMMAND
bill   281   0.1    3.0   1492   948   2   S    18:25   0:00   /bin/login -- ĺbill
bill   284   0.1   2.4   1180   768   2   S   18:26   0:00    -bash
bill   302   0.0   1.5   856   492    2   R   18:27   0:00   ps au
root   228   0.0   3.0   1496    952   1   S   18:18   0:00   /bin/login -- ĺroot
root   230   0.0   1.0   740   316    3   S   18:18    0:00   /sbin/mingetty ĺtty3
root   231   0.0   1.0   740   316   4   S   18:18   0:00   /sbin/mingetty ĺtty4
root   232   0.0   1.0 740   316   5   S   18:18   0:00   /sbin/mingetty ĺtty5
root   233   0.0   1.0   740   316   6   S   18:18   0:00   /sbin/mingetty ĺtty6
root   236   0.0   2.5   1184   772   1   S   18:19    0:00   -bash
root   248   2.5   4.4    2456   1372   1   S 18:19    0:12   /usr/bin/mc -P
root   250   0.0  2.5   1188    772   p0   S   18:19   0:00   bash -rcfile ĺ.bashrc
Wyświetlane są kolumny zawierające te same informacje, jak w przypadku użycia opcji u, ale dotyczące wszystkich działających procesów. Porządek, w jakim podane zostaną opcje, nie jest istotny. Opcja l pozwala na uzyskanie informacji o tym, przez jaki proces dany proces został uruchomiony:
$ ps l
FLAGS   UID   PID   PPID   PRI   NI   SIZE   RSS   WCHAN   STA   TTY   TIME   COMMAND
100100   501   281   1   0   0   1492   948   wait4   S   2   0:00
ĺ /bin/login -- bill
  501   284   281   9   0   1180   768   wait4   S   2   0:00   -bash
100000   501   304   284   10   0   968   504   R   2   0:00   ps -l

Kolumna PPID (ang. Parent Process ID) zawiera identyfikator procesu, który urucho-mił dany proces. Jak widać, program ps uruchomiony został przez powłokę bash, któ-ra z kolei została uruchomiona przez proces o numerze 1 - czyli proces init, który jest "matką" wszystkich innych procesów (jeśli zastanawiasz się, jakie ma to konse-kwencje - odpowiedź jest prosta: jeśli ten proces zakończy działanie, przestaną dzia-łać wszystkie inne procesy). Wydając polecenie ps można, ale nie trzeba używać myślnika przed nazwami opcji.
Uwagi dla administratorów
W większości przypadków trzy przedstawione wcześniej wersje polecenia ps dostarcza-ją wszystkich potrzebnych informacji. Jeśli potrzebne są dane o systemie jako całości, wystarczy wydać polecenia:
ps -ax
ps -aux
ps -le
Na ekranie otrzymasz wszystkie chyba dostępne w systemie informacje o procesach. Dokładniejsze dane o działaniu polecenia ps możesz znaleźć na stronach man (które w tym przypadku nie są - niestety - kompletne).
Polecenie kill
Od czasu do czasu zdarza się proces, który zawiesi terminal albo po prostu nic nie robi. Zwykle sytuacja taka jest wynikiem błędów tkwiących w różnych programach. W obu przypadkach jedyną drogą usunięcia takiego procesu jest wydanie polecenia kill. Kiedy kończysz działanie procesu, a jesteś zalogowany jako root, zwróć szczególną uwagę na numer procesu, który zamierzasz usunąć, żeby przy-padkiem nie popełnić mogącej mieć przykre skutki pomyłki. Nie powinie-neś usuwać procesów systemowych, chyba że dokładnie wiesz, co chcesz przez to osiągnąć. Aby użyć polecenia kill, musisz mieć dostęp do okna lub konsoli, w którym będziesz mógł wydawać polecenia. Jeśli terminal zawiesił się kompletnie - musisz znaleźć inny. Jako zwykły użytkownik możesz usuwać tylko własne procesy. Jako użytkownik root możesz manipulować wszystkimi procesami. Musisz również znać identyfikator procesu, który chcesz usunąć (polecenie kill służy również do wysyłania innych sygnałów do procesów, nie tylko do ich usuwania - przyp. tłum.). Jest on wyświetlany przez polecenie ps. Poniżej podano przykład, w któ-rym proces o nazwie bad_prog i identyfikatorze 292 nie zakończył się prawidłowo, w związku z czym trzeba go usunąć.
$ ps u
USER   PID   %CPU   %MEM   SIZE   RSS   TTY   STAT   START   TIME   COMMAND
walter   281   0.2   3.0   1245   467   2   S   13:25   0:00   -bash
walter   292   9.2   12.0   2134   467   2   R 15:51   2:01   bad_prog
ĺ$ kill 292
Polecenie kill nie wyświetla informacji potwierdzającej usunięcie procesu. Aby sprawdzić, czy wszystko przebiegło poprawnie, trzeba ponownie wydać polecenie ps.
Usuwanie procesów potomnych
Jeśli proces, który chcesz usunąć, podczas swojego działania uruchomił inne procesy, powinieneś usunąć również wszystkie procesy potomne. Czasem zdarza się, że usunię-ty proces "odradza" się po chwili - w takim przypadku usunąć należy proces, który go wywołuje (jego identyfikator można znaleźć w kolumnie PPID po wydaniu polecenia ps l). Jeśli pomimo wydania polecenia kill proces nadal działa, trzeba użyć mocniejszych argumentów. Polecenie kill udostępnia kilka poziomów działania. Wydane tylko z jednym argumentem - numerem procesu - próbuje grzecznie zakończyć proces, tzn. zamknąć otwarte pliki, zwolnić pamięć itd. Jeśli to nie pomaga, należy użyć opcji -9, która wymusza zakończenie procesu, na przykład tak:
kill -9 726
Jeśli nie działa nawet polecenie kill -9, możliwe, że masz do czynienia z jednym z "nieśmiertelnych" procesów. Jedynym sposobem na zakończenie działania takiego stworzenia jest ponowne uruchomienie systemu.
Co można, a czego nie można usunąć
Generalnie nie możesz usunąć procesu nie należącego do Ciebie. Przy próbie zrobienia czegoś takiego otrzymasz komunikat:
kill: - Not owner
Oczywiście użytkownik root może usunąć każdy proces.

Użytkownicy i konta
Każdy użytkownik ma dostęp do systemu linuxowego tylko poprzez swoje konto. Każde konto użytkownika musi zostać skonfigurowane przez administratora (za wy-jątkiem konta root, które jest zakładane podczas instalacji systemu). Choć z niektó-rych systemów linuxowych korzysta tylko jeden użytkownik, nie powinien on używać na co dzień konta root. W wielu systemach możliwa jest równoczesna praca kilku użytkowników, czy to dzięki konsolom wirtualnym, czy też przez modem, czy za po-mocą terminalu. Umiejętność konfigurowania i zarządzania kontami użytkowników jest ważnym aspektem administrowania systemem.
Konto administratora
W trakcie instalowania systemu linuxowego tworzone jest jedno konto - konto admini-stratora, o identyfikatorze root. Podczas gdy większość kont użytkowników jest za-bezpieczona przed wyrządzeniem jakichkolwiek szkód w systemie, użytkownik root może za pomocą jednego polecenia zniszczyć cały system. Na użytkownika root nie są nałożone żadne ograniczenia. Możliwości, jakie oferuje konto root, mogą uzależniać. Nie trzeba mar-twić się o prawa dostępu czy konfigurację oprogramowania; można zrobić wszystko i wszędzie. To powoduje, że większość nowych użytkowników używa konta root do codziennej pracy. Zwykle porzucają ten zwyczaj w momencie, gdy przez przypadek uda im się zniszczyć cały system. Brak ograniczeń nałożonych na konto root pociąga za sobą brak jakichkol-wiek zabezpieczeń. Z tego powodu konto root powinno być używane tyl-ko do zadań o charakterze administracyjnym. Nie używaj konta root do codziennej pracy! Konto root powinno być używane tylko wtedy, gdy sytuacja naprawdę tego wymaga. Dobrym pomysłem jest zmiana znaku zachęty dla użytkownika root, dzięki czemu będziesz widział, że jesteś zalogowany jako root i być może zastanowisz się przed wydaniem jakiegoś niefortunnego polecenia. Możesz to zrobić ustalając odpowiednio wartość zmiennej środowiskowej . Jeśli systemu używasz tylko Ty i uda Ci się go przez przypadek zniszczyć - to jeszcze niewielki problem. O wiele gorzej sytuacja wygląda, gdy zniszczysz efekty pracy innych użytkowników… Mając na uwadze wszystkie powyższe ostrzeżenia, nie masz chyba wątpliwości, że pierwsze, co powinieneś zrobić po zainstalowaniu systemu, to założenie dla siebie kon-ta do codziennego użytku. Hasło użytkownika root nie może być łatwe do odgadnię-cia dla innych użytkowników systemu. Powinieneś również w miarę regularnie je zmie-niać. Warto także założyć konta służące do prac administracyjnych nie wymagających aż tak szerokich uprawnień, jakie oferuje root, na przykład do tworzenia kopii zapaso-wych na taśmach. Użytkownik ten może mieć np. dostęp do całego systemu plików (tak jak root), ale bez prawa zapisu. Podobne konta mogą zostać stworzone do obsłu-gi poczty, Internetu itp. Przemyśl dobrze przywileje, jakie trzeba nadać każdemu użyt-kownikowi - dzięki temu system będzie bezpieczniejszy i unikniesz przypadkowych uszkodzeń. Jeśli chodzi o ścisłość, konto administratora nie musi nazywać się root. Może mieć dowolną nazwę, ale jego identyfikator numeryczny musi być ustawiony na 0 (w pliku /etc/passwd).
Konta użytkowników - plik /etc/passwd
Nawet jeśli jesteś jedynym użytkownikiem systemu, warto wiedzieć kilka rzeczy o kontach użytkowników i zarządzaniu nimi, choćby dlatego, że powinieneś posiadać konto do codziennej pracy (inne niż root). Musisz więc umieć dodać do systemu no-wego użytkownika. Jeśli inne osoby również będą korzystać z systemu, czy to przez modem, czy też bezpośrednio, powinieneś założyć dla każdej z nich osobne konto. Można też utworzyć konta ogólnodostępne, np. dla przyjaciół tylko okazyjnie korzy-stających z Twojego systemu. Każda osoba używająca systemu powinna posiadać własny identyfikator oraz hasło. Jedynym wyjątkiem mogą być użytkownicy typu guest, którzy powinni mieć jednak bardzo ograniczone prawa dostępu. Dzięki założeniu osobnego konta dla każdego użytkownika znacznie poprawia się bezpieczeństwo systemu. Jako administrator masz również lepsze pojęcie o tym, kto i w jakim celu z niego korzysta. Wszystkie informacje o kontach użytkowników przechowywane są w pliku /etc/passwd. Jego właścicielem powinien być root, a identyfikator grupy powinien być ustawiony na 0 (grupa root albo system, zależnie od wpisu w pliku /etc/groups). Prawa dostępu powinny być tak ustawione, by zapisywać do tego pliku mógł tylko root, natomiast prawo odczytu powinni mieć wszyscy użytkownicy (o gru-pach i prawach dostępu będziemy jeszcze mówić w dalszej części tego podrozdziału). Wpisy w pliku /etc/passwd mają następujący format:
nazwa_uzytkownika:hasło:ID_użytkownika:ID_grupy:komentarz:katalog_domowy:powłoka_domyślna
Listing 35.1 przedstawia przykładową zawartość takiego pliku.
Listing 35.1. Plik /etc/passwd utworzony podczas instalacji Linuxa
root:jyGSAETCyfRDE:0:0:root:/root:/bin/bash
bin:*:1:1:bin:/bin:
daemon:*:2:2:daemon:/sbin:
adm:*:3:4:adm:/var/adm:
lp:*:4:7:lp:/var/spool/lpd:
sync:*:5:0:sync:/sbin:/bin/sync
shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown
halt:*:7:0:halt:/sbin:/sbin/halt
mail:*:8:12:mail:/var/spool/mail:
news:*:9:13:news:/var/spool/news:
uucp:*:10:14:uucp:/var/spool/uucp:
operator:*:11:0:operator:/root:
games:*:12:100:games:/usr/games:
gopher:*:13:30:gopher:/usr/lib/gopher-data:
ftp:*:140:50:FTP User:/home/ftp:
nobody:*:-1:100:Nobody:/:
Każdy wiersz składa się z siedmiu pól rozdzielonych dwukropkami. Jeśli dane pole nie ma zawierać żadnych informacji, dwukropki muszą pozostać (tzn. każdy wiersz musi zawierać sześć dwukropków). Pola te mają następujące funkcje:
nazwa_uzytkownika:   niepowtarzalny identyfikator użytkownika;
hasło:   hasło dostępu do systemu, zakodowane tak, by jego odczytanie nie było możliwe;
ID_użytkownika:   identyfikator numeryczny, inny dla każdego użyt-kownika, używany przez system;
ID_grupy:   liczba określająca grupę, do której należy użytkownik;
komentarz:   zwykle prawdziwe imię i nazwisko użytkownika, ale można tu wpisać dowolny tekst;
katalog_domowy:   katalog, w którym użytkownik znajdzie się po zalogowaniu;
powłoka_domyślna   program uruchamiany po zakończeniu procesu logowania.
Każdemu polu przyjrzymy się nieco dokładniej. Powinieneś orientować się, w jaki sposób są one wykorzystywane przez programy. Taki plik, jak /etc/passwd, używany jest nie tylko w systemie Linux, ale we wszystkich systemach UNIX-owych.
Identyfikatory użytkowników
Identyfikatorem użytkownika może być dowolny tekst, zwykle o długości do ośmiu znaków, inny dla każdego użytkownika. Ponieważ jest on podstawą identyfikacji pod-czas pracy w sieci, powinien być prosty i oczywisty; nie od rzeczy jest na przykład kombinacja taka jak pierwsza litera imienia + nazwisko lub jego część (np. tszydl czy wkuc) - taka konwencja jest dość często stosowana w większych systemach. Zauważ, że wszystkie litery w powyższych przykładach są małe. Wielkość liter jest istotna w systemach UNIX-owych, więc identyfikator tszydl nie jest tożsamy z TSzydl. Zwykle używa się identyfikatorów składających się tylko z małych liter. Do-zwolone, choć rzadko używane, są podkreślenia, przecinki, cyfry i niektóre inne sym-bole. W niewielkich systemach często używa się identyfikatorów brzmiących nieco bardziej przyjaźnie, na przykład michal czy iwona. Jeśli dwóch użytkowników nosi te same imiona, trzeba znaleźć sposób na ich rozróżnienie (np. tomek i tom). Niektórzy użytkownicy wolą, żeby ich identyfikatorem było przezwisko czy cokolwiek innego. Wszystko jest w porządku w niewielkich sieciach i do zastosowań "rozrywko-wych", ale staje się dziwactwem w pracy, gdzie tylko utrudnia życie innym osobom próbującym skontaktować się z danym użytkownikiem.
Hasła
System przechowuje hasła użytkowników w postaci zakodowanej. Hasło może być zmienione przez użytkownika po zalogowaniu się (co wymaga znajomości tegoż ha-sła) lub też przez użytkownika root. Pole pliku /etc/passwd zawierające hasło jest bardzo wrażliwe na wszelkiego rodzaju modyfikacje, które w zasadzie zawsze powo-dują zablokowanie dostępu do danego konta (aż do zmiany hasła przez administrato-ra systemu). W niektórych wersjach UNIX-a dla zapewnienia większego bezpieczeństwa hasła nie są przechowywane w pliku /etc/passwd. Jeśli w Twoim sys-temie zamiast zakodowanych haseł w pliku passwd znajduje się znak x, oznacza to, że istnieje inny plik, w którym zapisane są ich rzeczywiste war-tości (ta technika nazywa się password shadowing - ukrywanie haseł). Systemy korzystające z Yellow Pages lub Network Information Service nie wykorzystują tego pola, a zamiast tego używają wspólnego pliku zawiera-jącego dane o użytkownikach. Pozwala to każdemu użytkownikowi na zalogowanie się do systemu za pomocą dowolnego komputera podłączo-nego do sieci. Podczas logowania program login sprawdza, czy wprowadzone hasło odpowiada za-kodowanemu. Jeśli nie, użytkownik nie uzyska dostępu do systemu. Pole to może również być wykorzystane do ograniczenia dostępu do systemu. Jeśli da-ne konto nie powinno być używane, wystarczy do pola zawierającego hasło wprowa-dzić pojedynczą gwiazdkę (*). Ma to zastosowanie również w przypadku użytkowni-ków systemowych, takich jak lp czy sync. Gwiazdka w polu hasła spowoduje zablo-kowanie dostępu do systemu dla określonego użytkownika. Można pozostawić to pole puste, co daje wszystkim możliwość dostania się do syste-mu bez podawania hasła. Użytkownik, który ma taką możliwość, powinien mieć bar-dzo ograniczone prawa dostępu do plików w systemie, ponieważ każdy może zalogo-wać się używając jego identyfikatora. Ogólnie nie należy jednak pozostawiać pustych haseł, chyba że używasz systemu wyłącznie do zabawy i w systemie plików nie są za-pisane żadne istotne dane. Nie powinieneś próbować wprowadzić zakodowanego hasła do pliku /etc/passwd ręcznie. Nie jest możliwe odtworzenie metody kodowania haseł, więc prawie na pewno skończy się to zablokowaniem dostępu do danego konta (aż do zmiany hasła przez administratora systemu).
Numeryczny identyfikator użytkownika
Z każdym identyfikatorem tekstowym użytkownika związany jest również identyfika-tor numeryczny. To on, a nie identyfikator tekstowy, jest używany przez system do rozróżniania użytkowników. Programy wyświetlające informacje o użytkownikach dokonują translacji numeru na odpowiadający mu identyfikator tekstowy (na pod-stawie zawartości pliku /etc/passwd) dla wygody czytającego. W większości systemów UNIX-owych numery użytkowników mają wartości od 100 w górę, ponieważ numery od 0 do 99 zarezerwowane są dla użytkowników systemowych. W podanym wcześniej przykładowym pliku /etc/passwd można zauważyć, że użyt-kownikowi root przypisany jest numer 0 - jest to reguła obowiązująca w każdym sys-temie. Użytkownikowi nobody (używanemu do obsługi sieciowych systemów plików NFS) przypisany jest numer - 1, który jest nieprawidłowy. Przy zakładaniu nowych kont dobrze jest numerować użytkowników kolejno, rozpoczynając od wartości 100, następnie 101 itd.
Identyfikator grupy
Identyfikator grupy zapisany w pliku /etc/passwd jest również wartością liczbową. Decyduje on o tym, do której grupy należał będzie dany użytkownik po zalogowaniu. Grupy używane są dla ułatwienia zarządzania prawami dostępu do plików ale w wielu małych systemach ich możliwości nie są wykorzystywane. Numery grup rozpoczynają się od 0. Grupa o nazwie users zwykle posiada numer 100. Identyfikator grupy używany jest do weryfikowania praw dostępu do plików, oraz przy tworzeniu i modyfikowaniu plików. Jeśli w Twoim systemie funkcjonuje tylko jedna grupa użytkowników, nie musisz martwić się o przydzielanie prawidłowych wartości identyfikatorów grupy. Jeśli chcesz założyć kilka grup, musisz również zmodyfikować plik /etc/group.
Komentarz
Pole komentarza używane jest przez administratora systemu po to, aby wpis można było łatwiej zidentyfikować. Zwykle zawiera ono prawdziwe imię i nazwisko użytkow-nika, czasem również wydział czy numer ewidencyjny. Nazywane jest czasem polem GECOS - nazwa ta pochodzi od pierwszego systemu, w którym go używano. Niektóre programy bazują na informacjach zapisanych w tym polu przy wyświetlaniu danych o użytkownikach, nie należy więc wpisywać tam żadnych poufnych danych. Systemy poczty na przykład informują na jego podstawie o tym, kto wysłał daną wiadomość. Choć nie trzeba używać tego pola, w większych systemach ułatwia ono życie zarówno administratorowi, jak i innym użytkownikom.
Katalog domowy
Pole to określa, w jakim katalogu będzie znajdował się użytkownik po zalogowaniu się do systemu. Każdy użytkownik powinien posiadać własny katalog domowy, w którym nie są na niego nałożone żadne ograniczenia. W nim zapisywane są pliki konfiguracyj-ne różnych programów. Na ten katalog powinna wskazywać wartość zmiennej środo-wiskowej HOME. Zwykle wszystkie katalogi domowe użytkowników zebrane są w jednym miejscu. W systemie Linux jest to przeważnie katalog /home. Czasem - jeśli administrator jest przyzwyczajony do innego ich umieszczenia - mogą znajdować się gdzieś indziej (na przykład w katalogu /usr czy /user; zdarza się również, szczególnie w większych systemach, że katalogi domowe użytkowników znajdują się w kilku różnych podkata-logach - przyp. tłum.).
Powłoka domyślna
Pole określające powłokę domyślną zawiera nazwę programu, który zostanie urucho-miony po zakończeniu logowania. W większości przypadków jest to interpreter poleceń bash czy tcsh, ale może to być dowolna aplikacja, taka jak program do obsługi poczty itp. - na przykład dla użytkownika uucp jest to program uucp. Jeśli pole to po-zostawione jest puste, system uruchomi interpreter domyślny (zwykle bash, ale zależy to od konfiguracji systemu). Wiele wersji Linuxa pozwala użytkownikowi na zmianę wartości tego pola za pomocą polecenia passwd -s lub chsh. Jeśli używasz któregoś z tych poleceń, możesz zmienić program uruchamiany tylko na jeden z tych, których nazwy zapisane są w pliku /etc/shells (plik ten można modyfikować dowolnym edytorem tekstów). Pozwala to na zachowanie wyższego poziomu bezpieczeństwa. Administrator może w tym polu wpisać dowolny program. Jeśli w Twoim systemie używany jest plik /etc/shells, powinien on mieć takie same prawa dostępu, jak plik /etc/passwd, ponieważ konse-kwencje płynące z możliwości jego modyfikacji przez niepowołane osoby są równie niebezpieczne jak nieautoryzowany dostęp do pliku /etc/passwd.
Użytkownicy systemowi
Podany wcześniej przykładowy plik /etc/passwd zawiera kilkanaście wpisów, wprowadzonych przez system podczas instalacji. Wszyscy zdefiniowani w nim użyt-kownicy spełniają w systemie linuxowym specjalną rolę. Kilku z nich jest szczególnie wartych uwagi:
root    administrator - użytkownik, na którego nie są nałożone żadne ograniczenia;
daemon    konto używane dla procesów systemowych;
bin    właściciel niektórych plików wykonywalnych;
sys    właściciel niektórych plików wykonywalnych;
adm    właściciel plików administracyjnych;
uucp    konto używane do komunikacji za pomocą protokołu UUCP.
W innych systemach mogą również być założone konta do specyficznych zadań; ich nazwy zwykle wyjaśniają przeznaczenie - na przykład użytkownik postmaster przeznaczony jest do obsługi poczty. Większości z tych wpisów nie należy modyfikować. W polu hasła mają one wpisaną gwiazdkę, co zabezpiecza przed ich wykorzystaniem do zalogowania się do systemu.
Dodawanie nowego konta
Nowego użytkownika można dodać do systemu na dwa sposoby: ręcznie, edytując plik /etc/passwd, bądź też za pomocą skryptu automatyzującego wszystkie czynno-ści, dzięki czemu minimalizowane jest ryzyko popełnienia błędów, co jest szczególnie ważne dla mało doświadczonych administratorów lub w przypadku dodawania więk-szej liczby użytkowników. Tylko użytkownik root może modyfikować plik /etc/passwd. Przed dokonaniem jakichkolwiek zmian w pliku /etc/passwd zrób jego kopię zapasową. Jeśli przez przypadek uszkodzisz go, może się zdarzyć, że nie będziesz mógł się zalogować nawet jako root (do systemu można wówczas dostać się tylko w trybie administracyjnym). Na wypadek pro-blemów dobrze mieć kopię tego pliku na dyskietce startowej. Aby dodać wpis do pliku /etc/passwd, można użyć dowolnego edytora tekstów. Dane nowego użytkownika można dopisać na końcu pliku; każdemu użytkownikowi musi odpowiadać oddzielny wiersz. Upewnij się, że numery identyfikacyjne użytkow-ników się nie powtarzają. Przykładowo, aby dodać użytkownika o identyfikatorze bill, numerze identyfikacyjnym 103 i numerze grupy 100, którego katalogiem do-mowym jest /home/bill, a domyślnym interpreterem poleceń - bash, powinieneś do-dać wiersz:
bill::103:100:Bill Smalwood:/home/bill:/bin/bash
Pole określające hasło należy pozostawić puste, ponieważ nie da się wprowadzić zako-dowanego hasła samodzielnie. Następnie należy zmienić hasło używając polecenia passwd:

passwd bill
Po wydaniu tego polecenia należy dwukrotnie wprowadzić hasło. Użytkownik bill powinien je zmienić jak najszybciej (na takie, które będzie znał tylko on). Niektórzy administratorzy jako pierwsze hasło wpisują jakiś łatwy do odgadnięcia tekst, na przykład password albo identyfikator użytkownika, zmuszając jednocześnie użyt-kownika do zmiany hasła zaraz po zalogowaniu się. Jest to dopuszczalne, jeśli pierw-sze logowanie następuje zaraz po założeniu hasła. W przeciwnym przypadku konto przez dłuższy czas może pozostać niezabezpieczone, stwarzając potencjalne zagroże-nie dla bezpieczeństwa systemu. Po wpisaniu odpowiednich danych do pliku /etc/passwd należy utworzyć katalog domowy użytkownika, o ile nie istnieje on jeszcze w systemie. Jego właścicielem musi być osoba, która ma go używać:
mkdir /home/bill
chown bill /home/bill
Każdy użytkownik musi należeć do jakiejś grupy. Jeśli w Twoim systemie jest zdefi-niowana tylko jedna grupa, dodaj identyfikator nowego użytkownika do odpowiednie-go wiersza w pliku /etc/group. Plik ten jest omówiony bardziej szczegółowo w pod-rozdziale "Grupy". Na koniec należy jeszcze skopiować do katalogu domowego nowego użytkownika pli-ki konfiguracyjne interpreterów poleceń itp., na przykład tak:
cp /home/iwona/.profile /home/bill/.profile
chown bill /home/bill/.profile
Pliki takie warto przejrzeć na wypadek występowania w nich nieprawidłowych wpisów, na przykład ustawiających wartość zmiennej HOME czy katalog poczty. W przypadku używania powłoki C plik konfiguracyjny nazywa się .login lub .cshrc, w przypad-ku powłoki bash oraz pdksh - .profile. Ogólnie proces dodawania nowego użytkownika składa się z trzech etapów:
1. dodania wpisu do pliku /etc/passwd,
2. utworzenia katalogu domowego i przypisania mu odpowiedniego właściciela,
3. skopiowania plików konfiguracyjnych do katalogu nowego użytkownika.
Niektóre dystrybucje Linuxa zawierają polecenie przeniesione z wersji Berkley BSD UNIX o nazwie vipw, które wywołuje domyślny edytor (zwykle vi) na tymczasowej kopii pliku /etc/passwd; dzięki takiemu rozwiązaniu nie jest możliwe, aby dwóch użytkowników edytowało równocześnie ten sam plik, co zapobiega potencjalnym pro-blemom. Przed zapisaniem pliku sprawdzana jest jego poprawność syntaktyczna, co dodatkowo podnosi poziom bezpieczeństwa. Często można również użyć skryptów automatyzujących dodawanie nowych użytkowników, które nazywają się adduser albo useradd. Zwykle zadają one pytanie o początkowe hasło, które można pozostawić puste. Główną ich zaletą jest fakt, że au-tomatycznie kopiują pliki konfiguracyjne dla wszystkich obsługiwanych powłok, czę-sto również same ustawiają poprawne wartości zmiennych środowiskowych. Może to znacząco ułatwić proces dodawania nowych użytkowników. Hasła w systemie linuxowym to jeden z najbardziej newralgicznych, z punktu widzenia bezpieczeństwa, problemów. Do każdego konta powinno być przypisane bezpieczne hasło, chyba że masz pewność, ze nikt obcy nie korzysta z systemu (pewność taką możesz mieć tylko wtedy, gdy nie jesteś podłączony do sieci, a komputer jest pod kluczem). Hasła przypisuje się i zmienia poleceniem passwd. Administrator może zmienić każde ha-sło w systemie, natomiast zwykły użytkownik może zmienić tylko swoje hasło.
Usuwanie kont
Podobnie jak dodawanie nowego konta, usuwanie można przeprowadzić na dwa spo-soby: ręcznie lub używając odpowiedniego skryptu, który zwykle nazywa się deluser lub userdel. Skrypt pyta o identyfikator użytkownika, którego należy usunąć z sys-temu, a następnie wykonuje wszystkie niezbędne czynności: usuwa wpis z pliku /etc/passwd, może również posprzątać w katalogach kolejek i usunąć katalog do-mowy. Jeśli chcesz usunąć konto ręcznie, najpierw usuń odpowiedni wiersz z pliku /etc/passwd. Następnie możesz usunąć pliki, których właścicielem jest nieistniejący już użytkownik. Możesz również usunąć jego katalog domowy wraz z całą zawarto-ścią za pomocą polecenia:
rm -r /home/nazwa_użytkownika
/home/nazwa_użytkownika to pełna ścieżka dostępu do katalogu domowego użyt-kownika. Upewnij się najpierw, że w katalogu tym nie ma żadnych plików, które chciałbyś zatrzymać! Następnie należy usunąć plik poczty, który zwykle znajduje się w katalogu /usr/spool/ mail/nazwa_użytkownika. Powinieneś sprawdzić, czy w pliku /etc/aliases nie ma wpisów dotyczących usuwanego użytkownika. Plik ten mody-fikuje się za pomocą polecenia newaliases. Na koniec wyłącz wszystkie zadania programów cron i at, których właścicielem był usuwany użytkownik. Dane o nich możesz uzyskać używając polecenia crontab. Jeśli musisz pozostawić danego użytkownika w systemie z jakiegoś powodu, najłatwiej uniemożliwić mu logowanie, wpisując w miejsce hasła w pliku /etc/passwd gwiazdkę. Tak zablokowane konto może być ponownie uaktywnione poleceniem passwd. Proces ręcznego usuwania użytkownika składa się z następujących etapów:
1. usunięcie wpisów z plików /etc/passwd i /etc/group,
2. usunięcie poczty użytkownika,
3. wyłączenie zadań at i cron,
4. usunięcie katalogu domowego (o ile pliki w nim zawarte nie będą już potrzebne).
Czasem trzeba tymczasowo zablokować konto użytkownika (na przykład kiedy wyjeżdża on na dłuższe wakacje i nie będzie używał systemu). W takim przypadku należy w miejsce hasła wpisać do pliku /etc/passwd gwiazdkę. Można również dodać gwiazdkę przed pierwszym znakiem hasła - po powrocie użytkownika będzie można ją usunąć, a hasło użytkownika nie ulegnie zmianie.
Grupy
Każdy użytkownik w systemie UNIX-owym musi należeć do jakiejś grupy. Grupa to logiczny zbiór użytkowników. Przykładowo, grupę mogą stanowić wszyscy pracownicy jednego wydziału, którzy powinni mieć dostęp do jakichś wspólnych danych, czy moż-liwość używania danego urządzenia, na przykład skanera czy kolorowej drukarki lase-rowej. W systemie może być dowolnie dużo grup. Użytkownik może być w danym momencie przypisany tylko do jednej grupy. Jeśli jednak należy jeszcze do innych (każdy użytkownik może należeć do dowolnej liczby grup), może w każdej chwili sam przyłączyć się do odpowiedniej grupy. Prawa dostępu dla grup można ustalić tak, by ich członkowie mieli np. dostęp do da-nych urządzeń, plików czy systemów plików, natomiast nie mieli ich inni użytkownicy. Przykładowo, wszyscy pracownicy księgowości powinni mieć dostęp do rachunków firmy, do których jednak nie powinni mieć dostępu pozostali pracownicy - takie ogra-niczenie może być z łatwością zrealizowane za pomocą grup. W wielu systemach linuxowych istnieje tylko jedna grupa użytkowników. Takie roz-wiązanie jest akceptowalne w małych, najwyżej kilkuosobowych systemach. Dostęp do plików i urządzeń określany jest wówczas nie w oparciu o przynależność do grupy, ale o indywidualne ustawienia praw dostępu dla każdego pliku. Zalety używania grup ujawniają się, gdy z systemu zaczyna korzystać większa liczba użytkowników - na przykład dzieci i przyjaciele - wówczas, używając grup, można z łatwością manipulo-wać prawami dostępu do plików. Informacje o grupach przechowywane są w pliku /etc/groups, którego struktura jest podobna do struktury pliku /etc/passwd. Plik /etc/groups pochodzący ze świeżo zainstalowanego systemu przedstawiony jest na listingu
Plik /etc/groups utworzony podczas instalacji Linuxa
root::0:root
bin::1:root,bin,daemon
daemon::2:root,bin,daemon
sys::3:root,bin,adm
adm::4:root,adm,daemon
tty::5:
disk::6:root
lp::7:daemon,lp
mem::8:
kmem::9:
wheel::10:root
mail::12:mail
news::13:news
uucp::14:uucp
man::15:
floppy:x:19:
games::20:
gopher::30:
dip::40:
ftp::50:
nobody::99:
users::100:
pppusers:x:230:
popusers:x:231:
slipusers:x:232:
Każdy wiersz składa się z czterech pól, rozdzielonych dwukropkami (dwa dwukropki obok siebie oznaczają, że dane pole jest puste):
nazwa_grupy:hasło_grupy:ID_grupy:użytkownicy
Pola te mają następujące znaczenie:
nazwa_grupy:    niepowtarzalna nazwa grupy, składająca się maksymalnie z ośmiu znaków;
hasło_grupy:    pole to zwykle pozostawiane jest puste (w niektórych wersjach systemu tu przechowywane jest hasło, które użytkownik musi podać, chcąc przyłączyć się do grupy); większość wersji Linuxa nie obsługuje tego pola;
ID_grupy:    numer identyfikacyjny, różny dla każdej grupy, używany przez system operacyjny;
użytkownicy:    lista użytkowników należących do danej grupy.
W każdym systemie istnieje pewna liczba grup tworzonych podczas instalacji, służących do obsługi samego systemu operacyjnego (jak na przykład bin, mail, uucp, sys itd.). Na powyższym wydruku są to wszystkie grupy oprócz ostatnich czterech. Nigdy nie powinieneś pozwolić użytkownikom, by należeli do jednej z tych grup, ponieważ daje im to prawa dostępu zagrażające bezpieczeństwu systemu. Mogą do nich należeć tylko użytkownicy systemowi.
Grupy systemowe
Jak widać na listingu , istnieje kilka grup systemowych, do których nie należą zwykli użytkownicy systemu. Funkcje niektórych z nich są następujące:
root/wheel/system    zwykle używana, aby uzyskać prawa użytkownika root za pomocą polecenia su; grupa ta jest właścicielem większości plików systemowych;
daemon    używana do obsługi katalogów kolejki dla poczty, dru-karek itp.;
kmem    używana przez programy wymagające bezpośredniego dostępu do pamięci (np. ps);
sys    właściciel niektórych plików systemowych; w niektó-rych systemach grupa ta zachowuje się tak samo jak kmem;
tty    właściciel plików obsługujących terminale.
Domyślna grupa dla zwykłych użytkowników nazywa się users i posiada numer identyfikacyjny 100 (w niektórych systemach funkcję tę pełni grupa group o numerze 50).
Dodawanie nowej grupy
Aby utworzyć nową grupę, można ręcznie edytować plik /etc/groups, ale można również w tym celu użyć skryptu o nazwie addgroup czy groupadd. Z punktu widze-nia administratora ręczna edycja pliku jest nawet wygodniejsza, ponieważ umożliwia od razu wgląd w całą strukturę grup. Poza tym nie we wszystkich systemach dostępne są odpowiednie skrypty. Jeśli chcesz modyfikować zawartość pliku /etc/groups, powinieneś najpierw wyko-nać jego kopię zapasową. Za pomocą dowolnego edytora tekstów dodaj nowy wiersz dla każdej grupy, którą zamierzasz utworzyć. Upewnij się, że nie popełniłeś żadnych błędów składniowych. Poniżej znajdują się dwa wiersze, które spowodują utworzenie dwóch nowych grup; do każdej z nich należeć będzie jeden użytkownik:
rachunki::101:bill
skaner::102:iwona
Numery identyfikacyjne tych grup to 101 i 102. Nowe wiersze można dodać w dowol-nym miejscu pliku. Identyfikatory użytkowników mających należeć do danej grupy powinny znajdować się na końcu wiersza. W powyższym przykładzie do każdej z grup należy tylko jeden użytkownik - w następnym podrozdziale dowiesz się, w jaki sposób można dodać do grupy więcej niż jednego użytkownika. Definicje grup nie muszą po-jawiać się w kolejności zgodnej z ich numerami identyfikacyjnymi. Po dokonaniu zmian w pliku /etc/groups powinieneś sprawdzić, czy nadal ma on prawidłowo ustawione prawa dostępu. Jego właścicielem powinien być użytkownik root (lub system). Nikt prócz właściciela nie powinien mieć prawa zapisu do tego pli-ku.
Dodawanie użytkowników do grupy
Każdy użytkownik może być członkiem wielu grup; w takim przypadku jego identyfi-kator powinien pojawić się w każdym wierszu odpowiadającym grupie, do której on przynależy (identyfikatory użytkowników w pliku /etc/groups powinny być roz-dzielone przecinkami). Nie ma formalnego ograniczenia liczby użytkowników mogą-cych należeć do danej grupy, ale w praktyce nie jest aż tak dobrze: liczba użytkowni-ków należących do grupy jest efektywnie ograniczana przez maksymalną długość wiersza w pliku /etc/groups (255 znaków). Istnieją metody obejścia tego problemu, ale w większości systemów nie będzie to konieczne. Oto fragment pliku /etc/groups zawierającego definicje kilkuosobowych grup:
rachunki::101:bill,iwona,michal,root,szymon
scanner::102:iwona,janek,root
cad::103:michal,piotr,wojtek
Identyfikatory użytkowników mogą pojawiać się w dowolnej kolejności. W danym momencie użytkownik może należeć tylko do jednej grupy. O tym, do której grupy będzie należał po zalogowaniu, decyduje wpis w pliku /etc/passwd.
Usuwanie grupy
Jeśli zdecydujesz, że dana grupa nie jest już potrzebna, możesz usunąć odpowiedni wpis z pliku /etc/groups. Powinieneś również sprawdzić w pliku /etc/passwd, czy któryś użytkownik nie loguje się jako członek tej grupy (w takim przypadku bowiem nie będzie mógł się zalogować). Możesz również wyszukać w systemie plików pliki i ka-talogi należące do danej grupy i zmienić ich przynależność (bądź też usunąć). Jeśli tego nie zrobisz, inni użytkownicy mogą nie mieć dostępu do tych plików. W niektórych wersjach Linuxa do usuwania wpisów z pliku /etc/group przeznaczony jest skrypt o nazwie delgroup lub groupdel.
Polecenie su
Czasem zachodzi potrzeba wydania jakiegoś polecenia jako inny użytkownik. Jeśli je-steś zalogowany jako root, a chcesz stworzyć pliki, których właścicielem będzie bill, łatwiej zalogować się jako bill niż zmieniać potem prawa dostępu do plików. Podob-nie wygląda sytuacja, jeśli jesteś zalogowany jako zwykły użytkownik, a potrzebujesz na chwilę uprawnień administratora. W takich sytuacjach z pomocą przychodzi pole-cenie su. Polecenie su zmienia identyfikator użytkownika i przyznaje wszystkie uprawnienia, jakie posiada inny użytkownik. Jego parametrem jest identyfikator użytkownika, któ-rym chcesz się na chwilę stać, na przykład:
su root
Po wydaniu takiego polecenia system zapyta Cię o hasło. Jeśli wprowadzisz je po-prawnie, będziesz miał wszystkie uprawnienia użytkownika root (do czasu, aż wydasz polecenie exit lub wciśniesz Control+d). Jeśli jesteś zalogowany jako root, możesz stać się innym użytkownikiem bez podawania hasła, na przykład wydając polecenie:
su bill
Po wciśnięciu kombinacji klawiszy Control+d znowu staniesz się użytkownikiem root. Jeśli jesteś zalogowany jako zwykły użytkownik, a chcesz przełączyć się na chwilę na inne konto zwykłego użytkownika, również musisz podać hasło.

Obsługa urządzeń SCSI
SCSI (ang. Small Computer System Interface; skrót ten wymawia się skazi) jest stan-dardową metodą komunikacji pomiędzy komputerem a urządzeniami peryferyjnymi. Posiada wiele zalet, które powodują, że jest lepszy od innych interfejsów (takich jak IDE), niestety, zwykle jest również nieco droższy. SCSI używa dedykowanej karty kontrolera (zintegrowanej z niektórymi lepszymi pły-tami głównymi), do której podłączany jest łańcuch urządzeń. Mogą to być urządzenia wewnętrzne - wtedy kabel ma formę płaskiej taśmy, lub zewnętrzne - kabel do ich podłączenia jest okrągły, ekranowany. Każde urządzenie musi posiadać inny identyfi-kator (od 0 do 7, ale nowsze sterowniki dopuszczają do 16 urządzeń). Zwykle karcie kontrolera przypisany jest numer 7, natomiast dyskowi twardemu, z którego urucha-miany jest system - 0. Główną zaletą interfejsu SCSI jest jego duża prędkość. Ponadto w urządzeniach SCSI zamontowana jest elektronika służąca do obsługi interfejsu, co powoduje, że jest im łatwiej się ze sobą porozumieć. Następną zaletą jest fakt, że system sam się konfiguru-je. Po podłączeniu do magistrali SCSI np. skanera (mającego oczywiście ustawiony unikalny identyfikator) urządzenie samo przesyła do sterownika dane o sobie, dzięki czemu cały proces konfiguracji może odbyć się automatycznie. Na końcu łańcucha SCSI musi być zamontowany terminator. Jest to w najprostszym przypadku zestaw oporników, zapewniający właściwe warunki rozchodzenia się fali elektromagnetycznej. Niektóre urządzenia SCSI posiadają terminator wewnętrzny, który powinien być aktywny tylko wtedy, gdy urządzenie podłączone jest na końcu łańcucha. Niektóre urządzenia potrafią również samodzielnie wykryć taką sytuację i załączyć terminator. Aby uniknąć niespodzianek, powinieneś przejrzeć dołączoną do urządzeń dokumentację. Urządzenia S
ogą komunikować się poprzez magistralę SCSI bez angażowania płyty głównej czy procesora, np. skaner może wysyłać polecenia bezpośrednio do dys-ku twardego czy drukarki, co wpływa na zwiększenie sprawności systemu.
Nowsze standardy SCSI
Kilka lat temu dostępny był tylko jeden rodzaj interfejsu SCSI. W tej chwili funkcjonu-je przynajmniej pięć jego wersji, z których niektóre są kompatybilne ze sobą, inne nie. Wszystkie wersje dzielą się na trzy kategorie, nazywane SCSI-I, SCSI-II i SCSI-III. SCSI-I to tradycyjny, ośmiobitowy interfejs mogący obsłużyć do siedmiu urządzeń. Można go rozpoznać po prostokątnych, 50-nóżkowych gniazdach. SCSI-I był dość ograniczony pod względem szybkości, dlatego wprowadzone zostały nowsze systemy. Ważne jest, by nie mylić nazw złączy używanych przez urządzenia z nazwami stan-dardów, ponieważ nie zawsze są one zgodne. SCSI-II pozwala na dołączenie do 15 urządzeń poprzez o wiele mniejsze, choć również 50-nóżkowe gniazda w kształcie lite-ry D. SCSI-III również pozwala na dołączenie 15 urządzeń, ale używa szerszych, 68-nóżkowych złączy w kształcie litery D. Na pewno spotkałeś się z takimi określeniami standardów jak Fast, Wide czy UltraWi-de SCSI. Są to określenia związane z tym, czy wtyk kabla wewnętrznego ma 50 czy 68 nóżek (i odpowiednio zewnętrznego 40 czy 68 nóżek). Połączenia wewnętrzne i zewnętrzne mają różne szerokości, co może być nieco mylące. Dostępne są również karty sterowników dopuszczające transmisję danych nawet z prędkością 40 MB/s, ale nie są one kompatybilne z większością urządzeń. Differen-tial SCSI to standard, który różni się nieco pod względem elektrycznym w sposobie przesyłania danych (używana jest metoda różnicowa) - dzięki temu możliwe jest stosowanie dłuż-szych przewodów i większych prędkości przesyłu. Obecnie dostępnych jest niewiele urządzeń obsługujących ten standard. Również karty sterowników są droższe niż dla pozostałych odmian. W obrębie jednego łańcucha SCSI nie można mieszać urządzeń standardowych i różnicowych. Nie będziemy wgłębiać się w szczegóły interfejsu SCSI, ponieważ nie są one istotne dla Linuxa. Jeśli chcesz uzyskać więcej informacji, przejrzyj dokumentację dołączaną do sterownika, która zwykle zawiera teoretyczny opis interfejsu.
Obsługiwane urządzenia SCSI
Nie można, niestety, założyć, że jeżeli Linux obsługuje interfejs SCSI, to każde urzą-dzenie SCSI będzie działać poprawnie. Do każdej wersji systemu dołączany jest plik, w którym znajdują się informacje o obsługiwanych urządzeniach. Zajrzyj do niego przed zakupem nowej karty kontrolera czy innego urządzenia. Niektóre urządzenia rozprowadzane są wraz z poprawkami w kodzie jądra systemu (ang. patch), dzięki którym urządzenie może być obsługiwane. Musisz upewnić się wtedy, czy poprawki przeznaczone są do Twojej wersji jądra, a następnie przekompi-lować jądro z nowymi sterownikami. Czasem poprawki nie są rozprowadzane z urzą-dzeniami, ale można je znaleźć na stronach WWW producenta.
Sterowniki SCSI
Każdemu urządzeniu w systemie Linux musi odpowiadać plik urządzenia - pod tym względem urządzenia SCSI nie są żadnym wyjątkiem. W większości przypadków Li-nux jest rozprowadzany wraz z pełnym zestawem takich plików, które wymagają tyl-ko skonfigurowania. Jeśli nie jesteś jeszcze za pan brat ze sterownikami, plikami urzą-dzeń oraz głównymi i pobocznymi numerami urządzeń, zajrzyj do rozdziału 33. "Urządzenia".
Dyski twarde
Dyski SCSI zawsze są urządzeniami blokowymi, a ich numer główny powinien mieć wartość 8. W przeciwieństwie do systemów BSD, Linux nie obsługuje bezpośredniego dostępu do dysków SCSI. Dla każdego dysku rezerwowanych jest 16 numerów pobocznych. Numer 0 reprezentu-je cały dysk, numery od 1 do 4 - partycje podstawowe, od 5 do 15 - partycje rozsze-rzone. W Linuxie numery poboczne dysków są przydzielane dynamicznie, rozpoczynając od najniższej wartości identyfikatora SCSI. Zgodnie z przyjętą powszechnie konwencją dyski twarde SCSI nazywają się /dev/sdX (na przykład /dev/sda, /dev/sdb), a ich poszczególne partycje - /dev/sdXY (na przykład /dev/sda1, /dev/sda2). Linux nie sprawia problemów podczas dzielenia dysków SCSI na partycje, ponieważ potrafi komunikować się bezpośrednio z kontrolerem. Każdy dysk jest widziany tak, jak widzi go kontroler, z numerami bloków zaczynającymi się od 0 do najwyższego numeru (i przy założeniu, że wszystkie bloki są pozbawione błędów). W ten sposób ła-two jest uzyskać informacje o geometrii dysku (dla porównania, DOS wymaga odwzo-rowania numerów bloków na adresy w formacie głowica/cylinder/sektor, które nie są zbyt wygodne, choć pozwalają na bezpośrednią manipulację zawartością dysku). Możesz przeznaczyć cały dysk twardy dla systemu Linux - wtedy program instalacyj-ny zajmie się zakładaniem partycji. Można również podzielić dysk na partycje linuxo-wym lub DOS-owym programem fdisk, dzieląc dostępną przestrzeń pomiędzy różne systemy operacyjne. W systemach obsługujących zarówno urządzenia SCSI jak i IDE, może być konieczna zmiana ustawień BIOS-u tak, by można było uruchomić system z dysku SCSI.
Napędy CD-ROM
Napędy CD-ROM, w których wielkość bloku danych wynosi 512 lub 2048 bajtów, bę-dą w systemie linuxowym działać prawidłowo, nie będą natomiast działać pozostałe typy napędów. Nie powinno to raczej sprawiać problemów, ponieważ inne napędy są rzadkością. Dyski CD-ROM zapisywane są w kilku różnych formatach i - niestety - nie wszystkie z nich dają się odczytać w systemie linuxowym. Najważniejszym, międzynarodowym standardem jest ISO9660, ale nie wszystkie płyty są z nim zgodne, ponieważ został on wprowadzony dość długo po rozpowszechnieniu się napędów CD-ROM. Numer główny CD-ROM-u z interfejsem SCSI to 11, natomiast numery poboczne przydzielane są dynamicznie (pierwsze urządzenie otrzyma numer 0, drugie - 1 itd.). Poszczególne napędy nazywają się /dev/srX, np. /dev/sr0, /dev/sr1, lub też /dev/scdX, np. /dev/scd0, zależnie od wersji systemu. Aby możliwy był odczyt danych z dysku CD-ROM, należy zamontować zawarty na nim system plików. Można to zrobić ręcznie lub zamieścić odpowiednie polecenie w jednym z plików inicjalizacyjnych. Ma ono postać:
mount nazwa_urządzenia punkt_zamontowania, np.:
mount /dev/sr0 /mnt/cdrom
Jeśli Twój CD-ROM nie montuje się poprawnie po wydaniu takiego polecenia, przy-czyną może być niewłaściwy format dysku, brak katalogu, w którym system plików ma być zamontowany, lub brak wpisu w pliku /etc/fstab. Wpis taki powoduje, że domyślnym typem systemu plików zapisanego na dysku CD-ROM jest ISO9660. W takim przypadku możesz użyć pełniejszej wersji polecenia:
mount -t iso9660 /dev/sr0 /mnt/cdrom
Aby możliwe było zamontowanie systemu plików zapisanego na płycie CD-ROM, ją-dro systemu musi obsługiwać system plików ISO9660. Jeśli tak nie jest, trzeba je prze-kompilować załączając odpowiednie opcje. Linux próbuje zablokować otwieranie napędu w czasie, gdy dysk jest zamontowany. Jest to zabezpieczenie przed próbą zmiany dysku bez poinformowania o tym systemu operacyjnego. Nie wszystkie napędy pozwalają na to, ale jeśli nie możesz wyjąć dysku, to najprawdopodobniej oznacza to, że najpierw trzeba go odmontować poleceniem umount punkt_zamontowania (nawet jeśli nie jest aktualnie używany).
Napędy taśmowe
Linux obsługuje kilka typów napędów taśmowych SCSI. Przed zakupem powinieneś sprawdzić, czy dany model jest obsługiwany, przeglądając dokumentację dołączoną do dystrybucji. Najpopularniejsze modele, takie jak Archive Viper firmy QIC, Exabyte, Wangtek 5150S i napędy DAT działają w systemie Linux bez zarzutu. Napędy taśmowe mają zwykle numer główny 9, a numery poboczne przydzielane są dynamicznie. Nazwy napędów nieprzewijanych mają przeważnie postać /dev/nrstX (np. /dev/nrst0), a napędów przewijanych - /dev/rstX (np. /dev/rst1). W przypadku napędów nieprzewijanych najstarszy bit numeru pobocznego jest ustawio-ny, więc pierwsze urządzenie tego typu będzie miało numer główny 9, a poboczny 128. Ogólnie Linux obsługuje zarówno urządzenia o stałej, jak i o zmiennej długości bloku, pod warunkiem, że jego długość jest mniejsza od długości bufora sterownika, która jest ustawiona w większości dystrybucji na 32 kB (ale może zostać zmieniona). Parametry napędu - takie jak długość bloku, buforowanie czy gęstość taśmy - ustawiane są pole-ceniem ioctls lub za pomocą programu mt.
Inne urządzenia
Dostępnych jest również wiele innych urządzeń opartych na interfejsie SCSI, takich jak skanery, drukarki, dyski wymienialne itp. Takie urządzenia obsługiwane są przez ogól-ny sterownik SCSI. Sterownik ten udostępnia interfejs służący do wysyłania poleceń do dowolnego urządzenia SCSI. Sterownik ogólny SCSI używa trybu znakowego i ma numer główny 21. Numery po-boczne są przydzielane dynamicznie - 0 dla pierwszego urządzenia, 1 dla drugiego itd. Odpowiednie urządzenia nazywają się /dev/sg0, /dev/sg1 itd.
SCSI - rozwiązywanie problemów
Wiele często spotykanych przy pracy z interfejsem SCSI problemów da się łatwo roz-wiązać. Najtrudniej jest znaleźć ich źródło. Czasem pomaga czytanie komunikatów diagnostycznych wyświetlanych podczas uruchamiania systemu i inicjalizacji magistrali SCSI. Poniżej zebraliśmy najczęściej występujące problemy z urządzeniami SCSI wraz z rozwiązaniami, które pomogą w większości przypadków Wszystkie identyfikatory przydzielone są jednemu urządzeniu SCSI: Urządze-nie ma przypisany ten sam numer, który jest przypisany kontrolerowi (zwykle 7). Należy zmienić ustawienie odpowiedniej zworki. Wszystkie dostępne numery LUN są zajęte przez dane urządzenie: Prawdopo-dobnie posiadasz starą wersję oprogramowania firmowego. W pliku /usr/src/linux/ drivers/scsi/scsi.c w definicji zmiennej blacklist zawarta jest lista "nieposłusznych" urządzeń - możesz spróbować dodać swo-je urządzenie do tej listy i przekompilować jądro. Jeśli to nie pomaga, skontak-tuj się z producentem. Komunikat "time out": Upewnij się, że przerwania, z których korzysta kontro-ler, są ustawione prawidłowo oraz że nie ma żadnych konfliktów IRQ, DMA czy portów wejścia/wyjścia z innymi urządzeniami. Komunikaty "sense error": Komunikaty te spowodowane są zwykle wadli-wymi przewodami lub brakiem terminatorów. Upewnij się, że łańcuch SCSI jest prawidłowo zakończony z obu stron. Nie używaj terminatora w środku łańcucha - to również sprawia problemy. Jeśli używasz długich przewodów, możesz spróbować zamontować aktywne terminatory zamiast pasywnych. Napęd taśmowy nie jest rozpoznawany podczas uruchamiania systemu: Spró-buj uruchomić system z włożoną taśmą. Jądro obsługujące sieć nie pracuje poprawnie z urządzeniami SCSI: Procedu-ra autoprobe używana dla wielu sterowników sieciowych może zakłócać działanie sterownika SCSI. Spróbuj wyłączać po kolei sterowniki, aż znaj-dziesz ten sprawiający problemy, a następnie skonfiguruj go ponownie. Urządzenie SCSI zostało wykryte, ale system nie potrafi z niego korzystać: Prawdopodobnie nie masz odpowiedniego pliku urządzenia. Plik taki powinien znaleźć się w katalogu /dev, powinien również mieć przypisany odpowiedni główny i poboczny numer urządzenia. Odpowiedni plik można stworzyć za pomocą programu mkdev. Kontroler SCSI nie działa prawidłowo, jeśli używa mapowanych adresów wejścia / wyjścia: Problem ten jest dość powszechny w przypadku sterowni-ków Trantor 128 i Seagate; jest on spowodowany nieprawidłowym buforowa-niem portów wejścia / wyjścia. Aby rozwiązać ten problem, należy wyłączyć buforowanie portu używanego przez kontroler (w ustawieniach XCMOS) lub, jeśli nie jest to możliwe, całkowicie wyłączyć buforowanie portów wejścia / wyjścia. System nie potrafi znaleźć żadnych urządzeń SCSI (komunikat scsi: 0 hosts): Procedura autoprobe dla sterownika opiera się na danych podawanych przez BIOS i nie potrafi prawidłowo uruchomić kontrolera. Problem ten występuje w przypadku urządzeń: Adaptec 152x, Adaptec151x, Adaptec AIC-6260, Adaptec AIC-6360, Future Domain 1680, Future Domain TMC-950, Future DomainTMC-8xx, Trantor T128, Trantor T128F, Trantor T228F, Seagate ST01, Seagate ST02 i Western Digital 7000. Sprawdź, czy BIOS kontrolera jest załączony i czy nie powoduje konfliktu z BIOS-em jakiegoś innego urządze-nia. Jeśli BIOS jest załączony, znajdź jego "podpis" uruchamiając program systemu DOS debug. Przykładowo, użyj polecenia d=c800:0 programu debug, aby sprawdzić, czy kontroler potwierdzi swoją obecność (jeśli sterownik używa adresu 0xc8000). Jeśli karta nie odpowiada, zmień ustawienia adresu. System SCSI czasem zawiesza się: Możliwych powodów jest wiele, nie wyłą-czając uszkodzenia karty sterownika. Sprawdź ją jakimś programem diagno-stycznym. Spróbuj użyć innego kabla. Jeśli system zawiesza się tylko wtedy, gdy pracują równocześnie jakieś urządzenia, jest to prawdopodobnie wina oprogramowania firmowego - skontaktuj się wówczas z producentem. Mo-żesz również sprawdzić, czy na dysku twardym nie występują uszkodzone sektory, które mogą być przyczyną najróżniejszych objawów.

Praca w sieci
TCP/IP
Linux oferuje użytkownikowi pełną implementację TCP/IP, protokołu używanego po-wszechnie w Internecie i sieciach lokalnych opartych o systemy UNIX-owe. Wszystko, czego potrzebujesz, by stworzyć własną sieć lub podłączyć się do istniejącej, to karta sieciowa, trochę kabla i kilka zmian w plikach konfiguracyjnych. Proces konfiguracji sieci przebiega zawsze tak samo, bez względu na to, czy łączysz ze sobą dwa komputery stojące w jednym pokoju, czy też podłączasz się do sieci, w któ-rej jest już 5000 innych komputerów. TCP/IP jest protokołem otwartym, tzn. jego specyfikacja techniczna jest ogólnodo-stępna i każdy może go zaimplementować w swoim programie czy sprzęcie. Dzięki te-mu stał się on bardzo popularny - dostępne są wersje tego protokołu dla wszystkich chyba platform. Jego największą zaletą jest fakt, że możliwe jest nawiązanie połącze-nia bez względu na to, jaki system operacyjny używany jest w komputerze. Ujmując rzecz precyzyjniej, TCP/IP nie jest pojedynczym protokołem, ale zestawem kilkunastu protokołów, z których każdy jest przeznaczony do innych zadań. Wszyst-kie te protokoły używają jednak wspólnych komponentów do wysyłania i odbierania pakietów danych. Dwa główne protokoły wchodzące w skład TCP/IP to Transmission Control Protocol i Internet Protocol (od nich właśnie wzięła się nazwa TCP/IP). Protokoły można podzielić ze względu na funkcje, do jakich są przeznaczone.
Transport. Poniższe protokoły używane są do przenoszenia danych pomiędzy systemami.
- TCP (Transmission Control Protocol). Usługa oparta na połączeniu, tzn. oba porozumiewające się systemy komunikują się przez cały czas.
- UDP (User Datagram Protocol). Usługa bezpołączeniowa, tzn. nie wymagająca bezpośredniego połączenia pomiędzy maszynami przez cały czas.
Kierowanie przepływem danych (ang. routing). Poniższe protokoły stworzono do adresowania danych tak, by jak najszybciej trafiły na miejsce przeznaczenia. Obsługują one również dzielenie większych porcji informacji na małe bloki.
- IP (Internet Protocol). Obsługuje transmisję danych.
- ICMP (Internet Control Message Protocol). Obsługuje przesyłanie informacji o statusie IP, takich jak komunikaty o błędach czy o zmianach struktury sieci, mogących mieć wpływ na kierowanie przepływem danych.
- RIP (Routing Information Protocol). Jeden z kilku protokołów używanych do znajdowania najlepszej drogi przepływu danych.
- OSPF (Open Shortest Path First). Inny protokół służący do znajdowania najlepszej drogi przepływu danych.
Adresowanie. Poniższe protokoły obsługują adresowanie maszyn w sieci, zarówno poprzez numery IP, jak i nazwy symboliczne.
- ARP (Address Resolution Protocol). Określa niepowtarzalny numer sieciowy maszyny.
- DNS (Domain Name System). Znajduje numer maszyny na podstawie jej nazwy.
- RARP (Reverse Address Resolution Protocol). Określa numer maszyny w sieci, ale odwrotnie niż ARP.
- BOOTP (Boot Protocol). Pozwala uruchomić urządzenie podłączone do sieci na podstawie informacji dostarczonych przez serwer.
Usługi dla użytkowników. Do tych aplikacji użytkownicy mają bezpośredni dostęp.
- FTP (File Transfer Protocol). Pozwala na łatwy transport plików z jednego komputera na drugi za pomocą protokołu TCP. - TFTP (Trivial FTP). Prosta aplikacja do transmisji plików, oparta na protokole UDP.
-TELNET . Pozwala na logowanie się do systemu z konsoli zdalnej.

Obsługa bramek sieciowych. Poniższe usługi pozwalają przekazywać informacje o kierowaniu danymi, informacje o statusie i obsługiwać przepływ danych w sieciach lokalnych.
- EGP (Exterior Gateway Protocol). Przesyła informacje o kierowaniu danymi do sieci zewnętrznych.
- GGP (Gateway-to-Gateway Protocol). Przesyła informacje o kierowaniu da-nymi pomiędzy bramkami internetowymi.
- IGP (Interior Gateway Protocol). Przesyła informacje o kierowaniu danymi w obrębie sieci lokalnej.
Inne. Ważne usługi nie pasujące do żadnej z powyższych kategorii.
- NFS (Network File System). Pozwala na montowanie katalogów jednego komputera w innym komputerze i dostęp do nich tak, jakby były katalogami lokalnymi.
- NIS (Network Information Service). Ułatwia zarządzanie kontami i hasłami użytkowników.
- RPC (Remote Procedure Call). Pozwala aplikacjom komunikować się ze sobą za pomocą wywołań funkcji.
- SMTP (Simple Mail Transfer Protocol). Protokół transmisji poczty pomiędzy maszynami.
- SNMP (Simple Network Management Protocol). Używany do otrzymywania informacji o konfiguracji TCP/IP i oprogramowania. Do prawidłowej pracy wymaga zainstalowania pętli zwrotnej. Choć od czasu do czasu zdarzają się uaktualnienia standardu TCP/IP poprawiające działanie dostępnych funkcji lub implementujące nowe usługi, kolejne wersje pozosta-ją kompatybilne z poprzednimi.
Wymagania sprzętowe
W zasadzie można skonfigurować TCP/IP nawet bez karty sieciowej czy podłączenia do sieci, używając tak zwanej pętli zwrotnej (ang. loopback). Metoda ta pozwala na porozumiewanie się protokołu TCP/IP z innym oprogramowaniem bez opuszczania komputera. Tworzona jest po prostu pętla pomiędzy wyjściem i wejściem programu. Jest to metoda stosowana powszechnie do testowania konfiguracji TCP/IP, również niektóre programy wymagają pętli zwrotnej do poprawnej pracy. Sterownik pętli zwrotnej zawsze ma numer sieciowy 127.0.0.1. Jeśli jednak chcesz podłączyć się do sieci, karta sieciowa jest niezbędna. W systemie Linux używane są karty Ethernet, zaprojektowane właśnie do obsługi protokołów TCP/IP. Często spotkasz się z określeniem pakiet (ang. pocket). Pakiet to pewna ilość danych i instrukcji sterujących, złożona razem przez protokół TCP/IP i przesyłana po-przez sieć. Wszystkie dane przed przesłaniem dzielone są na pakiety, a następnie po-nownie łączone w miejscu przeznaczenia. Większość kart Ethernet dostępnych dziś na rynku jest kompatybilna z systemem Li-nux, ale przed zakupem nowego sprzętu zawsze warto sprawdzić to w dokumentacji. Wszystkie popularniejsze karty sieciowe (włączając w to modele Plug-and-Play prze-znaczone dla systemu Windows 95) współpracują z Linuxem, czasem jednak koniecz-ne jest ręczne ustawienie numeru przerwania IRQ i adresu wejścia / wyjścia. Jeżeli zamierzasz łączyć się z siecią przez telefon, wówczas nie potrzebujesz karty sie-ciowej, ale modemu kompatybilnego z usługą, której zamierzasz używać. Przykłado-wo, aby użyć protokołu SLIP (Serial Line Interface Protocol), potrzebujesz modemu pracującego z prędkością co najmniej 14400 kbps (protokół V.32bis).
Pliki konfiguracyjne
Załóżmy, że posiadasz typowy komputer PC i kartę Ethernet i chcesz skonfigurować je tak, by móc używać sieci opartej na TCP/IP. W większości takich przypadków podana poniżej procedura zadziała. Ze względu jednak na mnogość wersji Linuxa i możliwość potencjalnych konfliktów ze wszystkimi chyba urządzeniami w systemie, a także spe-cyficzne wymagana niektórych kart, poniższy tekst powinien być traktowany tylko ja-ko przewodnik. Jeśli TCP/IP nie działa prawidłowo po skonfigurowaniu zgodnie z poniższymi wska-zówkami, powinieneś uważnie przejrzeć jeszcze raz pliki konfiguracyjne i na podstawie komunikatów o błędach spróbować zlokalizować problem. W razie niepowodzenia pomocy możesz szukać w grupach dyskusyjnych poświęconych Linuxowi i w innych źródłach informacji. Aby móc skonfigurować TCP/IP, powinieneś najpierw zainstalować oprogramowanie do obsługi sieci. Również jądro systemu musi obsługiwać sieć - jeśli tak nie jest, musisz je przekompilować (obsługa sieci instalowana jest domyślnie, ale jeśli instalacja syste-mu przebiegała w jakiś niestandardowy sposób, sieć może nie być zainstalowana). Najpierw zajmiemy się konfigurowaniem karty sieciowej. Następnie przedstawimy modyfikacje tego procesu niezbędne przy konfigurowaniu połączenia modemowego.
Zanim zaczniesz
Zanim przystąpisz do modyfikowania plików systemowych, powinieneś poświęcić parę minut na znalezienie kilku informacji, które będą później potrzebne. Najlepiej zapisz je gdzieś na kartce, aby do różnych plików konfiguracyjnych nie wprowadzić przypad-kiem różnych wartości.
Adres IP
Najpierw musisz poznać swój adres IP (nazywany również adresem internetowym). Na jego podstawie identyfikowany jest każdy komputer podłączony do sieci. 32-bitowy adres używany w sieciach opartych na protokole TCP/IP jest podzielony na cztery ośmiobitowe części, rozdzielone kropkami, na przykład 155.25.25.16 czy 147.23.145.2. Dla wygody, adresy IP dzielą się na dwie części; pierwsza identyfikuje samą sieć, na-tomiast druga jest numerem komputera w danej sieci. Jeśli chcesz samodzielnie podłączyć się do Internetu, musisz skontaktować się z Inter-net Network Information Center, instytucją, która przydziela numery IP tak, by się nie powtarzały (opierając się na wielkości sieci). Jeśli nie planujesz podłączenia do Interne-tu, możesz wybrać sobie dowolny adres IP. Dla zapewnienia elastyczności adresy IP przydzielane są w zależności od wielkości sie-ci. Sieci dzielą się na trzy kategorie: A (jeden bajt jest adresem sieci, pozostałe trzy - adresem maszyny w podsieci, co oznacza, że podsieć może zawierać ponad 16 milio-nów komputerów), B (dwa bajty adresu sieciowego i dwa bajty adresu maszyny w podsieci - czyli ponad 65000 komputerów) i C (trzy bajty adresu sieciowego i jeden dla identyfikacji w podsieci, co oznacza, że w sieci może pracować do 254 komputerów, ponieważ numery 0 i 255 są zarezerwowane). Większość sieci to sieci klasy B i C. Istnieją ograniczenia co do wartości pierwszego bajtu adresu: w sieci klasy A musi to być liczba z zakresu od 0 do 127, w sieci klasy B - od 128 do 191, a w sieci klasy C - od 192 do 223. Ograniczenie to spowodowane jest faktem, że starsze bity pierwszego bajtu adresu zawierają informacje o klasie sieci. Nie można również używać numerów 0 i 255, zarezerwowanych dla specjalnych celów. Wiadomości przesyłane za pomocą protokołu TCP/IP zawierają w nagłówku adres IP zarówno komputera, który wysłał dane, jak i komputera, który ma je odebrać. Jeśli zamierzasz podłączyć się do istniejącej sieci, powinieneś dowiedzieć się, jakiego adresu możesz użyć. Jeśli budujesz własną sieć, którą zamierzasz podłączyć do Internetu, powinieneś skontaktować się z Network Information Center. Jeżeli jednak z Internetem i innymi sieciami zamierzasz łączyć się co najwyżej przez telefon, możesz wybrać so-bie dowolny numer IP. Jeśli konfigurujesz tylko sterownik pętli zwrotnej, w ogóle nie potrzebujesz numeru IP. Domyślną wartością jest wtedy 127.0.0.1.
Maska podsieci
Następnym numerem, który będzie potrzebny, jest maska podsieci. Znając numer IP łatwo go znaleźć samemu. Zamiast adresu sieci należy wpisać 255, a pozostałe bajty ustawić na 0. Przykładowo, jeśli chcesz podłączyć się do sieci klasy C, maska podsieci będzie miała postać 255.255.255.0. Dla sieci klasy B jest to 255.255.0.0, a dla klasy A - 255.0.0.0. Jeśli konfigurujesz sterownik pętli zwrotnej, prawidłową maską jest 255.0.0.0.

Adres sieci
Adres sieci to - w zależności od klasy sieci - pierwszy bajt, dwa lub trzy pierwsze bajty adresu IP odpowiednio dla klas A, B i C. Na przykład jeśli łączysz się z siecią klasy B, a Twój numer IP to 147.120.43.31, to adresem sieci jest 147.120.0.0. Mówiąc ściśle, jest to wynik wykonania bitowej operacji AND na adresie IP i masce podsieci. Aby otrzymać adres sieci z adresu IP, należy zastąpić w nim numer komputera zerami. Jeśli podłączasz się do sieci klasy C, a Twój adres IP to 201.12.5.23, adresem sieci bę-dzie 201.12.5.0. Przy konfigurowaniu pętli zwrotnej adres ten jest niepotrzebny.
Adres rozgłoszenia
Adres rozgłoszenia (ang. broadcast) jest używany wtedy, gdy pakiet danych ma trafić do wszystkich urządzeń podłączonych do sieci. Jest to adres sieci, w którym zera za-mienione są na 255 (na przykład jeśli Twoim adresem IP jest 147.120.42.31, adres sie-ci jest równy 147.120.0.0, a adres rozgłoszenia - 147.120.255.255). Przy konfigurowaniu pętli zwrotnej adres ten jest niepotrzebny.
Adres bramki sieciowej
Adres bramki to numer IP komputera, który jest skonfigurowany jako bramka łącząca sieć lokalną z inną siecią (np. Internet). Jeśli konfigurujesz własną sieć nie podłączoną do innych sieci, adres ten nie jest potrzebny. Zwykle bramka ma taki sam numer IP jak Twój komputer, z tym że ostatni bajt ma wartość 1, np. jeśli Twój numer IP to 147.120.43.31, to numerem bramki jest prawdo-podobnie 147.120.43.1. Taka konwencja przyjęła się już od pierwszych wersji proto-kołu TCP/IP. Przy konfigurowaniu pętli zwrotnej adres ten jest niepotrzebny.
Adres serwera nazw
W wielu większych sieciach funkcjonuje komputer przeznaczony do tłumaczenia nazw symbolicznych na numery IP i odwrotnie. Zamiana taka dokonywana jest za pomocą systemu DNS (Domain Name System). Jeśli do Twojej sieci podłączone jest takie urządzenie, właśnie jego adres jest adresem serwera nazw. Jeśli to Twój komputer ma działać jako serwer nazw (co wymaga dodatkowych kroków konfiguracyjnych, nie opisanych tutaj), powinieneś podać numer sterownika pętli zwrotnej, czyli 127.0.0.1. Przy konfigurowaniu pętli zwrotnej adres ten jest niepotrzebny, ponieważ komputer łączy się tylko sam ze sobą.
Konfigurowanie interfejsu pozornego
Interfejs pozorny jest sposobem na przydzielenie komputerowi numeru IP w przypad-ku, gdy korzysta on tylko z interfejsów SLIP i PPP. Interfejs pozorny rozwiązuje pro-blem pojawiający się w systemach nie podłączonych na stałe do sieci, w których jedy-nym prawidłowym adresem IP, pod który można wysłać dane, jest 127.0.0.1. Chociaż za pomocą protokołów SLIP i PPP możesz połączyć się ze światem, to kiedy interfejs nie jest aktywny, nie posiadasz wewnętrznego adresu IP, którego mogłyby używać aplikacje. Problem ten jest szczególne dokuczliwy, gdy trzeba używać aplikacji, które do swojego działania wymagają podania prawidłowego adresu IP. Przykładowo niektóre edytory tekstów czy narzędzia zarządzające pulpitem wymagają podania takiego adresu. In-terfejs pozorny pozwala na ustawienie adresu IP dla Twojego komputera, który nie jest wykorzystywany do niczego oprócz oszukiwania aplikacji. Konfigurowanie takiego interfejsu jest bardzo proste. Jeśli w pliku /etc/hosts jest wpisany adres IP komputera, wystarczy wydać polecenia:
ifconfig dummy nazwa_komputera
route add nazwa_komputera
Spowodują one utworzenie połączenia z Twoim własnym adresem IP. Jeśli wcześniej nie wpisałeś adresu IP do pliku /etc/hosts, musisz to najpierw zrobić.
Pliki konfiguracyjne - szczegóły
Konfiguracja systemu TCP/IP dla Linuxa nie jest trudna i polega w zasadzie na wpisa-niu za pomocą dowolnego edytora tekstów odpowiednich adresów IP do kilku plików konfiguracyjnych. Przed wprowadzeniem zmian dobrze zrobić kopię zapasową mody-fikowanych plików na wypadek problemów. Pliki konfiguracyjne systemu TCP/IP są bardzo podobne we wszystkich systemach UNIX-owych, więc jeśli kiedykolwiek konfigurowałeś TCP/IP w UNIX-ie, nie znaj-dziesz w tym rozdziale nic nowego. Jeśli jest to Twój pierwszy raz - po prostu postępuj zgodnie z podanymi niżej wskazówkami.
Pliki rc
Pliki rc (ang. run command) są przetwarzane podczas uruchamiania systemu. Proces ten kontrolowany jest przez program init. Zwykle za ich pośrednictwem uruchamiane są procesy obsługujące pocztę, drukarki itp. Tu również następuje inicjalizacja połą-czeń TCP/IP. W większości systemów linuxowych pliki rc znajdują się w katalogu /etc/rc.d. Informacje dotyczące konfiguracji TCP/IP zapisane są w dwóch plikach: rc.inet1 (w nim ustawiane są parametry sieci) i rc.inet2 (tu uruchamiane są programy rezy-dentne obsługujące TCP/IP). W niektórych systemach pliki te połączone są w jeden większy plik o nazwie rc.inet lub rc.net. Zanim zaczniesz modyfikować dane zapisane w tych plikach, najpierw upewnij się, że są one faktycznie wczytywane przez program init. Jest tak, jeśli w pliku /etc/inittab lub /etc/rc.d/rc.M znajdują się polecenia nakazujące odczytanie tych plików. Niektóre wersje Linuxa do uruchamiania programów obsługujących TCP/IP używają tylko pliku /etc/inittab, w innych zaś w pliku tym znajduje się polecenie wywołu-jące plik /etc/rc.d/rc.M (jeśli uruchamiany jest tryb wielodostępny), w którym za-pisane są odpowiednie informacje. W takim przypadku protokół TCP/IP nie jest uru-chamiany w trybie administracyjnym. Jeśli odpowiednie wpisy w którymś z powyższych plików za pomocą symbolu # na początku wiersza zaznaczone są jako komentarz - powinieneś usunąć ten symbol. Przykładowe wpisy w pliku rc.M mogą wyglądać tak:
/bin/hostname `cat /etc/HOSTNAME | cut -f1 -d .`
/bin/sh /etc/rc.d/rc.inet1
/bin/sh /etc/rc.d/rc.inet2
Jeśli w pliku /etc/inittab nie znajdziesz odniesienia do pliku rc.inet lub odniesie-nia do pliku, w którym znajduje się polecenie przetwarzania tego pliku (na przykład /etc/rc.d/rc.M w dystrybucji Slackware), musisz sam dopisać odpowiednie polece-nia. Pamiętaj, że modyfikujesz jedne z najważniejszych plików w systemie, więc wy-konaj ich kopię zapasową, najlepiej na dyskietce startowej. Zwykle w plikach inicjalizacyjnych zawarta jest spora liczba komentarzy, znacznie ułatwiających konfigurację, na przykład takich:
#IPADR="127.0.0.1"
#NETMASK=""
#NETWORK="127.0.0"
#BROADCAST=""
#GATEWAY=""
W takim przypadku wystarczy usunąć znaki # i wpisać odpowiednie numery. Jeśli któ-ryś z wpisów nie jest Ci potrzebny (na przykład numer bramki internetowej), po prostu pozostaw w odpowiednim wierszu symbol komentarza. W pliku rc.inet1 występują też odwołania do programów ifconfig i route. ifconfig jest programem służącym do konfigurowania interfejsów sieciowych, na-tomiast route jest używany do określania drogi przesyłania danych. Odwołania do tych programów konfigurujące sterownik pętli zwrotnej powinny mieć następującą po-stać:
/sbi/ifconfig lo 127.0.0.1
/sbin/route add -net 127.0.0.0
Żaden z tych wierszy nie może być zaznaczony jako komentarz. Sterownik pętli zwrotnej musi być skonfigurowany, aby system TCP/IP mógł działać prawidłowo. Poniżej tych wpisów prawdopodobnie znajduje się dość spora liczba wierszy zazna-czonych jako komentarz, służących do konfigurowania interfejsów sieciowych. Na początek spróbuj usunąć symbol komentarza z wiersza wyglądającego mniej więcej tak:
/etc/ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}
Jeśli spowoduje to problemy podczas uruchamiania systemu, spróbuj zamiast niego użyć wpisu
/etc/ifconfig eth0 ${IPADDR} netmask ${NETMASK}
eth0 to etykieta pierwszej karty Ethernet w systemie.
Na koniec, jeśli w sieci działa bramka internetowa, znajdź odpowiednie wiersze i wpisz tam jej adres. Zanim to jednak zrobisz, warto upewnić się, że wszystko inne jest skon-figurowane poprawnie - o wiele łatwiej jest znaleźć błąd w konfiguracji, jeśli bramka sieciowa nie jest używana. W pliku rc.inet2 znajdują się polecenia uruchamiające programy obsługi TCP/IP. W większości przypadków nie powinieneś go modyfikować. Możesz sprawdzić, czy wiersz wywołujący program inetd nie jest zaznaczony jako komentarz. Odpowiedni fragment będzie prawdopodobnie wyglądał tak:
if [-f ${NET}/inetd
then
echo -n " inetd"
${NET}/inetd
else echo" no INETD found. INET cancelled." exit 1
fi
Jeśli wiesz coś o programowaniu w innych językach, łatwo zrozumiesz, o co chodzi w powyższym fragmencie. Powoduje on sprawdzenie, czy w systemie znajduje się program inetd, je-śli tak - program ten zostaje uruchomiony. Jeśli odpowiedniego pliku nie ma, genero-wany jest komunikat o błędzie i dalsza część pliku nie jest przetwarzana. Inne programy, takie jak named czy routed, nie są wymagane do poprawnej pracy TCP/IP. Jeśli nie jesteś pewny, czy chcesz korzystać z oferowanych przez nie możliwo-ści, możesz ich nie załączać. Możesz jeszcze chcieć uruchomić program syslogd, który potrafi zapisać do pliku wszystkie komunikaty generowane przez programy rezydentne (co ułatwia znajdowa-nie ewentualnych błędów). Ścieżka dostępu do pliku, w którym rejestrowane będą ko-munikaty, określana jest w pliku /etc/syslog.conf. Omówiliśmy już wszystkie modyfikacje, które należy wprowadzić do plików rc. Po za-instalowaniu i przetestowaniu systemu TCP/IP możesz kolejno załączać pozostałe programy, takie jak routed, named itd.
/etc/hosts
W pliku /etc/hosts znajduje się lista adresów IP i nazw symbolicznych, które się do nich odnoszą. Jest to dobre miejsce na wpisanie danych o najczęściej odwiedzanych serwerach - dzięki temu zamiast numerami IP można będzie posługiwać się ich na-zwami W małych sieciach można tu wpisać dane o wszystkich maszynach - nie trzeba będzie wówczas używać programu named. W pliku /etc/hosts musi znajdować się wpis odpowiadający komputerowi lokalne-mu - localhost (czasem również ma on nazwę loopback; odpowiada mu adres 127.0.0.1), prawdopodobnie jest tam również wpis z nazwą Twojego komputera (jeśli nadałeś mu nazwę podczas instalacji oprogramowania). Nie trudź się wpisywaniem zbyt wielu nazw dopóki nie jesteś pewny, że TCP/IP pracuje prawidłowo. Oto przykła-dowa zawartość pliku /etc/hosts:
127.0.0.1 localhost
147.12.2.42 merlin.tpci merlin
Jak widać, format wpisów jest prosty: najpierw numer IP, następnie nazwa, oddzielona od numeru tabulatorem. Można podać więcej niż jedną nazwę komputera. W powyż-szym przykładzie komputer o nazwie merlin jest częścią sieci o nazwie tpci, przewi-dziano więc również możliwość zaadresowania go jako merlin.tpci. Bardziej rozbudowana wersja tego pliku może mieć postać:
127.0.0.1 localhost
147.12.2.42 merlin.tpci merlin
147.12.2.43 wizard.tpci wizard 147.12.2.44 arthur.tpci arthur komp_michala
W powyższym przykładzie zdefiniowanych jest kilka nazw komputerów działających w obrębie jednej sieci (posiadających takie same numery sieci). Jeden z komputerów dostępny jest pod trzema różnymi nazwami. Jeśli używasz tylko sterownika pętli zwrotnej, jedynym wpisem w pliku /etc/hosts powinien być numer 127.0.0.1 z nazwą localhost i ewentualne nazwą Twojego komputera.
/etc/networks
W pliku /etc/networks znajduje się adres sieci lokalnej i adresy sieci, z którymi czę-sto się łączysz. Plik ten jest używany przez program route, uruchamiany w pliku rc.inet1. Dzięki niemu zamiast używać adresu sieci można podać jej nazwę, np. za-miast wpisywać 149.23.24 wpisać po prostu siec_wojtka. W pliku /etc/networks powinny znaleźć się wpisy dla każdej sieci, dla której bę-dziesz używał polecenia route. W przeciwnym przypadku generowane będą komuni-katy o błędach, a sieć nie będzie działała prawidłowo. Poniżej przedstawiamy przykładową zawartość pliku /etc/networks. Pamiętaj, że adresy sieci zawierają tylko jeden, dwa lub trzy pierwsze bajty (zależnie od wielkości sieci), pozostałe bajty są równe zero. W pliku /etc/networks znajdować się musi przynajmniej wpis loopback i localnet.
loopback 127.0.0.0
localnet 147.13.2.0
siec_wojtka 197.32.1.0
big_net 12.0.0.0
/etc/host.conf
Dane zapisane w pliku /etc/host.conf decydują o sposobie, w jaki nazwy symbo-liczne tłumaczone są na numery IP. Zwykle zawiera on dwa wiersze:
order hosts, bind
multi on
Mówią one, że przy tłumaczeniu nazw najpierw należy sprawdzić plik /etc/hosts, a następnie szukać pomocy w serwerze nazw (jeśli taki istnieje w sieci). Wpis multi pozwala na użycie więcej niż jednego numeru IP dla danego komputera (ma to zasto-sowanie w przypadku używania bramki internetowej lub w przypadku komputerów podłączonych jednocześnie do kilku sieci). Jeśli zawartość pliku /etc/host.conf jest taka, jak pliku przykładowego, nie trzeba go modyfikować.
resolv.conf
Plik resolv.conf jest używany przez program tłumaczący nazwy. Zawiera on adres serwera nazw i nazwę Twojej domeny (jeśli taką posiadasz - a musisz posiadać, jeśli jesteś podłączony do Internetu). Plik resolv.conf dla systemu merlin.tpci.com (dla którego nazwą domeny jest tpci.com) może na przykład zawierać następujący wiersz:
domain tpci.com
Jeżeli w sieci działa serwer nazw, w pliku tym powinien również znaleźć się wpis zawie-rający jego numer IP:
domain tpci.com
nameserver 182.23.12.4
Jeśli w sieci działa kilka serwerów nazw (co często zdarza się w większych sieciach), każdy z nich powinien być wpisany w osobnym wierszu. Jeżeli Twój system nie posiada nazwy domenowej, nie musisz przejmować się tym plikiem.
/etc/protocols
W systemach UNIX-owych plik /etc/protocols używany jest do identyfikacji i znajdowania numerów wszystkich dostępnych w systemie protokołów transmisji danych (każdemu z protokółów przypisany jest inny numer, ale nie jest to w tej chwili istotne). Ten plik zwykle nie wymaga modyfikacji; jest on aktualizowany automatycznie pod-czas instalacji oprogramowania. Poniżej zamieszczamy przykładową zawartość takie-go pliku:
# Internet protocols (IP)
ip 0 IP
icmp 1 ICMP
ggp 3 GGP
tcp 6 TCP
egp 8 EGP
pup 12 PUP
udp 17 UDP
hello 63 HELLO
Jeśli w Twoim systemie plik ten wygląda nieco inaczej, nie jest to powód do zmartwień. Nie trzeba go modyfikować, ale warto wiedzieć, jakie informacje zawiera.
/etc/services
W pliku /etc/services przechowywane są dane o wszystkich dostępnych usługach sieciowych. Jego również nie należy edytować. Plik ten składa się z wpisów o formacie nazwa_usługi numer_portu/protokół [inne_ nazwy ...], na przykład:
# network services
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail mailx
tftp 69/udp
# specific services
login 513/tcp
who 513/udp whod
Choć nie trzeba modyfikować zawartości tego pliku, powinieneś orientować się, jakie-go typu informacje on zawiera - pozwoli Ci to nieco lepiej zrozumieć zasadę działania systemu TCP/IP.
/etc/hostname lub /etc/HOSTNAME
W pliku /etc/hostname lub /etc/HOSTNAME (zależnie od systemu) przechowywana jest nazwa systemu, na przykład:
merlin.tpci
I to wszystko. Nazwa systemu używana jest przez większość protokołów i wiele apli-kacji, więc ważne jest jej prawidłowe ustawienie. Można ją zmienić modyfikując za-wartość tego pliku i ponownie uruchamiając komputer, ale w większości systemów dostępny jest specjalny program służący do tego celu. W systemie Linux dostępny jest program hostname, który wyświetla aktualną nazwę systemu, oraz uname, który uruchomiony z opcją -n wyświetla nazwę węzła:
$ hostname
merlin.tpci.com
$ uname -n
merlin
W niektórych wersjach Linuxa polecenie hostname wyświetla tylko nazwę komputera, nie dołączając nazwy domeny. Omówiliśmy już wszystkie pliki, które są istotne z punktu widzenia konfiguracji TCP/IP. Możesz teraz zresetować komputer i sprawdzić, czy wszystko działa jak należy.
Testowanie konfiguracji i rozwiązywanie problemów
Przyjrzyj się dokładnie informacjom wyświetlanym przy uruchamianiu systemu. Jeśli zauważysz komunikaty o błędach, pomogą Ci one w zlokalizowaniu problemu. Jeśli nie wystąpią żadne problemy, wyświetlone zostaną komunikaty o ładowaniu poszcze-gólnych programów obsługi TCP/IP.
Polecenie netstat
Za pomocą programu netstat łatwo sprawdzić, czy konfiguracja TCP/IP jest po-prawna. Program ten wyświetla informacje o statusie połączeń sieciowych. Jest to naj-częściej używanym program do diagnozowania problemów z TCP/IP. Oprócz wymienionych niżej opcji tego programu, dostępnych jest jeszcze wiele innych - jeśli chcesz dowiedzieć się on nich czegoś więcej, zajrzyj na strony man lub do jakiejś dobrej książki na temat pracy w systemach UNIX-owych.
Wyświetlanie danych o połączeniach
Polecenie netstat bez żadnych parametrów wyświetla informacje o wszystkich ak-tywnych połączeniach (bez względu na to, czy aktualnie odbywa się przez nie transmi-sja danych). Aby wyświetlić dane również o połączeniach biernych, użyj opcji -a. Dane wyjściowe programu netstat wyświetlane są w kolumnach o nazwach: Proto (typ protokołu), Recv-Q i Send-Q (ilość danych odebranych i wysłanych), Local Address (adres lokalny), Foreign Address (adres zdalny) oraz state - aktualny stan połączenia. Oto fragment takich danych:
merlin> netstat -a
Active Internet connections (including servers)
Proto  Recv-Q  Send-Q   Local Address  Foreign Address (state)
ip  0  0   *.*  *.* 
tcp  0  2124  tpci.login  oscar.1034  ESTABL.
tcp  0  0   tpci.1034  prudie.login  ESTABL.
tcp  11212  0 tpci.1035  trejis.1036  ESTABL.
tcp  0  0  tpci.1021  reboc.1024  TIME_WAIT
tcp  0  0  *.1028  *.*  LISTEN
tcp  0  0  *.*  *.*  CLOSED
udp  0  0  localhost.1036  localhost.syslog
udp  0  0  *.1034  *.* 
udp  0 0  *.*  *.* 
udp  0 0  *.*  *.* 
W powyższym przykładzie widać trzy aktywne połączenia (ich status jest oznaczony jako ESTABL.), przez jedno z nich wysyłane są dane (wartość większa od zera w ko-lumnie Send-Q). Gwiazdka oznacza, że dla danego adresu nie odnaleziono jeszcze punktu końcowego.
Statystyki interfejsu sieciowego
Za pomocą polecenia netstat -i można sprawdzić, jak ogólnie zachowuje się inter-fejs sieciowy (i na przykład sprawdzić działanie karty sieciowej). Polecenie to wyświetla nazwę interfejsu, maksymalną liczbę znaków, jaką może za-wierać pakiet (MTU), liczbę pakietów odebranych bez błędów (RX-OK), liczbę pakie-tów odebranych z błędami (RX-ERR), liczbę pakietów odrzuconych (RX-DRP) i liczbę pakietów, które nie mogły być odebrane (RX-OVR). Takie same dane są dostępne dla pakietów wysyłanych. Poniżej przedstawiamy przykładowy wynik działania tego po-lecenia:
merlin> netstat -i
Kernel Interface table
Iface  MTU  Met  RX-OK  RX-ERR  RX-DRP  RX-OVR  TX-OK  TX-ERR  TX-DRP
ĺ  TX-OVR Flags 
lo  2000  0  0  0  0  0  12  0  0  0
ĺ  BLRU  
eth0  1500  0  218  0  0  0  144  0  0  0
ĺ  BRU
Tablica kierowania przepływem danych (routing table)
Tablice kierowania przepływem danych są uaktualniane w sposób ciągły w oparciu o dane dotyczące połączeń z innymi komputerami. Jeśli chcesz uzyskać informacje o nich (o ile są dostępne w Twoim systemie), powinieneś wydać polecenie netstat -r. W poszczególnych kolumnach wyświetlone zostaną dane o maszynie docelowej, adres bramki, która zostanie użyta do przesłania danych, znacznik, czy dana droga jest ak-tywna (U) i czy prowadzi do bramki (G) czy komputera (H), licznik odniesień (Refs) po-kazujący, ile aktywnych połączeń może korzystać z danej drogi równocześnie, liczbę pakietów przesłanych do tej pory daną drogą (Use) i nazwę używanego interfejsu.
merlin> netstat -r
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
localnet * 255.255.0.0 U 0 0 262 eth0
loopback * 255.0.0.0 U 0 0 12 lo
default * 0.0.0.0 U 0 0 0 eth0
ping
Program ping (ang. Packet Internet Groper) używany jest do wysyłania i odbierania pakietów danych po to, by upewnić się, że połączenie jest aktywne. Jeśli komputer do-celowy odbierze pakiet, w którym znajduje się żądanie odpowiedzi, natychmiast wysy-ła odpowiedź do Twojego komputera. System, w którym uruchomiony jest program ping nie przestaje wysyłać pakietów aż do przerwania działania programu (na przykład kombinacją klawiszy Control+c). Po przerwaniu jego działania wyświetlane jest krótkie podsumowanie. Oto przykładowy wynik działania polecenia ping:
prudie> ping merlin
PING merlin: 64 data bytes
64 bytes from 142.12.120.12: icmp_seq=0, time=20. ms
64 bytes from 142.12.120.12: icmp_seq=1, time=10. ms
64 bytes from 142.12.120.12: icmp_seq=2, time=10. ms
64 bytes from 142.12.120.12: icmp_seq=3, time=20. ms
64 bytes from 142.12.120.12: icmp_seq=4, time=10. ms
64 bytes from 142.12.120.12: icmp_seq=5, time=10. ms
64 bytes from 142.12.120.12: icmp_seq=6, time=10. ms
--- merlin PING Statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip - min/avg/max = 10/12/20
Jeśli ping nie był w stanie połączyć się z komputerem docelowym, wyświetlane są komunikaty o błędach. Można również wywołać polecenie ping localhost, które pokaże, czy sterownik pętli zwrotnej jest skonfigurowany prawidłowo. Program ping jest przydatny, ponieważ podaje cztery ważne informacje: czy opro-gramowanie TCP/IP działa prawidłowo, czy urządzenia sieciowe może być prawidło-wo zaadresowane, czy można połączyć się z komputerem zdalnym (testując adreso-wanie i kierowanie danych) oraz weryfikuje działanie odpowiedniego oprogramowania w systemie zdalnym.

SLIP i PPP
Większość systemów linuxowych i UNIX-owych połączonych jest z Internetem za pomocą protokołów SLIP (ang. Serial Line Internet Protocol) lub PPP (ang. Point-to-Point Protocol). Oba te protokoły służą do obsługi połączenia modemowego (przez modem synchroniczny, asynchroniczny lub ISDN). Linux obsługuje również ulepszoną wersję protokołu SLIP - CSLIP (ang. Compressed SLIP). Konfigurację tych protokołów można przeprowadzić podczas instalowania TCP/IP, ale można również odłożyć ją do czasu, gdy będziesz chciał połączyć się z Internetem (ponieważ większość usługodawców internetowych wymaga łączenia się za pomocą tych protokołów). Sam proces konfigurowania protokołów SLIP i PPP nie jest skomplikowany. Jeśli bę-dziesz trzymał się podanych niżej wskazówek, całość zajmie Ci tylko kilka minut.
Konfigurowanie interfejsu pozornego
Interfejs pozorny jest sposobem na przydzielenie komputerowi numeru IP w przypad-ku, gdy korzysta on tylko z interfejsów SLIP i PPP. Interfejs pozorny rozwiązuje pro-blem pojawiający się w systemach nie podłączonych na stałe do sieci, w których jedy-nym prawidłowym adresem IP, pod który można wysłać dane, jest 127.0.0.1. Problem ten jest szczególne widoczny, gdy musisz używać aplikacji wymagających podania prawidłowego adresu IP, którego zwykle nie posiadasz jeśli nie jesteś podłączony do sieci. Konfigurowanie takiego interfejsu jest bardzo proste. Jeśli w pliku /etc/hosts jest wpisany adres IP komputera, wystarczy wydać polecenie tworzące odpowiedni inter-fejs i powiadomić system, że może za jego pośrednictwem przesyłać dane:
ifconfig dummy nazwa_komputera
route add nazwa_komputera
Powyższe polecenia spowodują utworzenie połączenia z Twoim własnym adresem IP. Jeśli wcześniej nie wpisałeś adresu IP do pliku /etc/hosts, musisz to najpierw zrobić, dopisując do niego wiersz:
127.0.0.1 loopback
W niektórych wersjach Linuxa zamiast programów ifconfig i route używa się od-powiednich programów obsługiwanych za pomocą menu. W większości przypadków sterownik pętli zwrotnej jest konfigurowany automatycznie przy instalacji Linuxa. Sprawdź, czy w pliku /etc/hosts znajduje się wiersz zawierający adres 127.0.0.1. Je-śli nie, dodaj go i uruchom ponownie komputer.
Konfiguracja protokołu SLIP
Protokół SLIP używany jest przy kontaktowaniu się z usługodawcą internetowym i do połączeń pomiędzy dwoma komputerami. Nawiązywanie połączenia przez modem odbywa się w zwykły sposób, a następnie SLIP przejmuje kontrolę nad połączeniem. Sterownik SLIP powinien być częścią jądra systemu - jeśli tak nie jest, należy je prze-kompilować. Większość sterowników SLIP obsługuje również protokół CSLIP, umoż-liwiający kompresję nagłówków, co prowadzi do uzyskania większej szybkości przesy-łania danych (nie każdy usługodawca internetowy pozwala jednak na połączenia CSLIP - powinieneś to sprawdzić, zanim zaczniesz konfigurację). W większości systemów linuxowych do obsługi protokołu SLIP musi być przeznaczony jeden z portów szeregowych, co oznacza, że nie będzie go można używać do innych celów. Kernel używa programu SLIPDISC (ang. SLIP Discipline) do kontrolowania portu szeregowego i blokowania dostępu do niego aplikacjom próbującym wykorzy-stać go w inny sposób nawet wtedy, gdy protokół SLIP nie jest wykorzystywany.
Protokół SLIP
Połączenia SLIP obsługiwane są przez dwa programy: dip i slattach. Oba mogą zo-stać użyte do zainicjalizowania połączenia. Nie można natomiast do tego celu użyć standardowych programów komunikacyjnych. Przeznaczenie obu programów jest nieco różne. slattach, który po prostu podłącza się do portu szeregowego, używany jest gdy istnieje stałe połączenie z serwerem SLIP (wtedy niepotrzebna jest obsługa modemu ani potwierdzanie transmisji). Program dip obsługuje inicjalizowanie połączenia, logowanie i potwierdzanie transmisji. Powinieneś go używać, jeśli łączysz się przez modem. Można go również użyć, by skonfigurować system jako serwer SLIP, pozwalając innym łączyć się z Twoim komputerem. SLIP jest protokołem bardzo prostym, ponieważ w transmisji danych biorą udział tyl-ko dwa urządzenia: Twój komputer i serwer. Po nawiązaniu połączenia, SLIP przesyła numer IP, który będzie później używany. Niektóre systemy wysyłają ten sam numer za każdym razem (adresowanie statyczne), inne natomiast mają różne numery przy róż-nych połączeniach (adresowanie dynamiczne). Konfigurowanie obu typów połączeń wymaga nieco innych zabiegów. Najłatwiejszym sposobem na to, aby przeznaczyć port szeregowy do połączeń SLIP, jest użycie programu slattach. Jest on dostępny w przeważającej większości syste-mów linuxowych. Jego argumentem powinna być nazwa portu szeregowego. Przykła-dowo, aby do połączeń SLIP przeznaczyć drugi port szeregowy, wydaj polecenie
slattach /dev/cua1 &
Gdyby po poleceniu tym nie postawić znaku & powodującego uruchomienie go w tle, konsola przestałaby być dostępna. Powyższe polecenie można również wpisać do któ-regoś z plików inicjalizacyjnych. Po uruchomieniu programu slattach, port szeregowy jest podłączany do pierwszego urządzenia SLIP (zwykle /dev/sl0). Jeśli używasz więcej niż jednego portu do połą-czeń SLIP, musisz uruchomić program slattach odpowiednią liczbę razy. Domyślnie większość systemów linuxowych używa dla takich portów interfejsu CSLIP. Jeśli nie odpowiada Ci taka sytuacja, powinieneś explicite zażądać użycia protokołu SLIP:
slattach -p slip /dev/cua1 &
Ważne jest, aby po obu stronach połączenia ustawiony był taki sam protokół - w przeciwnym przypadku prawidłowe przesyłanie danych będzie niemożliwe (istnieją jeszcze dwie wersje protokołu SLIP: slip6 - protokół sześciobitowy, oraz protokół, który potrafi dostosować się do wersji używanej przez serwer). Nie można na przykład nawiązać połączenia, jeśli jeden komputer używa protokołu slip6, a drugi CSLIP. Po przydzieleniu protokołowi SLIP portu szeregowego, należy skonfigurować interfejs sieciowy tak samo, jak dla wszystkich innych urządzeń, za pomocą poleceń ifconfig i route. Przykładowo, jeśli Twój komputer nazywa się merlin, a chcesz połączyć się z komputerem arthur, powinieneś wydać polecenia:
ifconfig sl0 merlin-slip pointtopoint arthur
route add arthur
Polecenie ifconfig służy do konfiguracji interfejsu sieciowego o nazwie merlin-slip (lokalny adres interfejsu SLIP), natomiast polecenie route powoduje dodanie odpowiedniego wpisu do tablic kierowania przesyłem danych. Jeśli chcesz używać protokołu SLIP do łączenia się z Internetem, musisz posiadać ad-res IP i odpowiedni wpis w pliku /etc/hosts. Po wykonaniu poleceń ifconfig i route możesz przetestować połączenie - powinno działać bez problemów. Jeśli w przyszłości będziesz chciał usunąć interfejs SLIP, naj-pierw należy usunąć odpowiedni wpis z tablic kierowania przesyłem danych, później wyłączyć interfejs poleceniem ifconfig, a na koniec zakończyć działanie procesu slattach. Można to zrobić w następujący sposób:
route del arthur
ifconfig sl0 down
Aby zakończyć działanie procesu slattach, trzeba podać jego numer identyfika-cyjny (wyświetlany przez polecenie ps) jako argument polecenia kill (patrz rozdział 34. "Procesy"). Jeśli posiadasz dedykowane połączenie z serwerem SLIP i chcesz używać programu slattach, plik rc.inet1 powinieneś zmodyfikować następująco:
IPADDR="123.12.3.1" #adres IP Twojego komputera
REMADDR="142.12.3.12" #adres IP serwera SLIP
slattach -p cslip -s 19200 /dev/ttyS0 #ustawienie predkosci i portu
/etc/ifconfig sl0 $IPADDR pointtopoint $REMADDR up
/etc/route add default gw $REMADDR Wiersze podobne do powyższych zwykle znajdują się już w tym pliku, tyle że zazna-czone są jako komentarz. Informacje o prędkości połączenia, protokole i porcie powi-nieneś oczywiście dostosować do swoich potrzeb. Jeśli serwer nie obsługuje protokołu cslip, zamiast niego jako parametru polecenia slattach użyj wartości slip. Jeśli serwer SLIP przydziela adresy IP dynamicznie, nie możesz wpisać adresu IP do pliku konfiguracyjnego. Większość serwerów SLIP wyświetla wtedy informację zawie-rającą przydzielony numer IP, który może zostać przechwycony za pomocą programu dip.
dip
Program dip znakomicie upraszcza łączenie się z serwerem SLIP. Aby go użyć, bę-dziesz potrzebował skryptu, zawierającego wszystkie polecenia związane z nawiąza-niem połączenia. W skrypcie takim zwykle następuje również przesłanie identyfikatora i hasła, co jeszcze bardziej upraszcza logowanie. Przykładowy skrypt dip zamieszczony jest ma stronach man dotyczących tego pro-gramu - jeśli chcesz go użyć, skieruj go do pliku i dostosuj do swoich potrzeb. Oto pro-sty skrypt (jeśli jest taka potrzeba, możesz oczywiście wpisać go ręcznie, nie zapomina-jąc o dostosowaniu danych do swojego systemu).
#
# sample.dip Dialup IP connection support program.
#
# Version: @(#)sample.dip 1.40 07/20/93
#
# Author: Fred N. van Kempen,
#
main:
# First of all, set up our name for this connection.
# I am called "uwalt.hacktic.nl" (== 193.78.33.238)
get $local uwalt.hacktic.nl
# Next, set up the other side's name and address.
# My dialin machine is called 'xs4all.hacktic.nl'
ĺ(== 193.78.33.42)
get $remote xs4all.hacktic.nl
# Set netmask on sl0 to 255.255.255.0
netmask 255.255.255.0
# Set the desired serial port and speed.
port cua02
speed 38400
# Reset the modem and terminal line.
# This seems to cause trouble for some people!
reset
# Prepare for dialing.
send ATQ0V1E1X4\r
wait OK 2
if $errlvl != 0 goto modem_trouble
dial 555-1234567
if $errlvl != 1 goto modem_trouble
# We are connected. Login to the system.
login:
sleep 2
wait ogin: 20
if $errlvl != 0 goto login_error
send MYLOGIN\n
wait ord: 20
if $errlvl != 0 goto password_error
send MYPASSWD\n
loggedin:
# We are now logged in.
wait SOMETEXT 15
if $errlvl != 0 goto prompt_error
# Set up the SLIP operating parameters.
get $mtu 296
# Ensure "route add -net default xs4all.hacktic.nl" will be done
default
# Say hello and fire up!
done:
print CONNECTED $locip ---> $rmtip
mode CSLIP
goto exit
prompt_error:
print TIME-OUT waiting for SLIPlogin to fire up...
goto error
login_trouble:
print Trouble waiting for the Login: prompt...
goto error
password_error:
print Trouble waiting for the Password: prompt...
goto error
modem_trouble:
print Trouble occurred with the modem...
error:
print CONNECT FAILED to $remote
quit 1
exit:
exit
Konfiguracja protokołu PPP
Protokół PPP jest używany częściej niż SLIP, głównie dlatego, że ma większe możliwo-ści. Jego funkcje podzielone są na dwie grupy: protokół HLDC (ang. High Level Data Link Control), który definiuje zasady przesyłania bloków informacji pomiędzy ma-szynami, oraz funkcje rezydentnego programu pppd, obsługującego protokół po na-wiązaniu połączenia przez HDLC. Podobnie jak w przypadku protokołu SLIP, najpierw następuje normalne połączenie pomiędzy dwoma komputerami poprzez modem, a dopiero później PPP przejmuje kontrolę nad połączeniem. Zanim uda Ci się ustanowić połączenie PPP, musisz skonfi-gurować sterownik pętli zwrotnej. Powinieneś również posiadać prawidłowo działający system tłumaczenia nazw, obojętnie, czy zapisany w pliku /etc/hosts, czy w postaci serwera DNS (patrz podrozdział "Używanie systemu DNS z protokołami SLIP i PPP" w dalszej części tego rozdziału).
Zakładanie konta PPP
Jeśli zamierzasz pozwolić innym użytkownikom łączyć się z Twoim systemem za po-mocą protokołu PPP, ze względów bezpieczeństwa najlepiej jest założyć konto prze-znaczone tylko do tego celu, o nazwie ppp. Nie jest to konieczne w przypadku, gdy nie przewidujesz, by ktoś miał łączyć się z systemem przez telefon. Możesz również użyć protokołu PPP logując się jako dowolny użytkownik. Jednak dla podniesienia poziomu bezpieczeństwa warto założyć konto PPP, szczególnie jeśli zamierzasz zezwolić na ob-sługę połączeń przychodzących. Proces zakładania konta PPP nie różni się niczym od zakładania konta dla nowego użytkownika - można użyć skryptu adduser czy ne-wuser, bądź też ręcznie zmodyfikować zawartość pliku /etc/passwd. Przykładowy wpis w pliku /etc/passwd definiujący konto użytkownika o identyfika-torze ppp (o numerze UID równym 201 oraz numerze GID równym 51) może mieć następującą postać:
ppp:*:201:51:PPP account:/tmp:/etc/ppp/ppscript
W tym przypadku dla użytkownika ppp hasło jest zablokowane (nikt więc nie będzie mógł się zalogować na to konto) i, ponieważ nie zostały utworzone żadne pliki, katalo-giem domowym jest /tmp. Program uruchamiany domyślnie po zalogowaniu to /etc/ppp/pppscript, będący skryptem, w którym powinieneś zapisać wszystkie in-formacje konfiguracyjne. Oto przykładowa zawartość skryptu pppscript:
#!/bin/sh
mesg n
stty -echo
exec pppd -detach silent modem crtscts
Pierwszy wiersz wymusza uruchomienie programu w interpreterze sh, bez względu na to, jaki jest aktualnie używany (patrz rozdział 14. "Programowanie w języku powło-ki"). Drugi wyłącza wszystkie próby zapisu do konsoli używanej przez PPP. Polecenie stty w trzecim wierszu powoduje, że dane wysyłane przez zdalny komputer nie będą wyświetlane na ekranie. Ostatnie polecenie uruchamia program rezydentny pppd, ob-sługujący protokół PPP. Program pppd zostanie omówiony nieco później. Nawiązywanie połączenia - program chat
Aby można było uruchomić PPP, wcześniej trzeba nawiązać połączenie z komputerem zdalnym. Można to zrobić na wiele sposobów; jednym z nich jest użycie programu chat. Pogram ten jest popularny głównie dlatego, że korzysta ze skryptów o formacie bardzo podobnym do skryptów UUCP. Aby użyć programu chat, trzeba wydać polecenie przypominające nieco wiersze pliku konfiguracyjnego protokołu UUCP o nazwie /etc/Systems. Przykładowo, aby połączyć się z komputerem dostępnym pod numerem telefonu 555-1234, można wydać polecenie:
chat "" ATZ OK ATDT5551234 CONNECT "" login: ppp word: secret1
Parametry tego programu to pary spodziewany tekst-tekst do wysłania. Po uruchomie-niu programu nie musimy czekać na przesłanie żadnego tekstu, więc pierwszy tekst jest pusty. Wysyłamy polecenie AZT, resetujące modem i oczekujemy na potwierdzenie (OK). Następnie wybieramy numer (ATDT5551234) i oczekujemy na komunikat CONNECT. Po uzyskaniu połączenia nie wysyłamy nic i czekamy na zachętę login: ze strony zdalnego komputera. Po jej uzyskaniu wysyłamy identyfikator ppp i cze-kamy na pytanie o hasło (word:). Na koniec wysyłane jest hasło (secret1 - tu należy oczywiście podstawić wartość oczekiwaną przez system zdalny) i program chat koń-czy działanie, pozostawiając jednak otwarte połączenie. Jeśli druga strona połączenia nie wysyła tekstu login: zaraz po uruchomieniu mode-mu, możesz być zmuszony do użycia polecenia BREAK, aby "obudzić" system zdalny. Można to zrobić wydając polecenie:
chat - v "" ATZ OK ATDT5551234 CONNECT "" ogin: -BREAK- ogin: ppp word: secret1
Istnieje jednak dość poważny problem związany z bezpieczeństwem, ponieważ dowolny użytkownik, który wykona polecenie ps ef zobaczy na ekranie pełną treść po-lecenia, jakie wydałeś przy uruchamianiu programu chat - nie wyłączając hasła. Można łatwo obejść ten problem zapisując odpowiednie parametry w pliku, którego nazwę należy następnie przekazać jako parametr polecenia chat:

chat -f nazwa_pliku
Plik nazwa_pliku powinien zawierać następującą treść:
"" ATZ OK. ATDT5551234 CONNECT "" login: ppp word: secret1
W skrypcie można również wykryć często spotykane problemy, np. gdy linia jest zajęta (BUSY) lub nie udało się nawiązać połączenia (NO CARRIER). Takie komunikaty gene-rowane przez modem można poprzedzić słowem ABORT, które powoduje zakończenie działania skryptu, gdy odebrana zostanie któraś z tych informacji. Przykładowo zmo-dyfikowany skrypt wygląda następująco:
ABORT BUSY ABORT `NO CARRIER` "" ATZ OK. ATDT5551234 CONNECT "" login: ppp word: secret1
Potrzebne były dwa polecenia ABORT, ponieważ pojedyncze polecenie ABORT może przyjąć tylko jeden argument. Reszta skryptu pozostała bez zmian. Pojedynczy cu-dzysłów wokół składającego się z dwóch wyrazów parametru NO CARRIER zapewnia jego prawidłową interpretację.
Uruchamianie pppd
Po nawiązaniu połączenia i zalogowaniu się na konto PPP, można uruchomić program rezydentny pppd, który przejmie kontrolę nad połączeniem PPP. Jeśli Twój komputer używa portu /dev/cua1 (oznaczenie pierwszego portu szeregowego podłączonego do modemu) do połączeń PPP z prędkością 38400 bodów, odpowiednie polecenie ma po-stać:
pppd /dev/cua1 38400 crtscts defaultroute
Nakazuje ono kernelowi przełączyć interfejs obsługujący /dev/cua1 na PPP i usta-nowić połączenie IP z komputerem zdalnym. Opcja crtscts, używana prawie zawsze przy połączeniach o prędkości powyżej 9600 bodów, załącza potwierdzanie transmisji. Twój system będzie używał własnego numeru IP, co nie powinno sprawiać problemów większości przypadków. Jeśli jednak chcesz wymusić użycie innego numeru (zarówno dla systemu lokalnego, jak i zdalnego), możesz to zrobić podając go w wierszu poleceń w następującym formacie:
lokalny_adres_IP:zdalny_adres_IP
Jeśli chcesz zmienić tylko jeden adres, drugą część po prostu pozostaw pustą, na przykład tak:
147.23.43.1:
Powyższe polecenie spowoduje wymuszenie użycia przez komputer lokalny adresu 147.23. 43.1. Za pomocą polecenia chat uruchomionego jako argument polecenia pppd można od razu nawiązać połączenie i przekazać je do programu pppd. Najwygodniej w tym celu zapisać parametry programu chat w pliku i użyć opcji -f: pppd connect "chat -f nazwa_pliku" /dev/cua1 38400 -detach crtscts modem ĺ defaultroute Plik nazwa_pliku zawiera pary tekst wysyłany-tekst oczekiwany, jak omówiliśmy to już wcześniej. Opcja -detach nakazuje programowi pppd nie odłączać się od konsoli i rozpocząć działanie w tle. Opcja modem powoduje obserwację portu szeregowego i rozłączenie "rozmowy" w przypadku zerwania połączenia. Program pppd rozpoczyna nawiązywanie połączenia PPP od wymiany adresów IP, na-stępnie ustawia parametry transmisji. Później pppd daje znać oprogramowaniu siecio-wemu, że w użyciu jest łącze PPP, ustawiając odpowiedni interfejs dla /dev/ppp0 (jeśli jest to pierwsze połączenie PPP). Na koniec wykonane zostaje odpowiednie polecenie route, kierujące dane przez to połączenie.
Testowanie konfiguracji
pppd wysyła komunikaty bezpośrednio do programu syslog (taką samą sytuację mamy w przypadku programu chat, o ile został uruchomiony z opcją -v). Jeśli masz jakieś kłopoty z połączeniem PPP, powinieneś nakazać programowi syslog rejestro-wanie wszystkich przychodzących informacji w pliku, a potem je przejrzeć. Musisz być jednak świadomy faktu, że zapisywane są również hasła i identyfikatory użytkowni-ków - z tego powodu nie powinieneś domyślnie używać opcji -v polecenia chat. Jeśli w pliku /etc/syslog.conf nie ma wpisu określającego nazwę pliku, w którym należy rejestrować komunikaty, wszystkie komunikaty przesyłane do programu syslog są tracone. Jeśli więc chcesz rejestrować informacje pochodzące z programów pppd i chat, powinieneś do tego pliku dodać wiersz:
daemon.* /tmp/ppp-log
Powoduje on zapisywanie wszystkich informacji od programów rezydentnych do pliku /tmp/ppp-log (można oczywiście użyć dowolnej nazwy pliku). W wielu wersjach Li-nuxa separatorem w tym pliku musi być znak tabulacji, nie spacja. Kiedy skrypt za-cznie działać poprawnie, pamiętaj o usunięciu tego wiersza, ponieważ rozmiary pliku z rejestrowanymi danymi szybko stają się nie do przyjęcia.
PPP a bezpieczeństwo
PPP to wspaniały protokół do komunikowania się przez modem, ale luki w bezpieczeń-stwie, które tworzy, są tak wielkie, że mógłby przez nie przejechać autobus. Drobne błędy w jego konfiguracji powodują, że każdy może uzyskać dostęp do komputera lub użyć połączenia PPP do łączenia się z innymi komputerami. Dla wyeliminowania tych problemów wprowadzono technikę uwierzytelniania (zwaną po angielsku authentica-tion), polegającą na sprawdzaniu, czy komputer/osoba na każdym z końców połącze-nia faktycznie jest tym, za kogo się podaje, i czy wolno mu używać połączenia. PPP używa dwóch metod uwierzytelniania: PAP (ang. Password Authentication Proto-col, protokół uwierzytelniania haseł) i CHAP (ang. Challenge Handshake Authentica-tion Protocol, protokół uwierzytelniania przez wezwanie do potwierdzenia). PAP przy-pomina nieco procedurę logowania. Kiedy jeden komputer wysyła identyfikator użyt-kownika i hasło do drugiego, komputer odbierający sprawdza te informacje po swojej stronie. Metoda ta jest bardzo prosta, ale ma jedną bardzo poważną wadę: każdy mo-że przechwycić połączenie i podsłuchać przesyłane hasło. CHAP rozwiązuje ten problem, dlatego jest używany o wiele częściej. Pierwszy kompu-ter wysyła dowolny ciąg znaków do drugiego komputera razem ze swoją nazwą. Drugi komputer używa takiego samego ciągu, tej nazwy oraz swojej nazwy do przeprowa-dzenia pewnych operacji na przesłanym ciągu znaków, po czym odsyła go wraz ze swoją nazwą. Pierwszy komputer przeprowadza podobną operację, po czym jeśli otrzymany ciąg znaków zgadza się z pierwszym wysłanym, połączenie uważane jest za bezpieczne. Dodatkowym zabezpieczeniem jest fakt, że taka procedura powtarza-na jest wielokrotnie podczas trwania połączenia. Kiedy dwa systemy łączą się, domyślnie nie używają mechanizmów uwierzytelniania. Kiedy uwierzytelnianie jest jednak załączone, jeden z końców połączenia próbuje użyć protokołu CHAP. Jeśli nie uda się nawiązać połączenia, wypróbowywany jest protokół PAP. Jeżeli również za pomocą tego protokołu nie uda się potwierdzić tożsa-mości komputera z drugiej strony połączenia, połączenie jest przerywane. Aby przy połączeniach używać mechanizmów uwierzytelniania, trzeba w pliku /etc/ppp/options podać opcję auth. Jeśli jednak komputery, z którymi się łączysz, nie obsługują tych mechanizmów, nawiązanie połączenia nie będzie możliwe. Informacje potrzebne do używania CHAP i PAP przechowywane są w plikach /etc/ppp/chap-secrets i /etc/ppp/pap-secrets. Jeśli zamierzasz używać uwie-rzytelniania dla wszystkich połączeń (co jest bardzo dobrym pomysłem), powinieneś zadbać o odpowiednią zawartość tych plików. Jeśli skonfigurujesz oba te pliki i zasto-sujesz opcję auth w pliku /etc/ppp/options, nikt nie będzie mógł połączyć się z Twoim systemem bez potwierdzenia swojej tożsamości. Plik /etc/ppp/chap-secrets składa się z czterech kolumn danych, zawierających odpowiednio nazwę klienta, nazwę serwera, tekst-hasło i opcjonalną listę adresów IP. Zachowanie systemu jest różne w zależności od tego, czy komputer lokalny żąda uwie-rzytelnienia od komputera próbującego się połączyć, czy też sam jest wzywany do uwierzytelnienia. Kiedy komputer lokalny ma potwierdzić swoją tożsamość, pppd sprawdza, czy w pliku tym znajduje się wpis z nazwą klienta zgodną z nazwą systemu i odpowiednią nazwą serwera, po czym używa podanego tekstu do skonstruowania wysyłanej wiadomości. Pojedynczy wpis w pliku /etc/ppp/chap-secrets może mieć następującą postać:
#client server string adresses
merlin.tpci.com big_guy.big_net.com "I hate DOS"
W takim przypadku do konstruowania wiadomości potwierdzającej używany jest tekst I hate DOS (otoczony cudzysłowem, ponieważ składa się z więcej niż jednego wyra-zu). Wraz z nazwą systemu jest on wysyłany do big_guy.big_net.com, gdzie jest kodowany wraz z nazwą tamtego systemu i odsyłany z powrotem. Tu jest odkodowywany i jeśli otrzymany zostanie ponownie tekst I hate DOS, oznacza to, że wszystko jest w porządku. W pliku /etc/ppp/chap-secrets może oczywiście znajdować się wię-cej wpisów, na przykład:
#client server string adresses
merlin.tpci.com big_guy.big_net.com "I hate DOS"
merlin.tpci.com chatton.cats.com "Meow, meow, meow"
merlin.tpci.com roy.sailing.ca "Hoist the spinnaker"
Kiedy to Twój komputer żąda potwierdzenia, procedura jest odwrócona. Program pppd szuka wpisu z nazwą zdalnego komputera w polu z nazwą klienta i z nazwą lokalnego komputera w polu serwera. Odpowiednie wpisy mają więc postać:
#client server string adresses
big_guy.big_net.com merlin.tpci.com "Size isn't everything"
Jak widać, plik /etc/ppp/chap-secrets powinien składać się z par wpisów, w których pola klienta i serwera są zamienione miejscami (ponieważ uwierzytelnianie może przebiegać w obie strony), na przykład tak:
#client server string adresses
merlin.tpci.com big_guy.big_net.com "I hate DOS"
big_guy.big_net.com merlin.tpci.com "Size isn't everything"
merlin.tpci.com chatton.cats.com "Meow, meow, meow"
chatton.cats.com merlin.tpci.com "Here, Kitty, Kitty"
merlin.tpci.com roy.sailing.ca "Hoist the spinnaker"
roy.sailing.ca merlin.tpci.com "Man overboard"
Rozmiar takiego pliku może być dość znaczny, jeśli łączysz się z większą liczbą kom-puterów. Na szczęście dozwolone jest użycie symboli wieloznacznych, takich jak sym-bol gwiazdki:
#client server string adresses
merlin.tpci.com big_guy.big_net.com "I hate DOS"
big_guy.big_net.com merlin.tpci.com "Size isn't everything"
merlin.tpci.com chatton.cats.com "Meow, meow, meow"
chatton.cats.com merlin.tpci.com "Here, Kitty, Kitty"
merlin.tpci.com roy.sailing.ca "Hoist the spinnaker"
* merlin.tpci.com "Man overboard"
W podanym wyżej przykładzie ostatni wpis pozwala każdej innej maszynie połączyć się z komputerem lokalnym za pomocą tego samego tekstu. Oczywiście, w pliku chap-secrets zdalnego komputera musi znajdować się taki sam wpis. Jest to nieco mniej bezpieczny sposób, niż użycie osobnego tekstu dla każdego komputera, ale może za-oszczędzić sporo czasu. Pole zawierające adresy IP, nie wykorzystane w powyższych przykładach, pozwala używać zarówno adresu IP, jak i nazwy symbolicznej klienta. Jest to konieczne w przypadku, gdy zdalny komputer wysyła inny numer IP za każdym razem, co normal-nie spowodowałoby błąd przy uwierzytelnianiu. Jeśli pole to jest puste, akceptowany jest dowolny adres IP. Jeśli jest w nim myślnik, dostęp z danego komputera jest zabro-niony. Plik /etc/ppp/pap-secrets jest podobny do pliku /etc/ppp/chap-secrets. Po-szczególne pola określają nazwę klienta, serwera, tekst tajnego hasła i dostępne dla systemu aliasy. Pliki te jednak różnią się nieco wyglądem, ponieważ nazwy klienta i serwera nie są nazwami pełnymi, a hasło jest pojedynczym blokiem tekstu, na przy-kład:
# /etc/ppp/pap-secrets
# user server string addresses
merlin darkstar yG55Sj28 darkstar.big_net.com
darkstar merlin 5Drbt32 merlin.tpci.com
merlin chatton MeowMeow chatton.cats.com
chatton merlin 74GRr34 merlin.tpci.com
Dwa pierwsze wiersze odpowiadają za połączenia z komputerem darkstar. Pierwszy wiersz określa, w jaki sposób ma przebiegać uwierzytelnianie w przypadku, gdy wyma-ga go komputer darkstar. Nazwa użytkownika zapisana w pierwszej kolumnie jest przesyłana do komputera zdalnego, druga kolumna określa nazwę, pod jaką widziany będzie serwer. Stwarza to problem: program pppd nie ma możliwości poznania pełnej nazwy komputera zdalnego - może tylko poznać jego numer IP. Można również po-dać numer IP lub nazwę komputera zdalnego na końcu polecenia uruchamiającego proces pppd, na przykład tak:
pppd ...... remotename chatton user merlin
W powyższym przykładzie serwer nazywa się chatton, natomiast Twój komputer - czyli klient - merlin. Dzięki możliwości podania opcji user można wymusić użycie innej niż rzeczywista nazwy systemu lokalnego.
Używanie systemu DNS z protokołami SLIP i PPP
Jeśli protokołów SLIP i PPP używasz do czegoś więcej niż czytania poczty czy przeglą-dania grup dyskusyjnych, prawdopodobnie wygodnym rozwiązaniem będzie użycie systemu DNS. Najłatwiej zrobić to wpisując adres IP serwera nazw do pliku /etc/ resolv.conf. Przykładowo, jeśli masz dostęp do serwera nazw o adresie IP 145.2.12.1, Twój plik /etc/reslov.conf powinien wyglądać tak:
#/etc/resolv.conf
domain merlin.com #domena lokalna
nameserver 145.2.12.1 #serwer nazw internetowych
Jeśli taki wpis istnieje, SLIP czy PPP wysyła prośbę o przetłumaczenie nazwy na adres IP do serwera nazw i czeka na odpowiedź. Im łatwiejszy jest dostęp do serwera nazw, tym wydajniejsza będzie taka procedura. Z tego powodu powinieneś wybierać możli-wie najbliższy serwer nazw (pod względem czasu dostępu). Użycie tego sposobu ma jednak swoje wady. Każde tłumaczenie adresu musi przejść przez linię SLIP czy PPP, co może spowodować zwolnienie działania aplikacji i zwięk-szenie ruchu w sieci. Problem zmniejszenia wydajności można obejść konfigurując bufor serwera nazw. W tym celu trzeba zmodyfikować zawartość pliku /etc/named.boot. Jeśli chcesz skon-figurować swój komputer jako bufor serwera nazw, plik ten powinien wyglądać nastę-pująco:
; /etc/named.boot
directory /var/named
cache .db.cache ;cache-only
primary 0.0.147.in-addr.arpa db.cache ;loopback
W powyższym przykładzie do określenia sterownika pętli zwrotnej użyta została lo-kalna nazwa sieciowa w formacie IN-ADDR.ARPA. Lista serwerów nazw będzie prze-chowywana w pliku .db.cache.

UUCP
Protokół UUCP (ang. UNIX to UNIX Copy) opracowany został jako prosty protokół do połączeń modemowych pomiędzy systemami UNIX-owymi. Dziś najczęściej używany jest do przesyłania poczty, pozwalając na korzystanie z niej za pośrednictwem mode-mu systemom nie podłączonym na stałe do sieci. Może również być używany do prze-glądania grup dyskusyjnych i innych podobnych usług, nie wymagających stałego po-łączenia. UUCP tworzy połączenie pomiędzy dwoma systemami UNIX-owymi. Nie może być użyty do korzystania z systemu zdalnego (typu FTP czy Telnet). Choć po-siada zabezpieczenia adekwatne do większości zastosowań, właśnie ten protokół jest najczęściej używany do włamań, ponieważ administratorzy przez niedopatrzenie czy niewiedzę nie konfigurują odpowiednio tych zabezpieczeń. W systemach linuxowych używa się kilku wersji UUCP, które są kompatybilne ze sobą pod względem przesyłania danych, ale różnią się procesem konfiguracji. Często pod-czas instalacji systemu można wybrać pomiędzy wersją Taylor UUCP i HDB (Honey-DanBer) UUCP. Wielu użytkowników Linuxa woli wersję Taylor, choć użytkownicy in-nych systemów UNIX-owych wybierają nowszą wersję HDB. W tym rozdziale przyj-rzymy się obu tym wersjom (inne są spotykane względnie rzadko, nie będziemy się wiec nimi zajmować). W pierwszej części rozdziału zajmiemy się konfiguracją UUCP, druga omawia używanie tego protokołu.
Konfiguracja protokołu UUCP
Większość plików konfiguracyjnych dotyczących UUCP znajduje się w katalogu /usr/lib/uucp. Choć proces konfiguracji może wydawać się okropnie skomplikowa-ny, w rzeczywistości tylko kilka plików wymaga modyfikacji (w każdym z nich trzeba zmienić jeden lub dwa wpisy). Wersje Taylor i HDB różnią się całkowicie pod względem konfiguracji, omówimy je więc oddzielnie. Nie musisz się martwić o to, jaka wersja działa na drugim końcu połą-czenia - nie ma to żadnego znaczenia, o ile tylko system jest skonfigurowany prawi-dłowo. W niektórych wersjach Linuxa dostępne są skrypty nieco ułatwiające konfigurację (częściej skrypty takie rozprowadzane są z wersją HDB, choć kilka skryptów jest rów-nież dostępnych dla wersji Taylor UUCP). Jeśli zdecydujesz się na ich użycie, mimo wszystko powinieneś sprawdzić wszystkie wpisy "ręcznie". W podanym niżej przykładzie zakładamy, że nazwą naszego komputera jest merlin i chcemy połączyć się za pomocą UUCP z komputerem arthur. Podczas konfiguro-wania swojego systemu powinieneś zachować format wszystkich podanych przykła-dów, wprowadzając oczywiście poprawki dotyczące nazw systemów.
Konfigurowanie Taylor UUCP
Poniżej przedstawiamy pliki biorące udział w procesie konfigurowania Taylor UUCP, wraz z ich krótkim opisem:
- /usr/lib/uucp/config - definiuje nazwę komputera lokalnego;
- /usr/lib/uucp/sys - określa, jak wywoływać systemy zdalne;
- /usr/lib/uucp/port - opisuje każdy port używany do nawiązywania połączenia i jego parametry;
- /usr/lib/uucp/dial - definiuje metody porozumiewania się z modemem przy nawiązywaniu połączeń;
- /usr/lib/uucp/dialcodes - w nim zapisywane są pełne odpowiedniki symbolicz-nych kodów numerów telefonicznych; rzadko używany, gdy istnieje połączenie bezpośrednie;
- /usr/lib/uucp/call - może zawierać identyfikator i hasło systemu zdalnego, ale obecnie jest rzadko używany;
- /usr/lib/uucp/passwd - zawiera identyfikatory użytkowników i hasła używane, gdy ktoś chce połączyć się z Twoim systemem; używany tylko w przypadku, gdy zamiast zwykłego logowania aktywny jest program uucico.
Aby nie komplikować problemu, pominiemy tu całą teorię i przejdziemy od razu do omówienia przykładowej konfiguracji. Jedyne, co musisz zrobić, to podstawić własne dane, takie jak numery telefonów, pliki urządzeń, nazwy systemów itp. Proces powi-nien być powtórzony dla każdego systemu, z którym chcesz się łączyć. Pierwszy plik, który należy zmodyfikować, zawiera nazwę systemu i kilka innych ogól-nych parametrów. Plik /usr/lib/uucp/config powinien zawierać jeden wiersz defi-niujący nazwę Twojego systemu:
nodename merlin
Słowo nodename musi rozpoczynać wiersz, po nim muszą następować spacje lub zna-ki tabulacji, a następnie nazwa systemu lokalnego. Informacja w tym pliku może być wprowadzona podczas instalowania systemu - wtedy nie trzeba jej modyfikować. Po-winieneś jednak upewnić się, że jest ona prawidłowa - w przeciwnym przypadku połą-czenie nie będzie działało. Aby można było używać UUCP, Twój system musi posiadać nazwę. Dla kompatybilności ze starszymi wersjami UUCP powinna ona składać się z siedmiu lub mniej znaków. Najlepiej, jeśli jest to ta sama nazwa, którą po-dałeś podczas instalacji systemu. Ułatwi to życie użytkownikom, którzy będą chcieli połączyć się z Twoim systemem. Przykładowo, jeśli pełna na-zwa domenowa systemu ma postać merlin.tpci.com, rozsądnie bę-dzie nadać mu nazwę UUCP merlin. Potrzebne będą również informacje o systemie, z którym zamierzasz się połączyć. Na-leży je wprowadzić do pliku /usr/lib/uucp/sys. Zwykle plik ten zawiera kilka przy-kładowych wpisów, można więc użyć jednego z nich jako szablonu, usuwając również znaki komentarza (#). Wpis określający parametry połączenia z komputerem arthur może wyglądać na przykład tak:
# system: arthur (Bill Smallwood's Linux system)
system arthur
time Any
phone 555-1212
port com1
speed 9600
chat login: merlin password: secret1 Pierwszy wiersz powyższego przykładu jest komentarzem. Następne wiersze określają różne parametry połączenia, takie jak nazwa systemu zdalnego (arthur), czas, kiedy można łączyć się z systemem (wartość Any oznacza brak ograniczeń), numer telefonu (włącznie z numerem kierunkowym itp.), port szeregowy, którego należy użyć (com1), prędkość połączenia (9600 bodów) oraz skrypt chat, automatyzujący logowanie (w tym przypadku odpowiadający na monit login: tekstem merlin, a następnie wysy-łający hasło secret1 po odebraniu tekstu password:). Większość połączeń wymaga podania identyfikatora i hasła - muszą się one znaleźć w pliku konfiguracyjnym, ponieważ UUCP nie dopuszcza sesji interaktywnych. Może to stanowić pewien problem, ponieważ pozwala innym użytkownikom na odczytanie hasła dostępu, ale ponieważ używane jest ono tylko do obsługi UUCP, nie jest to poważne zagrożenie. Poza tym odpowiednio ustalone prawa dostępu do tego pliku powinny zabezpieczać przed odczytaniem go przez użytkowników systemu. Nie wszystkie serwery wymagają podania hasła przy połączeniach UUCP. W niektórych używa się hasła pustego, w jeszcze innych - uucp. Nazwa portu podana w pliku /usr/lib/uucp/sys nie musi zgadzać się z faktyczną nazwą urządzenia w systemie Linux - odpowiednie połączenie zapewnia wpis w pliku /usr/ lib/uucp/port, w którym dla modemu o prędkości 9600 bodów powinien znaleźć się wpis podobny do takiego:
# com1 device port
port com1
type modem
device /dev/cua0
speed 9600
dialer Hayes
Pierwszy wiersz w powyższym przykładzie określa nazwę portu, używaną również w pliku /usr/lib/uucp/sys. Typ połączenia (zwykle modem) określony jest w następ-nym wierszu. Faktyczne urządzenie, do którego odnosi się dany port, określone jest w wierszu trzecim. W wielu systemach można tu wpisać identyfikator /dev/modem, który jest dowiązaniem do odpowiedniego urządzenia. Dalej następuje maksymalna prędkość połączenia modemowego. Jako ostatnia poda-na jest informacja o typie modemu, a właściwie sposobie, w jaki ma on wybrać numer. Jest to pozostałość po czasach, gdy modemy nie potrafiły same wybierać numeru i używały do tego celu urządzenia o nazwie dialer. Typ modemu podany w pliku /usr/lib/uucp/port musi być zdefiniowany w pliku /usr/lib/uucp/dial; oto przykładowy wpis:
# Hayes modem
dialer Hayes
chat "" ATZ OK ATDT\T CONNECT
Symbol \T automatycznie zastępowany jest przez numer, z jakim należy się połączyć. W niektórych systemach dane z plików /usr/lib/uucp/dial i /usr/lib/uucp/port połączone są w jeden wpis w pliku /usr/lib/uucp/sys, bezpośrednio opisujący wszystkie parametry modemu i połączenia. Komputer na drugim końcu połączenia (w tym przypadku arthur) musi posiadać w plikach konfiguracyjnych odpowiednie wpisy dla komputera merlin. Będą one po-dobne do przedstawionych powyżej, różnice wystąpią tylko w nazwach systemów, numerze telefonu, ewentualnie również w skrypcie chat i typie modemu. Dopóki oba komputery nie są skonfigurowane prawidłowo, uzyskanie połączenia nie będzie moż-liwe. W niektórych systemach dostępny jest program uuchck, który weryfikuje wpisy w pli-kach konfiguracyjnych i wyświetla odpowiednie podsumowanie. Program ten możesz również zdobyć w węzłach FTP i BBS. Domyślnie Taylor UUCP pozwala systemowi zdalnemu po połączeniu się wykonać tylko wybrane polecenia. Zwykle są to polecenia rmail i rnews. Jeśli chcesz pozwolić na używanie jakichś dodatkowych poleceń, musisz dodać wiersz zawierający ich na-zwy do pliku /usr/lib/uucp/sys; na przykład, aby zezwolić na używanie poleceń rmail, rnews, rsmtp i rdataupdate, należy dodać następujący wiersz:
system chatton
...
commands rmail rnews rsmtp rdataupdate
Wszystkie polecenia muszą znajdować się w ścieżce przeszukiwania używanej przez programy obsługi UUCP (czyli w zasadzie program uuxqt). Jeśli chcesz przesyłać pliki pomiędzy dwoma komputerami, musisz również zmodyfi-kować inne pliki konfiguracyjne. Kiedy system zdalny wysyła plik do Twojego kompu-tera, powinien być on ze względów bezpieczeństwa zapisany w katalogu /usr/spool/ uucppublic lub /var/spool/uucppublic. Nie powinieneś pozwalać na zapisanie plików gdziekolwiek indziej, ponieważ może się to skończyć zniszczeniem plików sys-temowych. Przyjęło się, że przesyłane pliki trafiają do katalogu /usr/spool/uucppublic lub /usr/ spool/uucp/system, gdzie system to nazwa systemu zdalnego. Katalogi, do których trafiać mają pliki przesyłane przez UUCP i z których można wy-syłać pliki, można określić w pliku /usr/lib/uucp/sys:
system chatton
...
local-send ~/send
local-receive ~/receive
Przy takiej konfiguracji użytkownicy Twojego systemu mogą wysyłać pliki znajdujące się w podkatalogu send katalogu uucp, a każdy plik przychodzący zostanie zapisany w podkatalogu receive. Można zezwolić na wysyłanie plików z kilku różnych miejsc, na przykład z katalogów domowych użytkowników:
local-send ~/send /home
Jeśli chcesz umożliwić obsługę żądań transferu pochodzących z komputera zdalnego, powinieneś dodać dwa wpisy:
remote-send /usr/lib/uucppublic
remote-request /usr/lib/uucppublic
Powodują one, że komputer zdalny może pobierać pliki z katalogu /usr/lib/ uucppublic, może również w tym samym katalogu zapisywać pliki. Również tu moż-na zezwolić na korzystanie z kilku katalogów, oddzielając ich nazwy spacjami. UUCP pozwala także na przesyłanie danych do innego komputera za pomocą kompu-tera pośredniczącego (ang. hopping). Przykładowo, jeśli chcesz wysyłać pocztę do sys-temu warlock, ale połączyć się z nim możesz tylko przez systemem wizard, powinie-neś poinformować o tym fakcie system UUCP. W tym celu do pliku /usr/lib/uucp/sys powinieneś dodać polecenie forward:
system wizard
...
forward warlock
Następnie należy dodać wpis dla systemu warlock, który poinformuje UUCP, że pocz-ta przychodząca od Ciebie przechodzić będzie przez system wizard:
system warlock
...
forward-to merlin
Wpis forward-to gwarantuje, że pliki zwrócone przez system warlock będą przesy-łane do systemu merlin, czyli do Twojego komputera. W przeciwnym przypadku by-łyby one usuwane jako niemożliwe do dostarczenia. Domyślnie Taylor UUCP nie pozwala na pośredniczenie w przesyłaniu poczty. Admini-strator powinien dokładnie rozważyć zezwolenie na taką działalność ze względu na po-tencjalne duże obciążenie łącza modemowego plikami pochodzącymi z innych syste-mów.
Konfigurowanie HDB UUCP
HDB UUCP jest systemem nowszym niż Taylor UUCP. Pod wieloma względami jego konfiguracja jest łatwiejsza, ale tak naprawdę oba systemy nie jest trudno skonfiguro-wać. Nazwa systemu lokalnego nie jest ustawiana w żadnym pliku konfiguracyjnym - uży-wana jest nazwa podana podczas instalacji sieci. Można ją zmienić za pomocą pole-cenia hostname. Nazwy systemów zdalnych przechowywane są w pliku /usr/lib/uucp/Systems (w niektórych starszych wersjach plik ten nazywa się /usr/lib/uucp/L.sys). Każdemu z systemów odpowiada osobny wiersz o formacie:
nazwa_systemu ogr_czasowe typ_urządzenia prędkość telefon
ĺ skrypt_logowania
Pole nazwa_systemu określa nazwę systemu zdalnego. Pole ogr_czasowe pozwala ustalić, w jakich godzinach może nastąpić połączenie. typ_urządzenia to etykieta odpowiadająca odpowiedniemu wpisowi w pliku /usr/lib/uucp/Devices. pręd-kość określa maksymalną prędkość przesyłania danych (ograniczoną zwykle prędko-ścią modemu z jednej lub z drugiej strony połączenia), telefon to numer telefonu, do którego podłączony jest system zdalny, a skrypt_logowania określa identyfikator użytkownika i hasło, które należy podać po połączeniu się z systemem (podobnie jak skrypt chat w systemie Taylor UUCP). Przykładowy wpis dla systemu zdalnego arthur może mieć postać: arthur Any ACU 9600 555-1212 login: uucp password: ĺsecret1
Wartość Any w polu ogr_czasowe nie nakłada żadnych ograniczeń co do czasu po-łączenia. Typ urządzenia o etykiecie ACU musi być zdefiniowany w pliku /usr/lib/uucp/ Devices (w starszych wersjach plik ten nazywa się /usr/lib/uucp/L-devices). Wpisy w pliku /usr/lib/uucp/Devices (lub w starszych wersjach /usr/lib/uucp/ L-devices) zawierają dane o urządzeniach, których można użyć do połączeń z systemami zdalnymi. Mają one składnię:
typ_urządzenia sterownik dialer_line prędkość dialer
ĺ [token Dialer ...]
typ_urządzenia to etykieta, która będzie używana dla danych ustawień. sterownik to nazwa urządzenia, które użyte będzie do komunikacji (zwykle port szeregowy, jak np. /dev/tty2a czy /dev/modem). Pole dialer_line nie jest używane, należy w nie wpisać myślnik. Parametr prędkość określa maksymalną prędkość przesyłania da-nych, a dialer to nazwa pliku, w którym znajdują się instrukcje dotyczące obsługi danego urządzenia. Przykładowy wpis dla modemu Hayes 9600 podłączonego do drugiego portu szeregowego może wyglądać tak:
ACU tty2A - 9600 dialHA96
Opisuje on urządzenie o etykiecie ACU, podłączone do portu /dev/tty2A (część /dev nazwy urządzenia została pominięta - HDB UUCP dopuszcza takie uproszczenie), używające programu zapisanego w pliku dialHA96 do sterowania obsługą wybierania numerów. Dla większości popularnych modemów dostępne są gotowe pliki, których nazwy należy wpisać w polu dialer. Jeśli nie jest dostępny plik opisujący komunikację z modemem, należy stworzyć od-powiedni wpis w pliku /usr/lib/uucp/Dialers o formacie:
dialer translacje oczekuj wyślij ...
dialer to etykieta odpowiadająca użytej w pliku /usr/lib/uucp/Devices. translacje to tablica translacji używana podczas wybierania numeru, pozwalająca zamienić odpowiednie znaki na pauzy itp. Pola oczekuj i wyślij to skrypt chat, dzięki któremu ustawiane są parametry pracy modemu. Znaki białe w tym skrypcie są ignorowane, chyba że znajdują się w cudzysłowach. Oto przykładowy wpis dla mo-demu Hayes 1200 Smartmodem:
hayes1200 =,-, "" AT\r\c OK\r \EATDT\T\r\c CONNECT
Przy wybieraniu numeru znaki - i = zamieniane są na , (przecinek) oznaczający pauzę. Dalej następują polecenia inicjujące modem i wybierające numer. Ponieważ w pli-ku Dialers znajdują się gotowe wpisy dla większości popularnych modemów, nie będziemy szczegółowo omawiać tego zagadnienia. Problem zezwalania na transfer plików jest nieco bardziej złożony niż w przypadku Taylor UUCP, ponieważ HDB UUCP pozwala na bardziej szczegółową konfigurację. W książkach poświęconych UUCP na temat ten poświęconych jest prawie sto stron - my skoncentrujemy się na niezbędnym minimum. Dane dotyczące praw dostępu do systemu i plików zawarte są w pliku /usr/lib/uucp/ Permissions. Format pojedynczego wpisu w takim pliku jest na-stępujący:
MACHINE=nazwa_zdalna LOGNAME=uucp \
COMMANDS=rmail:rnews:uucp \
READ=/usr/spool/uucppublic:/usr/tmp \
WRITE=/usr/spool/uucppublic:/usr/tmp \
SENDFILES=yes REQUEST=no
Pole MACHINE określa nazwę komputera zdalnego. LOGNAME to identyfikator, za po-mocą którego komputer ten (lub Twój komputer) loguje się do systemu, COMMANDS - polecenia, jakie może wykonać, READ i WRITE - lista katalogów z których może czy-tać i do których może zapisywać pliki, pole SENDFILES określa, czy dopuszcza się przesyłanie plików, a REQUEST - czy dozwolone jest żądanie przesłania plików z Two-jego systemu. Ukośniki na końcu każdego wiersza służą do ukrycia znaku nowego wiersza - dzięki temu cały wpis jest traktowany jak jeden wiersz, a jednocześnie za-chowana jest dobra czytelność tekstu. Jest to rozwiązanie typowe w systemach UNIX-owych. Kompletny wpis dla komputera zdalnego o nazwie wizard może mieć następującą postać:
MACHINE=wizard LOGNAME=uucp1 \
COMMANDS=rmail:uucp \
READ=/usr/spool/uucppublic \
WRITE=/usr/spool/uucppublic \
SENDFILES=yes REQUEST=yes
Komputer ten może pobierać i wysyłać pliki do katalogu /usr/spool/uucppublic. Może uruchomić programy mail oraz uucp. Jeśli nie chcesz, by komputer zdalny przesyłał pliki do Twojego systemu, ustaw wartość SENDFILES na równą no. Podobnie, jeśli nie życzysz sobie, by jakiekolwiek pliki były pobierane z Twojego systemu, ustaw na no wartość REQUEST.
Połączenie UUCP
Nawiązanie połączenia UUCP składa się z kilku etapów. Łatwiej będzie zrozumieć rolę plików konfiguracyjnych, jeśli przyjrzymy się przebiegowi typowej sesji UUCP. Proces nawiązujący połączenie UUCP i obsługujący przesyłanie informacji nazywa się uucico (ang. UUCP Call In/Call Out). Połączenie może być zrealizowane przez uru-chomienie uucico z nazwą zdalnego komputera podaną jako parametr:
uucico -s arthur
Przy uruchomieniu, program uucico szuka danych o systemie zdalnym w pliku /usr/lib/uucp/sys (Taylor UUCP) lub /usr/lib/uucp/Systems (HDB UUCP). Po odnalezieniu ich, odczytuje odpowiednie dane z innych plików konfiguracyjnych (/usr/lib/uucp/port i /usr/lib/uucp/dial dla Taylor UUCP albo /usr/lib/uucp/ Devices i /usr/lib/uucp/Dialers dla HDB UUCP), uruchamia połączenie modemowe i tworzy plik blokujący dostęp do portu szeregowego innym aplikacjom (sprawdzając najpierw, czy urządzenie nie jest używane przez inną aplika-cję - czyli czy nie istnieje plik LCK, np. LCK..cua0 dla pierwszego modemu). Po wykonaniu skryptu chat inicjalizującego modem i wybierającego numer, do logo-wania do komputera zdalnego używany jest skrypt chat zapisany w pliku /usr/lib/uucp/sys lub /usr/lib/uucp/System. Po zakończeniu logowania, w sys-temie zdalnym uruchamiany jest również program uucico, po czym oba programy wymieniają potwierdzenia i rozpoczyna się transfer danych. Po zakończeniu sesji komputer lokalny upewnia się, że komputer zdalny nie ma nic więcej do przesłania i przerywa połączenie. Program uucico kończy działanie.
Komunikacja bezpośrednia
Jeśli dwa komputery połączone są bezpośrednio przez port szeregowy, do przesyłania danych również można użyć protokołu UUCP. Jedyna zmiana w opisanym wyżej pro-cesie konfiguracji dotyczy konfiguracji portu. Zamiast używać urządzenia modemu, użyć należy połączenia bezpośredniego. Przykładowo, dla systemu Taylor UUCP wpis w pliku /usr/lib/uucp/sys będzie zawierał wiersz:
port direct1
a w pliku /usr/lib/uucp/port znajdzie się wpis:
port direct1
type direct
speed 38400
device /dev/cua1
Prędkość transmisji i nazwę portu szeregowego należy dostosować do rzeczywistych wartości używanych w systemie. Podobnie rzecz wygląda w przypadku HDB UUCP, z tym że odpowiednie wpisy powinny znaleźć się w plikach /usr/lib/uucp/Systems i /usr/lib/uucp/Devices.
Skrypty logowania
Skrypty logowania są częścią pliku /usr/lib/uucp/sys lub /usr/lib/uucp/System; często okazują się one najtrudniejszym krokiem konfigu-racji połączenia. Jeśli łączysz się z typowym systemem UNIX-owym, wysyłane powin-ny być tylko standardowe zachęty do wprowadzenia identyfikatora i hasła, ale w nie-których systemach nie jest to takie proste. Z tego powodu przyjrzymy się temu pro-blemowi nieco dokładniej. Ogólnie rzecz biorąc, skrypt logujący składa się z par wzorzec-akcja. Wzorzec wyszu-kiwany jest wśród znaków wysyłanych przez drugi koniec połączenia, natomiast akcja określa tekst, który ma zostać wysłany przez komputer lokalny. Prosty skrypt może wyglądać tak:
login: merlin password: secret1
W takim przypadku system czeka na odebranie tekstu login:, następnie wysyła tekst merlin, czeka na tekst password: i wysyła secret1. Skrypt można troszkę skrócić, zdając sobie sprawę, że w zasadzie interesuje nas tylko moment zakończenia komuni-katu, na który czekamy:
gin: merlin word: secret1
Takie rozwiązanie ma też inne zalety, na przykład jeśli system zdalny zamiast login: wysyła tekst Login:, skrócona forma - w przeciwieństwie do formy pełnej - zarea-guje prawidłowo. Użyteczna jest możliwość wymuszenia na maszynie zdalnej zrestartowania procesu getty. W tym celu należy wstawić myślnik i słowo BREAK, co powoduje wysłanie se-kwencji resetującej połączenie po upływie określonego czasu, na przykład tak:
ogin: -BREAK-ogin: merlin sword: secret1
W takim przypadku, jeśli komputer zdalny nie wyśle zachęty login:, po pewnym cza-sie Twój komputer wysyła sekwencję resetującą połączenie i ponownie czeka na za-chętę. Można używać również kilku znaków specjalnych. Oto znaczenie najważniejszych z nich.
\c Zapobiega wysyłaniu znaku powrotu karetki (tylko przy wysyłaniu).
\d Opóźnienie o 1 sekundę (tylko przy wysyłaniu).
\p Pauza trwająca ułamek sekundy (tylko przy wysyłaniu).
\t Wysłanie znaku tabulacji.
\r Wysłanie znaku powrotu karetki.
\s Wysłanie spacji.
\n Wysłania znaku nowego wiersza.
\\ Wysłanie znaku \.
Czasem trzeba wysłać jeden lub więcej z podanych wyżej znaków, zanim komputer zdalny zechce się odezwać. Przykładowo, poniższy skrypt wysyła przed próbą nawią-zania kontaktu kombinację powrót karetki + znak nowego wiersza:
\n\r\p ogin: merlin word:secret1
To zwykle wystarcza, by w systemie zdalnym uruchomiony został proces getty obsługujący odpowiedni port.
Modyfikowanie harmonogramu dostępu
Zarówno Taylor, jak i HDB UUCP pozwalają na podanie, kiedy można łączyć się z danym systemem. W przykładach podanych wcześniej nie było żadnych ograniczeń czasowych (w odpowiednim polu występowało słowo Any), ale takie ograniczenia mo-gą być bardzo użyteczne - czy to ze względu na różne taryfy telefoniczne, czy też po prostu na ograniczony czas działania komputera po drugiej stronie połączenia. Jeśli chcesz zezwolić na połączenia w poszczególne dni tygodnia, użyj dwuliterowych skrótów ich angielskich nazw (Mo - poniedziałek i dalej Tu, We, Th, Fr, Sa, Su), Wk dla dni roboczych, Any dla dostępu bez ograniczeń i Never dla zablokowania do-stępu. Dozwolone są również kombinacje tych wartości. Godziny dostępu podaje się w formie zakresu, w formacie 24-godzinnym. Jeśli nie zostaną określone godziny, w któ-rych można się połączyć, połączenie jest możliwe przez cały dzień. Daty i godziny podaje się nie oddzielając ich spacjami, natomiast poszczególne wpisy rozdziela się przecinkami. Oto przykładowe definicje ograniczeń, prawidłowe zarówno w systemie Taylor, jak i HDB:
Wk1800-0730 dostęp w dni robocze od 18.00 do 7.30;
MoWeFr dostęp w poniedziałki, środy i piątki;
Wk2300-2400, SaSu dostęp w dni robocze od 23.00 do 24.00 i w weekendy przez całą dobę.
UUCP a bezpieczeństwo
Prawa dostępu do plików konfiguracyjnych UUCP powinny być uważnie ustawione, tak aby protokół mógł funkcjonować prawidłowo i nie zagrażał bezpieczeństwu sys-temu. Najprościej można zapewnić to w ten sposób, że wszystkie pliki konfiguracyjne powinny być własnością użytkownika uucp, grupy uucp. W tym celu w katalogu /usr/lib/uucp należy wydać polecenia:
chown uucp *
chgrp uucp *
Ze względów bezpieczeństwa dla użytkownika uucp powinieneś założyć jakieś dobre hasło. Niektóre wersje Linuxa pozostawiają domyślnie to hasło puste, co powoduje, że system stoi otworem dla każdego, komu tylko przyjdzie do głowy zalogować się jako uucp. Prawa dostępu do plików powinny umożliwiać czytanie i zapisywanie (i wykonywanie dla katalogów) tylko dla ich właściciela. Prawo odczytu dla kogokolwiek innego może dać mu informacje o hasłach pochodzące z plików konfiguracyjnych. Kiedy program obsługi UUCP loguje się do systemu zdalnego, musi podać identyfika-tor użytkownika i hasło. Dane te są przechowywane w plikach /usr/lib/uucp/sys lub /usr/lib/uucp/Systems, powinny więc być zabezpieczone przed nieautoryzo-wanym dostępem poprzez ustalenie odpowiednich praw dostępu. Jeśli kilka innych systemów łączy się z Twoim, możesz dla wszystkich utworzyć jedno wspólne konto i hasło, można również zrobić to dla każdego systemu zdalnego z osob-na - w tym celu wystarczy dodać dla każdego systemu wpis do pliku /etc/passwd i zdefiniować dla niego (za pomocą programu passwd) odpowiednie hasło. System zdalny będzie mógł zalogować się używając takiego konta. Na użytkownikach korzy-stających z protokołu UUCP należy wymusić użycie tylko programu uucico. Odpo-wiedni wpis w pliku /etc/ passwd może wyglądać tak:
uucp1:123:52:UUCP Login for Arthur:/usr/spool/uucppublic:usr/lib/uucp/uucico
Katalogiem domowym użytkownika uucp1 w powyższym przykładzie jest /usr/ spool/uucppublic, a po zalogowaniu uruchamiany jest program uucico. Jeśli utwo-rzysz osobne konto dla każdego łączącego się z Twoim systemu, możesz dokładniej kontrolować prawa dostępu. Należy uważnie sprawdzić, jakie polecenia może wykonać dany użytkownik. Odpo-wiednie ustawienia znajdują się w plikach konfiguracyjnych UUCP. Jeśli pliki są prze-syłane dalej przez Twój system, powinieneś wiedzieć kto je przysyła i dokąd trafiają. Najważniejszą jednak sprawą jest zapewnienie, aby z systemu mogli korzystać tylko zaufani użytkownicy. Nie otwieraj dostępu dla wszystkich, bo jest to proszenie się o kłopoty. Regularnie sprawdzaj dane konfiguracyjne i prawa dostępu do plików za-wierających newralgiczne informacje.
Używanie UUCP
Po skonfigurowaniu systemu UUCP można używać go do przesyłania plików i poczty. Najpierw trzeba jednak poznać składnię adresów, która nieco różni się od używanej powszechnie w Internecie:
komputer!cel
komputer to nazwa komputera zdalnego, natomiast cel to nazwa pliku, do którego chcesz się dobrać, bądź identyfikator użytkownika. Na przykład, aby wysłać pocztę do użytkownika yvonne w systemie arthur, można użyć polecenia mail w następu-jący sposób:
mail arthur!yvonne
UUCP pozwala również na przejście przez kilka komputerów, zanim plik trafi do adre-sata. Można dzięki temu zaoszczędzić na rachunkach telefonicznych lub też dostać się do większej sieci za pomocą jednego tylko połączenia. Załóżmy, że chcesz wysłać pocztę do użytkownika bill w systemie warlock, ale nie masz z nim połączenia. Masz za to połączenie z systemem arthur, który jest połączony z systemem warlock i skonfigurowany do przesyłania poczty od Ciebie. W takim przypadku możesz wysłać pocztę poleceniem:
mail arthur!warlock!bill
Podczas dekodowania adresu odczytywana jest tylko pierwsza część (arthur), pozo-stała jest przesyłana razem z pocztą do systemu arthur. W tym systemie ponownie następuje odczytanie adresu - teraz adresatem jest system warlock; jeśli dozwolone jest pośredniczenie w przekazywaniu poczty, wiadomość zostanie przesłana do tego systemu. Droga przesłania wiadomości może być bardziej skomplikowana, na przy-kład poniższy adres powoduje przesłanie wiadomości do użytkownika alex w syste-mie vader za pośrednictwem systemów arthur, warlock i chatton:
mail arthur!warlock!chatton!vader!alex
W skomplikowanych przypadkach trudno jednak nie pomylić kolejności, w jakiej trzeba podać nazwy komputerów. Możliwość taka może być dość użyteczna w przy-padku, gdy pewna liczba użytkowników posiada lokalne połączenia pomiędzy kom-puterami - dzięki temu możliwe jest skonfigurowanie nawet dość złożonej sieci (sym-bol wykrzyknika w adresie nazywany jest po angielsku bang, cały adres może więc zo-stać odczytany jako arthur-bang-warlock-bang-chatton-bang-vader-bang-alex). Niektóre interpretery poleceń nie akceptują znaku !, ponieważ jest on za-rezerwowany do innych celów - na przykład powłoka C używa go do przywoływania poprzednio wydanego polecenia. W takim przypadku na-leży zabronić jego interpretacji, na przykład poprzedzając go symbolem \:
mail arthur\!warlock\!
W zależności od tego, jak skonfigurowany jest system, może on albo od razu po wy-słaniu wiadomości łączyć się z innym systemem, albo wstawiać wiadomości do kolejki oczekującej na wysłanie przy najbliższym połączeniu, szczególnie jeśli połączenia są dozwolone tylko w określonych godzinach. Dane dotyczące ograniczania czasu połą-czeń zapisane są w pliku /usr/lib/uucp/sys lub /usr/lib/uucp/Systems. Musisz pamiętać o tym, że jeśli systemy, przez które przesyłasz dane, nie łączą się od razu z następnym systemem, proces przesyłania wiadomości może się znacznie prze-dłużyć. Jeśli na przykład komputer łączy się z następnym systemem raz na dobę, w najgorszym przypadku może wprowadzić nawet 24-godzinne opóźnienie. Każdy na-stępny komputer pośredniczący powoduje dodatkowe opóźnienie. Nie możesz założyć, że dane przesyłane przez UUCP będą poufne. W sys-temie zdalnym może je przeglądać każdy, kto ma dostęp do katalogu UUCP. Nie w każdym systemie prawa dostępu są ustawione prawidłowo. Jeśli musisz przesłać poufne dane, najlepiej je zakoduj, podając adresato-wi odpowiedni klucz (oczywiście nie za pomocą poczty elektronicznej). W systemie UUCP wszystkie zlecenia transferu traktowane są jako zadania (ang. jobs) - z tym terminem możesz spotkać się dość często, przeglądając dokumentację doty-czącą UUCP. Zadanie to polecenie, które ma zostać wykonane w systemie zdalnym, plik, który ma zostać przesłany, czy też dowolne inne dane, które mają zostać przesła-ne pomiędzy dwoma systemami.
Przesyłanie poczty
Większość programów do obsługi poczty akceptuje adresy w formacie UUCP bez żad-nych dodatkowych zabiegów konfiguracyjnych, co upraszcza znacząco używanie tego protokołu. W poprzednim podrozdziale przedstawiliśmy przykład użycia polecenia mail z adresem w formacie UUCP. Można wykorzystać wszystkie opcje modyfikujące zachowanie polecenia mail. Dla przykładu spróbujmy za pomocą tego polecenia przesłać zawartość pliku dane_1 do użytkownika yvonne w systemie chatton przez system arthur, dołączając nagłó-wek z tematem. W tym celu należy wydać polecenie:
mail -s "Plik z danymi" arthur\!chatton\!yvonne < dane_1
Praktycznie wszystkie programy pocztowe, również te pracujące w systemie X, akcep-tują oprócz zwykłych adresów internetowych adresy w formacie UUCP, ale warto sprawdzić to w dokumentacji przed zainstalowaniem nowego pakietu pocztowego.
Przesyłanie plików
Do przesyłania plików za pomocą protokołu UUCP służy polecenie uucp, którego składnia jest następująca:
uucp [opcje] źródło cel
Opcje obsługiwane przez to polecenie różnią się nieco w zależności od wersji i typu systemu UUCP, ale większość wersji obsługuje opcje zebrane poniżej.
-c Zapobiega kopiowaniu pliku do kolejki przed wysłaniem. Do-myślnie plik, który ma zostać przesłany, jest kopiowany do katalogu kolejki. Za pomocą opcji -C można określić położe-nie tego katalogu.
-f Zapobiega odtwarzaniu struktury katalogów w systemie doce-lowym. Domyślnie struktura katalogów jest odtwarzana, moż-na również zażądać tego explicite, podając opcję -d.
-m Wysyła wiadomość do osoby, która wydała polecenie uucp, potwierdzającą zakończenie kopiowania danych.
-nużytkownik Wysyła po zakończeniu kopiowania wiadomość do użytkownika w systemie zdalnym.
Ustawienia domyślne odpowiadają większości użytkowników, choć opcja -m może być przydatna, jeśli chcesz otrzymać potwierdzenie przesłania danych. Parametry źródło i cel określają nazwy odpowiednich plików lub katalogów, analogicznie jak w przypadku polecenia cp. Trzeba jednak pamiętać, że jeśli nazwa odnosi się do systemu zdalnego, musi posiadać prawidłowy format UUCP. Przykładowo, jeśli chcesz przesłać plik dane_1 z bieżącego katalogu do katalogu /usr/spool/uucppublic w systemie arthur, powinieneś wydać polecenie:
uucp dane_1 arthur\!/usr/spool/uucppublic
Zauważ, że przed ścieżką dostępu do katalogu w systemie zdalnym pojawiła się nazwa tego systemu. Katalog /usr/spool/uucppublic jest zwykle jedynym katalogiem, do którego można przesłać dane. Adresat danych musi sam zadbać o skopiowanie ich do odpowiedniego katalogu. Jeśli chcesz wysłać plik do użytkownika bill, umieszczając go w osobnym podkata-logu, i powiadomić go o tym fakcie oraz otrzymać potwierdzenie wysłania pliku, powi-nieneś wydać polecenie:
uucp -m -nbill dane_1 arthur\!/usr/spool/uucppublic/bill/
Jeśli chcesz skopiować plik z komputera zdalnego, musisz znać jego położenie i mieć dostęp do katalogu i prawo odczytu tego pliku (lub też ktoś musi skopiować dla Ciebie ten plik do katalogu uucppublic). Poniższe polecenie skopiuje plik bigfile z katalo-gu /usr/tmp w systemie chatton do lokalnego katalogu /home/reksio:
uucp chatton\!/usr/tmp/bigfile /home/reksio
UUCP pozwala na użycie symboli wieloznacznych, ale należy otoczyć je cudzysło-wami (żeby zapobiec ich interpretacji przez interpreter poleceń powłoki). Aby skopio-wać wszystkie pliki, których nazwa zaczyna się od liter chap, zapisane w katalogu /usr/ bill/book (zakładając, że masz odpowiednie prawa dostępu) do lokalnego katalogu /usr/bigbook, wydaj polecenie:
uucp "warlock\!/usr/bill/book/chap*" /usr/bigbook
Możliwe jest także przesyłanie plików za pośrednictwem innych systemów, co wymaga posiadania odpowiednich praw dostępu we wszystkich systemach pośredniczących. Można również przesyłać pliki z jednego systemu do innego (co prawda trudno znaleźć zastosowanie dla tej sztuczki), na przykład tak:
uucp arthur\!/usr/lib/uucppublic/bigfile warlock\!/usr/lib/uucppublic/
Powyższe polecenie powoduje przesłanie pliku bigfile z systemu arthur do systemu warlock. Prostszym rozwiązaniem byłoby wydanie odpowiedniego polecenia w systemie arthur lub warlock - nie występują wówczas problemy z konfiguracją praw dostępu.
Sprawdzanie transferu
Za pomocą polecenia uustat można sprawdzić, jaki jest aktualny status transferu, który został "zamówiony", ale nie dotarł jeszcze na miejsce. Po jego wydaniu pojawi się lista wszystkich wydanych przez Ciebie zleceń kopiowania o następującym forma-cie:
ID_zadania system użytkownik data polecenie rozmiar
system jest nazwą pierwszego komputera, do którego dane są wysyłane (czyli nie zawsze jest to nazwa systemu docelowego), użytkownik to identyfikator osoby, która wydała zlecenie kopiowania, pole data określa, kiedy dane zadanie zostało zlecone, polecenie to dokładna treść polecenia, które zostanie wykonane po nawiązaniu po-łączenia, a rozmiar to sumaryczna wielkość danych, które zostaną przesłane. Jeżeli wydasz polecenie uustat jako zwykły użytkownik, otrzymasz informacje tylko o tych zadaniach, które sam zleciłeś. Jeśli polecenie to wydasz jako root, wyświetlone zostaną dane o wszystkich czekających na skopiowanie plikach. Jako zwykły użyt-kownik również możesz uzyskać informacje o wszystkich zleceniach, używając opcji -a:
uustat -a
Aby anulować wysłanie jakiegoś pliku, użyj opcji -k polecenia uustat wraz z iden-tyfikatorem zadania; na przykład, aby anulować wysłanie pliku, któremu został przy-znany numer identyfikacyjny 17, należy wydać polecenie:
uustat -k 17
Możesz anulować wysłanie tylko tych plików, które sam zleciłeś (chyba że jesteś zalogowany jako administrator).

Konfigurowanie poczty
System obsługi poczty elektronicznej w Linuxie składa się z dwóch warstw: agenta poczty, czyli programu, którego używasz do wysyłania i odbierania poczty (ang. MUA, Mail User Agent), i warstwy systemowej (ang. MTA, Mail Transport Agent), która ob-sługuje procesy wysyłania i nadawania wiadomości. Najpopularniejsze w systemach linuxowych programy typu MTA to sendmail i smail. Programów typu MUA są dziesiątki i tylko do Ciebie należy wybór tego najod-powiedniejszego. Program sendmail oparty jest na systemie poczty opracowanym w Uniwersytecie Kalifornijskim w Berkley. Dostępnych jest kilka jego wersji, różniących się nieco możliwościami. Drugi dość powszechnie używany program o nazwie smail opracowany został przez Curta Nolla i Ronalda Karra. Również ten program jest do-stępny w kilku wersjach. Programy sendmail i smail rozprowadzane są wraz z większością dystrybucji Linu-xa, co może nieco zakłopotać użytkownika nie wiedzącego, na który system powinien się zdecydować. W przypadku niewielkich systemów (jakimi zwykle są komputery li-nuxowe, również te podłączone do sieci) oba te programy działają równie dobrze. Pod pewnymi względami smail jest nieco łatwiejszy w konfigurowaniu, głównie dlatego, że jest nowszy. Mimo to sendmail jest bardziej elastyczny i lepiej sprawdza się w większych systemach.
Jak działa poczta elektroniczna
Kiedy piszesz list czy wiadomość za pomocą jednego z programów do obsługi poczty, takiego jak np. Elm, Pine czy mail, aplikacja przekazuje jego treść do programu MTA, takiego jak sendmail lub smail. W systemie może działać kilka takich pro-gramów (na przykład jeden do obsługi sieci lokalnej i drugi do UUCP), ale zwykle dla wygody używa się tylko jednego. Ściślej rzecz ujmując, wiadomość nie jest przekazy-wana bezpośrednio do programu MTA, ale do programu rmail (nazwa ta jest zwykle tylko aliasem nazwy jednego z tych programów). Jeśli wiadomość adresowana jest do kogoś w sieci lokalnej (lub w tym samym syste-mie), MTA powinien to zauważyć na podstawie adresu. MTA musi również rozpozna-wać i tłumaczyć aliasy, dzięki którym możliwe jest adresowanie sieci, systemów czy użytkowników za pomocą różnych identyfikatorów. Jeśli wiadomość jest przeznaczo-na dla użytkownika innej sieci, MTA musi umieć nawiązać połączenie z komputerem, który przekaże pocztę dalej. Połączenie to może być oparte zarówno na TCP, jak i UUCP. Jeśli połączenie realizowane jest za pomocą TCP, często używa się protokołu SMTP (Simple Mail Transfer Protocol). MTA musi również radzić sobie z takimi pro-blemami, jak niemożność dostarczenia poczty z powodu błędnego adresu komputera czy użytkownika - w takim przypadku poczta musi być albo zignorowana, albo lepiej odesłana do nadawcy. Routing (czyli kierowanie drogą dostarczenia) poczty jest również ważnym aspektem pracy programów MTA i różni się w zależności od użytego schematu adresowania. Jeśli adres jest oparty na protokole TCP (czyli ma postać nazwy domenowej), MTA próbuje dostarczyć pocztę bezpośrednio do komputera docelowego w oparciu o adres IP, pozo-stawiając routing oprogramowaniu sieciowemu wchodzącemu w skład systemu TCP/IP.
Konfigurowanie programu sendmail
Najczęściej używanym programem typu MTA jest sendmail, rozprowadzany z większością dystrybucji Linuxa. Jest to system niebywale potężny i elastyczny, co niestety powoduje, że nie jest najłatwiejszy w konfiguracji i utrzymaniu. Mimo to skonfiguro-wanie go do prostych zadań jest całkiem łatwe, o czym przekonasz się, czytając ten rozdział. Jeśli wybrałeś właśnie ten program, zawarte tu informacje powinny wystar-czyć dla skonfigurowania systemu poczty w dowolnej sieci (może za wyjątkiem naj-bardziej skomplikowanych). Ze względu na swoją złożoność sendmail jest często dostarczany razem z programem użytkowym o nazwie IDA pod wspólną nazwą sendmail+IDA. Program IDA znacznie upraszcza konfigurację programu sendmail, dlatego jest bardzo często uży-wany w systemach linuxowych. Dzięki niemu sendmail staje się najprostszym w użyciu programem do obsługi transportu poczty. Jeśli w Twoim systemie zainstalowany jest tylko program sendmail, warto rozważyć załadowanie pakietu sendmail+IDA z któregoś z węzłów FTP lub BBS. Oferowane przez ten pakiet udogodnienia z nawiązką wyna-grodzą trud włożony w załadowanie odpowiednich plików. Wiele dystry-bucji oferuje program sendmail w wersji 8, do którego zwykle nie jest dodawany program IDA. Informacji o najświeższych wersjach programu sendmail i IDA szukaj w węzłach BBS i FTP. System sendmail (bez programu IDA) przechowuje większość informacji konfiguracyjnych w pliku /etc/sendmail.cf (lub, w niektórych systemach, /usr/lib/sendmail.cf). Język używany w tym pliku różni się zupełnie od innych plików konfiguracyjnych i jest stosunkowo złożony. Zresztą obejrzyj ten plik za po-mocą programu more i sam spróbuj domyślić się, o co w nim chodzi. Plik sendmail.cf zawiera dane o czynnościach podejmowanych domyślnie przez system sendmail. Inne pliki służące do konfiguracji tego programu to:
- decnexttable: zamienia ogólne adresy na adresy DECnet;
- genericfrom: zamienia adresy wewnętrzne na ogólne;
- mailertable: określa reguły specjalnego traktowania serwerów i domen;
- pathtable: definiuje ścieżki UUCP do zdalnych komputerów i domen;
- uucpxtable: wymusza dostarczanie poczty z adresem DNS za pomocą UUCP;
- uucprelays: umożliwia "skróty" do komputerów zdalnych;
- xaliases: zamienia adresy ogólne na wewnętrzne.
Każdemu z tych plików przyjrzymy się nieco bardziej szczegółowo dalszej części tego rozdziału. Jak już wspomniano, pliki te trudno modyfikować ręcznie. Użycie programu IDA znacznie poprawia sytuację, ponieważ umożliwia on skonfigurowanie systemu sendmail przez podanie odpowiednich opcji. System sendmail+IDA za pomocą preprocesora takiego jak m4 lub dbm generuje na podstawie wprowadzonych danych odpowiednie pliki konfiguracyjne.
Plik sendmail.cf
W przypadku użycia programu sendmail+IDA, plik sendmail.cf nie jest edytowany ręcznie. Jest on generowany po zakończeniu konfiguracji. Cała procedura konfiguracyjna opiera się na danych zapisanych w pliku sendmail.m4, zawierającym podstawowe takie informacje, jak nazwa systemu, specyficzne ścieżki dostępu, nazwa do-myślnego programu obsługi poczty itp. Choć plik ten może stać się dość długi, w większości instalacji używających do przesyłania poczty protokołów UUCP lub SMTP wystarczy wprowa-dzić do niego tylko podstawowe informacje. Jedną z ważniejszych sekcji w pliku sendmail.m4 jest sekcja określająca położenie plików i katalogów. Zwykle zaczyna się ona od wiersza definiującego zmienną LIBDIR, który może mieć następującą postać:
dnl #define(LIBDIR, /usr/local/lib/mail)
Katalog LIBDIR określa miejsce, gdzie sendmail+IDA szuka plików konfiguracyj-nych i tablic kierowania przepływem danych (ang. routing tables). Zwykle modyfika-cja wartości domyślnej nie jest konieczna, ponieważ jest ona ogólnie przyjęta w syste-mach linuxowych. Jeżeli ścieżka zapisana w pliku sendmail.m4 jest prawidłowa, nie należy jej zmieniać. Jest ona zwykle również na stałe zapisana w pliku wykonywalnym programu sendmail i nie musi być nadpisywana przez plik sendmail.m4 (czy gene-rowany na jego podstawie plik sendmail.cf). Jeśli musisz zmienić tę wartość, powi-nieneś usunąć z początku wiersza tekst dnl, który jest znacznikiem komentarza, wprowadzić odpowiednią dla Twojego systemu ścieżkę i ponownie wygenerować plik sendmail.cf. Program dostarczający pocztę jest określony wartością zmiennej LOCAL_MAILER_DEF, której definicja może mieć postać:
define (LOCAL_MAILER_DEF, mailers.linux)dnl
Wiersz ten jest potrzebny, ponieważ sendmail nie zajmuje się dostarczaniem poczty. Dba o to inny program. Domyślnie używany jest program zdefiniowany w pliku mailers.linux, którym prawie zawsze jest deliver. Powinieneś jednak na wszelki wypadek sprawdzić, co zawiera plik mailers.linux (zapisany w tym samym katalo-gu, co plik sendmail.m4, czyli zwykle /usr/local/lib/mail). Typowo jego zawar-tość jest następująca:
#mailers.linux
Mlocal, P=/usr/bin/deliver, F=SlsmFDMP, S=10, R=25/10, A=deliver $u
Mprog, P=/bin/sh, F=lsDFMeuP, S=10, A=sh -c $u
Nazwa programu dostarczającego pocztę musi być również wprowadzona do pliku Sendmail.mc, który jest używany do generowania pliku sendmail.cf. Jeśli używasz programu innego niż deliver, powinieneś również tam skorygować odpowiedni wpis (jeśli używasz programu deliver, nie musisz przejmować się zawartością tego pliku). Plik Sendmail.mc jest wczytywany przy przetwarzaniu pliku sendmail.m4, za co od-powiada znajdujący się zwykle na początku pliku sendmail.m4 wiersz
include(Sendmail.mc)dnl
Możliwe, że będziesz musiał dodać kilka wartości do definicji zmiennej PSEUDODOMAINS, używanej do obsługi systemów nie posiadających nazwy domeno-wej, na przykład dostępnych przez UUCP. Odpowiednie ustawienie wartości tej zmien-nej zapobiega próbie tłumaczenia tych nazw przez DNS (co zawsze kończy się niepo-wodzeniem). Odpowiedni wiersz może mieć następującą postać:
define(PSEUDODOMAINS, BITNET UUCP)dnl
Można również użyć zmiennej PSEUDONYMS, pozwalającej na ukrycie nazwy Twojego komputera przed światem zewnętrznym. Oznacza to np. że bez względu na to, czy poczta została wysłana z systemu merlin.tpci.com czy chatton.tpci.com, od-biorca otrzyma tylko adres tpci.com - nazwy komputerów lokalnych zostały ukryte. Jeśli wartość tej zmiennej jest zdefiniowana, sendmail przyjmuje pocztę od wszyst-kich maszyn w sieci lokalnej, np. definicja:
define(PSEUDONYMS, tpci.com)dnl
pozwala wszystkim komputerom w sieci tpci.com wysyłać pocztę za pośrednictwem systemu sendmail. Aby określić nazwę komputera lokalnego, należy odpowiednio ustawić wartość zmiennej DEFAULT_HOST. Zwykle nazwa ta pokrywa się z nazwą serwera poczty (lub Two-jego komputera, jeśli nie jesteś podłączony do sieci). Poniższy wiersz określa nazwę domyślnego serwera poczty:
define(DEFAULT_HOST, merlin.tpci.com)dnl
Jeśli nie ustawisz wartości tej zmiennej, poczta nie będzie prawidłowo zwracana do Twojego systemu. Jeśli system nie pracuje jako bramka internetowa (albo do innej sieci dostępnej z sieci lokalnej), można skonfigurować go tak, by cała poczta była przesyłana do innego komputera, który powinien rozesłać ją dalej. Zrobić to można ustawiając wartości zmiennych RELAY_HOST (zmienna ta określa nazwę komputera, do którego ma być przekazywana poczta) i RELAY_MAILER (określa protokół używany do transportu poczty do tego komputera). Aby na przykład przesyłać pocztę do systemu o nazwie wizard, można zdefiniować wartości tych zmiennych w następujący sposób:
define(RELAY_HOST, wizard)dnl
define(RELAY_MAILER, UUCP-A)dnl
Położenie tablic konfiguracyjnych
W pliku sendmail.m4 znajdują się wiersze określające położenie tablic konfiguracyj-nych. Zwykle znajdują się one w katalogu określonym przez wartość zmiennej LIBDIR. Ta sekcja pliku może wyglądać tak:
define(ALIASES, LIBDIR/aliases)dnl
define(DOMAINTABLE, LIBDIR/domaintable)dnl
i tak dalej dla pozostałych plików (zwykle jest ich około siedmiu). Możesz zmienić te wartości, jeśli chcesz przenieść odpowiednie pliki w inne miejsce. Najlepiej jednak po-zostawić je tam, gdzie są. Plik decnexttable używany jest do tłumaczenia nazw domenowych na nazwy w standardzie DECnet. Jest to pozostałość po wcześniejszych wersjach programu send-mail i prawdopodobnie nigdy nie przyda się użytkownikowi systemu linuxowego (chy-ba że pracuje on w systemie DECnet). Plik domaintable używany jest do wymuszania wykonania pewnych poleceń po uży-ciu DNS. Plik ten, prawie nigdy nie używany w Linuxie, pozwala na rozwijanie nazw skróconych. Załóżmy na przykład, że często wysyłasz pocztę do komputera o nazwie okropnie_dluga_nazwa.w_okropnie_duzej_sieci.com i nie masz ochoty wpi-sywać jej za każdym razem. Możesz umieścić w pliku domaintable wpis
okropnie_dluga_nazwa.w_okropnie_duzej_sieci.com dlugi.com
dzięki któremu każdy adres postaci bill@dlugi.com zostanie przetłumaczony do formy bill@okropnie_dluga_nazwa.w_okropnie_duzej_sieci.com. Wpis w tym pliku może również być użyteczny do poprawiania często popełnianych błędów typograficznych, na przykład jeśli użytkownicy często przez pomyłkę próbują wysłać pocztę do systemu abcdef.com, którego poprawną nazwą jest abcdfe.com, możesz do tego pliku dodać wiersz
abcdfe.com abcdef.com
Pierwszą wartością jest prawidłowa nazwa systemu, natomiast druga wartość określa nazwę skróconą lub często używaną nazwę nieprawidłową. Tabela genericfrom jest używana do ukrywania nazw komputerów lokalnych i iden-tyfikatorów użytkowników, które są zamieniane na jakiś ogólniejszy identyfikator. Jest ona rzadko używana w systemach linuxowych, ponieważ ogólnie przyjętą konwencją jest podawanie w wysyłanych wiadomościach prawdziwego identyfikatora i adresu. Plik komplementarny, xaliases, tłumaczy ogólne adresy na adresy lokalne. Tablica mailertable używana jest do określania reguł specjalnego traktowania ser-werów i domen. Najczęściej stosuje się ją do określenia, za pomocą jakiego protokołu można połączyć się z poszczególnymi domenami. Plik ten nie musi być modyfikowa-ny, jeśli system korzysta tylko z protokołu UUCP, ale jeśli chcesz używać również SMTP lub DNS, powinieneś sprawdzić jego zawartość. Plik mailertable jest przetwarzany od ostatniego wiersza w górę. Z tego powodu najczęściej używane reguły należy umieścić na końcu pliku, a bardziej specyficzne na początku. Reguły określane są w formacie:
protokół modyfikator adres_pośredni adres-docelowy
Protokół definiowany na początku wiersza może przyjąć jedną z trzech wartości:
TCP-    TCP z adresami w formacie internetowym
TCP-U    TCP z adresami w formacie UUCP
UUCP-A    UUCP z adresami w formacie internetowym
modyfikator może być jednym ze znaków:
! usuwa nazwę komputera z adresu przed przesłaniem wiadomości (używane przy adresowaniu w formacie UUCP)
, nie modyfikuje adresu
: usuwa nazwę komputera tylko wtedy, gdy podane są nazwy komputerów pośredniczących.
Jeśli na przykład chcesz spowodować, aby poczta do systemu roy.sailing.org była przesyłana przez system wizard za pomocą protokołu UUCP, powinieneś dodać do pliku mailertable wiersz:
UUCP-A,wizard roy.sailing.org
Można również zdefiniować bardziej ogólne reguły, na przykład wpis
TCP-A, wizard chatton.com
powoduje, że poczta przesyłana do sieci chatton.com będzie obsługiwana przez lo-kalny serwer poczty za pomocą TCP. Tablica pathtable pozwala na bezpośrednie określenie drogi przesyłania danych do zdalnych komputerów i sieci. Poszczególne wpisy mają format podobny do definicji aliasów dla systemu UUCP i są posortowane alfabetycznie. Tablica pathtable jest używana rzadko, ponieważ systemy linuxowe zwykle radzą sobie z routingiem bez "prowadzenia za rączkę". Plik uucpreleays pozwala na "zwarcie" ścieżki UUCP w przypadku, gdy istnieje lep-sza droga pozwalająca na dostarczenie poczty. Przykładowo, jeśli użytkownicy często wysyłają pocztę do systemu określonego ścieżką wizard!bignet!merlin!tpci, a w systemie utworzone zostało bezpośrednie połączenie z systemem tpci, możesz za pomocą wpisu w pliku uucprelays skierować pocztę krótszą drogą. Plik ten jest dość rzadko używany w systemach linuxowych. Tablica uucpxtable używana jest, gdy do dostarczenia poczty należy użyć adresu UUCP. Pozwala ona na przetłumaczenie adresu DNS na adres UUCP. Jeśli używasz serwera poczty innego niż aktualny system albo chcesz łączyć się z poszczególnymi komputerami za pomocą protokołu UUCP ze względu na niezawodność, powinieneś skorzystać z możliwości udostępnianych przez ten plik. W pliku tym znajdują się pary nazwa UUCP - nazwa DNS, na przykład:
chatton chatton.com
Taki wpis informuje program sendmail, że poczta mająca trafić do systemu chatton.com powinna być przesłana za pomocą protokołu UUCP do systemu o na-zwie chatton. Dzięki temu adres yvonne@chatton.com zostanie przetłumaczony do postaci chatton! yvonne, która może zostać obsłużona przez protokół UUCP.
Tworzenie pliku sendmail.cf
Po wpisaniu danych do pliku sendmail.m4 i innych związanych z nim plików, można wygenerować plik sendmail.cf. Do tego celu używa się preprocesora m4. Kiedy plik sendmail.m4 jest gotowy, należy wydać polecenie:
make sendmail.cf
podstawiając oczywiście odpowiednią nazwę pliku (o ile została ona zmieniona - na przykład jeśli plik konfiguracyjny nazywał się tpci.m4, powinieneś podstawić nazwę tpci.cf). Po utworzeniu pliku sendmail.cf, należy skopiować go do katalogu /etc i urucho-mić program sendmail poleceniem:
/usr/lib/sendmail -bd -q1h
lub zresetować komputer (ponieważ sendmail zwykle uruchamiany jest z jednego z plików inicjalizacyjnych rc). Ścieżki dostępu do katalogów, w których zapisane są pliki konfiguracyjne, mogą być inne - w takim przypadku należy oczywiście skopiować plik sendmail.cf do odpowiedniej lokacji.
Używanie programu sendmail w wersji 8
Najnowsza wersja programu sendmail ma numer 8. Nie przejmuj się tym, że nie wi-działeś wersji 6 ani 7 - wersje o takich numerach nigdy nie istniały. Po wersjach 5.X pojawiła się od razu wersja z numerem 8 (jednym z ważniejszych ulepszeń tej wersji jest ochrona przed spamem - czyli niechcianą pocztą; sama ta cecha może być wy-starczającym powodem dla uaktualnienia wersji oprogramowania!). Szczegóły konfiguracji systemu sendmail 8 nie różnią się od konfiguracji innych wer-sji, za wyjątkiem obsługi aż czterech wersji protokołu UUCP:
- uucp-old (to samo co uucp) Klasyczny UUCP, używający adresów w formacie komputer!użytkownik, potrafiący wysłać wiadomość tylko pod jeden adres (kiedy wiadomość adresowana jest do kilku osób, do każdej z nich wysyłana jest osobna kopia). Ta wersja powinna być używana, tylko jeśli kompatybil-ność ze starymi systemami UUCP jest bezwzględnie konieczna.
- uucp-new (wcześniej znane jako suucp) Protokół podobny do UUCP, ale po-zwalający za pomocą polecenia rmail wysłać wiadomość do więcej niż jed-nego adresata. Poza tym nie wprowadza żadnych znaczących zmian w po-równaniu z poprzednią wersją.
- uucp-dom Pozwala na użycie adresów w formacie domenowym. Ta wersja protokołu może być niekompatybilna z niektórymi systemami, z którymi przyjdzie Ci się łączyć.
- uucp-udom Kombinacja wersji uucp-new i uucp-dom, obsługująca popraw-nie zarówno adresy domenowe jak i UUCP.
Którąkolwiek z wersji programu obsługi UUCP wybierzesz, odpowiedni plik powinien zostać skopiowany (lub dołączony) do standardowego programu obsługi UUCP.
smail
Pod względem funkcjonalności system smail jest bardzo podobny do systemu sendmail, ale proces jego konfiguracji jest inny. Pod pewnymi względami program smail jest łatwiejszy w obsłudze niż sendmail, dlatego może stanowić dobrą alterna-tywę w mniejszych systemach. Jeśli zdecydujesz się na użycie systemu smail, będziesz musiał ręcznie modyfikować pliki konfiguracyjne, ponieważ skrypty czy programy au-tomatyzujące ten proces są w zasadzie niedostępne. System smail używa wielu opcji i parametrów, których nie trzeba modyfikować, dla-tego przyjrzymy się tylko tym, które są naprawdę niezbędne. Jeśli chcesz dowiedzieć się więcej o opcjach i parametrach, których nie omawiamy w tym rozdziale, zajrzyj na strony man poświęcone programowi smail. Tu skoncentrujemy się na łatwej i szybkiej konfiguracji programu smail do najczęściej wykonywanych zadań.
Konfigurowanie programu smail
Aby program smail mógł działać poprawnie, niezbędne jest utworzenie kilku dowią-zań do niego. Dwa najważniejsze to /usr/bin/rmail i /usr/lib/sendmail (w niektórych systemach /usr/sbin/sendmail). Dowiązania te są konieczne, ponieważ większość programów kieruje pocztę wychodzącą do programu rmail lub sendmail, a powinna trafić ona do smail. Utworzenie odpowiednich dowiązań spowoduje, że proces przekierowania danych do programu smail stanie się "przezroczysty" i nie trzeba będzie zmieniać konfiguracji programów pocztowych. Powinieneś więc sprawdzić, czy programy rmail i sendmail są dowiązaniami do pro-gramu smail; jeśli nie, powinieneś utworzyć odpowiednie dowiązania. Dowiązania (symboliczne) zaznaczane są podczas wyświetlania danych o zawartości katalogów w następujący sposób:
lrwxrwxrwx 1 root root 6 Sep 16:35 plik1 -> plik2
Strzałka (->) symbolizuje istnienie dowiązania symbolicznego. Jeśli dowiązania nie istnieją, można je utworzyć poleceniami:
ln -s /usr/local/bin/smail /usr/bin/rmail
ln -s /usr/local/bin/smail /usr/bin/sendmail
Jeśli może się zdarzyć, że poczta wychodząca lub przychodząca będzie przesyłana również przez SMTP, potrzebne będzie jeszcze jedno dowiązanie
ln -s /usr/local/bin/smail /usr/bin/smtpd
kierujące do programu smail również dane adresowane do programu smtpd (oczywi-ście należy podstawić odpowiednie dla systemu ścieżki dostępu do tych programów). W takim przypadku należy również sprawdzić, czy konfiguracja TCP dopuszcza uży-wanie tego protokołu. Wiersz pliku /etc/services o postaci
smtp 25.tcp #Simple Mail Transfer Protocol
nie powinien być zaznaczony jako komentarz (symbolem komentarza w tym pliku jest znak # w pierwszej kolumnie). Taki wpis pozwala na nawiązanie połączenia SMTP poprzez port TCP o numerze 25 (jest to wartość domyślna). Jeśli program smail ma działać w tle przez cały czas, powinieneś uruchomić go w jednym z plików inicjalizacyjnych (zwykle rc.inet2), wpisując tam wiersz:
/usr/local/bin/smail -bd -q15m
Opcja -bd powoduje, że smail ładuje się jako program rezydentny, a -q15m nakazuje przetwarzać pocztę co 15 minut. Jeżeli chcesz, aby poczta obsługiwana była częściej, podstaw odpowiednią wartość. Zbyt częste obsługiwanie poczty obciąża jednak niepo-trzebnie system. Jeśli wolisz, by program smail nie działał cały czas, ale był uruchamiany przez inetd gdy jest potrzebny, powinieneś usunąć wpis z pliku rc (lub zaznaczyć go jako komen-tarz) i do pliku /etc/inetd.conf wpisać następujący wiersz:
smtp stream tcp nowait root /usr/sbin/smtpd smtpd
Aby powyższy wpis działał prawidłowo, musi być utworzone dowiązanie do programu smail o nazwie smtpd. Zmiany w plikach konfiguracyjnych systemu smail zależą od tego, jakiego protokołu używasz do przesyłania poczty: UUCP (łatwiejszy w konfiguracji) czy TCP. Obu przy-padkom przyjrzymy się osobno. Można również skonfigurować obie metody przesyła-nia poczty.
Konfigurowanie smail z protokołem UUCP
Konfigurowanie systemu smail tak, aby używał do przesyłania danych protokołu UUCP jest bardzo proste. Odpowiednie dane należy w prowadzić do pliku konfigura-cyjnego /usr/lib/smail/config. Często w tym samym katalogu znajduje się plik config.sample, którego można użyć jako szablonu. Do modyfikacji zawartości pliku /usr/lib/smail/config można użyć dowolnego edytora tekstów potrafiącego zapisać plik w formacie ASCII. Wprowadzić trzeba po-prawki dotyczące czterech zmiennych:
visible_domain   nazwa domeny, do której należy Twój system,
visible_name   pełna nazwa domenowa komputera,
uucp_name   nazwa UUCP komputera (zwykle taka sama jak visible_name),
smart_host   nazwa serwera UUCP.
Każdy parametr podawany jest w formacie nazwa=wartość. Po obu stronach znaku równości nie powinno być spacji. Tekst od symbolu # do końca wiersza traktowany jest jako komentarz.
Ustawianie lokalnych nazw domenowych
Rozpocznij od wprowadzenia nazw domenowych dla komputerów lokalnych. Znajdź w pliku /usr/lib/smail/config fragment, który określa wartość zmiennej visible_ domain; zwykle ma on postać:
#Our domain name
visible_domain=tpci
Zmienna visible_domain zawiera nazwę domenową Twojego komputera. Jeśli możliwe ma być użycie kilku nazw, wszystkie one powinny zostać wyszczególnione, na przykład:
#Our domain name
visible_domain=tpci:tpci.com:tpci.UUCP:uucp
Wartość tej zmiennej (oraz nazwa komputera lokalnego zwracana przez polecenie ho-stname) wykorzystywana jest do rozstrzygnięcia, czy wiadomość jest adresowana do systemu lokalnego, czy należy przesłać ją dalej. Jeśli Twój system jest prawidłowo zarejestrowany w plikach mapujących UUCP, powi-nieneś do zmiennej visible_domain dodać również nazwę uucp, tak jak to przed-stawiono w powyższym przykładzie. Warto również dodać wersje nazwy lokalnej za-wierające najczęstsze pomyłki typograficzne (dla podanego wyżej przykładu mogłyby to być nazwy tcpi czy tcpi.com). Ustawianie domeny lokalnej dla poczty wychodzącej Kiedy wiadomość ma wyjść poza sieć lokalną, jako część informacji o trasie jej do-starczenia dołączana jest pełna nazwa domenowa komputera-nadawcy. Określana jest ona na podstawie wartości zmiennej visible_name, której definicja może na przykład mieć postać:
#Our domain name for outgoing mail
visible_name=tpci.com
Ogólnie rzecz biorąc, nazwa ta powinna składać się z nazwy komputera i jednej z nazw domen podanych w zmiennej visible_domain, w przeciwnym przypadku listy odsyłane jako odpowiedzi na wysyłane z Twojego systemu wiadomości nie będą mo-gły do niego trafić. Zmienna visible_name zawiera zwykle pełną nazwę domenową systemu (i ile sys-tem takową posiada) lub nazwę domenową, która występuje w tablicach kierowania przesyłem danych.
Inne nazwy UUCP W pliku /usr/lib/smail/config znajduje się również definicja zmiennej uucp_name. Jest ona opcjonalna i nie musisz jej używać, jeśli wartości zmiennych visible_domain i visible_name są ustawione prawidłowo. Może jednak być przydatna wtedy, gdy na przykład zmienisz nazwę swojego komputera. Normalnie wymagałoby to wprowadze-nia zmian we wszystkich tablicach mapowania UUCP, ale można tego uniknąć, poda-jąc starą nazwę systemu w zmiennej uucp_name. W pozostałych przypadkach jej war-tość powinna być taka sama jak wartość zmiennej visible_name:
#UUCP mapping name
uucp_name=tpci.com
Jeśli nazwa Twojego komputera się zmieniła, możesz pozostawić starą wartość w zmiennej uucp_name, co pozwoli uniknąć konieczności uaktualniania tablic mapowa-nia UUCP.
Ustawianie serwera UUCP
Niektóre komputery wykorzystują serwer UUCP, tzn. komputer, który obsługuje prze-syłanie poczty do i z innych sieci. W takim przypadku należy go podać jako wartość zmiennej smart_host definiowanej w pliku /usr/lib/smail/config:
# Smart host
smart_host=merlin
W takim przypadku program smail przesyła pocztę adresowaną do innych sieci do komputera merlin (jego pełna nazwa domenowa to merlin.tpci.com - jest ona określana na podstawie wartości zmiennych smart_host i visible_name), który zajmuje się przesyłaniem jej dalej. Komputer ten musi być dostępny poprzez UUCP (czyli powinien posiadać odpowiednie wpisy w plikach konfiguracyjnych UUCP - patrz rozdział 39. "UUCP").
Konfigurowanie smail z protokołem TCP
Jeśli do przesyłania poczty chcesz wykorzystać połączenie sieciowe, musisz wprowa-dzić odpowiednie modyfikacje do pliku /usr/lib/smail/config, zawierającego da-ne o typach połączeń wraz z nazwami systemów zdalnych. Istnieje kilka sposobów konfigurowania poczty w sieci lokalnej. Można na przykład użyć usługi NFS tak, aby jeden plik konfiguracyjny był dostępny dla wszystkich systemów, protokołu POP (ang. Post Office Protocol) czy IMAP (ang. Interactive Mail Access Protocol), które pozwa-lają na przetwarzanie wszystkich wiadomości w centralnym komputerze, lub też skon-figurować każdy z komputerów niezależnie od innych. Sam proces konfiguracji niewie-le się różni w każdym z tych przypadków; różnica polega głównie na tym, że dane trzeba wprowadzić albo do wspólnego pliku konfiguracyjnego, dostępnego poprzez NFS lub SMTP, albo do plików konfiguracyjnych każdego z komputerów z osobna. Proces konfiguracji rozpocznij od ustawienia lokalnych nazw domenowych w zmien-nych visible_domain i visible_name. Były one omówione bardziej szczegółowo w podrozdziale dotyczącym konfigurowania smail dla UUCP, tu ograniczymy się tyl-ko do podania przykładów:
#Our domain name
visible_domain=tpci.com
#Our domain name for outgoing mail
visible_name=tpci.com
Te definicje ustalają nazwę domenową systemu lokalnego - na jej podstawie smail rozstrzyga, czy poczta adresowana jest do systemu lokalnego, czy należy przesłać ją dalej. Wartość zmiennej visible_domain będzie dołączana do wszystkich wiadomo-ści wychodzących jako adres zwrotny (zamiast nazwy zwracanej przez polecenie ho-stname). Najczęściej wartości zmiennych visible_domain i visible_name są takie same. Następnym krokiem konfiguracji jest ustawienie nazwy komputera zajmującego się wymianą poczty z innymi sieciami. Jeśli to Twój system pełni taką funkcję, nie musisz wpisywać żadnych wartości. Zmienne, których wartości należy ustawić, to smart_path (określa nazwę komputera obsługującego pocztę; nazwa ta jest ustalana przez dołączenie do wartości zmiennej smart_path wartości zmiennej visi-ble_domain), oraz smart_transport (która określa protokół używany do przesyła-nia poczty; przeważnie jest to protokół SMTP). Oto przykładowy fragment pliku /usr/lib/smail/config, określający wartości tych zmiennych:
#smart host routing
#smart host name
smart_host=merlin
# communications protocol to smart host
smart_transport=smtp
Modyfikacja zachowania programu smail
Konfiguracja opisana w poprzednich podrozdziałach wystarcza dla większości syste-mów linuxowych. Ponieważ jednak system smail składa się z trzech modułów (route-ra, modułu transportującego i dostarczającego), możliwe jest dostosowanie jego za-chowania do praktycznie każdej, nawet najbardziej nietypowej sieci. W typowych sie-ciach jedynym elementem, który może wymagać dalszej konfiguracji, jest router, dla-tego zajmiemy się nim nieco bardziej szczegółowo. W większości przypadków zachowanie każdego elementu programu smail kontrolo-wane jest przez plik konfiguracyjny (lub kilka plików) zapisany w katalogu /usr/lib/smail. Zarówno w standardowych dystrybucjach, jak i w węzłach FTP, dostępnych jest wiele przykładowych plików konfiguracyjnych. Modyfikacja takiego pliku jest znacznie łatwiejsza, niż tworzenie go "od zera". Liczba dostępnych opcji i niektóre szczegóły konfiguracji różnią się w zależności od wersji program smail - na-leży więc sprawdzić, czy pliki przykładowe są przeznaczone dla właściwej wersji tego programu. Router odpowiada za tłumaczenie adresów docelowych, kierowanie wiadomości do następnego komputera na drodze przesyłu, oraz określanie protokołu, jakiego należy użyć do przesyłania danych. Jeśli wiadomość adresowana jest do użytkownika w sys-temie lokalnym (co rozpoznawane jest przez porównanie adresu z wartością odpo-wiedniej zmiennej definiowanej w pliku /usr/lib/smail/config), jest przekazywa-na do modułu dostarczającego. Jeśli wiadomość ma dotrzeć do maszyny zdalnej, odpowiednie sterowniki (określone w pliku /usr/lib/smail/routers) decydują na podstawie adresu, do którego kompu-tera dane powinny zostać przesłane. Plik /usr/lib/smail/routers zawiera nazwy sterowników routera. Każdy z nich (w kolejności określonej przez kolejność wpisów w tym pliku) otrzymuje adres docelowy wiadomości i sprawdza, czy na podstawie takie-go adresu potrafi określić drogę, jaką wiadomość powinna zostać skierowana. W większości przypadków nie będą konieczne żadne zmiany w pliku /usr/lib/smail/ routers. Domyślnie używana konfiguracja działa w następujący sposób:
- tłumaczenie nazwy bezpośrednio na numer IP za pomocą funkcji bibliotecz-nej gethostbyaddr;
- tłumaczenie za pomocą nazwy symbolicznej używając funkcji gethostbyname;
- tłumaczenie za pomocą bazy danych o nazwach skróconych (zapisanej w pliku /usr/lib/smail/paths);
- dla adresów UUCP - sprawdzenie, czy komputer docelowy jest dostępny bez-pośrednio;
- przesłanie poczty do komputera obsługującego wymianę poczty z innymi sie-ciami, o ile wszystkie inne metody nie dały rezultatu.
Ten sposób routingu działa dobrze w większości systemów, ale powinieneś zaznaczyć wiersz dotyczący UUCP jako komentarz, jeśli protokół ten nie został prawidłowo skonfigurowany lub też w ogóle nie zamierzasz go wykorzystywać (w przeciwnym przypadku zostaniesz zasypany komunikatami o błędach generowanymi przez system smail). Jeśli system jest podłączony bezpośrednio do Internetu, konfiguracja programu smail musi być nieco zmodyfikowana, ponieważ nie potrafi on bezpośrednio obsługiwać formatu MX. Należy wówczas zaznaczyć jako komentarz wszystkie wiersze w pliku routera i zamiast tego użyć routera BIND (jeśli nie jest on dostarczony z Twoją wer-sją Linuxa, możesz go załadować z węzłów BBS i FTP). Jeżeli używasz zarówno połączeń SLIP/PPP, jak i UUCP, możesz spotkać się z sytua-cją, że smail zbyt długo czeka na połączenie. W takim przypadku powinieneś prze-stawić kolejność akcji w pliku /usr/lib/smail/routers tak, aby najpierw przeglą-dana była baza danych o nazwach skróconych. Ponieważ UUCP jest bardziej wydaj-ny przy połączeniach SLIP/PPP niż SMTP, możesz w zasadzie całkowicie wyłączyć tłumaczenie za pomocą funkcji gethostbyaddr i gethostbyname. Kiedy router znajdzie już najlepszą drogę dostarczenia poczty, określa również protokół, za pomocą którego ma ona zostać przesłana. W tym punkcie adres docelowy mo-że zostać zmodyfikowany. Przykładowo, jeśli chatton@bigcat.com jest dostępny przez UUCP, adres zostanie zmieniony na bigcat!chatton. W innych przypadkach adres docelowy może zostać wzbogacony o pewne szczegóły, na przykład adres chatton@bigcat.com może zostać uzupełniony o nazwę komputera chatton@whiskas.bigcat.com, jeśli zapewni to efektywniejsze dostarczenie wiadomości. Niektóre routery UUCP używają również pliku /usr/lib/smail/paths, w którym de-finiowane są aliasy pozwalające na dostęp do systemów z wykorzystaniem serwerów pośredniczących. Plik ten zawiera posortowany zestaw wpisów, składających się z dwóch pól rozdzielonych znakiem tabulacji; pierwsze z nich określa nazwę systemu docelowego, natomiast drugie - pełną ścieżkę w formacie UUCP. W pliku tym nie jest dozwolone używanie komentarzy

Konfigurowanie grup dyskusyjnych
Jeśli posiadasz dostęp do Internetu, wcześniej czy później będziesz chciał skorzystać z dobrodziejstw oferowanych przez grupy dyskusyjne sieci Usenet. Jest to jeden z naj-bardziej dynamicznych (i najbardziej kontrowersyjnych) aspektów Internetu. Choć można korzystać tylko z list korespondencyjnych, większość użytkowników jest zain-teresowana szczególnie dostępem do sieci Usenet. Usenet został stworzony po to, aby ułatwić użytkownikom dostęp do grup dyskusyj-nych (ang. newsgroups). Grupa dyskusyjna pozwala każdemu, kto ma do niej dostęp, na publiczną rozmowę z pozostałymi członkami grupy. Usenet jest obsługiwany przez miliony sieci w setkach krajów, a korzystają z niego setki milionów użytkowników. Każdy komputer, który połączony jest z Internetem, czy to bezpośrednio, czy przez bramkę internetową lub połączenie modemowe, może uzyskać dostęp do sieci Usenet. W tym celu trzeba posiadać odpowiednie oprogramowanie, które potrafi załadować i odesłać wiadomości, oraz przeglądarkę, umożliwiającą czytanie i pisanie artykułów. Oprogramowanie implementujące przekazywanie wiadomości z Usenetu poprzez sieci lokalne nazywane jest NNTP (ang. Network News Transfer Protocol). Za pomocą NNTP system może współpracować z każdym innym obsługującym Usenet. NNTP wchodzi w skład większości dystrybucji Linuxa, dzięki czemu nie trzeba szukać dodat-kowego oprogramowania.
Usenet i grupy dyskusyjne
Usługa Usenet składa się z dwóch elementów. Najpierw trzeba załadować do systemu wszystkie wiadomości, za co odpowiedzialne jest oprogramowanie transportujące (NNTP dla połączeń TCP i CNews dla UUCP), a następnie połączyć je i przekonwerto-wać do czytelnej dla użytkownika postaci. Pierwotnie grupy dyskusyjne korzystały wy-łącznie z protokołu UUCP, dlatego większość oprogramowania obsługiwała ten stan-dard, a funkcje umożliwiające przesyłanie danych w inny sposób zostały dodane póź-niej. Ponieważ większość z Was używać będzie protokołów TCP/IP, w tym rozdziale skoncentrujemy się na oprogramowaniu NNTP. Transfer wiadomości odbywa się za pomocą techniki nazywanej trasowaniem rozpły-wowym (ang. flooding). Jeden komputer łączy się z drugim i wysyła do niego wszystkie artykuły (proces przesyłania artykułów nazywa się po angielsku newsfeed). Ten z kolei łączy się i wysyła artykuły do następnego komputera lub kilku komputerów. Takie rozwiązanie pozwala na uniknięcie centralnego rozprowadzania danych. W każdym systemie znajduje się lista komputerów, do których należy przesłać dane. W systemie biorącym udział w przesyłaniu artykułów może zostać dodany nowy arty-kuł. Do każdego z artykułów dołączona jest lista serwerów, które go już "widziały" (nazywana ścieżką, ang. Path), co pozwala zapobiegać wielokrotnemu przesyłaniu tych samych danych. System, do którego trafia artykuł, dopisuje swój identyfikator do ścieżki, używając notacji UUCP. Można ograniczyć obszar, na którym dany artykuł ma być rozprowadzany, przez od-powiedni wpis w jego nagłówku. Dzięki temu możesz napisać artykuł, który będzie czytany tylko w sieci lokalnej (komputery sieci lokalnej po prostu nie prześlą go dalej). Aby zapobiec powstawaniu duplikatów artykułów krążących w sieci Usenet, każdy z nich posiada swój identyfikator (zapisany w polu Message-Id nagłówka), składający się z niepowtarzalnego numeru i nazwy systemu, w którym artykuł został napisany. Identyfikator artykułu używany jest przez każdy komputer w momencie rozpoczęcia transferu danych. W każdym systemie znajduje się plik o nazwie history, zawierają-cy identyfikatory dostarczonych do systemu artykułów, na którego podstawie system stwierdza, czy chce, aby dana wiadomość została przesłana, czy też ma już jej własną kopię. Za przesyłanie odpowiednich informacji odpowiedzialny jest protokół ihave/sendme. Za pomocą protokołu ihave/sendme jeden komputer przesyła do drugiego listę wszystkich posiadanych artykułów i czeka, aż tamten prześle informacje o tym, które z nich chce otrzymać. Artykuły są przesyłane pojedynczo, w odpowiedzi na sygnały sendme. Następnie proces może zostać odwrócony. Takie rozwiązanie działa dobrze, ale jest dość niewygodne przy przesyłaniu większych ilości danych. Z tego powodu (oraz z powodu niewielkiej prędkości przesyłu danych poprzez modemowe połączenia UUCP) protokół ihave/sendme raczej nie jest używany w przypadku, gdy trzeba regu-larnie przesyłać duże ilości artykułów. Przykładowo, przesłanie 100 MB artykułów za pomocą protokołu ihave/sendme każdego dnia jest praktycznie niewykonalne. Inną metodą jest przesyłanie za pośrednictwem szybkiego połączenia wszystkich po-siadanych artykułów do następnego komputera (ang. batching), który może usunąć te, które już ma (porównując ich numery identyfikacyjne z zapisanymi w pliku history). Ta metoda jest jednak również dość uciążliwa, ponieważ komputer odbierający otrzymuje dużo danych i musi je przetworzyć, co obciąża system. Istnieją zasadniczo trzy metody dostępu do artykułów przechowywanych w innym systemie. Za pomocą NNTP można załadować artykuły, używając techniki podobnej do protokołu ihave/sendme. Można również zamówić artykuły, które powstały po określonej dacie. Trzecim sposobem jest czytanie artykułów po jednym, bez koniecz-ności ładowania ich do swojego komputera. W tym celu trzeba jednak zalogować się do systemu zdalnego, co w dzisiejszych czasach często nie stanowi problemu.
NNTP
NNTP może działać w dwóch trybach: aktywnie i biernie. Tryb aktywny (podobny do protokołu CNews ihave/sendme) polega na tym, że system wysyłający (klient) oferu-je dany artykuł odbierającemu (serwer), który go przyjmuje lub odrzuca. Ten tryb po-woduje duże obciążenie serwera, który musi przetworzyć wszystkie posiadane artyku-ły. Tryb bierny polega na tym, że komputer odbierający zamawia wszystkie artykuły, któ-re przybyły od określonej daty (za pomocą polecenia newnews). Następnie usuwa ar-tykuły powtarzające się lub niepotrzebne, wykorzystując polecenie article. Jest to rozwiązanie mniej obciążające serwer, który musi tylko wysłać większą liczbę artyku-łów, ale ze względów bezpieczeństwa serwer przed przesłaniem danych powinien upewnić się, że zamawiający ma prawo czytać otrzymywane informacje. NNTP został zaimplementowany dla systemu Linux przez Stana Barbera i Phila Lap-sleya jako program rezydentny nntpd. Zwykle jest on rozprowadzany w postaci kodu źródłowego, ponieważ do poprawnego działania wymaga wprowadzenia kilku infor-macji dotyczących systemu. System nntpd składa się z programu-serwera i dwóch programów-klientów (jednego dla trybu aktywnego, drugiego dla biernego). Dodatkowo większość wersji nntpd za-wiera zamiennik programu inews. Alternatywą dla nntpd może być program INN (InterNetNews), opracowany przez Richa Salza. Jest on również rozprowadzany z wieloma dystrybucjami Linuxa. Pozwala na korzystanie zarówno z UUCP, jak i TCP, ale przeznaczony jest raczej dla większych komputerów. Jeśli przewidujesz korzystanie z wielu grup dyskusyjnych, powinieneś zamiast systemu nntpd zainstalować program INN. Ponieważ nntpd wystarcza dla większości użytkowników, skoncentrujemy się na jego konfiguracji. Dokładniejsze in-formacje na temat programu INN znajdziesz w dokumentacji dołączonej do oprogra-mowania lub dostępnej w węzłach BBS i FTP oraz w postaci dokumentu FAQ posyła-nego często na listy dyskusyjne. Kiedy NNTP otrzymuje artykuł z innego komputera, przekazuje go do jednego z pro-gramów obsługujących grupy dyskusyjne. Zwykle jest to program rnews lub inews. Możliwe jest również skonfigurowanie NNTP tak, by współpracował z programem re-laynews, pozwalającym na przesyłanie wszystkich artykułów do następnych kompu-terów (ang. batching - proces ten został omówiony wcześniej). Aby można było uży-wać NNTP, należy skonfigurować plik /usr/lib/news/history, zawierający infor-macje niezbędne do przesyłania danych za pomocą niektórych protokołów.
Instalowanie serwera NNTP
Serwer NNTP o nazwie nntpd zwykle rozprowadzany jest w postaci kodu źródłowego. Trzeba go skompilować w systemie lokalnym, po wprowadzeniu do kodu źródłowego pewnych informacji o systemie. Informacje te można dostarczyć za pomocą progra-mu zapisanego zwykle w pliku o nazwie /usr/lib/news/common/conf.h. Uruchom ten program (jest on w zasadzie zestawem makropoleceń) i odpowiedz na wszystkie zadawane pytania. Jeśli nie możesz go znaleźć, użyj polecenia find:
find / -name conf.h -print
Proces instalacji NNTP zacznij od utworzenia katalogu, w którym będą przechowywa-ne przychodzące artykuły. Może to być na przykład /usr/spool/news/.tmp (lub /var/ spool/news/.tmp). Właścicielem tego katalogu powinien być użytkownik news, należy więc wydać polecenia:
mkdir /usr/spool/news/.tmp
chown news.news /usr/spool/news/.tmp
Serwer NNTP można skonfigurować na dwa sposoby. Może on działać przez cały czas, wówczas należy uruchomić go w jednym z plików rc (zwykle rc.inet2) w trak-cie uruchamiania systemu. Można również uruchamiać go tylko wtedy, gdy jest po-trzebny, za pośrednictwem programu inetd. Jeśli nntpd ma działać przez cały czas, upewnij się (sprawdzając w pliku /etc/inetd.conf), że nie jest on wywoływany również przez program inetd, po-nieważ spowoduje to konflikt. Jeżeli chcesz, aby nntpd uruchamiany był przez proces inetd, co może nieco odciążyć system w czasie, gdy grupy dyskusyjne nie muszą być obsługiwane, musisz wpro-wadzić odpowiednie informacje do pliku /etc/inetd.conf. Za pomocą dowolnego edytora ASCII dodaj do niego wiersz:
nntp stream tcp nowait news /usr/etc/in.nntpd nntpd
Taki wpis może się tam już znajdować, zaznaczony jako komentarz (znak # w pierw-szej kolumnie). W takim przypadku wystarczy usunąć symbol komentarza. Bez względu na to, czy nntpd działa cały czas, czy jest uruchamiany przez proces in-etd, w pliku /etc/services, określającym usługi dostępne za pośrednictwem proto-kołu TCP/IP, musi znajdować się wpis:
nntp 119/tcp readnews untp
W większości wersji Linuxa taki wpis istnieje, ale jest zaznaczony jako komentarz - usuń wtedy znak #.
Konfigurowanie nntpd
Po skompilowaniu programu nntpd (które następuje automatycznie po uruchomieniu programu conf.h) powinieneś skonfigurować plik /usr/lib/news/nntp_access i zdecydować, które serwery i w jaki sposób będą mogły łączyć się z Twoim kompute-rem za pomocą nntpd. Wpisy w tym pliku mają format:
nazwa_serwera read|xfer|both|no post|no zabronione
nazwa_serwera musi być albo pełną nazwą domenową, albo adresem IP. Można również podać część nazwy lub numeru IP, zezwalając na dostęp wszystkich systemów wchodzących w skład podsieci. Jeżeli nazwa komputera, który próbuje się połączyć, dokładnie zgadza się z zawartością pola nazwa_serwera, plik nie jest przeszukiwany dalej. Jeśli natomiast pasuje tylko częściowo (tzn. zgadza się numer podsieci) przeszu-kiwanie jest kontynuowane. Aby określić prawa dostępu dla wszystkich komputerów, można zamiast nazwy serwera użyć słowa default. Prawa dostępu definiowane są w drugim polu. Rozpoznawane są cztery wartości:
read    komputer może otrzymywać artykuły;
xfer    komputer może wysyłać artykuły;
both    komputer może otrzymywać i wysyłać artykuły;
no    brak dostępu do artykułów.
Trzecie pole mówi o tym, czy komputer zdalny może wysyłać nowe artykuły. Jeśli znajduje się tu wartość post, komputer może wysyłać nowe artykuły, a lokalny sys-tem NNTP zadba o skompletowanie informacji w ich nagłówkach. Jeśli słowo no po-jawi się w drugim lub trzecim polu, system nie będzie mógł wysyłać nowych artykułów. Ostatnie pole zawiera listę grup, do których komputer nie będzie miał dostępu. Pole to rozpoczyna się od wykrzyknika i ma format listy, której poszczególne elementy roz-dzielane są przecinkami (taki format jest również używany w programie CNews), na przykład wpis:
chatton.bignet.com both post !alt.local
pozwala komputerowi chatton.bignet.com na wysyłanie i odbieranie artykułów ze wszystkich grup dyskusyjnych za wyjątkiem grup alt i local. Serwer może również wysyłać nowe artykuły. Prawdopodobnie będziesz chciał skonfigurować plik /usr/lib/news/nntp_access tak, aby wszystkim systemom zdalnym przyznać jakieś domyślne uprawnienia, a na-stępnie stworzyć konkretne wpisy dla systemów, z którymi faktycznie chcesz współ-pracować. Oto przykładowa zawartość pliku /usr/lib/news/nntp_access:
#wpis domyslny
default xfer no
#pelny dostep dla chatton
chatton.bignet.com both post
#tylko odczyt dla brutus
brutus.bignet.com read no
Dzięki takiemu rozwiązaniu każdy komputer będzie mógł przesyłać artykuły do Two-jego komputera (ale nie będzie mógł wysyłać nowych artykułów), natomiast komputer chatton.bignet.com posiada pełne uprawnienia, a brutus.bignet.com tylko prawo odczytu artykułów. W niektórych systemach NNTP zaimplementowane są systemy autoryzacji, które za-bezpieczają przed dostępem do danych przez osoby niepowołane. Ponieważ jak na ra-zie nie działają one dość sprawnie, najlepiej ich nie używać. Jeśli posiadasz nowszą wersję nntpd, poszukaj w dokumentacji informacji o zastosowaniu tych mechani-zmów.
Konfiguracja przeglądarek grup dyskusyjnych
Przeglądarka grup dyskusyjnych przedstawia w sposób wygodny dla użytkownika da-ne zapisane przez takie programy, jak nntpd czy CNews. Pozwala czytać, zapisywać, drukować i wykonywać inne operacje na artykułach, włączając oczywiście możliwość odpowiadania na nie. Można zapoznać się z tematami poruszanymi w danej grupie, zapisać się do grupy i wykonywać inne czynności. Przeglądarki różnią się między sobą złożonością, użytecznością i wygodą obsługi. Wraz z dystrybucjami Linuxa dostarczane są zarówno aplikacje graficzne, jak i dzia-łające w trybie tekstowym. Programiści przystosowują również swoje ulubione przeglą-darki działające pierwotnie w systemach UNIX czy DOS. Nie możemy omówić wszystkich dostępnych przeglądarek, ale pokażemy, jak skonfi-gurować najpopularniejsze z nich. Te informacje w połączeniu z dokumentacją po-winny pozwolić Ci uporać się z konfigurowaniem dowolnej przeglądarki. Ponieważ prawie z każdą dystrybucją rozprowadzane są programy trn i tin, właśnie im przyj-rzymy się bliżej w tym rozdziale.
Konfigurowanie programu trn
Przeglądarka trn, wykorzystywana powszechnie przez użytkowników UNIX-a, oparta jest na klasycznej już przeglądarce rn (ang. read news). Główną nowością, jaką wpro-wadził trn, była możliwość śledzenia wątków (ang. thread, są to artykuły powiązane tematycznie). W większości systemów program trn jest gotowy do użycia bez żadnych dodatkowych zabiegów konfiguracyjnych, o ile nie chcesz korzystać z obsługi wątków. Aby trn mógł odnaleźć artykuły powiązane ze sobą tematycznie, musi posiadać bazę danych o poszczególnych wątkach. Jest ona zwykle przechowywana w pliku /usr/local/ bin/rn/mthreads, a tworzy ją program mthreads. Najlepiej urucha-miać go w regularnych odstępach czasu za pomocą programu cron (zwykle tak często, jak ładowane są nowe artykuły). Program trn będzie działał bez programu mthre-ads, ale nie będzie umożliwiał obsługi wątków. Polecenie mthreads bez żadnych argumentów generuje bazę danych tylko dla ostat-nio załadowanych artykułów we wszystkich grupach dyskusyjnych. Aby poindekso-wać wszystkie grupy od zera, wydaj polecenie:
mthreads all
Spowoduje ono sprawdzenie zawartości pliku /usr/lib/news/active i rozpoczęcie indeksowania wszystkich grup wyszczególnionych w tym pliku. Jeśli chcesz indeksować tylko niektóre grupy, możesz przekazać ich nazwy jako argu-menty wywołania polecenia mthreads (w wierszu poleceń lub pliku crontab), na przykład polecenie
mthreads rec.auto.antique
spowoduje poindeksowanie bazy wątków grupy rec.auto.antique. Możliwe jest też poindeksowanie kilku grup - należy wówczas podać ich nazwy rozdzielone przecin-kami jako argumenty polecenia mthreads. Możesz również indeksować całe gałęzie grup, na przykład tak:
mthreads alt
Aby nie indeksować którejś z grup, poprzedź jej nazwę wykrzyknikiem; polecenie:
mthreads rec.auto,rec.audio,!rec.audio.tech
spowoduje poindeksowanie grup gałęzi rec.auto i rec.audio, za wyjątkiem grupy rec.audio.tech. Jeśli nowe artykuły ładujesz bardzo często, możesz rozważyć uruchomienie programu mthreads jako programu rezydentnego, dzięki czemu nie trzeba uruchamiać go co ja-kiś czas, a nadchodzące artykuły są przetwarzane natychmiast - obciąża to jednak nieco bardziej zasoby systemu. Aby uruchomić program mthreads jako program re-zydentny, należy użyć opcji -d. Domyślnie nowe artykuły indeksowane są co 10 mi-nut. Polecenie uruchamiające ten program można umieścić w jednym z plików rc.
Konfigurowanie programu tin
W przeciwieństwie do programu trn, tin nie wymaga interwencji użytkownika do zbudowania bazy danych o wątkach - tworzy ją za każdym razem, gdy użytkownik wchodzi na listy dyskusyjne. Indeksowanie przebiega dość szybko, chyba że grupa zawiera więcej niż 500 nowych artykułów. Plik zawierający indeks zapisywany jest w katalogu domowym użytkownika pod na-zwą .tin/index/nazwa_grupy_dyskusyjnej. Jego rozmiary mogą być całkiem spore, dlatego warto rozważyć utworzenie jednego indeksu, z którego będą mogli ko-rzystać wszyscy użytkownicy. Taki efekt można uzyskać zmieniając właściciela pro-gramu tin:
chown news.news tin
Baza danych o wątkach będzie teraz zapisywana w pliku /usr/spool/news/.index. Możesz również uruchomić program rezydentny tind, który zadba o aktualizację ba-zy danych na bieżąco. Kod źródłowy tego programu dostarczany jest wraz z niektó-rymi dystrybucjami Linuxa, ale rzadko jest on rozprowadzany w wersji skompilowanej - dlatego do jego zainstalowania konieczny będzie kompilator języka C i program na-rzędziowy make.

Bezpieczeństwo w sieci
Omówienie wszystkich zagadnień związanych z bezpieczeństwem systemów zajęłoby kilka tomów, z konieczności więc omówimy tylko te najprostsze. Przyjrzymy się naj-bardziej podstawowym mechanizmom zabezpieczania się przed włamaniami poprzez łącza telefoniczne i niektórym aspektom zabezpieczeń w sieci lokalnej. Nie będziemy omawiać skomplikowanych rozwiązań, które są trudne do wprowadzenia i wymagają specjalistycznej wiedzy, a ponadto mogą być zastosowane tylko w niektórych syste-mach. Zamiast tego przyjrzymy się podstawowym metodom zabezpieczania systemu, które są zarówno proste, jak i skuteczne. Wielu administratorów albo nie wie, co można zro-bić, aby zabezpieczyć się przed włamaniem, albo też lekceważy taką możliwość. Włamania są jednak wyjątkowo częste, więc nie warto igrać z ogniem.
b>Słabe hasła
Może się to wydawać nieprawdopodobne, ale najczęściej intruzi dostają się do syste-mów (obojętne czy przez sieć lokalną, czy połączenie modemowe), wykorzystując słabe - czyli łatwe do odgadnięcia - hasła użytkowników. Jeśli użytkownicy stosują słabe hasła, nawet najlepszy system zabezpieczeń nie może zabezpieczyć przed wła-maniem. Jeśli zarządzasz systemem, w którym jest kilku użytkowników, powinieneś wymagać od nich zmiany hasła co pewien czas (na przykład co sześć czy osiem tygodni). Naj-lepsze hasła składają się z kombinacji cyfr i liter, których nie można znaleźć w żad-nym słowniku. Czasem zmiana haseł nie wystarcza - powinieneś wtedy rozważyć użycie jednego z programów komercyjnych lub dostępnych na licencji public domain, wymuszają-cych użycie mocnych haseł. Pakiety takie zwykle rozprowadzane są w postaci kodu źródłowego, przed użyciem konieczne jest więc ich skompilowanie.
Bezpieczeństwo plików
Dbałość o bezpieczeństwo systemu powinna zaczynać się już na poziomie praw dostę-pu do plików, które powinny być ustawiane bardzo uważnie. Jeśli chcesz zabezpieczyć nowe pliki przed niepowołanymi osobami, ustaw odpowiednią wartość zmiennej umask. Oczywiście kwestie bezpieczeństwa plików mają znaczenie tylko wtedy, gdy z systemu korzysta jeszcze ktoś oprócz Ciebie. Jeśli tak jest, warto pomyśleć nad globalnym ustawieniem wartości tej zmiennej dla wszystkich użytkowników, zapewniając, że no-we pliki będą miały przypisane prawa dostępu nadające ich właścicielom i nikomu in-nemu prawo do odczytu i zapisu. To w zasadzie wszystko, co można zrobić dla zabez-pieczenia plików. Szczególnie ważne pliki (na przykład zawierające dane o pracownikach) warto dodat-kowo zabezpieczyć za pomocą jakiegoś programu szyfrującego - dostępnych jest wie-le tego rodzaju aplikacji. W większości z nich do kodowania i dekodowania używa się tego samego hasła
Dostęp przez modem
Dla większości użytkowników Linuxa problem zabezpieczania się przed włamaniem poprzez bramkę internetową nie jest szczególnie istotny z prostego powodu - nie po-siadają oni bezpośredniego połączenia z Internetem. Trzeba jednak pomyśleć o za-bezpieczeniu się przed włamaniami przez modem. Modemy są najczęściej używanym "oknem na świat" w systemach linuxowych. Za ich pośrednictwem można używać systemu z komputera zdalnego, uzyskać dostęp do In-ternetu itp. Zabezpieczenie linii używanych przez modem jest prostą i efektywną me-todą powstrzymania przypadkowych szperaczy.
Modemy oddzwaniające
Najbezpieczniejszą techniką kontrolowania dostępu do modemu jest użycie mode-mów oddzwaniających (ang. callback modems). Modemy tego typu pozwalają użyt-kownikowi połączyć się w zwykły sposób, następnie przerywają połączenie, wyszuku-ją w bazie danych numer telefonu użytkownika, który chciał się zalogować, i same nawiązują połączenie. Największą wadą takiego rozwiązania są wysokie koszty, dlatego nie jest ono stoso-wane zbyt często. Dodatkowe problemy pojawiają się, gdy użytkownicy często zmieniają miejsce, z któ-rego dzwonią, co wiąże się ze zmianą numeru telefonu. Modemy oddzwaniające dają się również oszukać za pomocą przekazywania rozmowy - rozwiązania oferowanego przez wiele nowocześniejszych aparatów telefonicznych.
Problemy z modemami
Typowy modem telefoniczny może być źródłem problemów, jeśli nie kończy prawi-dłowo połączenia (nie odwiesza słuchawki po zakończeniu sesji). Wynika to często ze złej konfiguracji modemu lub niewłaściwego podłączenia. Problemy powodowane przez nieprawidłowe podłączenie modemu mogą wydawać się banalne, ale w wielu systemach połączenia montowane na własną rękę nie zapewniają prawidłowej kontroli nad linią i możliwe jest pozostawienie nie zakończonego połącze-nia. Wtedy następny dzwoniący kontynuuje sesję poprzedniego użytkownika. Aby zabezpieczyć się przed tego typu problemami, wymień wszystkie robione ręcznie połączenia na okablowanie pochodzące od pewnego producenta. Warto również kilka czy kilkanaście razy sprawdzić, czy po zakończeniu sesji połączenie jest prawidłowo przerywane. Problem ten może być również spowodowany nieprawidłową konfiguracją oprogra-mowania. Sprawdź w dokumentacji modemu, czy Twój skrypt potrafi odwiesić słu-chawkę po zakończeniu sesji i przy zerwaniu połączenia. Problem ten rzadko występu-je w przypadku popularnych modemów, ale mając jakiś mniej znany model warto się upewnić, czy nie będzie on powodował problemów, sprawdzając, czy po zakończeniu połączenia linia jest zwalniana. Bardzo skuteczną metodą zapobiegania włamaniom przez modem jest po prostu od-łączanie go w czasie, kiedy nie jest potrzebny. Ponieważ włamania zwykle mają miej-sce po normalnych godzinach pracy systemów, można po prostu wyłączać modem na noc. Można również użyć pliku crontab do czasowego wyłączania portu szeregowe-go, do którego podłączony jest modem. W wielu systemach wyłączanie modemu nie jest praktycznym rozwiązaniem, ale czę-sto warto je rozważyć. Jeśli dostęp w godzinach nocnych jest konieczny, można na przykład pozostawić jeden modem załączony, wyłączając pozostałe. W większych systemach zwykle liczba modemów działających po godzinach pracy jest znacznie mniejsza, niż pracujących normalnie.
Jak modem obsługuje połączenie
Aby użytkownik mógł otrzymać dostęp do systemu linuxowego przez modem, w sys-temie musi działać proces getty. Jest on uruchamiany przez proces init dla każdego portu szeregowego. Proces getty jest odpowiedzialny za pobranie identyfikatora użyt-kownika, ustalenie parametrów transmisji (na przykład typu terminalu i prędkości przesyłu danych) oraz obserwowanie, czy czas oczekiwania na odpowiedź nie został przekroczony. W systemie Linux porty szeregowe i porty kart multiport kontrolowane są przez plik /etc/ttys. W niektórych systemach możliwe jest założenie dodatkowego hasła, wymaganego do połączeń modemowych. Użytkownik łączący się za pośrednictwem modemu będzie musiał wprowadzić dwa hasła. Jeśli hasło do połączeń modemowych jest obsługiwane, ustawia się je w pliku /etc/dialups. W systemach linuxowych w pliku /etc/dialups przechowywana jest lista portów wymagających podania hasła, natomiast same hasła przechowywane są w innym pli-ku (na przykład /etc/d_passwd). Podobne rozwiązanie można również zastosować do połączeń UUCP.
UUCP
Przy projektowaniu systemu UUCP brano pod uwagę problemy bezpieczeństwa, ale było to wiele lat temu - od tego czasu wymagania stawiane tego typu systemom zmie-niły się bardzo znacznie. Znaleziono również sporo luk w bezpieczeństwie stwarzanych przez ten system, choć większość z nich została naprawiona poprzez modyfikacje w kodzie źródłowym. System UUCP nadal wymaga, by poświęcić nieco uwagi prawidło-wej konfiguracji - wtedy będzie działał poprawnie i bezpiecznie. Jeśli nie zamierzasz używać UUCP, usuń z pliku /etc/passwd użytkownika uucp (lub przynajmniej zablokuj logowanie dopisując gwiazdkę na początku hasła). Usunięcie użytkownika uucp nie zakłóci w żaden sposób działania systemu, o ile nie jest uży-wany protokół UUCP. Wszystkim katalogom i plikom systemu UUCP powinny być przypisane tak ograni-czone prawa dostępu, jak to tylko możliwe (zwykle są to katalogi /usr/lib/uucp, /usr/ spool/uucp i /usr/spool/uucppublic). Odpowiednie prawa możesz ustalić za pomocą poleceń chown, chmod i chgrp. Właścicielem tych katalogów powinien być użytkownik uucp, grupa uucp. Warto również regularnie sprawdzać, czy wszystkie pliki mają przypisane prawidłowe prawa dostępu. To, czy dany system ma prawo korzystać z protokołu UUCP, ustalane jest na podsta-wie zawartości kilku plików. Pliki te (na przykład /usr/lib/uucp/Systems i /usr/lib/ uucp/Permissions) powinny być również własnością użytkownika uucp i tylko on powinien mieć do nich dostęp. To zabezpieczy przed ich modyfikacją przez niepowołane osoby. Katalog /usr/spool/uucppublic często jest celem włamań, ponieważ każdy łą-czący się system ma w nim prawo zapisu i odczytu. Pewnym zabezpieczeniem może być utworzenie dwóch podkatalogów: jednego do odbierania, a drugiego do nadawa-nia plików. Można również utworzyć osobny podkatalog dla każdego systemu łączą-cego się za pośrednictwem UUCP.
Dostęp poprzez sieć lokalną
Choć sieci lokalne rzadko stanowią zagrożenie same w sobie (ponieważ zwykle korzy-stają z nich zaufane osoby), są jednak jednym z najłatwiejszych sposobów na wła-manie się do systemu. Najpoważniejszy problem polega na tym, że jeśli choć jedna maszyna ma jakieś słabe punkty (jeśli chodzi o zabezpieczenia), to żaden inny kom-puter w sieci nie jest bezpieczny. Z tego powodu każde zabezpieczenie powinno działać na wszystkich bez wyjątku komputerach w sieci. Idealny system bezpieczeństwa w sieci lokalnej wymusza zastosowanie odpowiednich procedur uwierzytelniania dla każdego połączenia. Niestety, takie rozwiązanie może powodować konflikty z wieloma istniejącymi programami i rozwiązaniami systemo-wymi. Dlatego w Linuxie istnieje pojęcie komputera zaufanego (ang. trusted host). Ta-ki komputer może połączyć się z systemem bez żadnych problemów, pod warunkiem, że jego nazwa znajduje się w odpowiednim pliku - w większości przypadków nie jest wymagane nawet hasło! Wszystko, co musi zrobić włamywacz, to poznać nazwę komputera zaufanego i połączyć się, podając taką nazwę. Sprawdź więc dokładnie zawartość plików /etc/hosts.equiv, /etc/hosts i .rhosts. Jednym z rozwiązań jest używany ostatnio dość powszechnie system Kreberos, opra-cowany przez MIT. Kreberos wprowadza pojęcie komputera bardzo bezpiecznego (ang. very secure host), który działa jako serwer uwierzytelniający połączenia. Szyfro-wanie przesyłanych wiadomości zabezpiecza również przed odczytywaniem ich na-główków przez włamywaczy. System Kreberos uwierzytelnia wszystkie wiadomości przesyłane w obrębie sieci. Ze względu na naturę większości sieci, systemy linuxowe są narażone na ataki intruzów posiadających dużą wiedzę o systemie. Znane są dosłownie setki problemów stwarza-nych przez oprogramowanie TCP/IP. Jako pierwszy krok w zabezpieczaniu systemu powinieneś więc wyłączyć wszystkie te usługi i protokoły, których nie wykorzystujesz, ponieważ ktoś może użyć ich do włamania się do systemu.
Śledzenie intruza
Większość włamań dokonywanych jest przez ludzi ciekawych, jakiego typu dane przechowywane są w systemie, ale nie mających na celu dokonania zniszczeń. Często włamują się do systemu co jakiś czas, rozglądają się, grają w jakieś gry i wylogowują się niczego nie zmieniając. Z tego powodu trudno zauważyć, że ktoś się włamał - wówczas zdany jesteś tylko na łaskawość intruza. Może nie przyjdzie mu do głowy ni-czego niszczyć. Czasem również system może być wykorzystywany jako odskocznia przy atakowaniu innego - wtedy administrator tego systemu stwierdzi, że włamanie nastąpiło z Twojego komputera i możesz mieć kłopoty. "Śledzić" użytkowników systemu możesz włączając proces rejestrujący dane użyt-kownika za każdym razem, gdy łączy się on i rozłącza z systemem, nazywany proce-sem audytu (ang. auditing) lub procesem monitorowania połączeń. Nie we wszystkich wersjach Linuxa proces taki jest dostępny. Dokładniejszych informacji szukaj na stro-nach man. Jeśli proces audytu działa w Twoim systemie, powinieneś często przeglądać generowa-ny plik. Dobrze jest również napisać prosty skrypt wyświetlający podsumowanie, za-wierające dane o tym, kto ile czasu był podłączony do systemu, w jakich godzinach itp. To może pozwolić Ci wyłapać wszelkie anomalie czy zauważyć coś, co nie zgadza się z Twoimi informacjami (na przykład logowanie się po godzinach pracy itp.). Taki skrypt możesz z łatwością napisać na przykład w języku gawk. Dostępne są również gotowe programy do tego celu.
Przygotowywanie się na najgorsze
Załóżmy, że ktoś się włamuje. Co możesz zrobić w takim przypadku? Oczywiście kopii zapasowych nie da się przecenić - pomogą Ci one odzyskać wszystkie usunięte czy uszkodzone pliki. Ale poza tym, co jeszcze można zrobić? Po pierwsze, powinieneś dowiedzieć się, w jaki sposób dokonano włamania i zabezpie-czyć tę drogę tak, by włamanie nie mogło się już powtórzyć. Jeśli nie jesteś pewny, wy-łącz wszystkie modemy i terminale i uważnie sprawdź wszystkie pliki konfiguracyjne, szukając nieprawidłowych danych. Gdzieś musi być błąd, ponieważ inaczej nie byłoby włamania. Sprawdź również hasła i listę użytkowników - być może zapomniałeś usu-nąć jakieś konto, które dawno już nie powinno istnieć. Jeśli jesteś ofiarą powtarzających się ataków, spróbuj załączyć system monitorowania połączeń. Być może dzięki temu będziesz mógł wyśledzić, jaką drogą nieproszony gość dostaje się do systemu i co w nim robi. Powinieneś również mieć świadomość, że włamania są nielegalne - w ostateczności możesz więc skontaktować się z organami ścigania.

NFS
NFS (Network File System, sieciowy system plików), stworzony przez firmę Sun Micro-systems, umożliwia współużytkowanie plików i katalogów pomiędzy systemami UNIX-owymi. Katalog sieciowy udostępniany poprzez NFS widziany jest w każdym systemie tak, jakby był katalogiem lokalnym. Przykładowo, jeśli masz dostęp do sys-temu linuxowego, w którym zainstalowane jest mnóstwo gier, a nie masz miejsca, by je wszystkie zainstalować u siebie, możesz za pomocą NFS skonfigurować swój system tak, aby gry te były widoczne w jakimś katalogu lokalnym i używać ich bez żadnych problemów. Dzięki NFS proces łączenia się z innym komputerem i transportu danych za każdym razem, gdy uruchamiasz grę, jest niewidoczny dla użytkownika (może za wyjątkiem opóźnień wprowadzanych przez sieć). NFS może być używany w sieciach różnego typu, choć został zaprojektowany dla sieci opartych na TCP/IP. Ze względu na jego popularność, pojawiły się implementacje dla różnych systemów operacyjnych, co pozwala na współużytkowanie plików i katalo-gów w sieciach niejednorodnych. W UNIX-ie i Linuxie NFS działa w trybie peer-to-peer (równy z równym). Oznacza to, że Twój komputer może zachowywać się zarówno jako klient, jak i serwer usługi NFS, a nawet spełniać obie te funkcje równocześnie. Wiele osób używa NFS w pracy, ale boi się skonfigurować go we własnym systemie li-nuxowym, ponieważ uważają, że jego konfiguracja jest złożona, trudna, i wymaga dużej wiedzy o systemie operacyjnym. Z tego powodu wiele osób rezygnuje z NFS, choć jest to jedna z najbardziej pożytecznych usług oferowanych przez TCP/IP. Jak jednak przekonasz się czytając ten rozdział, konfigurowanie NFS w systemie Linux nie jest ani takie skomplikowane, ani długotrwałe, jak się powszechnie uważa. Oczywiście abyś mógł docenić jego zalety, w skład sieci musi wchodzić więcej niż jeden kompu-ter... Niektóre nowsze produkty, takie jak VisionFS, znacznie upraszczają uży-wanie dysków sieciowych. Wersje tych programów są dostępne również dla Linuxa, ale niestety są to produkty komercyjne. Konfiguracja NFS w systemie Linux NFS intensywnie korzysta z usługi RPC (Remote Procedure Call, zdalne wywoływanie procedur). Z tego powodu przed uruchomieniem NFS trzeba sprawdzić, czy program obsługujący RPC działa poprawnie. W niektórych systemach możesz to zrobić wyda-jąc polecenie:
rpcinfo -p
Wynikiem jego działania powinna być lista wszystkich serwerów RPC działających w Twoim systemie, na przykład:
[root@linux reksio]# rpcinfo -p
program vers proto port 100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
300019 1 udp 737
100001 13 udp 791 rstatd
100001 3 udp 791 rstatd
100001 2 udp 791 rstatd
100001 1 udp 791 rstatd
100001 13 udp 796 rstatd
100001 3 udp 796 rstatd
100001 2 udp 796 rstatd
100001 1 udp 796 rstatd
Jeśli RPC działa prawidłowo, powinieneś zobaczyć przynajmniej pięć pozycji: dwie dla UDP, dwie dla TCP oraz jedną dla programu pcnfsd, obsługującego NFS. W powyż-szym przykładzie nie ma pozycji pcnfsd,więc wiemy, że program obsługi NFS nie jest aktywny. Programy obsługujące NFS muszą najpierw zostać zainstalowane: Linux najczęściej pozwala na to przy instalacji systemu. Jeśli nie zainstalowałeś ich wtedy, zrób to teraz, używając programu instalacyjnego dołączonego do Twojej wersji Linuxa. W niektó-rych systemach (np. Caldera Linux i wiele dystrybucji Slackware) program obsługi NFS jest domyślnie instalowany i uruchamiany przy starcie systemu, bez względu na to, czy jest faktycznie używany.
Konfiguracja serwera linuxowego
W większości wersji Linuxa NFS jest uruchamiany i wyłączany za pomocą skryptu /etc/nfs. Jeśli chcesz uruchamiać go automatycznie, powinieneś utworzyć dowiąza-nie do tego skryptu o nazwie /etc/rc2.d/Sname. Aby prawidłowo wyłączać NFS, powinieneś również stworzyć dowiązanie /etc/rc0.d/Kname. Ręcznie możesz go uru-chomić i zatrzymać poleceniami:
/etc/nfs start
/etc/nfs stop
W niektórych wersjach Linuxa używane są inne nazwy plików i katalogów, na przykład wspomniany wyżej skrypt /etc/nfs może być zapisany pod nazwą /etc/rc.d/init.d/nfs albo /etc/init.d/nfs. Po wydaniu polecenia uruchamiającego NFS na ekranie powinny zostać wyświetlone komunikaty potwierdzające uruchomienie odpowiednich programów:
$ /etc/nfs start
Starting NFS services: exportfs mountd nfsd pcnfsd biod(x4)
Starting NLM services: statd lockd
natomiast przy wyłączaniu usługi NFS, komunikaty o zakończeniu ich działania:
$ /etc/nfs stop
NFS shutdown: [NFS Shutdown Complete]
Jeśli linuxowy system plików ma być dostępny za pośrednictwem usługi NFS dla in-nych komputerów, musi być wymieniony w pliku /etc/exports. W niektórych sys-temach NFS uruchamia się automatycznie, jeśli plik /etc/exports istnieje podczas uruchamiania systemu - wywoływany jest wówczas program exportfs, pozwalający innym komputerom korzystać z systemu plików za pośrednictwem NFS. Jeśli zmodyfi-kujesz plik /etc/exports, powinieneś wydać polecenie exportfs jeszcze raz albo ponownie uruchomić komputer, aby uaktywnić zmiany. Składnia wpisów w pliku etc/exportfs jest następująca:
katalog [-opcja, opcja ...]
katalog to ścieżka dostępu do katalogu, który ma być udostępniany (eksportowany, według terminologii NFS) za pomocą NFS, a opcje mogą przybierać następujące war-tości: ro    eksportowanie w trybie tylko do odczytu (domyśl-nie: do odczytu i zapisu);
rw=nazwy_komputerów    zezwolenie na zapis tylko dla wymienionych komputerów, dla pozostałych - tylko odczyt;
anon=uid    jeśli żądanie NFS pochodzi z nieznanego serwera, używa identyfikatora użytkownika uid dla okre-ślenia praw dostępu;
root=nazwy_komputerów    nadaje uprawnienia użytkownika root użytkow-nikom root pochodzącym z wyszczególnionych komputerów;
access=klient    umożliwia używanie NFS tylko wyszczególnionym klientom. Pole klient może zawierać nazwę komputera lub całej grupy sieciowej.
Podany niżej przykładowy plik /etc/exports ułatwi zrozumienie zastosowania tych opcji. Symbol # oznacza początek komentarza.
/usr/stuff -ro     #eksport tylko do odczytu dla wszystkich
/usr -access=clients    #eksport dla grupy o nazwie clients
/usr/public     #eksport do odczytu i zapisu dla każdego
Jeśli zmodyfikujesz zawartość pliku /etc/exports, powinieneś zrestartować progra-my obsługi NFS. Polecenie exportfs wyświetla nazwy wszystkich eksportowanych systemów plików. Niektóre systemy automatycznie generują plik o nazwie /etc/xtab, za-wierający informacje o systemach plików. Nie należy modyfikować tego pliku, ponieważ NFS może przestać działać prawidłowo. Plik ten jest two-rzony przez program exportfs. W niektórych systemach linuxowych do eksportowania katalogów używa się polecenia share (wiele wersji Linuxa nie obsługuje tego polecenia, ponieważ jego funkcje po-krywają się funkcjami pliku /etc/exports). Jego składnia jest następująca:
share -F nfs -o opcje -d opis ścieżka
Parametr nfs określa, że katalog ma być eksportowany za pośrednictwem usługi NFS. opcje mogą przyjmować takie same wartości, jak opcje podawane w pliku /etc/exports. Można również podać opisową nazwę eksportowanego katalogu, używając opcji -d. Jeśli na przykład chcesz udostępnić do odczytu i zapisu katalog /usr/public, możesz wydać polecenie:
share -F nfs -d "Server public directory" /usr/public
Można również użyć jednocześnie kilku opcji, na przykład:
share -F nfs -o ro=artemis,anon=200 -d "Book material" /usr/reksio/book
Powyższe polecenie spowoduje udostępnienie katalogu /usr/reksio/book, opisanego jako Book material, dla każdego w trybie do odczytu i zapisu, za wyjątkiem komputera artemis, który będzie miał tylko możliwość odczytu. Prawa dostępu ano-nimowych użytkowników będą określane na podstawie praw dostępu użytkownika o identyfikatorze numerycznym 200. Polecenie share bez parametrów zwykle wyświetla informacje o wszystkich eksportowanych katalogach.
Konfigurowanie klienta
Eksportowany przez serwer system plików można zamontować bez żadnych problemów poleceniem mount o następującej składni:
mount -F nfs [-o opcje] serwer:katalog punkt_zamontowania
Opcja -F nfs określa, że chodzi o system plików dostępny przez NFS. serwer:katalog to nazwa serwera i ścieżka dostępu do katalogu, który ma zostać zamontowany. punkt_zamontowania określa katalog, w którym zdalny system pli-ków będzie dostępny w komputerze lokalnym (katalog ten musi istnieć). W niektórych wersjach Linuxa składnia polecenia mount może być nieco inna, na przykład czasem zamiast opcji -F nfs należy podać -f NFS. Dokładne informacje o składni znajdu-ją się w dokumentacji. Podane niżej przykładowe polecenie montuje system plików znajdujący się w katalogu /usr/public systemu artemis w katalogu lokalnym /usr/artemis:
mount -F nfs artemis:usr/public /usr/artemis
Katalog /usr/artemis musi zostać wcześniej utworzony.
opcje mogą być kombinacją następujących wartości:
rw montuje system plików do odczytu i zapisu (ustawienie domyślne);
ro montuje system plików tylko do odczytu;
timeo=x określa maksymalny czas, jaki należy odczekać przed daniem za wygraną, jeśli montowanie się nie powiedzie (w dziesiątych sekundy);
retry=x w razie niepowodzenia powoduje powtórzenie próby montowania x razy;
soft wymusza poddanie się, jeśli od serwera nie przychodzi potwier-dzenie zamontowania;
hard powoduje, że klient kontynuuje próby montowania aż do skutku;
intr pozwala na przerwanie montowania przez naciśnięcie dowolnego klawisza; w przeciwnym przypadku próby montowania są powtarzane do skutku.
Poniższe polecenie powoduje próbę zamontowania katalogu /usr/public udostępnianego w systemie artemis w trybie tylko do odczytu, i poddanie się, jeśli komputer zdalny nie potwierdzi zamontowania systemu plików:
mount -F nfs -o soft,ro artemis:usr/public /usr/artemis
Polecenie mount bez parametrów wyświetla listę wszystkich zamontowanych systemów plików. Istnieje jeszcze prostsza metoda montowania często używanych systemów plików. Jeśli nazwy systemów plików i punkty ich zamontowania wraz z opcjami zostaną umieszczone w pliku /etc/fstab lub /etc/vfstab (zależnie od wersji Linuxa), bę-dzie można je zamontować wydając polecenie mount tylko z jednym parametrem - punktem zamontowania, na przykład
mount /usr/artemis

NIS i YP
System NIS (ang. Network Information Service, sieciowy system informacyjny) umoż-liwia dostęp do plików, które normalnie byłyby dostępne tylko lokalnie, z dowolnego punktu sieci. Takie rozwiązanie ułatwia życie zarówno użytkownikom, jak i admini-stratorom systemu. Podstawą systemu NIS jest wspólny dla całej sieci plik z hasłami, dzięki czemu użytkownik nie musi posiadać konta w każdym z podłączonych do sieci komputerów. Zamiast tego komputer-nadzorca (ang. NIS master) kontroluje dostęp do wszystkich innych komputerów. YP (Yellow Pages) to system będący poprzednikiem NIS. Nazwa systemu została zmieniona ze względu na prawa autorskie, ale większość termino-logii używanej w opisie systemu NIS pochodzi z systemu YP. W tym rozdziale dowiesz się, w jaki sposób skonfigurować system NIS w prostej sieci. Niestety, nie wszystkie sieci są proste - w niektórych przypadkach szczegóły architek-tury i konfigurowania sieci mogą stać się bardzo skomplikowane. Choć ogólne zasady działania systemu NIS pozostają takie same, konfigurowanie bardziej złożonych sieci może wymagać dodatkowych zabiegów - co gorsza innych praktycznie w każdym przypadku. Dlatego pozostawimy ten temat na boku, skupiając się na prostych sie-ciach, do których zwykle podłączone są komputery linuxowe. Nazwy plików używanych do konfigurowania systemu NIS zebrane są w tabeli
Nazwa pliku    Funkcja
/etc/ethers    Odwzorowywanie adresów Ethernet MAC na IP
/etc/group    Informacje o prawach dostępu dla grup
/etc/hosts    Odwzorowywanie adresów IP na nazwy symboliczne
/etc/netmasks    Maski IP
/etc/passwd    Informacje o kontach użytkowników
/etc/protocols    Odwzorowywanie protokołów i numerów sieciowych
etc/rpc    Numery RPC
/etc/services    Odwzorowywanie numerów portów na protokoły TCP/IP
Podczas konfigurowania komputera-nadzorcy i nadzorców zastępczych przyjrzymy się najczęściej używanym plikom konfiguracyjnym, zobaczymy również, jakie mody-fikacje należy wprowadzić do plików konfiguracyjnych komputerów mających pra-cować w systemie NIS.
Konfiguracja domeny NIS
W systemie NIS do logicznego grupowania komputerów używa się pojęcia domeny. Domena NIS zawiera jeden komputer skonfigurowany jako nadzorca i jeden lub wię-cej komputerów skonfigurowanych jako nadzorcy zastępczy. Nadzorca zastępczy przejmuje wszystkie funkcje nadzorcy w takich sytuacjach, jak załamanie systemu czy problemy z siecią. Dzięki takiemu rozwiązaniu system działa przez cały czas, bez względu na dostępność komputera-nadzorcy. Konfigurowanie nadzorcy zastępczego jest bardzo proste, więc w każdej sieci powinien znaleźć się co najmniej jeden kompu-ter pełniący tę rolę. Można również podzielić obsługę NIS pomiędzy komputer-nadzorcę i jego zastępcę. Zmiany w plikach konfiguracyjnych nadzorcy są automa-tycznie rozprowadzane do zastępców. Obszar domeny NIS nie musi pokrywać się z domeną internetową, choć z taką sytua-cją mamy do czynienia w większości systemów (czyli, innymi słowami, cała sieć jest domeną NIS). Domena NIS musi posiadać nazwę, która również może, ale nie musi, pokrywać się z nazwą domeny internetowej. Zamiast jednej dużej domeny można też stworzyć mniejsze domeny NIS, na przykład osobną dla każdego wydziału w przed-siębiorstwie. Aby skonfigurować domenę NIS, powinieneś najpierw wybrać dla niej jakąś nazwę i ustalić numer IP komputera-zarządcy i zarządcy zastępczego. Jeśli konfigurujesz wię-cej niż jedną domenę, musisz zdecydować, które komputery będą należały do której domeny. Każdy komputer w obrębie domeny musi zostać wyszczególniony w odpowiednim pliku konfiguracyjnym. Konfiguracja domeny NIS wymaga zalogowania się w każdym systemie podłączonym do sieci i ustawienia we wszystkich systemach takiej samej nazwy domeny za pomocą polecenia:
domainname nazwa_domeny
Aby ustawić nazwę domeny, musisz mieć uprawnienia administratora. Ponieważ jed-nak takie polecenie zachowuje ważność tylko do momentu zrestartowania komputera, najlepiej zapisać je w jednym z plików rc (zwykle znajdujących się w katalogu /etc/rc.d). Szczegóły dotyczące tej operacji mogą różnić się w zależności od wersji Linuxa. W niektórych wersjach Linuxa dostępne są skrypty automatyzujące te zadania, na przykład w systemie Caldera OpenLinux dostępny jest program narzędziowy, po uru-chomieniu którego trzeba tylko podać nazwę domeny i adresy IP komputera-nadzorcy i zastępców (program ten ogranicza ich liczbę do najwyżej dwóch).
Programy rezydentne obsługujące NIS
System NIS korzysta z kilku programów rezydentnych działających w systemie kom-putera-nadzorcy i jego zastępców. Jednym z nich jest program ypserv, obsługujący wszystkie żądania pochodzące od komputerów-klientów. Po stronie klientów działa program ypbind, który jest odpowiedzialny za łączenie się z nadzorcą podczas uruchamiania systemu i podejmowanie wszelkich działań związa-nych z przesyłaniem danych o użytkownikach i konfiguracji sieci. Proces łączenia się programu ypbind z komputerem-nadzorcą nazywany jest wiązaniem (ang. binding). Proces wiązania się z nadzorcą rozpoczyna się w momencie, kiedy komputer-klient wysyła do wszystkich komputerów informację o tym, że poszukuje adresu IP nadzor-cy systemu NIS. Nadzorca w odpowiedzi na taką informację powinien przesłać swój numer IP i numer portu, na którym może nastąpić połączenie. Jeśli odezwie się więcej niż jeden nadzorca, używany jest numer pierwszego z nich. Jeśli nikt się nie odezwie, in-formacja jest ponownie wysyłana do sieci - aż do skutku. Aby sprawdzić, z którym komputerem-nadzorcą system jest aktualnie związany, nale-ży wydać polecenie ypwhich:
$ ypwhich
merlin
Konfigurowanie komputera-nadzorcy NIS
Konfigurowanie komputera-nadzorcy NIS jest czynnością dość prostą. Należy zacząć od sprawdzenia, czy wszystkie informacje w plikach /etc/passwd i /etc/group są aktualne; usuń wpisy o wszystkich nieistniejących już użytkownikach i grupach, sprawdź, czy wszystkie katalogi domowe i interpretery poleceń uruchamiane przy logowaniu są ustawione prawidłowo. Zwróć uwagę na to, czy dla każdego konta założone jest hasło. Błąd w plikach konfiguracyjnych za pomocą NIS rozprzestrzenia się na całą sieć, znacznie obniżając poziom bezpieczeństwa. Po przygotowaniu plików upewnij się, że jesteś zalogowany jako root - tylko wtedy będziesz posiadał odpowiednie prawa dostępu i pełny dostęp do systemu. Pliki mapo-wania systemu NIS generowane są z plików istniejących w systemie za pomocą pro-gramu ypinit z opcją -m (która oznacza, że komputer ma być nadzorcą, ang. ma-ster):
/usr/sbin/ypinit -m
Ścieżka dostępu do programu ypinit może być inna w Twoim systemie - sprawdź ją, jeśli po wydaniu powyższego polecenia generowany jest komunikat o błędzie. Po uruchomieniu, program ypinit przegląda wszystkie pliki NIS wymienione w pliku /var/yp i generuje pliki mapowania, które będą używane przez procesy klientów. W niektórych systemach plik spełniający funkcję taką, jak /var/yp, nazywa się nieco inaczej - na przykład w systemie SCO UNIX jest to jeden z plików zapisanych w kata-logu /etc/yp; powinieneś to sprawdzić w dokumentacji. Plik /var/yp zawiera listę plików mapowania, które mają zostać wygenerowane, i zwykle nie wymaga modyfi-kacji. Program ypinit tworzy nowy katalog, zazwyczaj o nazwie /var/yp/nazwa_domeny, w którym zapisuje wszystkie wygenerowane pliki. Jeśli konfigurujesz kilka domen ob-sługiwanych przez tego samego nadzorcę, pliki utworzone dla każdej z domen zostaną umieszczone w osobnym podkatalogu. Na koniec program ypinit zapyta o komputery spełniające funkcję nadzorców za-stępczych - powinieneś podać ich nazwy. Nazwy te są zapisywane w pliku w katalogu /var/yp/nazwa_domeny. W niektórych wersjach Linuxa pliki związane z NIS znajdują się w innych niż przykładowe katalogach - jeśli nie potrafisz ich znaleźć, użyj polecenia find. Po wygenerowaniu odpowiednich plików możesz uruchomić program rezydentny ypserv. Najlepiej zautomatyzować ten proces, wpisując do pliku rc polecenie (które być może już w nim się znajduje)
if [ -f /etc/yp/ypserv -a -d /var/yp/`domainname` ]
then
/etc/yp/ypserv
fi
Powyższy fragment skryptu powoduje uruchomienie programu ypserv, o ile jest on zainstalowany w systemie i zostały wygenerowane odpowiednie pliki. W pierwszym wierszu nazwa polecenia domainname otoczona jest odwróconym pojedynczym cu-dzysłowem, dzięki czemu polecenie to zostanie wykonane, a w miejsce, w którym się ono znajduje, zostanie podstawiony wynik jego wykonania (czyli faktyczna nazwa domeny). Jeśli odpowiedni katalog istnieje, uruchamiany jest program ypserv. Powinieneś pod-stawić właściwe dla Twojego systemu ścieżki dostępu. Można również uruchomić program ypserv ręcznie (jeśli jesteś zalogowany jako ro-ot), wydając polecenie
/etc/yp/ypserv
Następnie w systemie komputera-nadzorcy należy uruchomić program ypbind (w przeciwnym przypadku program ypserv nie będzie potrafił odnaleźć plików mapo-wania). W tym celu możesz do jednego z plików rc dopisać następujące wiersze:
if [ -d /var/yp ]
then
/etc/yp/ypbind
fi
Tu również powinieneś w razie potrzeby podstawić odpowiednie dla Twojego systemu ścieżki dostępu. Jeśli jesteś zalogowany jako root, możesz uruchomić program ypbind z wiersza poleceń. Upewnij się, że ścieżka dostępu jest prawidłowa. Jeśli chcesz szybko sprawdzić, czy programy obsługi NIS działają poprawnie, wydaj polecenie:
ypmatch reksio passwd
Polecenie ypmatch wysyła do nadzorcy NIS żądanie, by dopasował do pierwszego ar-gumentu wiersz z pliku podanego jako drugi argument. W przykładzie sprawdzony zo-stanie plik passwd (passwd to w zasadzie alias nazwy passwd.byname) w poszukiwa-niu wiersza zaczynającego się od tekstu reksio. Jako wynik działania tego polecenia powinien zostać wyświetlony odpowiedni wiersz.
Konfigurowanie nadzorców zastępczych
Aby skonfigurować nadzorcę zastępczego, komputer-nadzorca musi już być skonfigu-rowany i działać. Gdy jesteś pewny, że pracuje on prawidłowo, zaloguj się jako admi-nistrator systemu, który ma działać jako nadzorca zastępczy. Wcześniej należy rów-nież ustawić nazwę domeny - sprawdź więc, czy istnieje odpowiednie odwołanie do programu domainname w jednym z plików rc lub uruchom ten program samodziel-nie. Aby skonfigurować nadzorcę zastępczego i skopiować wszystkie potrzebne pliki konfi-guracyjne z komputera-nadzorcy, wydaj polecenie (podstawiając ścieżkę dostępu wła-ściwą dla Twojego systemu):
/etc/yp/ypbind
Za pomocą polecenia ypwhich sprawdź, czy połączenie przebiegło prawidłowo. Po-winno ono zwrócić nazwę komputera-nadzorcy. Na koniec wydaj polecenie:
/etc/yp/ypinit -s nazwa_komputera-nadzorcy
Opcja -s powoduje, że dany komputer będzie zachowywał się jak nadzorca zastęp-czy. Zostaną założone odpowiednie katalogi, a z komputera-nadzorcy przesłane zo-staną wszystkie potrzebne pliki mapowania. Po zakończeniu tych czynności możesz sprawdzić, czy wszystko jest w porządku, używając podobnie jak w poprzednim podrozdziale polecenia ypmatch,. Aby regularnie uaktualniać pliki mapowania w komputerach-zastępcach, używa się polecenia ypxfer. Argumentem tego polecenia powinna być nazwa pliku, który ma być przesyłany, np.:
ypxfer passwd.byname
Większość administratorów automatyzuje uaktualnianie plików mapowania albo do-dając odpowiedni wpis do pliku crontab, dzięki czemu transfer odbywa się regularnie (zwykle w nocy), albo też umieszczając odpowiednie polecenia w skrypcie uruchamia-nym przez administratora.
Klienci NIS
Konfigurowanie komputera korzystającego z systemu NIS wymaga prawidłowego ustawienia nazwy domeny (za pomocą programu domainname, który może być uru-chamiany w jednym z plików rc) oraz wydania polecenia ypbind, wiążącego kompu-ter z odpowiednim komputerem-nadzorcą. Kiedy zachodzi potrzeba znalezienia jakiegoś wpisu w pliku /etc/passwd lub /etc/group, najpierw przeszukiwane są pliki lokalne, a w razie niepowodzenia do nadzorcy wysyłane jest zapytanie. Aby było to możliwe, w pliku /etc/passwd musi znajdować się wpis:
+:*:0:0:::
Zgodnie z formatem pliku /etc/passwd, jest to prawidłowy wpis, choć nie zawiera żadnych informacji. Znak + poleca przesłać zapytanie do nadzorcy NIS. Może on znajdować się w dowolnym miejscu w pliku - po dojściu do niego wysyłane jest zapy-tanie, a jeśli ono nie przyniesie rezultatu, przeszukiwanie pliku jest kontynuowane.

Kopie zapasowe
Trzy podstawowe zasady administratora systemu to: 1) należy wykonywać kopie za-pasowe, 2) należy wykonywać kopie zapasowe i 3) należy wykonywać kopie zapaso-we. Liczba osób, które utraciły wartościowe dane, nie wspominając o czasie, które spę-dziły na mozolnym odtwarzaniu plików konfiguracyjnych, jest ogromna. Nawet jeśli nie posiadasz napędu taśmowego czy innego odpowiednio pojemnego nośnika, powi-nieneś przyzwyczajać się do wykonywania kopii zapasowych swoich danych. Jak to robić - dowiesz się w tym rozdziale. Jeżeli z Twojego systemu korzysta wielu użytkowników, jesteś podłączony do sieci, działa poczta itd., to chyba nie masz wątpliwości, że kopie zapasowe powinny być wy-konywane nawet codziennie. Jeżeli jednak system służy głównie do zabawy, sprawa ta nie jest aż tak poważna - w razie problemów tracisz "tylko" wszystkie pliki konfigura-cyjne. Jednak kopie zapasowe należy wykonywać i w tym przypadku, co najwyżej z mniejszą częstotliwością.
Po co tworzyć kopie zapasowe
Kopia zapasowa może zawierać dane z całego systemu plików lub też jego fragmentu i używana jest po to, aby w razie potrzeby można było odzyskać potrzebne pliki. W większości systemów do przechowywania danych używa się napędów taśmowych, ale nadają się do tego również wyjmowalne dyski twarde czy nawet dyskietki. Źródeł zagrożeń w nowoczesnym systemie komputerowym jest bardzo wiele, od awarii dysku twardego, przez przerwy w zasilaniu do zwykłych pomyłek. Kopia zapasowa okazuje się wówczas wręcz wybawieniem. Choć często trudno jest zmusić się do jej utworzenia, zwykle czas stracony na to zwraca się z nawiązką w przypadku proble-mów. Można również uprościć sobie pracę używając programu cron. Jednym z zagrożeń w systemie Linux jest sama natura systemu: ponieważ jest to sys-tem wielozadaniowy i wielodostępny, równocześnie może być otwartych wiele plików. Przez cały czas odbywa się wymiana danych pomiędzy pamięcią i dyskiem twardym (nawet wtedy, gdy nie jest zalogowany żaden użytkownik i nie działa żaden program uruchomiony przez użytkownika). Wiele informacji o systemie plików jest również przechowywanych w pamięci. Choć są one często zapisywane na dysku, to jednak nie następuje to natychmiast, w efekcie czego przerwanie tego procesu może prowadzić do utraty zawartości plików systemo-wych. Pliki na dysku mogą pozostać w stanie przejściowym, nie odpowiadającym rze-czywistemu stanowi systemu plików. Choć uszkodzenie systemu plików może być spowodowane przez najróżniejsze czyn-niki - z których nie wszystkie są zależne od administratora systemu - zadaniem admi-nistratora jest nie dopuścić do utraty ważnych danych niezależnie od okoliczności i w razie problemów odtworzyć cały system plików w możliwie krótkim czasie. Ważną kwestią jest również zdecydowanie, gdzie będą przechowywane nośniki zawie-rające kopie zapasowe systemu. Większość administratorów (głównie używających systemu linuxowego w domu) wykonuje kopie systemu na takich nośnikach, jak ta-śmy czy dyskietki, i przechowuje je w tym samym miejscu, w którym znajduje się sys-tem. Należy upewnić się, że nie występują tam silne pola magnetyczne (występujące w pobliżu różnych urządzeń, na przykład głośników, monitorów, modemów czy telewizo-rów), nie jest za ciepło itd. Warto jednak rozważyć przechowywanie nośników gdzieś zupełnie indziej - takie rozwiązanie pozwala im przetrwać również poważniejsze (ale i o wiele rzadsze) katastrofy, takie jak na przykład pożar, który może zniszczyć zarów-no system, jak i kopie danych.
Nośniki
Nośnikiem używanym najczęściej do tworzenia kopii zapasowych jest taśma. Jest ona popularna ze względu na stosunkowo niską cenę, niewygórowane wymagania co do warunków przechowywania i rozsądną prędkość transmisji danych. Proces zapisu i od-czytu danych jest pewny, a taśmy są przenośne pomiędzy systemami. Niestety, aby używać taśm, trzeba posiadać napęd taśmowy. Jeśli nie dysponujesz napędem taśmo-wym, musisz rozważyć inne rozwiązania. Jedną z alternatyw są dyski wyjmowalne różnych typów, takie jak Iomega Bernoulli czy ZIP. Dyski z danymi, zwykle zapakowane w specjalne pojemniki, mogą być wyj-mowane i przechowywane z dala od systemu. Niektóre z tych dysków, podobnie jak taśmy, pozwalają na zapis cykliczny. Inna możliwość to po prostu użycie dodatkowego dysku twardego - ceny tych urzą-dzeń stale spadają. Można więc do Twojego komputera (lub dowolnego innego kom-putera w sieci) podłączyć dysk przeznaczony wyłącznie do przechowywania kopii za-pasowych i zapisywać na nim pełną kopię systemu. Nagrywarki dysków CD-ROM i WORM również dobrze nadają się do tworzenia kopii zapasowych. Dyskietki to ostatnia deska ratunku w większych systemach. Nie są jednak złym roz-wiązaniem do przechowywania niewielkich plików. Choć pojawiło się kilka napędów o większej gęstości zapisu, brak sterowników dla systemu Linux nie zachęca do ich uży-cia. <
>Harmonogram tworzenia kopii zapasowych
Jednym z najważniejszych aspektów tworzenia kopii zapasowych jest regularność. Jest to szczególnie ważne w systemach, z których korzysta wielu użytkowników, i w któ-rych zawartość systemu plików zmienia się bardzo intensywnie. Jeśli tylko Ty używasz systemu, możesz tworzyć kopie wtedy, kiedy uznasz to za stosowne. Dla większości systemów wykorzystywanych przez kilku użytkowników, stale komu-nikujących się z Internetem i dokonujących rutynowych operacji w systemie plików, konieczne jest codzienne tworzenie kopii zapasowych. Niekoniecznie pełnych - wy-starczy, że zapiszesz tylko te pliki, które uległy zmianie od utworzenia ostatniej kopii (jest to tzw. system przyrostowy, ang. incremental backup). Większość administratorów wykonuje kopie zapasowe w nocy lub wcześnie rano, po-nieważ wtedy system jest stosunkowo najmniej obciążony (zarówno w sensie obciąże-nia procesora, jak i liczby otwartych plików). Proces ten można zautomatyzować pole-ceniem cron lub at (patrz rozdział 46. "cron i at"), co zwalnia operatora od koniecz-ności jego ręcznej obsługi i umożliwia wybranie najdogodniejszej z punktu widzenia systemu pory. Po wykonaniu operacji wystarczy tylko sprawdzić, czy wszystko poszło dobrze, zanotować dane o nowej kopii i wymienić nośnik. W systemach mało obciążonych i takich, z których korzysta jedna osoba, kopie moż-na wykonywać w dowolnym momencie, ale nadal warto zautomatyzować ten proces, o ile system pracuje nieprzerwanie. Jeśli Twój komputer jest włączony tylko wtedy, gdy go używasz, powinieneś przyzwyczaić się do tworzenia kopii zapasowych w czasie, gdy robisz coś innego. Byli użytkownicy systemów DOS i Windows często podchodzą do problemu tworzenia kopii zapasowych w ten sposób, że każdorazowo zapisują nowe dane na tym samym nośniku. Praktyka ta nie ma większego sensu -posiadanie jednej tylko kopii danych bardzo często okazuje się niewystarczające, nie pozwala bowiem wrócić do poprzed-nich wersji plików. Przypuśćmy, że usunąłeś przed tygodniem jakiś plik, zapisując go wcześniej dla bezpieczeństwa na taśmie. Teraz orientujesz się, że był to błąd, ale nie masz już żadnych szans odzyskania pliku, ponieważ na taśmie zapisane są wczorajsze dane (takie postępowanie zabezpiecza tylko przed awarią, a biorąc pod uwagę złośliwość rzeczy martwych, jeśli już zdarzy się awaria, to pewno okaże się, że taśma również uległa uszkodzeniu ). W idealnym przypadku kopie powinny być przechowywane przez kilka dni - lub nawet tygodni - przed ponownym użyciem nośnika. Jest to szczególnie ważne w systemach wykorzystywanych przez wielu użytkowników, zdarza się bowiem, że ktoś przypomina sobie, że dwa miesiące temu usunął plik, bez którego nie może żyć - a Ty właśnie dwie minuty temu skończyłeś zapisywać na tej taśmie dzisiejszy stan systemu. Istnieją me-tody na zabezpieczenie się przed takimi przypadkami - omówimy je za chwilę. To, ja-ki system tworzenia kopii powinieneś zastosować, zależy od przeznaczenia systemu, ale generalnie powinna to być co najmniej jedna pełna kopia co tydzień, uzupełniona codziennymi kopiami przyrostowymi, przy czym kopie powinny być przechowywane na co najmniej dwa tygodnie wstecz. Wykonanie pełnej kopii systemu sprowadza się do utworzenia obrazu całej zawartości systemu plików i wymaga nośnika o pojemności odpowiadającej wielkości tego ostat-niego. W celu zmniejszenia wymaganej objętości nośnika można użyć kompresji da-nych, jednak możliwość ta nie zawsze jest dostępna. Inną alternatywą jest użycie kilku jednostek nośnika (taśm). Ponieważ jednak program cron nie jest w stanie zmieniać ich automatycznie, przy tworzeniu kopii w takim systemie niezbędna jest obecność administratora. Nietrudno się domyślić, że wykonanie pełnej kopii zapasowej na wielu nośnikach o małej pojemności jednostkowej (na przykład na dyskietkach) jest proce-sem żmudnym i długotrwałym. Kopie przyrostowe (czasem również zwane różnicowymi, ang. differential backup) za-wierają jedynie te pliki, które zmieniły się od momentu utworzenia poprzedniej kopii. Nie we wszystkich systemach pliki posiadają atrybut pozwalający to łatwo stwierdzić (atrybut taki nie występuje również w najpowszechniej używanym w Linuxie systemie plików ext2), ale wtedy z pomocą może przyjść data ostatniej modyfikacji pliku. Utworzenie kopii przyrostowej w Linuxie nie jest rzeczą łatwą, chyba że ograniczysz się do części systemu plików, w której dokonywanych jest najwięcej modyfikacji, na przykład /home. Takie rozwiązanie to tzw. kopia częściowa (ang. partial backup). Za-uważ, że w dowolnym systemie można tworzyć kopie przyrostowe za pomocą procesu działającego cały czas w tle i rejestrującego wszystkie zmiany w systemie w pliku, a następnie zapisującego pliki, które się zmieniły. Opłacalność takiego rozwiązania jest jednak dyskusyjna. Jak często należy robić kopie zapasowe? Najprostsza reguła jest taka, że nie powinie-neś dopuścić do utraty informacji. Dla wielu oznacza to kopiowanie codzienne. Za-łóżmy, że pracując nad dokumentem lub programem tracisz wszystkie dane wprowa-dzone od czasu zapisania ostatniej kopii zapasowej. Ile czasu zajmie Ci ich odtworze-nie? Jeśli więcej, niż zajęłoby zrobienie kopii zapasowej, zrób kopię. W pozostałej czę-ści tego rozdziału przyjmiemy, że nośnikiem jest taśma magnetyczna, ale nasze roz-ważania odnoszą się również do innych mediów. Jaki jest zatem najwydajniejszy system tworzenia kopii zapasowych, zakładając, że konieczne jest ich regularne tworzenie? Dla średniej wielkości systemów (obsługują-cych kilku użytkowników nie generujących nadmiernego "ruchu" w systemie plików) warto zalecić codzienne tworzenie kopii, co wymaga od 10 do 14 taśm, zależnie od te-go, czy kopie będą tworzone również w weekendy. Każdą taśmę należy opisać zgodnie z jej przeznaczeniem, np. "Dzień 1", "Dzień 2" itd. Taśm tych używaj cyklicznie, dzięki czemu będziesz mógł zawsze wrócić do stanu sprzed dwóch tygodni (przy założeniu, że kopie nie są tworzone w weekendy). Jeśli po-siadasz więcej taśm, możesz wydłużyć cykl tworzenia kopii. Metoda taka jest używa-na w wielu dużych organizacjach, ponieważ charakteryzuje się dobrym wyważeniem pomiędzy kosztami, szybkością i bezpieczeństwem oraz możliwościami odzyskania danych. Zależnie od potrzeb można wykonywać kopie pełne lub częściowe. Dobrym rozwiąza-niem jest tworzenie jednej pełnej kopii systemu po utworzeniu około pięciu kopii czę-ściowych. Można na przykład robić pełne kopie systemu w poniedziałki, w pozostałe dni tygodnia ograniczając się do wykonywania kopii katalogu /home. Wyjątki powi-nieneś robić wówczas, gdy wprowadzasz jakieś zmiany do konfiguracji systemu - wte-dy należy zrobić jego pełną kopię. Warto również prowadzić dokładną dokumentację tworzonych kopii zapasowych - ten temat omówimy za chwilę. Rozszerzeniem przedstawionego wyżej harmonogramu wykonywania kopii zapaso-wych może być dodanie oprócz cyklu dziennego również cyklu dwutygodniowego. Po-siadane nośniki należy podzielić wówczas na dwie grupy. Jeśli na przykład posiadasz czternaście taśm, możesz używać dziesięciu z nich do codziennego tworzenia kopii za-pasowych, dokładnie tak samo, jak w poprzednim przykładzie. Opisz je na przykład "Dzień 1" … "Dzień 10". Pozostałe cztery taśmy zostaną wykorzystane do utworzenia cyklu dwutygodniowego - można je opisać "Tydzień 1" … "Tydzień 4". Używając tak zmodyfikowanego harmonogramu wykonywania kopii zapasowych, należy wykonywać codzienne kopie tak samo, jak w poprzednim przykładzie, ale po dojściu do końca cyklu codziennego (czyli po zapisaniu kopii na taśmę z etykietą "Dzień 10") należy wykonać kopię zapasową na kolejnym nośniku wchodzącym w skład cyklu dwutygodniowego. Pełny cykl powinien wtedy wyglądać tak: "Dzień 1" … "Dzień 10" "Tydzień 1" "Dzień 1" … "Dzień 10" "Tydzień 2" "Dzień 1" itd. Taki harmonogram ma dość znaczną przewagę nad omówionym wcześniej codzien-nym cyklicznym wykonywaniem kopii zapasowych. Po zakończeniu całego cyklu, po-siadasz dziesięć wykonywanych codziennie kopii, pozwalających wrócić do stanu sys-temu sprzed dwóch tygodni. Posiadasz również taśmy, których używałeś co dwa tygo-dnie, dzięki którym masz również szansę na odzyskanie pliku usuniętego osiem tygodni wcześniej. Daje to możliwość odzyskania plików, których uszkodzenie czy usunięcie nie zostało wykryte od razu. Dołączając następne taśmy można wydłużyć cykl dwu-tygodniowy albo dodać cykl 40-dniowy.
Inwentaryzowanie zapisanych danych
Wielu administratorów zaczyna swoją karierę robiąc grzecznie kopie zapasowe, ale gdy przychodzi im odzyskać jakiś konkretny plik, nie mają pojęcia, gdzie go szukać. Nie-którzy radzą sobie z tym w ten sposób, że naklejają na taśmy kartki, na których zapi-sana jest data wykonania kopii i jej zawartość. Oznacza to jednak, że szukając kon-kretnego pliku musisz przerzucić cały stos taśm, co może być dość męczące, szczegól-nie jeśli taśm jest dużo. Z tego powodu dobrze jest przechowywać gdzieś dokładny spis tego, co na której taśmie się znajduje (odnosi się to do wszystkich kopii zapasowych, zarówno wykonywanych w systemie Linux, jak i DOS czy Windows). Wykonanie każdej kopii zapasowej powinno wiązać się z uaktualnieniem takiego spi-su. Nie musi on być szczególnie złożony ani długi. Wystarczy kilka kolumn danych w notesie czy też przechowywanych w postaci pliku tekstowego na dysku twardym (taki plik należy oczywiście regularnie drukować). Minimalny zestaw informacji, które mu-sisz posiadać, to: - data utworzenia kopii;
- nazwa taśmy, na której kopia się znajduje (na przykład "Dzień 1");
- nazwa systemu plików, który został skopiowany;
- informacja o tym, czy kopia jest kopią pełną, przyrostową czy częściową, i ewentualnie nazwy katalogów, z których pochodziły archiwizowane dane.
Zapisanie tych informacji trwa tylko kilka sekund, a może zaoszczędzić naprawdę sporo czasu. W większych systemach należy również zanotować:
- kto wykonał kopię;
- czy kopia była wykonana automatycznie, czy ręcznie;
- miejsce, w którym przechowywana jest taśma.
Dzięki zapisywaniu dat można z łatwością przywrócić określoną wersję pliku - jeśli na przykład użytkownik wie, że usunął plik tydzień temu, na podstawie daty możesz usta-lić, na której z taśm znajduje się ostatnia wersja tego pliku. Zapisane informacje o kopiach zapasowych powinny być dla wygody przechowywane w pobliżu systemu, ale niektórzy administratorzy wolą, by znajdowały się one tam, gdzie przechowywane są nośniki. Czasem również - na wypadek katastrofy - admini-stratorzy przechowują kopię danych o taśmach gdzieś indziej.
Używanie programu tar do tworzenia kopii zapasowych
Do tworzenia kopii zapasowych zwykle używa się programu tar (ang. tape archiver). Potrafi on utworzyć pojedynczy, duży plik, zawierający dane z wszystkich archiwizo-wanych plików, wraz z danymi o ich położeniu, prawach dostępu itd. (podobnie jak robi to program PKZIP w systemie DOS). Potrafi obsłużyć tylko ten typ archiwów, któ-ry sam tworzy. Używanie tego polecenia jest dość uciążliwe ze względu na dużą liczbę opcji, ale na szczęście w codziennej pracy trzeba używać tylko kilku ich kombinacji. Ogólnie rzecz biorąc, składnia polecenia tar ma postać:
tar czynność opcje pliki
Argument pliki określa nazwy plików lub katalogów, które należy zarchiwizować lub odtworzyć. Zwykle jest to cały podsystem plików (jak np. /home) lub też pojedynczy plik (np. /home/reksio/wazny_plik). Pole czynność określa działanie programu tar i może przyjmować jedną z następujących wartości:
c    utworzenie nowego archiwum,
r    dołączenie informacji do istniejącego archiwum,
t    wyświetlenie listy plików zapisanych w archiwum,
u    dodanie plików do archiwum, o ile nie są już zarchiwizowane,
x    przywracanie plików zapisanych w archiwum.
opcje pozwalają kontrolować w pewnym zakresie sposób postępowania z archiwum. Dostępne wartości to:
A    zapobiega zapisywaniu bezwzględnych ścieżek dostępu do plików;
b    pozwala podać wielkość bloku (1 - 20);
e    zapobiega dzieleniu archiwów na kilka nośników;
f    pozwala podać nazwę pliku lub urządzenia, na którym zostanie zapisane archiwum; F    pozwala podać nazwę pliku zawierającego inne opcje;
k    pozwala podać wielkość archiwum (w kilobajtach);
l    wyświetla komunikaty o błędach w razie znalezienia "wiszących" dowiązań (nie prowadzących do żadnych istniejących plików ani katalo-gów);
m    nie przywraca czasu modyfikacji;
n    oznacza, że archiwum nie zapisane jest na taśmie;
p    przywraca pliki wraz z informacjami o prawach dostępu;
v    wyświetla komunikaty o aktualnie przetwarzanych plikach;
w    wymaga potwierdzenia przed podjęciem akcji.
Program tar w większości przypadków używa bezwzględnych ścieżek dostępu do plików (chyba że zostanie podana opcja A). Kilka przykładów pomoże Ci zrozumieć użycie tego programu i jego opcji. Jeśli uży-wasz urządzenia /dev/tape i chcesz sporządzić pełną kopię zapasową systemu na nośniku o pojemności większej niż rozmiar systemu plików, możesz wydać polecenie:
tar cf /dev/tape /
Utworzone zostanie nowe archiwum (opcja c) na nośniku w urządzeniu /dev/tape (opcja f). Dotychczasowa zawartość nośnika zostanie usunięta - i to bez żadnego ostrzeżenia, więc upewnij się, że nie usuwasz przez przypadek jakichś ważnych da-nych. Jeśli dodatkowo podana zostanie opcja v, program tar będzie wyświetlał na-zwę i rozmiar pliku, który jest aktualnie zapisywany. Jeśli chcesz przywrócić pliki zapisane za pomocą polecenia przedstawionego w po-przednim przykładzie, wydaj polecenie:
tar xf /dev/tape
Spowoduje ono przywrócenie wszystkich zapisanych plików, ponieważ nie został wy-szczególniony żaden specyficzny katalog ani plik. Jeśli chciałbyś odzyskać tylko poje-dynczy plik, wydaj polecenie:
tar xf /def/tape /home/reksio/duzy_plik
które spowoduje odtworzenie tylko jednego pliku, o nazwie /home/reksio/duzy_plik. Czasem potrzebna jest lista wszystkich plików zapisanych w danym archiwum. Mo-żesz ją otrzymać wydając polecenie:
tar tvf /dev/tape
Polecenie to wykorzystuje opcję v, powodującą wyświetlanie nazw przetwarzanych plików. Ponieważ otrzymana lista może być dość długa, wygodnie jest skierować ją do pliku. Teraz, kiedy zapoznałeś się już z podstawowymi możliwościami programu tar, pora na kilka bardziej praktycznych przykładów. Większość napędów taśmowych wymaga przy zapisie danych określenia wielkości bloku (przy odczycie parametr ten ustawiany jest automatycznie; oznacza on ilość danych, jaką można jednorazowo przesłać do urządzenia). Parametr ten określany jest za pomocą opcji b. Przykładowe polecenie:
tar cvfb /dev/tape 20 /home
tworzy nowe archiwum zapisane na nośniku w urządzeniu /dev/tape, przy czym wielkość bloku zapisywanych danych wynosi 20. Jest to wartość prawidłowa dla więk-szości napędów taśmowych, dlatego można przyjąć ją jako wartość domyślną, chyba że akurat Twój napęd wymaga podania innej wartości. W przypadku użycia dyskietek i dysków twardych również należy podać odpowiednią wartość. Zauważ, że argumenty występujące po opcjach muszą pojawić się w takiej samej kolejności, jak odpowiada-jące im opcje: ponieważ opcja f wystąpiła przed b, nazwa urządzenia musi wystąpić przed wielkością bloku. Często zdarza się, że nośnik nie może pomieścić całego systemu plików - w takim przypadku do utworzenia kopii potrzebna będzie więcej niż jedna taśma. Aby poin-formować program tar o pojemności kasety, należy użyć opcji k. Jej argumentem jest właśnie wielkość nośnika w kilobajtach. Polecenie
tar cvbfk 20 /dev/tape 122880 /usr
mówi programowi tar, że powinien zapisać dane (w blokach o wielkości 20) na nośnik w urządzeniu /dev/tape, który może pomieścić 122880 kB danych. Po przekroczeniu tego rozmiaru zostaniesz poproszony o wymianę nośnika. Tu również można zauwa-żyć, że porządek parametrów musi odpowiadać porządkowi opcji. Użycie dyskietek jako nośnika danych nieco komplikuje problem, ponieważ wymaga-na wielkość bloku danych jest zwykle inna. Tworzone archiwa przeważnie nie miesz-czą się w całości na dyskietce, dlatego należy użyć opcji k i podać pojemność nośnika. Przykładowo, jeśli chcesz wykonać kopię zapasową zawartości katalogu /home/reksio na dyskietkach o pojemności 1.2 MB, powinieneś wydać polecenie:
tar cnfk /def/fd0 1200 /home/reksio
Podczas tworzenia archiwów na dyskietkach warto podać opcję n, która informuje program tar, że nie współpracuje aktualnie z napędem taśmowym - przyspiesza to nieco jego działanie.

cron i at
Automatyzowanie zadań administracyjnych jest jednym z warunków utrzymywania systemu w dobrej kondycji. Jeśli wszystkie zadania będą wykonywać się same, bez Twojej interwencji, w tle, administrowanie stanie się samą przyjemnością. Z tego wła-śnie powodu powstały programy cron i at. Oba pozwalają na uruchamianie progra-mów o zadanej godzinie, bez interwencji użytkownika czy administratora.
Używanie programu cron
Program cron (jego nazwa jest skrótem angielskiego słowa chronograph) pozwala na automatyczne wykonywanie poleceń przez system o określonej godzinie. W tym celu jest on ładowany do pamięci jako program rezydentny podczas uruchamiania syste-mu (zwykle z jednego ze skryptów rc). Podczas działania odczytuje on dane o pro-gramach, które ma wykonać, i porach ich uruchomienia z pliku crontab. Za każdym razem, gdy dane o dniu i godzinie wykonania programu zgadzają się z czasem systemowym, wykonywane jest odpowiednie polecenie. Jeśli następnego dnia czas wykonania zadania znów zgadza się z czasem systemowym, odpowiedni program ponownie zostanie wykonany. Jest to idealne wręcz rozwiązanie do takich zadań, jak tworzenie codziennych kopii zapasowych, aktualizacja baz danych czy "sprzątanie" w systemie plików (usuwanie zbędnych plików tymczasowych, plików, w których reje-strowane są pewne zdarzenia itd.). Cykl jest powtarzany aż do zakończenia działania programu cron lub wprowadzenia odpowiednich zmian do pliku crontab. W większości systemów dostęp do programu cron ma tylko administrator. Taka sytuacja może zostać zmieniona przez wprowadzenie odpowiednich wartości do dwóch plików: /usr/lib/cron/cron.allow, który zawiera identyfikatory użytkowników mogących korzystać z tego polecenia, i /usr/lib/cron/cron.deny, z listą użytkowników nie mogących tego robić. W obu plikach identyfikatory użytkowników (odpowiadające tym zapisanym w pliku /etc/passwd) powinny być wpisywane po jednym w każdym wierszu. Jeśli nie istnieje żaden z tych plików, tylko użytkownik root może używać programu cron. Jeśli chcesz, aby mogli go używać wszyscy użytkownicy, utwórz pusty plik /usr/lib/ cron/cron.deny (w niektórych systemach /var/cron.d/cron.deny). Plik /usr/lib/ cron/cron.deny zawierający następujące dane:
bill
tom
spowoduje, że użytkownicy bill i tom nie będą mieli możliwości użycia programu cron, natomiast możliwość taką będą mieli wszyscy pozostali użytkownicy. Jeśli taką samą zawartość miałby plik /usr/lib/cron/cron.allow, tylko użytkownicy bill i tom (oraz oczywiście root) mieliby możliwość korzystania z tego programu. Możesz się zastanawiać, jaki sens ma używanie programu cron, skoro można zawsze odpowiednie polecenie wpisać ręcznie. To prawda, ale po pierwsze musisz o tym pamiętać, a po drugie musisz być na miejscu. Pro-gram cron umożliwia zautomatyzowanie wszystkich codziennych czyn-ności administracyjnych. Dzięki temu nie musisz codziennie wydawać dłu-giej listy poleceń tworzących kopie zapasowe, usuwających niepotrzebne pliki itd.
Tworzenie pliku crontab
Jeśli chcesz zrzucić na program cron codzienne obowiązki, powinieneś użyć programu crontab. Odczytuje on dane o procesach, które należy uruchamiać, z pliku, który naj-częściej również nazywa się crontab. Program ten potrafi również wyświetlić listę za-dań, usunąć ją czy dodać do niej nowe zadania. Program crontab posiada opcję pozwalającą jako plik z danymi wykorzystać plik o dowolnej nazwie. Domyślnie odczytywany jest plik o nazwie crontab znajdujący się w katalogu bieżącym. Instrukcje zawarte w pliku crontab mają prostą strukturę, choć przyzwyczajenie się do niej trwa chwilę. Każdemu procesowi odpowiada jeden wiersz o następującym for-macie: minuta godzina dzień_miesiąca miesiąc_roku dzień_tygodnia polecenie Oto przykładowe wpisy:
20 1 * * * /usr/bin/calendar -
0 2 * * * /bin/organize_data
Każdy wiersz składa się z sześciu pól, rozdzielonych znakiem tabulacji lub spacją. Są to kolejno:
minuta     dostępne wartości: 0 - 59;
godzina     dostępne wartości 0 - 23;
dzień_miesiąca    dostępne wartości 1 -31;
miesiąc_roku     dostępne wartości 1 - 12;
dzień_tygodnia     dostępne wartości 0 - 6 (0 = niedziela, 1=poniedziałek itd.);
polecenie    program, który ma zostać wykonany o danej godzinie w danym dniu.
Dzięki takiemu formatowi możliwe jest dokładne określenie, kiedy dany proces ma zo-stać uruchomiony. Aż pięć kategorii określających czas wykonania pozwala bardzo dokładnie określić porę wykonania, nawet jeśli wymagane są terminy nie układające się w żaden regularny schemat. Ostatnie pole zawiera nazwę skryptu, który ma zostać uruchomiony. Taki skrypt może składać się tylko z jednego polecenia, ale może również być całkiem skomplikowanym programem, zawierającym odwołania do innych skryptów i programów. Ważne jest podawanie pełnych ścieżek dostępu do skryptów (bez względu na to, czy katalogi w których są one zapisane wchodzą w skład ścieżki przeszukiwania), ponieważ cron nie dziedziczy środowiska użytkownika, w związku z czym nie będzie potrafił odszukać odpowiednich poleceń. Musisz również posiadać uprawnienia do wykonania określo-nego programu, cron bowiem wykonuje proces tak, jakbyś to Ty go uruchomił. W polach oznaczających czas mogą znaleźć się pojedyncze liczby z dozwolonego za-kresu, lista liczb rozdzielonych przecinkami, dwie liczby rozdzielone minusem (ozna-czające zakres, np. 1 - 5) lub gwiazdka, oznaczająca wszystkie dostępne wartości. Spójrzmy na przykładową zawartość pliku crontab:
20 1 * * * /usr/bin/calendar -
0 2 1 * 0 /bin/organize_data
10,30,50 9-18 * * * /bin/setperms
Pierwsze polecenie, /usr/bin/calendar - (myślnik jest częścią polecenia), będzie wykonane 20 minut po pierwszej w nocy każdego dnia tygodnia we wszystkie tygodnie roku. Gwiazdka oznacza wszystkie dostępne wartości. O drugiej w nocy w każdą niedzielę (0 w piątej kolumnie) i pierwszego dnia miesiąca (1 w trzeciej kolumnie) wykonane zostanie polecenie /bin/organize_data. Oczywiście jeśli pierwszego wypada w niedzielę, polecenie zostanie wykonane tylko raz. Trzecie polecenie, /bin/setperms, wykonywane będzie 10, 30 i 50 minut po każdej godzinie pomiędzy 9 i 18, każdego dnia tygodnia. Wpisy w pliku crontab mogą mieć dowolną kolejność, ale dane o każdym z progra-mów muszą zawierać sześć pól i znajdować się w osobnym wierszu. Jeśli do pliku wkradnie się jakiś błąd, cron poinformuje Cię o jego istnieniu pocztą (może to być dość uciążliwe, jeśli pomylisz się w poleceniu, które ma być wykonywane często, po-nieważ przy każdej próbie uruchomienia błędnego polecenia cron wygeneruje nową informację, co może doprowadzić nawet do przepełnienia skrzynki pocztowej). Plik zawierający zadania najlepiej przechowywać we własnym katalogu pod nazwą crontab, chyba że potrzebujesz kilku jego wersji - wybór używanych nazw zależy wówczas wyłącznie od Ciebie.
Zarządzanie plikami crontab
Po stworzeniu własnego pliku crontab powinieneś poinformować program cron, że należy go przetworzyć. Jego kopia znajdzie się wówczas w katalogu systemowym, zwykle /usr/spool/cron/crontabs. Plik będzie miał nazwę zgodną z identyfikato-rem użytkownika, który zamówił wykonanie danych zadań (na przykład plik zawiera-jący dane o poleceniach zleconych przez użytkownika bill może nazywać się /usr/spool/ cron/crontabs/bill). Aby uaktywnić plik crontab, wydaj polecenie crontab, podając jako argument wy-wołania nazwę pliku, w którym zapisane są odpowiednie dane, na przykład tak:
crontab crontab
Jeśli wcześniej wydałeś już takie polecenie, wszystkie zlecenia są anulowane, a w ich miejsce wstawiane są nowe. Aby zmodyfikować zamówione zadania, powinieneś edytować plik crontab i nakazać jego ponowne przetworzenie. Nigdy nie należy mo-dyfikować bezpośrednio plików w katalogu /usr/spool/cron/ crontabs. Jeśli chcesz sprawdzić, jakie programy będą uruchamiane przez program cron, możesz użyć polecenia crontab z opcją -l (ang. list):
crontab -l
Polecenie to powoduje wyświetlenie zawartości pliku o nazwie odpowiadającej Two-jemu identyfikatorowi użytkownika, zapisanego w katalogu
/usr/spool/cron/crontabs.
Jeśli chcesz usunąć swój plik nie zastępując go żadnym innym, użyj opcji -r (ang. re-move):
crontab -r
Polecenie crontab pozwala również edytować plik, który aktualnie jest używany (uru-chamiany jest edytor domyślny, którego nazwa jest zdefiniowana przez wartość od-powiedniej zmiennej środowiskowej - zwykle edytor vi):
crontab -e
Po zakończeniu edycji i zapisaniu pliku jest on automatycznie przetwarzany przez program cron. Zmiany w plikach crontab są zwykle wprowadzane w życie w ciągu pięciu minut - przynajmniej tak często są odczytywane te pliki (w większości systemów odbywa się to co minutę). Oznacza to również, że wykonanie danego programu może się opóźnić o kilka minut; nie można zakładać, że zostanie on uruchomiony punktualnie. Im więk-sze jest obciążenie systemu, tym większe mogą być opóźnienia. W niektórych systemach administrator ma możliwość monitorowania wszystkich czynności podejmowanych przez program cron - w tym celu należy zmodyfikować plik /etc/default/cron. Powinien się w nim znajdować wpis definiujący wartość zmiennej CRONLOG - ustaw tę wartość na YES, a wszystkie wywołania programów zo-staną odnotowane w pliku /usr/lib/cron/log. Nie we wszystkich wersjach Linuxa rozwiązanie takie jest dostępne. Powinieneś jednak używać go z rozwagą, ponieważ taki plik może szybko osiągnąć duże rozmiary.
Bardziej złożone polecenia
Plik crontab może zawierać dowolne polecenia poprawnie rozpoznawane przez in-terpreter poleceń powłoki. Problemem czasem staje się jednak fakt, że niektóre z nich generują jakieś informacje, które są następnie przesyłane pocztą do użytkownika, co może spowodować zablokowanie skrzynki pocztowej. Jeśli przewidujesz, że polecenie uruchamiane przez program cron będzie generowało jakieś komunikaty, powinieneś wyjście programu i komunikaty o błędach skierować do pliku lub, jeśli generowane in-formacje Cię nie interesują, do urządzenia /dev/null albo /dev/zero, na przykład tak:
0 * * * * date > /tmp/test1 2 > /dev/null
Powyższe polecenie co godzinę przepisuje aktualną datę do pliku /tmp/test1, komu-nikaty o błędach wysyłając do urządzenia /dev/null (co oznacza po prostu ich zi-gnorowanie). Możesz również komunikaty o błędach skierować gdzieś indziej, na przykład:
30 1 * * * cat /home/reksio/chapt* > /home/reksio/safe/backup 2> ĺ/home/reksio/cos_nie_tak
Powyższe polecenie powoduje, że pliki o nazwach rozpoczynających się od chapt w katalogu /home/reksio będą łączone w jeden plik o nazwie backup zapisany w ka-talogu /home/reksio/safe, a komunikaty o ewentualnych problemach przesyłane będą do pliku cos_nie_tak. Oto inny przykład użycia programu cron, wykorzystujący mechanizm potoków (ang. pipe):
0 1 * * * sort -u /tmp/userlist | mail -s"dzisiejsi uzytkownicy" root
Powoduje on wysyłanie do użytkownika root poczty zawierającej listę użytkowników, którzy logowali się danego dnia (przy założeniu, że taka lista znajduje się w pliku o nazwie /tmp/userlist). Lista ta jest posortowana i wyeliminowane są pozycje po-wtarzające się (opcja -u programu sort - ang. unique). Należy pamiętać, że domyślnie do przetwarzania poleceń używany jest interpreter bash, możesz więc spotkać się z problemami próbując wykonać polecenia powłoki csh.
Program at
Program at jest dość podobny do programu cron, z tym że zadane polecenie wyko-nuje nie okresowo, ale tylko raz. Jego składnia jest następująca:
at czas [data] Większość parametrów może być podana na kilka sposobów. Na przykład czas moż-na podać w postaci pełnej (18:43), podać tylko godzinę (10) bądź użyć modyfikato-rów am i pm. W polu czasu rozpoznawanych jest również kilka wyrazów, takich jak noon, midnight, now, next i zulu (konwersja na czas GMT). Niektóre wersje nie rozpoznają wyrazu now. Pole daty jest opcjonalne. Jego zawartość może stanowić angielska nazwa miesiąca i dzień (np. May 10) lub dzień tygodnia (pełna nazwa angielska lub skrócona, trzylite-rowa). Można także podać rok, ale rzadko jest to konieczne. Tu również rozpoznawa-nych jest kilka słów, takich jak today i tommorow (choć podawanie słowa today jest zbędne, ponieważ polecenia domyślnie wykonywane są w tym dniu, w którym zostały wydane). Plik wejściowy może zawierać dowolne polecenia. Można również wprowadzić je "ręcznie" - kombinacja klawiszy Control+D kończy wprowadzanie poleceń z klawia-tury. Załóżmy, że w Twoim katalogu znajduje się skrypt o nazwie reorg.data (i masz prawo go wykonać) o następującej zawartości:
/home/reksio/setperms
/home/reksio/sort_database
/home/reksio/index_database
/home/reksio/cleanup
Chciałbyś zapisane w nim polecenia wykonać o 8:30, ale nie będzie Cię wtedy przy komputerze. Aby rozwiązać ten problem, możesz wydać jedno z poleceń:
at 20:30 < reorg.data at 8:30 pm at 20:30 today Jeśli chciałbyś, żeby skrypt został wykonany w piątek, wydaj jedno z poleceń:
at 8:30 pm Friday < reorg.data
at 20:30 Fri < reorg.data
Niektóre wersje programu at są jeszcze sprytniejsze i rozpoznają konstrukcje takie jak:
at 0900 Monday next week Po zleceniu wykonania polecenia otrzymasz jego identyfikator:
at 6 job 54342.a at Wed Aug 31 06:00:00 EDT 1997
W tym przypadku identyfikatorem jest 54342.a. Identyfikator ten określa jedno-znacznie zadanie. Jest on wymagany np. do odwołania wydanego polecenia. Listę wszystkich zleconych zadań można obejrzeć za pomocą polecenia atq lub, w in-nych systemach, opcji -l programu at:
$ at -l
user = reksio job 54342.a at Wed Aug 31 06:00:00 EDT 1997
user = reksio job 54343.a at Wed Aug 31 09:30:00 EDT 1997
Jeśli chcesz anulować zlecenie, wydaj polecenie at z opcją -r i numerem identyfikacyjnym zadania:
at -r 54343.a
Linux nie potwierdzi usunięcia zadania, aby sprawdzić, czy wszystko przebiegło po-myślnie, trzeba jeszcze raz wydać polecenie wyświetlające listę oczekujących na wy-konanie poleceń. Anulować można wykonanie tylko tych zadań, których jesteś wła-ścicielem (ograniczenie to nie dotyczy użytkownika root). W niektórych wersjach sys-temu do usuwania zadań z kolejki służy polecenie atrm. Dane o zadaniach programu at są przechowywane w katalogu /usr/spool/cron/ atjobs, w plikach o nazwach odpowiadających identyfikatorom zadań. Podobnie jak miało to miejsce w przypadku polecenia cron, do limitowania dostępu do polecenia at służą pliki at.deny i at.allow, przechowywane w katalogu /usr/lib/cron lub /etc/cron.d. Jeśli chcesz umożliwić wszystkim użytkownikom używanie programu at, utwórz pusty plik o nazwie at.deny. Komunikaty generowane przez wykonywane programy i komunikaty o błędach wysy-łane są pocztą do użytkownika, chyba że zostaną skierowane do pliku. Polecenie at, w przeciwieństwie do cron, dziedziczy po użytkowniku środowisko, więc nie musisz aż tak martwić się o ścieżki dostępu. Jeśli zajrzysz do plików zapisanych w katalogu /usr/spool/cron/atjobs, zobaczysz, że przed właściwym poleceniem znajdują się definicje wszystkich zmiennych środowiskowych używanych w momencie wydawania polecenia at.

Konfiguracja węzła internetowego
System Linux jest doskonale przystosowany do połączenia z siecią i korzystania z usług przez nią oferowanych. Nie chodzi tu tylko o przeglądanie stron WWW czy uży-wanie protokołu FTP do przesyłania plików, ale przede wszystkim o możliwość zasto-sowania systemu linuxowego jako serwera sieciowego. Przy minimalnym nakładzie pracy poświęconej konfiguracji systemu można udostępniać własne strony WWW lub założyć węzeł FTP czy Gopher. Nie jest potrzebne żadne dodatkowe oprogramowanie, w zupełności wystarczy to, które rozprowadzane jest wraz z dystrybucją systemu na dyskach CD-ROM. Przyjrzymy się różnym sposobom łączenia się z Internetem. Kilka następnych rozdziałów omawia konfigurowanie systemu linuxowego mającego dzia-łać jako serwer najpopularniejszych usług internetowych. Jeśli zamierzasz używać Internetu tylko biernie, korzystając z usług innych serwerów, nie musisz czytać następnych czterech rozdziałów (choć nadal warto zapoznać się z tym rozdziałem, ponieważ opisujemy w nim metody łączenia się z siecią Internet). Z drugiej strony jednak dzielenie się zasobami własnego systemu z innymi użytkowni-kami sieci - czy to sieci lokalnej, czy też Internetu - jest chyba najprzyjemniejszym jej aspektem. Jeśli chcesz, by Twój system linuxowy oferował niektóre z usług internetowych (jak WWW, FTP czy Gopher), ale nie chcesz, by dostęp do nich mieli wszyscy użytkownicy (oprócz co najwyżej kilku przyjaciół), nie powinieneś obawiać się połączenia z Interne-tem. Musisz jednak skonfigurować oprogramowanie serwera.
Podłączanie się do Internetu
Istnieje wiele metod podłączania się do Internetu. Wybór jednej z nich jest głównie kwestią przyzwyczajenia i tego, z jakich usług zamierzasz korzystać. Choć na rynku działa wiele firm oferujących dostęp do Internetu na bardzo różnych warunkach, za-sadniczo istnieją tylko cztery typy połączenia - poniżej przedstawiamy ich skrótowy opis.
- Bezpośrednie połączenie z Internetem. Ta metoda wymaga zastosowania de-dykowanego komputera (bramki), połączonego z Internetem poprzez szybką linię telefoniczną, na przykład linię T1 (1,544 Mbps) czy ISDN (128 kbps). Po-łączenie bezpośrednie umożliwia pełny dostęp do wszystkich usług siecio-wych, ale zarówno jego instalacja, jak i utrzymanie są dość drogie.
- Połączenie przez czyjąś bramkę internetową. Wymaga - niestety - zezwolenia na używanie czyjegoś komputera. Również umożliwia dostęp do wszystkich usług sieciowych.
- Bezpośredni dostawca Internetu. Ten sposób połączenia polega na wykorzy-staniu bramki będącej w posiadaniu jakiejś firmy, do której można się podłą-czyć, by uzyskać częściowy lub pełny dostęp do usług sieciowych. Komputer po stronie firmy pełni tylko rolę bramki internetowej. Do łączenia się z nim zwykle używa się modemu lub dedykowanych, szybkich łączy telefonicz-nych. Firma, która jest właścicielem bramki, jest określana jako dostawca In-ternetu lub usługodawca internetowy (ang. Internet Service Provider).
- Pośredni dostawca Internetu. Ta metoda polega na wykorzystaniu połączeń z takimi sieciami, jak Delphi czy CompuServe, do uzyskania dostępu do nie-których lub wszystkich usług internetowych. Metoda taka nadaje się do wyko-rzystania tylko wtedy, jeśli mało korzystasz z Internetu, i nie pozwala wyko-rzystać całego potencjału drzemiącego w systemie Linux. Jeśli Twój system jest częścią większej instytucji lub dzielisz się kosztami dostępu do sieci z kilkoma przyjaciółmi, pośredni dostawca Internetu najprawdopodobniej nie bę-dzie w stanie zapewnić Ci wydajności niezbędnej do korzystania z takich usług, jak poczta elektroniczna czy FTP. Inną wadą takiego rozwiązania jest to, że większość do-stawców pośrednich nie umożliwia posiadania własnej nazwy domenowej. Rzadko można znaleźć bramki internetowe, z których można byłoby korzystać bez uczestniczenia w kosztach ich utrzymania. Większość firm posiadających bramki in-ternetowe nie zgadza się, by korzystał z nich ktokolwiek obcy. W takiej sytuacji pozostają właściwie tylko dwa rozwiązania: bezpośrednie połączenie z Internetem lub skorzystanie z oferty bezpośredniego dostawcy Internetu. Wybór jed-nej z tych metod zwykle wynika z kosztów połączenia. Instalacja własnej bramki in-ternetowej może być droga, ale i tak może okazać się tańsza niż skorzystanie z usług dostawcy, szczególnie jeśli planujesz duży ruch w sieci lub system z założenia ma być bardzo duży Jeśli połączenie z Internetem będzie wykorzystywane przez jedną osobę lub niewielką firmę, instalowanie własnej bramki nie ma większego sensu. Wtedy najlepszym roz-wiązaniem jest skorzystanie z usług bezpośredniego dostawcy Internetu. Niewielkie firmy prawie zawsze łączą się z siecią właśnie w taki sposób.
Usługi, których potrzebujesz
Przed podjęciem decyzji o typie połączenia z Internetem należy zastanowić się, jakie usługi będą potrzebne. Jeśli potrzebujesz tylko dostępu do poczty elektronicznej, mo-żesz wybrać dowolny typ połączenia, choć koszty mogą być niewspółmiernie duże w porównaniu do wykorzystywanych możliwości. Na początek zdecyduj, które z poniższych usług są niezbędne, a z których mógłbyś zrezygnować.
- Poczta elektroniczna. Pozwala na wysyłanie i odbieranie wiadomości od innych użytkowników Internetu.
- Telnet. Pozwala na logowanie się poprzez Internet do systemów zdalnych.
- FTP. Umożliwia przenoszenie plików pomiędzy komputerami.
- WWW (ang. World Wide Web), czyli dostęp do witryn, zwykle graficznych, tworzonych za pomocą języka HTML (ang. Hypertekst Markup Language).
- Usenet, czyli dostęp do grup dyskusyjnych, w których prowadzone są rozmowy na najprzeróżniejsze tematy.
- Gopher. System wyszukiwania i pobierania informacji.
- WAIS. Pozwala na wyszukiwanie i pobieranie dokumentów, obsługiwany za pomocą systemów menu.
- Archie. Metoda wyszukiwania plików, które należy przesłać.
- IRC (ang. Internet Rely Chat), czyli pogawędki internetowe, przypominające nieco CB Radio.
Każdy system podłączony do Internetu przez bramkę (zarówno w przypadku posia-dania własnej bramki, korzystania z użyczonej czy wynajmowanej u większości dostawców Internetu) umożliwia korzystanie ze wszystkich wymienionych powyżej usług. Niektórzy dostawcy dość mocno ograniczają jednak prędkość przesyłania da-nych, co staje się poważnym problemem szczególnie wtedy, gdy chcesz udostępniać strony WWW, zawierające prócz tekstu również grafikę. Niektórzy dostawcy limitują też na różne sposoby dostęp do poczty elektronicznej i grup dyskusyjnych, należy więc zasięgnąć dokładnych informacji przed zdecydowaniem się na współpracę z którymś z nich.
Połączenie bezpośrednie za pomocą bramki
Połączenie bezpośrednie (nazywane również dedykowanym) polega na podłączeniu się do sieci poprzez przeznaczony do tego celu komputer nazywany bramką lub route-rem IP. Połączenie realizowane jest przy użyciu szybkiego, dedykowanego łącza tele-fonicznego (zwykle o przepustowości 1.44 Mb na sekundę lub większej). Bramka staje się elementem architektury sieci Internet, w związku z czym musi przez cały czas po-zostawać włączona. Dostęp do usług internetowych można uzyskać w każdym syste-mie, który pracuje w tej samej sieci, co bramka internetowa. Zwykle połączenia dedykowane używane są tam, gdzie występuje duże natężenie ru-chu i wymagana jest prędkość transmisji nie spadająca poniżej granicy np. 9600 bo-dów (choć niczym nadzwyczajnym nie są połączenia światłowodowe, umożliwiające przesyłanie danych z prędkością 45 Mbps). Rzadko zdarza się, by bezpośrednie połą-czenie z Internetem było własnością indywidualnej osoby czy małej firmy, głównie ze względu na wysokie koszty jego instalacji i utrzymania. Aby stworzyć system posiadający bezpośrednie połączenie z Internetem, trzeba skon-taktować się z NIC (Network Information Center), organizacją, która dostarcza odpo-wiednich informacji konfiguracyjnych. Całkowite koszty instalacji i utrzymania takie-go połączenia są wysokie. Wiążą się one z koniecznością posiadania odpowiedniego sprzętu i oprogramowania, a także poprowadzenia łącza o odpowiednio dużej przepu-stowości. Najczęściej używane typy łączy to T1 (1,544 Mbps), T4 (4 Mbps) i bardziej dostępny dla zwykłych śmiertelników ISDN (128 kbps).
Połączenie za pomocą czyjejś bramki
Alternatywą dla połączenia bezpośredniego jest wykorzystanie bramki zainstalowanej przez kogoś innego, na przykład jakąś firmę czy szkołę. Mało kto jednak zgadza się na używanie swoich komputerów, również ze względów bezpieczeństwa. Jeśli jednak jesteś jednym z niewielu szczęśliwców, którym udało się otrzymać zgodę na tego typu połączenie, musisz po prostu połączyć się z bramką i - za jej pośrednic-twem - z Internetem. Pod wieloma względami rozwiązanie to nie różni się od skorzy-stania z usług bezpośredniego dostawcy Internetu. Zwykle w takich sytuacjach uzy-skujesz pełny dostęp do wszystkich usług sieciowych (choć niektóre organizacje na-kładają pewne ograniczenia).
Usługodawcy internetowi
Usługodawcy internetowi (lub dostawcy Internetu) to firmy, które posiadają bezpo-średnie połączenie z Internetem (za pomocą bramki) i pozwalają używać go swoim klientom za odpowiednią opłatą (bramka jest zwykle "przezroczysta" dla użytkowni-ka). Ten typ połączenia często nazywany jest połączeniem dial-up i opiera się na pro-tokołach SLIP (ang. Serial Line Interface Protocol) i PPP (ang. Point-to-Point Proto-col). Niektórzy usługodawcy do obsługi poczty elektronicznej używają protokołu UUCP. Dostawcy Internetu zwykle pobierają opłatę składającą się z pewnej części stałej oraz części uzależnionej od czasu połączenia lub ilości przesłanych danych. Połączenie się z dostawcą Internetu jest przeważnie bardzo proste. Większość z nich umożliwia rów-nież posiadanie własnej nazwy domenowej. Największą zaletą połączenia przez bezpośredniego dostawcę Internetu jest fakt, że system zachowuje się tak samo, jakby był podłączony bezpośrednio do sieci. Komu-nikacja z komputerem-bramką jest obsługiwana przez system operacyjny i jest proce-sem praktycznie niewidocznym dla użytkownika. Wadą tego rozwiązania jest to, że czasem niektóre usługi dostępne są tylko w ograniczonym zakresie (na przykład nie-którzy dostawcy nie pozwalają na przesyłanie plików za pomocą FTP do innych ser-werów). Jeśli bierzesz pod uwagę skorzystanie z usług bezpośredniego dostawcy Internetu, po-winieneś zorientować się, jakie usługi są oferowane przez dostawców działających w okolicy, czy wymagany jest jakiś dodatkowy sprzęt, jaki jest system opłat (czy są to opłaty stałe, czy zależne od wykorzystania łącza) i jak przedstawia się problem wspar-cia technicznego na wypadek kłopotów

Konfigurowanie FTP i anonimowego FTP
Jak myślisz, która z usług udostępnianych dzięki protokołowi TCP/IP i Internetowi jest używana najczęściej? Jeśli odpowiedziałeś, że FTP, to masz rację (jeśli uważałeś, że jest inaczej, może to być dla Ciebie niespodzianką - jest to jednak fakt, choć WWW staje się coraz popularniejsze). Popularność FTP jest łatwa do wytłumaczenia: opro-gramowanie do jego obsługi dostarczane jest wraz z każdą wersją UNIX-a i Linuxa. Jest ono łatwe do zainstalowania, skonfigurowania i używania. Pozwala na dostęp do ogromnej ilości danych przy minimalnym wysiłku. Rosnąca popularność stron WWW spowodowała również powstanie nowego interfejsu służącego do obsługi FTP, wbudo-wanego w przeglądarki WWW. Większość przeglądarek, na przykład Netscape Naviga-tor, pozwala na transfer plików za pomocą protokołu FTP. Jeśli zamierzasz używać protokołu FTP tylko do ładowania plików z innych systemów, musisz tylko załączyć obsługę tego protokołu w swoim systemie. O wiele bardziej inte-resujące jest jednak umożliwienie innym korzystania z plików zgromadzonych w Two-im systemie. Omówimy głównie zagadnienia związane z konfigurowaniem węzła FTP. Rozpoczniemy jednak od krótkiego omówienia protokołu FTP i jego powiązań z TCP/IP. Informacje te powinny ułatwić zrozumienie zasady działania usługi FTP.
Co to jest FTP?

FTP (ang. File Transfer Protocol, protokół transmisji plików) to jeden z protokołów ro-dziny TCP/IP, służący do przesyłania plików pomiędzy komputerami obsługującymi system TCP/IP (choć dostępne są również podobne do FTP programy przeznaczone do współpracy z innymi protokołami). FTP pozwala na przesyłanie plików w obie strony i poruszanie się po drzewie katalogów. Protokół ten nie jest przeznaczony do urucha-miania programów w systemie zdalnym, ale jest chyba najlepszym narzędziem do transmisji plików. Aby można było użyć FTP, na obu końcach połączenia musi być uruchomiony odpowiedni program. Komputer, który nawiązuje połączenie (klient), wywołuje drugi komputer (serwer) i po przesłaniu zestawu informacji potwierdzają-cych połączenie jest ustanawiane. Zwykle po uzyskaniu połączenia należy się zalogować, co oznacza, że trzeba być użytkownikiem systemu zdalnego (czyli posiadać własny identyfikator oraz hasło). Ponieważ niemożliwe jest przyznanie osobnego identyfikatora i hasła każdemu, kto chce skorzystać z ogólnodostępnych zasobów, w wielu systemach używa się tzw. ano-nimowego FTP. Rozwiązanie to pozwala każdemu zalogować się do systemu po poda-niu identyfikatora ftp lub anonymous, bądź to bez podania hasła, bądź podając swój adres e-mailowy.
Używanie FTP
Połączenie się z systemem zdalnym za pomocą FTP jest łatwe. Dostęp do komputera zdalnego poprzez Internet (bezpośrednio lub poprzez dostawcę Internetu) lub sieć lo-kalną można uzyskać wtedy, gdy komputer ten jest bezpośrednio osiągalny. Jeśli chcesz użyć FTP, uruchom odpowiedni program (nazywany klientem FTP), podając nazwę komputera, z którym chcesz się połączyć. Przykładowo, jeśli chcesz połączyć się z systemem o nazwie chatton.com, możesz (zakładając, że masz dostęp do kom-putera zdalnego przez sieć LAN lub Internet; w przypadku Internetu oznacza to rów-nież, że nazwa komputera musi dać się przetłumaczyć na numer IP za pomocą usługi Domain Name Service) wydać polecenie:
ftp chatton.com
Spowoduje ono uruchomienie klienta FTP i próbę nawiązania połączenia z systemem chatton.com. Po nawiązaniu połączenia (zakładając, że system zdalny pozwala na połączenia FTP) system zdalny oczekuje na podanie identyfikatora użytkownika. Jeśli dozwolone są anonimowe połączenia FTP, zwykle pojawia się odpowiednia informacja. Oto przykład pochodzący z węzła sunsite.unc.edu:
ftp sunsite.unc.edu
331 Guest login ok, send your complete e-mail address as password.
Enter username (default: anonymous): anonymous
Enter password [tparker@tpci.com]:
|FTP| Open
230- WELCOME to UNC and SUN's anonymous ftp server
230- University of North Carolina
230- Office FOR Information Technology
230- sunsite.unc.edu
230 Guest login ok., access restrictions apply.
FTP>
Po zakończeniu procesu logowania wyświetlana jest zachęta FTP>. Oznacza to, że sys-tem jest gotów do przyjmowania poleceń FTP. W niektórych systemach dodatkowo wyświetlany jest krótki komunikat zawierający instrukcje dotyczące ładowania plików, ograniczeń nałożonych na Ciebie jako użyt-kownika anonimowego oraz położenia bardziej przydatnych plików. Przykładowe komunikaty z węzła sunsite.unc.edu mają postać:
To get a binary file, type: BINARY and then: GET "File.Name" newfilename
To get a text file, type: ASCII and then: GET "File.Name"
ĺ newfilename
Names MUST match upper, lower case exactly. Use the "quotes" as shown.
To get a directory, type: DIR. To change directory, type: CD "Dir.Name"
To read a short text file, type GET "File.Name" TT
For more, type HELP or see FAQ in gopher.
To quit, type EXIT or Control-Z.
230- If you e-mail to info@sunsite.unc.edu you will be sent help ĺ information
230- about how to use the different services sunsite provides.
230- We use the Wuarchive experimental ftpd. If you "get"
ĺ .tar.Z
230- or .Z it will compress and/or tar it on the fly. Using ".gz" instead
230- of ".Z" will use the GNU zip (/pub/gnu/gzip*) instead, a superior
230- compression method.
Po zalogowaniu się do systemu zdalnego można przeglądać zawartość katalogów i po-ruszać się po nich używając poleceń znanych z systemu Linux. Na przykład, aby wy-świetlić zawartość bieżącego katalogu, należy wydać polecenie ls (niektóre wersje FTP obsługują również jego DOS-owy odpowiednik, dir). Do zmiany katalogu bieżącego służy polecenie cd. Jeśli chcesz przejść do katalogu nadrzędnego (czyli tego, w którym zawarty jest katalog bieżący), wydaj polecenie cd ... Jak widać, polecenia są takie same, jak te służące do poruszania się w obrębie lokalnego systemu plików; należy jednak pamiętać, że dotyczą one systemu zdalnego. Podczas używania FTP nie są dostępne żadne skróty klawiaturowe (takie jak dokań-czanie nazw plików po naciśnięciu klawisza Tab). Oznacza to, że trzeba wpisywać na-zwy plików w pełnej i poprawnej postaci. Jeśli się pomylisz, otrzymasz komunikat o błędzie i będziesz musiał spróbować jeszcze raz. Na szczęście, jeśli używasz systemu X Window, możesz wycinać i wklejać tekst, który wpisałeś wcześniej. Głównym zadaniem FTP jest przesyłanie plików, więc trzeba wiedzieć zarówno w jaki sposób można załadować plik z systemu zdalnego, jak i wysłać plik do tego systemu. Kiedy znajdziesz w systemie zdalnym jakiś plik, który chciałbyś załadować do swoje-go komputera, użyj polecenia get, którego argumentem jest nazwa tegoż pliku. Przy-kładowe polecenie:
get "soundcard_driver"
spowoduje załadowanie pliku o nazwie soundcard_driver znajdującego się w kata-logu bieżącym komputera zdalnego do katalogu bieżącego Twojego systemu. Po wy-daniu polecenia get system zdalny przesyła dane do Twojego komputera, wyświetla-jąc krótkie podsumowanie po zakończeniu tej operacji. W trakcie przesyłania danych nie jest wyświetlany żaden wskaźnik postępu, więc w przypadku większych plików po-winieneś uzbroić się w cierpliwość (większość wersji programu ftp udostępnia opcję hash, która powoduje wyświetlenie znaku # po przesłaniu każdego kilobajta informa-cji; mimo tego jednak nie jest wyświetlany czas pozostały do zakończenia transferu). Oto przykład:
FTP> get "file1.txt"
200 PORT command successful.
150 BINARY data connection for FILE1.TXT (27534 bytes)
226 BINARY Transfer complete.
27534 byte received in 2.35 seconds (12Kbytes/s).
Jeśli chcesz przesyłać pliki w przeciwnym kierunku (z Twojego systemu do komputera zdalnego, zakładając że posiadasz prawo zapisu w systemie plików komputera zdal-nego), powinieneś użyć polecenia put w taki sam sposób, jak polecenia get. Polecenie
put "comments"
powoduje przesłanie pliku o nazwie comments znajdującego się w katalogu bieżącym Twojego systemu do katalogu bieżącego w systemie zdalnym (można również bezpo-średnio podać odpowiednie ścieżki dostępu). Polecenia get (załaduj, pobierz) i put (wyślij) mają punkt odniesienia w komputerze lokalnym, co oznacza, że wydając polecenie get, każesz oprogramowaniu pobrać plik z serwera i umieścić go w swoim komputerze, natomiast poleceniem put wysyłasz pliki ze swojego komputera do serwera (mamy tu sytuację dokładnie odwrotną, niż w przy-padku programu telnet, w którym polecenia są odniesione do komputera zdalnego). Ważne jest, by dobrze zapamiętać, które polecenie działa w którą stronę, w przeciw-nym przypadku może zdarzyć się, że niechcący pozbędziesz się jakichś ważnych da-nych. Cudzysłów otaczający nazwy plików w większości wersji FTP nie jest wymagany, ale zabezpiecza przed złym interpretowaniem polecenia przez serwer, więc stosowanie go jest dobrą praktyką. Niektóre wersje ftp udostępniają polecenia umożliwiające przesyłanie większej liczby plików - polecenia mput i mget. Polecenia get i put powodują jednorazowe przesła-nie tylko jednego pliku, którego nazwa musi być podana w całości (bez symboli wielo-znacznych). Polecenia mget i mput pozwalają na użycie symboli wieloznacznych, ta-kich jak * czy ?. Jeśli na przykład chcesz załadować wszystkie pliki z rozszerzeniem .doc znajdujące się w katalogu bieżącym, powinieneś wydać polecenie
mget *.doc
Musisz sam sprawdzić, czy polecenia mget i mput działają w Twojej wersji ftp (nie-które wersje zamiast tego umożliwiają po prostu użycie symboli wieloznacznych w ar-gumentach poleceń get i put - powinieneś więc sprawdzić również taką możliwość). FTP pozwala na przesyłanie plików w kilku trybach, zwykle zależnych od systemu. Większość systemów (w tym Linux) obsługuje tylko dwa tryby: binary (binarny) oraz ASCII (pliki tekstowe). Niektóre stacje robocze obsługują jeszcze standard EBCDIC, a wiele sieci lokalnych posiada własne formaty, pozwalające na przyspieszenie transmi-sji (mogą one używać 32 - lub 64 - bitowych słów). Różnica pomiędzy trybem binarnym i ASCII jest prosta. Tryb tekstowy umożliwia przesyłanie plików ASCII, w których wiersze są rozdzielone powrotem karetki i zna-kiem nowego wiersza, podczas gdy tryb binarny pozwala przesyłać dane bez żadnego sformatowania. Tryb binarny jest szybszy od tekstowego, a pozwala również na pra-widłową transmisję plików tekstowych. FTP nie pozwala na przesyłanie praw dostępu do plików, ponieważ nie zostało to ujęte w protokole. Linux udostępnia dwa tryby transmisji danych: ASCII i binarny. Niektóre systemy przełączają się pomiędzy nimi automatycznie po rozpoznaniu pliku binarnego, ale nie należy zakładać, że jest tak zawsze. Dla pewności zawsze warto ustawić odpowiedni tryb samodzielnie. Domyślnie większość wersji FTP uruchamia się w trybie ASCII (choć istnieją i takie, które uruchamiają się w trybie binarnym). Upewnij się, że używasz właściwego trybu. Jedną z bardziej nieprzyjemnych pomyłek zdarzających się niedoświad-czonym użytkownikom FTP jest użycie trybu tekstowego do przesyłania plików binarnych. Tryb transmisji nie ma znaczenia w przypadku przesy-łania plików tekstowych, ale jeśli chcesz uniknąć ładowania niepotrzeb-nych śmieci, przed rozpoczęciem ładowania plików binarnych powinieneś upewnić się, że załączyłeś tryb binarny. Aby załączyć tryb binarny (wymagany do ładowania plików wykonywalnych oraz plików z danymi zawierających specjalne kody, generowanych przez arkusze kalkula-cyjne, niektóre edytory tekstów czy programy graficzne), wydaj polecenie
binary
Do trybu tekstowego możesz wrócić wydając polecenie ascii. Ponieważ jednak węzły FTP zwykle odwiedza się po to, by załadować jakieś archiwa, nowe wersje programów itp., warto zawsze używać trybu binarnego. Pliki binarne przesłane w trybie ASCII nie będą się nadawały do użycia. Tryb ASCII pozwala tylko na przesyłanie znaków wchodzących w skład standardu ASCII (kodowanych za pomocą siedmiu bitów), w plikach binarnych natomiast mogą występować również kody nie należące do tego standardu. Przesłanie pliku ASCII w trybie binary nie narusza jego zawartości. Aby opuścić program ftp, wydaj polecenie quit albo exit. Obydwa te polecenia powodują zamknięcie sesji w systemie zdalnym i zakończenie działania programu ftp w systemie lokalnym. Poniższa lista przedstawia inne, często używane polecenia do-stępne w programie FTP:
ascii    włączenie tekstowego trybu przesyłania danych;
binary    włączenie binarnego trybu przesyłania danych;
cd    zmiana katalogu bieżącego na serwerze;
close    zamknięcie połączenia;
del    usunięcie pliku na serwerze;
dir    wyświetlenie zawartości bieżącego katalogu serwera;
get    pobranie pliku z serwera;
hash    wyświetlanie znaków # po załadowaniu każdego bloku danych;
help    wyświetlenie listy dostępnych poleceń;
lcd    zmiana katalogu bieżącego w systemie lokalnym;
mget    pobranie kilku plików z serwera;
mput    przesłanie kilku plików do serwera;
open    nawiązanie połączenia z serwerem;
put    wysłanie pliku do serwera;
pwd    wyświetlenie nazwy katalogu bieżącego na serwerze;
quote    bezpośrednie podanie polecenia protokołu FTP;
quit    zakończenie sesji FTP.
W większości wersji FTP w poleceniach rozróżniane są małe i wielkie litery, wpisanie więc polecenia wielkimi literami spowoduje wyświetlenie komunikatu o błędzie. W nie-których wersjach w takim przypadku nastąpi automatyczna konwersja na małe litery. Ponieważ jednak w systemie Linux prawie we wszystkich zastosowaniach używa się małych liter, dobrym pomysłem będzie używanie ich i tu.
Powiązania pomiędzy FTP a TCP/IP
Protokół FTP wykorzystuje dwa kanały TCP: port 20 jest używany do przesyłania da-nych, a port 21 do przesyłania poleceń. Oba te porty muszą funkcjonować, jeśli FTP ma działać poprawnie. Wykorzystanie dwóch kanałów odróżnia FTP od innych pro-gramów do przesyłania plików. Dzięki temu możliwe jest równoczesne przesyłanie po-leceń i danych. FTP działa na pierwszym planie i nie umożliwia użycia mechanizmów kolejkowania. W połączeniu FTP bierze udział program rezydentny, działający przez cały czas po stronie serwera, oraz program nazywany klientem FTP, uruchamiany po stronie nawią-zującej połączenie. W systemie Linux program rezydentny dla serwera nazywa się ftpd, natomiast program klienta FTP - ftp. Podczas nawiązywania połączenia pomiędzy klientem i serwerem oraz po wydaniu przez użytkownika każdego polecenia, pomiędzy komputerami przesyłane są ciągi po-leceń. Polecenia te są dostępne tylko dla protokołu FTP i nazywa się je protokołem wewnętrznym. Protokół wewnętrzny FTP składa się z czteroznakowych poleceń w standardzie ASCII, rozdzielanych znakiem nowego wiersza. Niektóre z poleceń wyma-gają podania parametrów. Główną zaletą takiego rozwiązania jest możliwość obser-wacji i zrozumienia przez użytkownika poleceń, jakie są przesyłane pomiędzy kompu-terami. Znacznie ułatwia to proces wyszukiwania ewentualnych błędów. Poza tym do-świadczony użytkownik może używać połączeń FTP nie wykorzystując programu klienta (innymi słowy, porozumiewać się z programem ftpd bez użycia programu ftp), ale ma to zastosowanie tylko do wyszukiwania przyczyn ewentualnych proble-mów (no i ewentualnie popisania się przed kolegami). Po zalogowaniu się do systemu zdalnego za pomocą FTP nie przenosisz się do tego sys-temu. Nadal jesteś logicznie po stronie klienta, więc wszystkie instrukcje dotyczące przesyłania plików i poruszania się po drzewie katalogów odnoszą się do komputera lokalnego, a nie do serwera. Po nawiązaniu połączenia należy:
1. zalogować się, podając identyfikator użytkownika i hasło;
2. przejść do katalogu, w którym znajdują się interesujące nas pliki lub do które-go zamierzamy wysłać pliki;
3. zdefiniować tryb przesyłania danych;
4. rozpocząć przesyłanie danych (lub też wydać polecenia służące innym celom);
5. po zakończeniu przesyłania danych zamknąć połączenie.
Powyższe kroki należy podjąć dla każdego połączenia.
Po dodaniu do polecenia ftp opcji -d uruchamiany jest tryb wyszukiwania błędów (ang. debugging). W tym trybie wszystkie polecenia przesyłane do portu poleceń są wyświetlane na ekranie. Instrukcje pochodzące od klienta oznaczone są strzałką, na-tomiast od serwera - trzycyfrową liczbą. Polecenie PORT oznacza adres kanału da-nych, na którym klient oczekuje na odpowiedź od serwera. Jeśli nie jest on podany, domyślnie używany jest port 20. Niestety, w trybie wyszukiwania błędów nie jest moż-liwe śledzenie postępów w transmisji danych. Przykładowa sesja FTP z załączoną op-cją -d przedstawiona jest poniżej.
$ ftp -d tpci_hpws4
Connected to tpci_hpws4.
220 tpci_hpws4 FTP server (Version 1.7.109.2 Tue Jul 28 23:32:34 GMT 1992) ready.
Name (tpci_hpws4:tparker):
---> USER tparker
331 Password required for tparker.
Password:
---> PASS qwerty5
230 User tparker logged in.
---> SYST
215 UNIX Type: L8
Remote system type is UNIX.
---> Type I
200 Type set to I.
Using binary mode to transfer files.
ftp> ls
---> PORT command successful.
---> TYPE A
200 Type set to A.
---> LIST
150 Opening ASCII mode data connection for /bin/ls.
total 4
-rw-r----- 1 tparker tpci 2803 Apr 29 10:46 file1
-rw-rw-r-- 1 tparker tpci 1264 Apr 14 10:46 file5_draft
-rwxr----- 2 tparker tpci 15635 Mar 14 23:23 test_comp_1
-rw-r----- 1 tparker tpci 52 Apr 22 12:19 xyzzy
Transfer complete.
--->TYPE I
200 Type set to I.
ftp>
$
W powyższym przykładzie można zaobserwować, że tryb przesyłania danych jest au-tomatycznie zmieniany z binarnego na tekstowy podczas przesyłania informacji o za-wartości katalogu, a następnie jest przywracany tryb binarny (który w tym przypadku jest trybem domyślnym).
Konfiguracja FTP
Jeśli zdecydujesz, że Twój komputer powinien działać jako serwer FTP (udostępniają-cy lub nie anonimowe FTP), musisz odpowiednio skonfigurować system - przede wszystkim uruchamiając rezydentny program obsługi FTP i konfigurując system pli-ków tak, by uniemożliwić dostęp do plików niepowołanym osobom. Proces konfigura-cji rozpoczyna się od wybrania nazwy węzła FTP. Nazwa taka nie jest niezbędna, ale ułatwi innym łączenie się z Twoim systemem (szczególnie w przypadku połączeń ano-nimowych). Nazwa węzła FTP powinna mieć format:
ftp.nazwa_domeny.typ_domeny
nazwa_domeny jest nazwą domeny, do której przynależy węzeł FTP, zaś typ_domeny to standardowe rozszerzenie DNS. Przykładowa nazwa
ftp.tpci.com
sugeruje, że jest to węzeł obsługujący anonimowe połączenia FTP dla domeny tpci.com. Używanie nazwy komputera w nazwie węzła FTP, na przykład
ftp.merlin.tpci.com
zwykle nie jest dobrym pomysłem, ponieważ powoduje problemy w sytuacji, gdy chcesz przenieść obsługę FTP na inny system należący do danej domeny. Zamiast tego warto użyć aliasu, który będzie wskazywał na konkretny komputer pełniący funkcje serwera FTP. Takie rozwiązanie nie jest konieczne, jeśli komputer nie wchodzi w skład sieci lokalnej, tylko jest połączony z Internetem za pośrednictwem dostawcy Internetu, ale często okazuje się nieodzowne w większych sieciach. Jeśli używasz systemu DNS, odpowiedni alias może zostać zdefiniowany bardzo łatwo. W takim przypadku wy-starczy do bazy danych o aliasach dodać wiersz
ftp IN CNAME merlin.tpci.com
podstawiając oczywiście nazwę własnego komputera. Wiersz ten skieruje każdego próbującego się połączyć z węzłem ftp.tpci.com do komputera mer-lin.tpci.com, działającym jako serwer FTP. Jeśli z jakichś powodów inny komputer przejmie rolę serwera ftp, należy zmodyfikować odpowiedni wpis w bazie danych o aliasach, tak by wskazywał na komputer pełniący aktualnie funkcję serwera (zmiana taka nie wchodzi w życie od razu, ponieważ odpowiednie informacje muszą zostać ro-zesłane do wszystkich baz danych DNS).
Konfigurowanie programu ftpd
Program rezydentny ftpd musi zostać uruchomiony po stronie serwera FTP. Zwykle jest on uruchamiany nie w jednym z plików rc, ale przez program inetd, dzięki cze-mu działa tylko wtedy, gdy jest potrzebny. Jest to najlepsze rozwiązanie w niezbyt ob-ciążonych węzłach FTP. Program inetd obserwuje przez cały czas port poleceń TCP (kanał 21) i po nadejściu pakietu danych z żądaniem nawiązania połączenia urucha-miany jest program ftpd. Powinieneś upewnić się, że program inetd rzeczywiście może uruchomić ftpd, spraw-dzając, czy w pliku konfiguracyjnym programu inetd (plik ten zwykle nazywa się /etc/ inetd.config lub /etc/inetd.conf) istnieje wpis podobny do następują-cego:
ftp stream tcp nowait root /usr/etc/ftpd ftpd -l
Jeśli takiego wpisu nie ma, należy go dodać. W większości systemów linuxowych taki wpis znajduje się w odpowiednim pliku, ale może być zaznaczony jako komentarz. W takim przypadku wystarczy usunąć symbol komentarza. Wiersz ten informuje pro-gram inetd, że FTP będzie korzystał z protokołu TCP, i że za każdym razem, gdy wy-kryte zostanie połączenie z portem FTP, powinien zostać uruchomiony program ftpd z opcją -l, załączającą rejestrowanie połączeń. Opcje tę można zignorować. Jeśli pro-gram ftpd znajduje się w innym miejscu niż /usr/etc/ftpd, należy oczywiście od-powiednio zmodyfikować ścieżkę dostępu. Program ftpd udostępnia jeszcze kilka innych opcji, pozwalających kontrolować jego działanie - one również mogą zostać podane w pliku /etc/inetd.conf. Poniżej po-dajemy listę najczęściej używanych z nich:
-d    uruchamia wysyłanie informacji o podejmowanych czynnościach do procesu syslog;
-l    aktywuje rejestrowanie danych o sesjach (tylko informacje o udanych i nieudanych połączeniach, beż żadnych informacji dodatkowych); jeśli opcja -l zostanie podana dwukrotnie, rejestrowane będą również wszystkie wydane polecenia; jeśli opcja -l jest podana trzykrotnie, reje-strowane są także rozmiary plików przesyłanych poleceniami put i get;
-t    ustawia czas, po jakim należy wyłączyć program ftpd po zakończeniu sesji (domyślnie: 15 minut); wartość należy podać w sekundach po opcji -t;
-T    ustawia maksymalny czas połączenia (w sekundach); wartość domyśl-na: 2 godziny;
-u    ustawia wartość zmiennej umask dla plików ładowanych do systemu lo-kalnego (domyślnie: 022); klient może zażądać zmiany tej wartości.
Konta FTP
Jeśli chcesz, by każdy użytkownik korzystający z Twojego węzła FTP posiadał własny identyfikator i hasło, musisz dla każdego z nich utworzyć osobne konto w pliku /etc/passwd. Jeśli nie zamierzasz umożliwiać anonimowego dostępu do FTP, nie po-winieneś tworzyć konta ogólnodostępnego. Aby umożliwić anonimowy dostęp do serwera FTP, należy założyć konto dla anoni-mowego użytkownika (jeśli konto takie jeszcze nie istnieje w systemie, ponieważ w wie-lu wersjach Linuxa konto takie zakładane jest podczas instalacji, choć dostęp do niego jest zablokowany). Sposób postępowania jest taki sam, jak w przypadku zakładania konta dla zwykłego użytkownika. Identyfikator użytkownika anonimowego powinien mieć postać anonymous lub ftp, ale można go zdefiniować dowolnie. Katalog domo-wy takiego użytkownika powinien być ze względów bezpieczeństwa oddzielony od reszty systemu plików. Typowy wpis dla anonimowego użytkownika o identyfikatorze ftp w pliku /etc/passwd ma postać:
ftp:*:400:51:Anonymous FTP access:/usr/ftp:/bin/false
Gwiazdka w polu zawierającym hasło powoduje, że dostęp do konta jest zablokowa-ny. Liczbowy identyfikator użytkownika (400) musi oczywiście być niepowtarzalny w obrębie systemu. Ze względów bezpieczeństwa dobrze jest utworzyć dla użytkownika ftp osobną grupę (edytując plik /etc/group), a następnie przypisać go do tej grupy. Użytkownik ftp powinien być jedynym użytkownikiem należącym do tej grupy; dzię-ki takiemu rozwiązaniu można lepiej skonfigurować prawa dostępu do plików w sys-temie. Katalogiem domowym w powyższym przykładzie jest /usr/ftp, ale możesz wybrać dowolny inny katalog, pod warunkiem że należy on do użytkownika root (jest to znów podyktowane względami bezpieczeństwa). Programem uruchamianym po zalogowaniu jest /bin/false, co dodatkowo zabezpiecza system przed dostępem do kont i programów nie posiadających dobrego zabezpieczenia hasłem.
Konfigurowanie katalogów
Jak przekonasz się czytając - "Ustawianie praw dostępu", możesz spróbować wyizolować z systemu plików podsystem dostępny dla anonimowego użytkownika FTP. Dzięki temu nie będzie mógł on wydostać się poza katalog /usr/ftp (czy jakikolwiek inny katalog, który zostanie użyty jako katalog domowy użytkownika ftp). W tym celu należy stworzyć jakby miniaturę systemu plików, za-chowując standardowe nazwy katalogów i kopiując do nich podstawowe pliki, których użytkownik ftp może potrzebować. Proces konfigurowania katalogów, które będą niezbędne anonimowemu użytkowni-kowi FTP, jest prosty, wymaga tylko utworzenia pewnej liczby katalogów i skopiowa-nia do nich odpowiednich plików. Poniżej przedstawiamy opis takiej procedury.
1. Utwórz podkatalog bin (na przykład /usr/ftp/bin) i skopiuj do niego po-lecenie ls, które będzie potrzebne użytkownikom do wyświetlania informacji o zawartości katalogów.
2. Utwórz podkatalog etc (na przykład /usr/ftp/etc) i skopiuj do niego plik passwd (/etc/passwd) oraz group (/etc/group). Za chwilę zajmiemy się modyfikowaniem zawartości tych plików.
3. Utwórz podkatalog lib (na przykład /usr/ftp/lib) i skopiuj do niego pliki /lib/ld.so i /lib/ld.so.X (gdzie X jest numerem wersji pliku libc). Pliki te są używane przez program ls. Ten krok jest wymagany tylko wtedy, gdy wersja programu ls dostępna w systemie używa biblioteki libc; w większości przypadków nie jest to potrzebne.
4. Utwórz podkatalog pub (na przykład /usr/ftp/pub), w którym przechowy-wane będą pliki udostępniane dla użytkowników. Katalogowi temu przyjrzy-my się dokładniej za chwilę.
5. Utwórz podkatalog dev (na przykład /usr/ftp/dev) i za pomocą polecenia mknod skopiuj do niego plik /dev/zero. Skopiowany plik musi posiadać taki sam numer główny i poboczny urządzenia jak plik oryginalny. Jest on używa-ny przez bibliotekę ld.so (i co za tym idzie, polecenie ls). Ten krok jest nie-zbędny tylko w przypadku, gdy dostępna w systemie wersja programu ls wymaga pliku /lib/ld.so.
Do katalogu ~ftp/etc trafiają kopie plików /etc/passwd i /etc/group. Należy usunąć z nich wszystkie wpisy oprócz tych dotyczących użytkownika ftp (zwykle tyl-ko anonymous i bin), a w miejsce haseł wstawić gwiazdki. W katalogu ~ftp/pub zwykle przechowywane są pliki, które mają być udostępniane anonimowym użytkownikom FTP. Można w nim utworzyć podkatalogi, tak aby za-chować przejrzysty układ plików. Można również stworzyć katalog, do którego użyt-kownicy będą mogli nadsyłać własne pliki (ang. upload directory); w takim katalogu użytkownik ftp musi mieć prawo zapisu. Jeśli zezwolisz użytkownikom zdalnym na korzystanie z Twojego systemu, zwróć uwagę na fakt, że zabezpieczenia powinny być legalne - dlatego powinieneś uprzedzić każdego użytkownika, że jego działania w Twoim systemie mogą być obserwowane. W dzisiejszych czasach trzeba zabez-pieczać się na każdym kroku!
Ustawianie praw dostępu
Polecenie chroot pomaga chronić system przed nieautoryzowanym dostępem do pli-ków. Umożliwia ono potraktowanie jednego z podkatalogów jako katalogu głównego. Przykładowo, polecenie chroot jest zwykle wydawane w przypadku użytkownika ftp, więc wszystkie polecenia związane z systemem plików będą odniesione do jego katalogu domowego. Innymi słowy, polecenie cd /bin nie spowoduje przejścia do ka-talogu /bin, ale do /usr/ftp/bin (o ile katalogiem domowym użytkownika ftp jest /usr/ftp). Takie rozwiązanie ułatwia ograniczanie dostępu do jakichkolwiek plików znajdujących się poza podsystemem zapisanym w katalogu domowym użytkownika. Jeśli zdecydujesz się na utworzenie katalogu, w którym anonimowy użytkownik będzie miał możliwość zapisu, powinieneś nadać mu prawo do wykonywania i zapisu, ale nie do odczytu - dzięki temu nikt nie będzie mógł załadować plików pozostawionych przez kogoś w Twoim systemie. Wszystkie pozostałe podkatalogi katalogu /usr/ftp powinny mieć ustawione prawa dostępu tak, by nikt nie miał prawa zapisu. Upewnij się, że anonimowy użytkownik może odczytywać z nich dane (właścicielem katalogów i plików powinien być użyt-kownik root, grupa root lub system) - dla wszystkich plików powinien być możliwy tylko odczyt. Katalogi, do których anonimowy użytkownik powinien mieć możliwość wejścia czy uzyskania informacji o ich zawartości (jak katalog pub), powinny mieć również ustawione prawo do wykonywania. Przestrzeganie tych wskazówek zapewnia stosunkowo wysoki poziom bezpieczeństwa. Prawo do odczytu i wykonywania dla ka-talogu możesz nadać poleceniem:
chmod 555 nazwa_katalogu
Jedynym wyjątkiem jest katalog, do którego anonimowy użytkownik może przesyłać dane, który może mieć ustawione prawo do zapisu.
Testowanie systemu
Zanim pozwolisz komukolwiek korzystać z węzła FTP, powinieneś zalogować się sam i spróbować uzyskać dostęp do plików, do których nie powinieneś mieć dostępu, wydo-stać się poza katalog ~ftp, usunąć pliki, których nie powinieneś móc usunąć itp. War-to poświęcić na to kilka minut. Upewnij się, że wszystko jest zapięte na ostatni guzik. Jeśli pozostawisz jakieś luki, znajdzie je i wykorzysta ktoś inny. Często przydatne jest założenie specjalnej skrzynki pocztowej dla administratora sys-temu FTP, dzięki czemu użytkownicy innych systemów, którzy potrzebują pomocy czy informacji, będą mogli wysłać do Ciebie pocztę. W tym celu powinieneś utworzyć w pliku /etc/aliases nowy alias (na przykład ftp-admin) i uruchomić polecenie newaliases, aby wprowadzić zmiany w życie. Nie będziemy wchodzić w szczegóły organizowania drzewa podkatalogów katalogu domowego użytkownika ftp, podamy tylko kilka porad. Na początek należy zdecy-dować, gdzie będą przechowywane katalogi FTP i zorganizować je w jakiś rozsądny sposób. Przykładowo, jeśli chcesz udostępnić kilka napisanych przez siebie progra-mów, powinieneś umieścić każdy z nich w osobnym katalogu. Plik README w każdym katalogu powinien zawierać objaśnienie co do jego zawartości. Główny plik README albo INSTRUCTIONS w katalogu ~ftp może wyjaśniać szczegóły konfiguracji Twojego węzła i skrótowo przedstawiać jego zawartość.
Bezpieczniejsze FTP
System FTP przedstawiony w poprzednich podrozdziałach, rozprowadzany praktycz-nie z każdą wersją Linuxa, wymaga nieco pracy jeśli chcesz, by był bezpieczny. Nieste-ty, nie jest on zabezpieczony przed bardziej doświadczonymi hakerami. Na szczęście istnieje alternatywa dla tych, którym bardzo zależy na bezpieczeństwie systemu; jest nią WU FTP. Jest to system FTP opracowany w Uniwersytecie Waszyngtońskim, który do standardowego systemu FTP dodaje takie cechy, jak:
- dokładniejsza kontrola identyfikatorów użytkowników i identyfikatorów grup,
- poprawione śledzenie przesyłania plików do i z systemu,
- automatyczne zamykanie systemu,
- automatyczna kompresja i dekompresja plików.
Jeśli uważasz, że powyższe cechy to właśnie to, czego potrzebujesz, możesz uzyskać kopię kodu źródłowego WU FTP w kilku węzłach FTP, na przykład w węźle wuar-chive.wustl. edu. Poszukaj tam pliku /packages/wuarchive-ftpd/wu-ftpd-X.X.tar.Z (gdzie X-X jest numerem wersji). Otrzymany kod musi zostać skompilowa-ny w systemie lokalnym. Szczegóły konfiguracji systemu WU FTP są ustalane poprzez definiowanie odpowiednich zmiennych środowiskowych - z pomocą przyjdzie Ci dokumentacja rozprowa-dzana razem z kodem źródłowym. Konfigurowanie WU FTP jest o wiele bardziej zło-żone, niż zwykłego systemu FTP, a dodatkowe zabezpieczenia, choć przydatne, dla wielu węzłów FTP (założonych na przykład w domu czy pracy) mogą być zupełnie niepotrzebne (o ile w systemie nie są przechowywane szczególnie ważne informacje).
Zabezpieczanie anonimowego FTP
Anonimowe FTP jest szybkie i łatwe w użyciu, ale źle skonfigurowane może stanowić ogromną lukę w bezpieczeństwie systemu. Poniżej przedstawiamy kilka kroków, które należy koniecznie podjąć podczas konfigurowania anonimowego FTP.
1. Utwórz konto o identyfikatorze ftp. W tym celu ręcznie zmodyfikuj zawar-tość pliku /etc/passwd, a w miejsce hasła wpisz gwiazdkę. Dzięki temu nikt nie będzie mógł dostać się do systemu przez konto ftp.
2. Jeśli podczas zakładania konta nie został utworzony katalog domowy użyt-kownika ftp, załóż go (może to być na przykład katalog /usr/ftp); katalog ten powinien być używany tylko przez użytkownika ftp.
3. Właścicielem katalogu domowego użytkownika ftp powinien być root, więc wydaj polecenie:
chown root /usr/ftp
4. Zabezpiecz katalog domowy użytkownika ftp przed zapisem wydając polecenie:
chmod ugo-w /usr/ftp
5. Utwórz w katalogu ftp podkatalog bin:
mkdir ~ftp/bin
6. Właścicielem podkatalogu bin również powinien być root; należy także za-bezpieczyć go przed zapisem:
chown root ~ftp/bin
chmod ugo-w ~ftp/bin
7. Skopiuj do podkatalogu bin polecenie ls (i inne polecenia, które chcesz udo-stępnić anonimowym użytkownikom):
cp /bin/ls ~ftp/bin
8. Utwórz podkatalog etc; powinien on być zabezpieczony przed zapisem, a jego właścicielem powinien być użytkownik root:
mkdir ~ftp/etc
chown root ~ftp/etc
chmod ugo-w ~ftp/etc
9. Skopiuj do katalogu ~ftp/etc pliki /etc/passwd i /etc/group. Następnie z utworzonych kopii usuń wszystkie wpisy oprócz tych dotyczących użytkownika ftp (a przynajmniej usuń wszystkie hasła innych użytkowników i zastąp je gwiazdką).
10. Utwórz podkatalog ~ftp/pub/incoming; jego właścicielem powinien być użytkownik root. Następnie wydaj polecenie zezwalające użytkownikowi ftp na zapis do tego katalogu:
mkdir ~ftp/pub/incoming
chown root ~ftp/pub/incoming
chmod ugo+w ~ftp/pub/incoming
11. Wszystkie pliki, które chcesz udostępnić, umieść w podkatalogu pub katalogu domowego użytkownika ftp. Dzięki temu anonimowi użytkownicy FTP będą mogli je pobrać. Zezwolenie użytkownikom na zapisywanie plików w tym ka-talogu nie jest pożądane, powinieneś więc odebrać wszystkim prawo zapisu albo często sprawdzać, czy nikt nie uszkodził plików. Jeśli przy konfigurowaniu anonimowego dostępu do FTP przestrzegałeś powyższych wskazówek (dostosowując je do potrzeb swojego systemu), Twój węzeł FTP jest względnie bezpieczny.

Konfiguracja węzła WAIS
WAIS (ang. Wide Area Information Service) to narzędzie obsługiwane za pośrednic-twem systemu menu, pozwalające na wyszukiwanie słów kluczowych w bazach da-nych o dokumentach dostępnych w systemie. Program WAIS został opracowany w firmie Thinking Machines, ale jak tylko zdobył popularność, zajęła się nim specjalnie w tym celu założona firma WAIS Incorporated. Jego darmowa wersja, znana pod na-zwą freeWAIS została udostępniona instytucji Clearinghouse for Networking Informa-tion Discovery and Retrieval (CNDIR) - i jest to wersja najczęściej spotykana w syste-mach linuxowych. WAIS pozwala na wyszukiwanie wprowadzonych przez użytkownika słów kluczowych czy nawet zdań w bazach danych. Po przeszukaniu wszystkich dostępnych indeksów baz danych, WAIS przedstawia wyniki poszukiwań Dane generowane przez program WAIS, wyświetlane w przeglądarce WAIS lub przeglądarce WWW, zawierają listę wszystkich dokumentów spełniają-cych kryteria wyszukiwania, wraz z punktacją od 0 do 1000, pozwalającą użytkownikowi ocenić, jak dobrze każdy z dokumentów spełnia zadane kryteria (im lepiej, tym więcej punktów). Po zakończeniu wyszukiwania można zdefiniować nowe kryteria lub przejrzeć znale-zione dokumenty. WAIS potrafi obsłużyć wiele formatów plików, włączając w to do-kumenty tekstowe, pliki audio, grafiki w formacie GIF i JPEG, a także pliki binarne. Najczęściej używaną w systemach linuxowych wersją programu WAIS jest freeWAIS. Pokażemy, jak można skonfigurować komputer linuxowy jako serwer WAIS. Warto rozważyć umożliwienie korzystania z takiej usługi szczególnie wtedy, gdy chcesz udo-stępnić innym użytkownikom większą ilość informacji - mogą to być informacje o produktach, o Twoim hobby czy dane praktycznie każdego innego typu, o ile chcesz udostępnić je innym użytkownikom sieci lokalnej lub Internetu. Pakiet freeWAIS składa się z trzech części: programu indeksującego dokumenty, ser-wera WAIS oraz programu klienta. Program indeksujący służy do generowania baz danych, zawierających indeksy, składające się ze słów kluczowych i tabeli ich wystą-pień w dokumentach. Serwer zapewnia obsługę zapytań użytkownika na podstawie plików z indeksami. Program klienta umożliwia użytkownikowi dostęp do systemu WAIS - jest to zwykle przeglądarka WAIS lub WWW. Przeglądarki WWW mają tę przewagę nad przeglądarkami WAIS, że prócz stron WAIS potrafią również wyświetlać dokumenty HTML. Następcą programu WAIS jest program ZDIST (kompatybilny ze swym poprzednikiem). Zachowuje się on bardzo podobnie do programu WAIS; wszystkie zmiany są opisane w dokumentacji. ZDIST ma kilka nowych cech, jest również nieco mniejszy i szybszy niż freeWAIS. Ponieważ jest jednak wciąż w fazie testów, skoncentrujemy się na programie freeWAIS.
Kompilowanie i instalacja programu freeWAIS
Program freeWAIS jest często dołączany do pełnych dystrybucji Linuxa, ale jest rów-nież dostępny w wielu węzłach FTP i BBS. Można go także załadować łącząc się z ad-resem http://ls6-www.informatik.uni-dortmund.de/ir/projects/freeWAIS-sf/index.html. W węźle tym dostępne są zarówno pliki wykonywalne przeznaczone dla różnych komputerów, jak i kod źródło-wy, który może być dostosowany do potrzeb wielu systemów. Jednym z plików wchodzących w skład dystrybucji tego programu jest plik Makefile, ułatwiający kompilację programu, który powinien znaleźć się w katalogu docelowym. Jeśli kompilujesz kod źródłowy samodzielnie, powinieneś upewnić się, że wszystkie zmienne definiowane w pliku Makefile mają poprawne wartości. W większości przy-padków wskazują one na standardowe programy użytkowe - wtedy nie trzeba ich modyfikować. Poniżej przedstawiamy kilka zmiennych, których modyfikacja może okazać się niezbędna:
CC    nazwa dostępnego w systemie kompilatora C (zwykle cc lub gcc);
CURSELIB    wartość odpowiadająca wersji biblioteki curses używanej w systemie;
TOP    pełna ścieżka dostępu do katalogu zawierającego kod źródłowy programu WAIS.
Znaczniki wyszczególnione w zmiennej CFLAGS pozwalają na określenie zachowania kompilatora. Dostępnych jest wiele znaczników - większość z nich jest opisana w do-kumentacji rozprowadzanej wraz z kodem źródłowym. W większości systemów linu-xowych wystarcza pozostawienie wartości domyślnych. Warto jednak wspomnieć o znaczeniu kilku z nich, ponieważ możesz chcieć zmienić ich wartość. Najistotniejsze są znaczniki dotyczące programu indeksującego - w praktyce przydatne mogą być dwa z nich:
-DBIO     pozwala indeksować symbole i terminy biologiczne - znacznik ten powinien być używany tylko wtedy, gdy w Twoim węźle udostępniane są materiały z dziedziny bio-logii;
-DBOOLEANS    pozwala używać operatorów logicznych AND (iloczyn) i NOT (negacja), dzięki czemu możliwe jest bardziej precy-zyjne określanie kryteriów wyszukiwania.
Znacznik -DBOOLEANS umożliwia używanie operatorów logicznych przy podawaniu kryteriów wyszukiwania. Jeśli na przykład szukasz słów kluczowych "zielony las", WAIS domyślnie będzie szukał każdego ze słów oddzielnie, niezależnie również przy-znając punkty. Jeżeli przy kompilacji aktywny będzie znacznik -DBOOLEANS, będzie można poszukać dokumentów, w których oba słowa występują jednocześnie, używa-jąc operatora AND (iloczyn logiczny). Oto kilka innych znaczników, które mogą być przydatne do określania zachowania się systemu WAIS jako całości:
-DBIGINDEX    powinien być ustawiany tylko wtedy, jeśli w węźle udostępnianych jest dużo (tysiące) dokumentów;
-DLITERAL    pozwala na wyszukiwanie całych tekstów, za-miast wyszukiwania wystąpień pojedynczych wy-razów wchodzących w skład tekstu;
-DPARTIALWORD    umożliwia używanie gwiazdki jako symbolu wie-loznacznego (na przykład auto*);
-DRELEVANCE_FEEDBACK    jeśli znacznik ten jest ustawiony na ON, użytkownik może wykorzystać wyniki poprzed-niego wyszukiwania jako nowe kryteria wyszuki-wania - taka możliwość jest dość przydatna w praktyce.
Zawartość pakietu freeWAIS jest rozrzucona po wielu katalogach; przeznaczenie większości z nich jest oczywiste (w katalogu bin znajdują się pliki wykonywalne, w katalogu man - strony man itd.). Katalogi używane przez program freeWAIS w do-myślnej konfiguracji to:
bin pliki wykonywalne;
config.c    pliki źródłowe w języku C, służące do konfiguracji;
doc    pliki zawierające dokumentację i odpowiedzi na często zadawane pytania;
include    pliki nagłówkowe, używane przez kompilator;
lib    pliki bibliotek;
man    strony man;
Src    kod źródłowy programu freeWAIS;
Wais-Sources    katalog serwerów internetowych;
Wais-Test    przykładowe skrypty programu indeksującego.
Po wprowadzeniu odpowiednich poprawek do pliku konfiguracyjnego można skom-plować program freeWAIS, wydając polecenie:
make linux
Domyślnie program make generuje dwa programy klienta: swais i waisq. Jeśli chcesz skompilować wersję przeznaczoną do pracy w systemie X Window o nazwie xwais (przydatną, jeśli chcesz umożliwić dostęp z terminali X lub konsol), usuń z pliku Make-file znacznik komentarza w wierszu, który kończy się tekstem makex.
Konfigurowanie programu freeWAIS
Po prawidłowym skompilowaniu i zainstalowaniu programu freeWAIS można przy-stąpić do indeksowania zgromadzonych w systemie dokumentów. Zwykle w tym celu tworzony jest nowy katalog, o nazwie wsindex. Często umieszcza się go w katalogu głównym (/wsindex), ale wielu administratorów woli przechowywać go w jakimś in-nym, wydzielonym miejscu (na przykład /usr/wais/wsindex). Należy wziąć pod uwagę fakt, że jeśli pliki z indeksami będą trudne do zlokalizowania, użytkownicy mo-gą mieć problemy z ich odszukaniem. Katalog wais-test, tworzony podczas instalacji programu freeWAIS, zawiera skrypt o nazwie test.waisindex, który umożliwia automatyczne wygenerowanie czterech plików indeksowych. Są one używane do sprawdzenia, czy program freeWAIS działa poprawnie, demonstrują również różne możliwości indeksowania i wyszukiwania. Wspomniane pliki to:
test-BOOL    indeks trzech przykładowych dokumentów, używający wyra-żeń logicznych i synonimów;
test-COMP    indeks demonstrujący obsługę skompresowanych plików źró-dłowych;
test-Docs    indeks plików znajdujących się w katalogu doc, demonstrują-cy możliwość rekursywnego przeszukiwania katalogów;
test-Multi    indeks grafik w formacie GIF z możliwością obsługi wielu do-kumentów.
Ostatni z czterech plików indeksowych jest poprawnie obsługiwany tylko w wersji opartej na interfejsie X, ale pozostałe trzy powinny działać poprawnie z każdą wersją prze-glądarki. Po upewnieniu się, że system indeksowania działa poprawnie, i że wszystkie składniki pakietu freeWAIS zostały prawidłowo zainstalowane, należy utworzyć indeks doku-mentów dostępnych w systemie. Można to zrobić na dwa sposoby, używając polecenia waisindex z opcją -t i jednym z poniższych słów kluczowych:
one_line    indeksowanie każdego wiersza dokumentu, pozwalające na dostarczanie dokładniejszej informacji co do miejsca wystąpienia szukanego słowa;
text    indeksowanie całych dokumentów, przez co w przeglądarce pojawia się tylko nazwa dokumentu, w którym występuje szukany wyraz. Polecenie waisindex pozwala również na podanie nazwy pliku z indeksami, który należy wygenerować (opcja -d, po której następuje nazwa pliku) oraz katalogów lub pli-ków, które mają zostać poindeksowane. Przykładowo, jeśli chcesz utworzyć indeks dla plików znajdujących się w katalogu /usr/sales/sales-lit i zachować go w pliku o nazwie sales, indeksując każdy wiersz dokumentu osobno, powinieneś wydać polecenie:
waisindex -d sales -t one_line /usr/sales/sales_lit
Ponieważ nie jest podana pełna ścieżka dostępu do generowanego pliku indeksu, zo-stanie on utworzony w katalogu bieżącym. Po uruchomieniu serwera WAIS (patrz podrozdział "Uruchamianie serwera freeWA-IS"), możesz przetestować pliki indeksów wydając polecenie waissearch. Aby na przykład znaleźć w pliku z indeksami tekst "WAIS", wydaj polecenie:
waissearch -p 210 -d plik_indeksowy WAIS
Opcja -p pozwala na podanie numeru portu TCP (domyślnie 210), natomiast opcja -d służy do poinformowania programu waissearch o położeniu pliku indeksowego. Jeśli przeszukiwanie zakończy się pomyślnie (tzn. zostanie odnaleziony co najmniej jeden plik spełniający zadane kryteria), wyświetlona zostanie informacja o liczbie zwróco-nych rekordów i punktacji przyznanej każdemu ze znalezionych dokumentów. Jeśli nie otrzymałeś żadnych komunikatów lub otrzymałeś komunikat o błędzie, powinieneś sprawdzić, czy do plików konfiguracyjnych wprowadzone zostały prawidłowe infor-macje i czy plik indeksowy został wygenerowany poprawnie. Ostatnim krokiem, wymaganym dla zapewnienia dostępu do pliku indeksowego użyt-kownikom Internetu, jest wydanie polecenia:
waisindex -export -register nazwy_plikow
gdzie nazwy_plikow to nazwy plików indeksowych. Polecenie to powoduje zareje-strowanie indeksów w katalogu serwerów przechowywanym w systemach cndir.org oraz quake.think.com. Połączenie z tymi serwerami następuje automatycznie po podaniu opcji -register. Powyższe polecenie należy wydać tylko wtedy, gdy wszy-scy użytkownicy Internetu mają mieć dostęp do zasobów zgromadzonych w systemie (wkrótce przyjrzymy się poleceniu waisindex nieco bardziej szczegółowo). Jeśli chcesz, by klienci mogli łączyć się z Twoim systemem freeWAIS za pomocą przeglądarek WWW takich jak Netscape czy Mosaic, musisz również wydać polecenie:
waisindex -d WWW -T HTML -contents -export /usr/resources/*.html
Zamiast /usr/resources/ powinieneś podstawić ścieżkę dostępu do plików HTML zebranych w systemie. Powyższe polecenie pozwala klientom WAIS na wyszukiwanie słów kluczowych również w dokumentach HTML. Jeśli chcesz, możesz skonfigurować system freeWAIS tak, by dostęp do niego był moż-liwy tylko z pewnych domen. Odpowiada za to wpis w pliku ir.h, o następującej po-staci:
#define SERVSECURITYFILE "SERV_SEC"
Kopię istniejącego pliku SERV_SEC lub plik stworzony własnoręcznie musisz umieścić w tym samym katalogu, w którym znajdują się pliki indeksowe. Jeśli WAIS nie odnaj-dzie pliku SERV_SEC, pozwoli na dostęp z dowolnej domeny (nazwę tego pliku można zmienić, pod warunkiem, że będzie ona taka sama jak nazwa podana w cudzysłowie w pliku ir.h). Każdy wpis w pliku SERV_SEC definiuje domenę, z której dostęp ma być możliwy. Wpisy te mają format:
domena [adres IP]
W każdym wierszu musi znajdować się nazwa domenowa komputera, któremu chcesz umożliwić dostęp; opcjonalnie można również podać jego adres IP. Jeśli adres IP i na-zwa domenowa nie zgadzają się, nie ma to znaczenia, ponieważ WAIS przyznaje do-stęp nawet wtedy, gdy zgadza się tylko nazwa lub tylko adres IP. Oto przykładowa zawartość pliku SERV_SEC:
chatton.com
roy.sailing.org
bighost.bignet.com
Każdy z wymienionych powyżej serwerów ma dostęp do systemu WAIS, natomiast żądania nadchodzące z dowolnych innych systemów nie zostaną obsłużone. Właścicielem pliku SERV_SEC powinien być użytkownik, który uruchamia program freeWAIS (ze względów bezpieczeństwa nie powinien być to użytkownik root), nato-miast prawo jego modyfikacji powinien mieć tylko administrator. Zmienna DATASECURITYFILE spełnia podobną rolę, jak zmienna SERVSECURITYFILE: pozwala zdefiniować nazwę pliku służącego do kontrolowania dostępu do baz danych. Wiersz definiujący tę zmienną w pliku ir.h ma postać
#define DATASECURITYFILE "DATA_SEC"
W pliku DATA_SEC znajduje się lista wszystkich baz danych wraz z informacją o tym, które systemy mogą mieć do nich dostęp. Również ten plik powinien zostać umiesz-czony w tym samym katalogu co pliki indeksowe. Wpisy w pliku DATA_SEC mają for-mat:
baza_danych domena [adres_IP]
baza_danych to nazwa bazy danych, do której odnosi się dany wpis, pola domena i adres_IP mają takie samo znaczenie jak w pliku SERV_SEC. Poniżej przedstawiamy przykładową zawartość pliku DATA_SEC:
primary chatton.com
primary bignet.org

primary roy.sailing.org

sailing roy.sailing.org W powyższym przykładzie trzy systemy otrzymały prawo dostępu do bazy danych przechowywanej w pliku o nazwie primary, ale tylko system roy.sailing.org ma dostęp do bazy danych o nazwie sailing. Jeśli chcesz zezwolić wszystkim systemom (wyszczególnionym w pliku SERV_SEC) na korzystanie z którejś z baz danych, możesz zamiast nazwy domenowej i adresu IP wpisać gwiazdki. Przykładowo, by zezwolić wszystkim mającym dostęp do systemu WAIS na korzystanie z bazy danych prima-ry, natomiast tylko systemowi roy.sailing.org na korzystanie z bazy o nazwie sailing, powinieneś do pliku DATA_SEC wprowadzić dane:
primary * *
sailing roy.sailing.org
Należy zachować ostrożność przy wprowadzaniu informacji do plików SERV_SEC i DATA_SEC, ponieważ pomyłka może spowodować przyznanie dostępu innym niż zamierzone systemom. Przykładowo, jeśli jako adres IP podasz 155.12, wszystkie syste-my o adresach zaczynających się od 155.12 (np. 15.121, 155.122 itp.) będą miały do-stęp do baz danych WAIS. Aby tego uniknąć, powinieneś podawać adresy IP bezpośrednio.
Uruchamianie serwera freeWAIS Podobnie jak miało to miejsce w przypadku serwera FTP, program obsługujący system freeWAIS może być uruchamiany z jednego ze skryptów rc przy starcie systemu, ale może również być wywoływany przez program inetd, gdy ktoś będzie próbował sko-rzystać z usługi WAIS. Jeśli chcesz, by system freeWAIS był uruchamiany z pliku rc, powinieneś wpisać do niego następujące polecenie:
waisserwer -u id_uzytkownika -p 210 -l 10 -d /usr/wais/wais_index
Opcja -u pozwala określić, który z użytkowników ma być właścicielem procesu wais-serwer (id_uzytkownika musi być prawidłowym identyfikatorem użytkownika, z odpowiednim wpisem w pliku /etc/passwd). Za pomocą opcji -p można podać nu-mer portu, którego należy używać (zwykle 210), natomiast opcja -d służy do infor-mowania programu waisserwer o położeniu plików indeksowych. Jeśli chcesz reje-strować informacje o przebiegu sesji do pliku, użyj opcji -e z nazwą pliku, do którego będą zapisywane informacje. Program waisserwer nie powinien być uruchamiany przez użytkownika root - uniemożliwi to wykorzystanie niedociągnięć tego programu przez hakerów. Jeśli wła-ścicielem procesu jest zwykły użytkownik (na przykład wais), w najgorszym przypad-ku zagrożone będą tylko pliki, których jest on właścicielem. Port 210 jest standardowo używany w Internecie do komunikacji z systemem WAIS. Inny numer portu można podać wtedy, gdy system konfigurowany jest wyłącznie z myślą o lokalnym dostępie do danych. Jeśli numer używanego portu jest mniejszy od 1023, usługa WAIS musi być uruchamiana i zarządzana przez użytkownika root. W przeciwnym przypadku może być ona obsłużona również przez zwykłego użytkowni-ka. Jeśli chcesz używać portu 210, nie musisz podawać w wierszu poleceń jego numeru, ale nadal należy podać opcję -p. Aby uruchamianiem programu waisserwer sterował proces inetd, w pliku /etc/services musi znajdować się odpowiedni wpis, na przykład:
z3955 210/tcp #WAIS
210 to numer portu, który jest używany przez system WAIS, natomiast tcp to nazwa wykorzystywanego protokołu. Po zmodyfikowaniu pliku /etc/services należy rów-nież poinformować program inetd o tym, że ma uruchamiać program waisserwer po wykryciu żądania przesyłanego do portu 210 (lub innego używanego w Twoim sys-temie); w tym celu w pliku inetd.conf musi znaleźć się wiersz (odpowiednie opcje są takie same, jak w przypadku wywoływania programu z wiersza poleceń):
z3955 stream tcp nowait root/usr/local/bin/waisserwer/waisserwer.d -u id_uzytkownika -d /usr/wais/wais_index
Zamiast programu waisserwer należy uruchomić program waisserwer.d, który jest przeznaczony do współpracy z programem inetd. Również w tym przypadku można użyć opcji -e do załączenia rejestrowania informacji o przebiegu sesji do pliku.
Tworzenie własnych indeksów dla programu WAIS
Jeśli skonfigurowałeś serwer freeWAIS i wszystko wydaje się działać prawidłowo, przyszła pora na dostarczenie systemowi WAIS jakichś użytecznych danych. Zwykle ich źródłem są dokumenty tekstowe, ale indeksować można pliki dowolnego typu. Najważniejszym krokiem jest utworzenie indeksu za pomocą programu waisindex. Program ten czasem zachowuje się niezgodnie z oczekiwaniami, ale odrobina praktyki i kilka prób pozwolą Ci go opanować. Program waisindex przegląda dane zawarte we wszystkich plikach, które mają zostać poindeksowane. Na ich podstawie generowanych jest zwykle siedem różnych plików indeksowych (zależnie od zawartości plików i wydanego polecenia). Każdy z tych pli-ków zawiera listę słów występujących w dokumentach. Pliki te są następnie łączone w jedną bazę danych, często nazywaną źródłem (lub źródłem WAIS, ang. WAIS source). Kiedy program klienta WAIS zamawia wyszukiwanie, podany przez użytkownika tekst jest porównywany ze źródłem i wyświetlane są wyniki porównania wraz z analizą do-kładności trafień (podawaną w postaci punktacji). Użycie plików indeksowych pozwala na znaczne skrócenie czasu wyszu-kiwania, ponieważ słowa kluczowe zostały wyszukane wcześniej. Ilość danych zawartych w plikach indeksowych może być jednak dość duża, dlatego powinieneś zapewnić serwerowi WAIS odpowiednio dużo miejsca na dysku (zwykle wystarcza dwa razy tyle, ile zajmuje samo źródło).
Pliki indeksowe programu WAIS
Pliki indeksowe programu WAIS nie nadają się (może poza dwoma wyjątkami) do bezpośredniego przeglądania przez użytkownika. Zwykle program waisindex generu-je siedem takich plików, choć ich liczba może być inna w zależności od wymagań. Każdy z plików indeksowych ma nazwę składającą się z dwóch członów: pierwszy z nich jest wspólny (można go podać w wierszu poleceń przy wywoływaniu programu waisindex; jeśli nie zostanie podany, domyślnie przyjmowana jest nazwa index), drugim jest rozszerzenie nazwy pliku, wskazujące na jego zastosowanie. Poniżej przed-stawiamy domyślne nazwy plików indeksowych i ich zastosowanie.
index.doc Dokument zawierający tabelę, na którą składają się: nazwa pli-ku, nagłówek (tytuł) pliku, pozycje pierwszych i ostatnich zna-ków wpisu, długość dokumentu, liczba wierszy dokumentu, oraz data i czas jego utworzenia.
index.dct Plik zawierający słownik, czyli listę wszystkich słów (bez powtó-rzeń) w indeksowanych plikach, wraz z odniesieniami do odpo-wiednich danych w pliku index.inv.
index.fn Plik, który zawiera tabelę z nazwami plików, datami utworzenia indeksów, oraz danymi o typach plików.
index.hl Plik zawierający tabelę nagłówków (tytułów) indeksowanych dokumentów. Nagłówki te są wyświetlane wraz z wynikami wyszukiwania.
index.inv Plik zawierający tabelę wiążącą każde słowo we wszystkich do-kumentach z wskaźnikami do tych dokumentów i wagą danego słowa (określoną przez jego odległość od początku pliku, liczbę wystąpień i procentową częstość występowania).
index.src Plik opisu źródła, który zawiera informacje o indeksowanych dokumentach, takie jak nazwa serwera, jego numer IP, numer portu używanego przez WAIS, nazwa pliku źródła, informacja o ewentualnym koszcie usługi, nagłówek, opis pliku źródła oraz adres e-mailowy administratora. Plik ten można edytować za pomocą dowolnego edytora tekstów. Wkrótce omówimy go nie-co bardziej szczegółowo.
index.status Plik statusu, zawierający informacje definiowane przez użyt-kownika.
Plik opisu źródła (który jest zwykłym plikiem ASCII) jest co pewien czas odczytywany przez program waisindex, który sprawdza w ten sposób, czy źródło zostało zmodyfi-kowane. Jeśli zmiany są znaczące, waisindex aktualizuje przechowywane wewnętrz-nie informacje. Oto przykładowy plik opisu źródła:
(:source
:version 2
:ip-address "147.120.0.10"
:ip-name "wizard.tpci.com"
:tcp-port 210
:database-name "Linux stuff"
:cost 0.00
:cost-unit free
:maintainer "wais_help@tpci.com"
:subjects "Everything you need to know about Linux"
:description "If you need to know something about Linux, it's here."
Zawartość tego pliku należy zmodyfikować podczas konfigurowania systemu free-WAIS, ponieważ dane domyślne nie są użyteczne.
Polecenie waisindex
Polecenie waisindex umożliwia podanie wielu różnych opcji - kilka z nich omówili-śmy we wcześniejszej części tego rozdziału. Oto lista najważniejszych opcji tego pro-gramu:
-a    umożliwia dołączenie nowych danych do istniejącego pliku in-deksowego (opcja używana do uaktualniania indeksów zamiast ich ponownego tworzenia za każdym razem, gdy udostępniany jest nowy dokument);
-contents    powoduje indeksowanie zawartości pliku (zachowanie domyślne);
-d     pozwala określić pierwszy człon nazwy plików indeksowych (na przykład podanie parametrów -d /usr/wais/nic spowoduje, że wszystkie pliki indeksowe znajdą się w katalogu /usr/wais, a ich nazwy będą się zaczynać od słowa nic);
-e    pozwala podać nazwę pliku, w którym rejestrowane będą infor-macje o błędach (domyślnie jest to stderr - czyli standardowe urządzenie rejestrujące komunikaty o błędach, zwykle konsola; można również podać opcję -s, powodującą wysyłanie komuni-katów do urządzenia /dev/null);
-export    powoduje dołączenie do pliku opisu nazwy serwera i numeru por-tu TCP, co ułatwia dostęp poprzez Internet;
-l    pozwala określić, jakie informacje mają być rejestrowane; do-stępne wartości to:
0    nie są rejestrowane żadne informacje,
1    rejestrowanie najważniejszych ostrzeżeń i informacji o błę-dach,
5    rejestrowanie mniej istotnych błędów i ostrzeżeń oraz nazw plików indeksowych,
10    rejestrowanie wszystkich informacji;
-M    umożliwia dołączanie plików różnych typów;
-mem    ogranicza zużycie pamięci podczas indeksowania (im wyższa liczba zostanie podana, tym szybszy będzie proces indeksowania, ale potrzebował będzie również więcej pamięci);
-nocontents    zapobiega indeksowaniu zawartości dokumentu (indeksowana jest wtedy tylko jego nazwa i nagłówek);
-nopairs    powoduje, że sąsiednie wyrazy napisane wielkimi literami nie są indeksowane wspólnie;
-nopos    powoduje ignorowanie pozycji słowa kluczowego w dokumencie przy obliczaniu punktacji;
-pairs    powoduje, że sąsiednie wyrazy napisane wielkimi literami będą indeksowane jako jedna całość;
-pos    powoduje obliczanie punktacji na podstawie położenia słów klu-czowych (jeśli słowa położone są blisko, punktacja jest większa);
-r    rekursywne indeksowanie dokumentów w podkatalogach;
-register    rejestracja indeksu WAIS w internetowej bazie WAIS Directory of Services;
-stdin    powoduje użycie nazwy pliku wprowadzonej z klawiatury, za-miast z wiersza poleceń;
-stop    pozwala na podanie nazwy pliku zawierającego słowa zbyt popu-larne, by je indeksować, zwykle zdefiniowanej w pliku /src/ir/ stoplist.c;
-t    znacznik typu danych w plikach;
-T    ustawienie żądanego typu danych.
Jeśli program waisindex nie otrzyma informacji o typie danych zapisanych w plikach, może nie być w stanie wygenerować poprawnego indeksu. Listę obsługiwanych przez freeWAIS typów plików możesz zobaczyć wpisując polecenie waisindex bez argu-mentów:
waisindex
Zwykle używa się tylko kilku spośród tych typów. Poniżej przedstawiamy listę najpopularniejszych z nich.
filename    To samo, co zwykły plik tekstowy (text), ale jako nagłówek używana jest nazwa
. first_line    To samo, co zwykły plik tekstowy (text), ale jako nagłówek używany jest pierwszy wiersz pliku.
ftp    Pliki zawierające kody FTP, które mogą zostać wykorzystane przez użytkowników do ładowania informacji z innych komputerów.
GIF    Grafika w formacie GIF (jeden obrazek odpowiada jednemu plikowi). Jako nagłówek używana jest nazwa pliku.
mail lub rmail    Indeksowanie zawartości skrzynki pocztowej mbox - jedna wiadomość odpowiada jednemu dokumentowi.
mail_digest    Standardowa poczta elektroniczna - indeksowanie poszcze-gólnych wiadomości. Jako nagłówek używane jest pole tematu (ang. subject).
netnews    Artykuły pochodzące z grup dyskusyjnych, indeksowane pojedynczo. Jako nagłówek używane jest pole tematu. one_line    Indywidualne indeksowanie każdego zdania w dokumencie.
PICT    Grafika w formacie PICT (jeden obrazek odpowiada jednemu plikowi). Jako nagłówek używana jest nazwa pliku.
ps    Plik postscriptowy (jeden dokument odpowiada jednemu plikowi).
text    Indeksowanie pliku jako jednego dokumentu. Jako nagłówek używana jest ścieżka dostępu do pliku.
TIFF    Grafika w formacie TIFF (jeden obrazek odpowiada jednemu plikowi). Jako nagłówek używana jest nazwa pliku.
Aby poinformować program waisindex o tym, jakiego typu pliki ma indeksować, na-leży podać opcję -t, po której następuje nazwa odpowiedniego typu plików. Przykła-dowo, jeśli indeksujesz standardowe pliki ASCII, możesz wydać polecenie:
waisindex -t text -r /usr/waisdata/*
Polecenie to spowoduje utworzenie indeksu dla wszystkich plików w katalogu /usr/waisdata i jego podkatalogach (opcja -r), przy założeniu, że są one plikami ASCII. Po zakończeniu procesu indeksowania wszelkie zmiany w dokumencie nie są uwzględniane w indeksie aż do ponownego przeprowadzenia pełnego indeksowania. Użycie opcji -a nie uaktualnia istniejących w indeksie da-nych. Zamiast tego powinieneś więc przeprowadzić proces indeksowania od nowa - warto robić to regularnie.
Inne możliwości systemu WAIS
Usługa freeWAIS udostępniana w systemie może zostać wzbogacona na wiele sposo-bów. W tym podrozdziale - który na pewno nie wyczerpuje tematu - przedstawimy dwa proste w implementacji sposoby uatrakcyjnienia węzła WAIS. Na początek załóżmy, że udostępniasz animacje, grafiki czy pliki dźwiękowe na jakiś określony temat - na przykład materiały o instrumentach muzycznych - i posiadasz kilka dokumentów o skrzypcach. Możesz wówczas chcieć udostępnić próbkę dźwięku skrzypiec, animację na ich temat czy zdjęcie skrzypiec Stradivariusa. W tym celu wszystkie pliki zawierające te dane powinny mieć nazwy o wspólnym rdzeniu, różniące się tylko rozszerzeniem. Przykładowo, jeśli główny dokument o skrzypcach nazywa się skrzypce.txt, w katalogach WAIS mogą znajdować się następujące pliki:
skrzypce.TEXT dokument opisujący skrzypce,
skrzypce.TIFF zdjęcie skrzypiec Stradivariusa,
skrzypce.MPEG animacja przedstawiająca proces budowania skrzypiec,
skrzypce.MIDI plik MIDI zawierający jakiś słynny utwór na skrzypce.
Wszystkie powyższe pliki powinny mieć taki sam rdzeń nazwy (skrzypce), ale różnić się typem (rozpoznawanym przez program waisindex). Następnie należy powiązać pliki multimedialne z dokumentem tekstowym. Można to zrobić wydając polecenie:
waisindex -d skrzypce -M TEXT,TIFF,MPEG,MIDI -export
ĺ /usr/waisdata/skrzypce/*
Spowoduje ono, że program waisindex obsłuży wszystkie cztery typy plików. Użyt-kownik szukający słowa kluczowego "skrzypce" otrzyma informację o wszystkich czterech plikach, a przeglądarka pozwoli mu obejrzeć czy odsłuchać odpowiednie pliki. Innym często spotykanym rozwiązaniem jest umożliwienie odnalezienia danego do-kumentu po podaniu kilku różnych słów kluczowych - mogą to być synonimy, na przykład znalezienie dokumentu o oferowanych przez firmę przewodach połączenio-wych powinno być możliwe zarówno po podaniu słowa "kable" jak i "przewody". Do tego celu przeznaczony jest plik o nazwie SOURCE.syn, odczytywany automatycznie podczas pracy programu wyszukującego dane. Wiersze tego pliku mają format:
słowo synonim [synonim …]
słowo to ciąg znaków, który będzie użyty do wyszukania informacji w bazie danych, natomiast synonim to inny ciąg znaków, po podaniu którego użytkownik powinien otrzymać takie same rezultaty. Przykładowo, jeśli w Twoim węźle WAIS udostępniasz informacje o zwierzętach domowych, zawartość pliku SOURCE.syn może być następu-jąca:
pies    wilczur owczarek chart buldog terier
ptak    papuga papużka nimfa kanarek
ryba    skalar gupik sum pielęgnica glonojad
Plik zawierający synonimy przydaje się, gdy użytkownicy stosują różne określenia ma-jąc na myśli ten sam temat. Możesz łatwo sprawdzić, czy jest on potrzebny w Twoim systemie - wystarczy, że na jakiś czas ustawisz poziom rejestracji zdarzeń programu waisindex na 10, a następnie przejrzysz wygenerowany plik - od razu zorientujesz się, jakie wyrażenia są stosowane przez użytkowników korzystających z Twojego wę-zła, dzięki czemu będziesz mógł dostosować odpowiednio dane zapisane w pliku SOURCE.syn. Rejestracja zdarzeń nie powinna być załączona przez zbyt długi czas, ponieważ pliki zawierające rejestrowane dane szybko stają się bardzo duże.

Konfigurowanie usługi Gopher
Gopher to jedna z bardziej przydatnych usług internetowych, używana zarówno przez początkujących, jak i doświadczonych użytkowników. Jest to oparty na interfejsie tek-stowym system wyszukiwania plików, który umożliwia użytkownikowi odszukanie in-teresujących danych za pomocą hierarchicznego systemu menu. Konfiguracja węzła Gopher sprowadza się do uruchomienia oprogramowania obsługi serwera i utworzenia pewnej liczby katalogów zawierających pliki indeksowane przez system Gopher. Działanie systemu Gopher polega na tym, że program klienta (uruchamiany przez użytkownika) łączy się z serwerem usługi Gopher i otrzymuje informacje o plikach do-stępnych w Internecie (albo w sieci lokalnej, jeśli działanie serwera jest ograniczone tylko do takiego obszaru). Pod koniec roku 1995 w Internecie działało około 6000 serwerów usługi Gopher, dostępnych dla każdego, kto posiadał odpowiedni program klienta. Choć liczba ta nieco się zmniejszyła (głównie z powodu rozpowszechnienia się stron WWW), w sieci wciąż działa mnóstwo węzłów udostępniających usługę Gopher. Serwery te zawierają informacje o ponad 10 milionach elementów, wśród których są najróżniejsze pliki, od dokumentów tekstowych do filmów, dźwięków czy grafik i róż-nego rodzaju plików wykonywalnych. Gopher pozwala użytkownikowi na przegląda-nie i manipulowanie listami plików, dzięki czemu możliwe jest łatwe odnalezienie inte-resujących materiałów. Jeśli chcesz łączyć się z serwerem usługi Gopher (osobiście, lub też chce to robić któryś z użytkowników Twojego systemu), będziesz potrzebował oprogramowania klienta Gopher. Niektóre programy tego typu rozprowadzane są wraz z dystrybucjami Linuxa, inne dostępne są w węzłach FTP, BBS i z innych źródeł. Jeśli nie chcesz pozwolić użyt-kownikom swojego systemu na uruchamianie klienta Gopher, możesz za pomocą pro-gramu Telnet połączyć się z serwerem umożliwiającym anonimowemu użytkownikowi dostęp do klienta Gopher. Większość pakietów umożliwiających dostęp do usługi Gopher pozwala również korzystać z systemu WAIS, FTP, a także w pewnym stopniu współpracuje z przeglądarkami WWW. Omówimy konfigurowanie serwera usługi Gopher, pozwalającego użytkownikom na dostęp do danych o plikach zgromadzonych w Twoim systemie. Nie będziemy oma-wiać problemów związanych z utworzeniem odpowiedniej (ułatwiającej poszukiwania) struktury udostępnianych danych, skoncentrujemy się tylko na konfiguracji oprogra-mowania.
Gopher i Linux
Obecnie dostępne są dwie wersje systemu Gopher przeznaczone do pracy w systemie Linux: Gopher i Gopher+ (Gopher Plus). Gopher jest systemem dostępnym za darmo, natomiast Gopher+ to produkt komercyjny. Różnią się one funkcjonalnością - jeśli za-leży Ci na możliwościach, jakie daje Gopher+, możesz rozważyć zakup tego programu. Gopher+ przewyższa system Gopher pod kilkoma względami:
- udostępnia rozszerzone informacje o pliku,
- umożliwia odczytanie opisu pliku,
- pozwala na jednoczesne ładowanie kilku wersji pliku (na przykład dokumen-tacji w formacie ASCII i postscriptowym),
- umożliwia ładowanie plików w oparciu o kryteria wyszukiwania definiowane przez użytkownika.
Gopher+ jest kompatybilny z systemem Gopher, ale Gopher nie potrafi korzystać z możliwości udostępnianych przez system Gopher+. Oba systemy współpracują z przeglądarkami WWW. Koszt zainstalowania systemu Gopher+ wynosi od 100 do 500 dolarów, zależnie od przeznaczenia węzła. Wersje systemu Gopher przeznaczone dla Linuxa pochodzą z dwóch źródeł. Uniwersy-tet w Minnesocie opracował systemy Gopher i Gopher+, a system Gopher dostępny jest również jako GN Public License Gopher. Najnowsza dostępna za darmo wersja syste-mu Gopher opracowana w UM ma numer 1.3 (wersja 2.13 jest darmowa tylko dla in-stytucji edukacyjnych), ale uniwersytet ten porzucił prace nad doskonaleniem wersji darmowej, koncentrując się na komercyjnym produkcie Gopher+. GN Public License Gopher zawiera również usługę WWW; niestety obecnie nie jest jeszcze w pełni funk-cjonalny. Gopher bazuje na jednym z protokołów rodziny TCP/IP, nazywanym (co za niespo-dzianka) protokołem Gopher. Jest to dość prosty protokół oparty na seriach zapytań i odpowiedzi, zaimplementowany ze zwróceniem uwagi na prędkość działania. Gopher przesyła informacje o plikach (nazywaną plikiem menu systemu Gopher) w następującym formacie:
< typ > < nazwa_widoku > < selektor > < serwer > < port>
Poszczególne pola mają następujące znaczenie:
typ   jednoznakowy identyfikator typu pliku (za chwilę przedstawimy listę wszystkich wartości, które mogą zostać użyte w tym polu);
nazwa_widoku   nazwa menu lub widoku, po której następuje znak tabulacji;
selektor   unikalny (w obrębie serwera) identyfikator dokumentu, zwykle oparty na nazwie pliku, po którym następuje znak tabulacji;
serwer   nazwa serwera, w którym przechowywany jest dokument, po której również musi wystąpić znak tabulacji;
port    numer portu, przez który należy łączyć się z serwerem. Po numerze portu (zwykle 70) przesyłane są znaki powrotu karetki i nowego wiersza.
Wersja Gopher+ przesyła jeszcze kilka dodatkowych danych, takich jak identyfikator administratora odpowiedzialnego za obsługę systemu Gopher, krótki opis typu doku-mentu (na przykład text), język, w jakim jest napisany dokument, datę ostatniej modyfikacji i rozmiar w bajtach. Kiedy użytkownik zdecyduje się na pobranie któregoś z plików, do nawiązania połą-czenia wykorzystywane są informacje o nazwie serwera i numerze portu, natomiast se-lektor pozwala na zidentyfikowanie pliku, który ma zostać przesłany.
Gopher obsługuje kilkanaście typów plików, oznaczanych jednoznakowymi kodami. Oto ich lista:
0    plik tekstowy;
1    katalog;
2    serwer książki telefonicznej CSO (nazwa serwera określa komputer, z którym należy się połączyć, natomiast selektor w tym przypadku po-zostawiany jest pusty);
3    błąd;
4    plik typu BinHex systemu Macintosh;
5    archiwum binarne systemu DOS;
6    archiwum UNIX-owe, zakodowane programem uuencode;
7    serwer przeszukiwania indeksu;
8    wskaźnik do tekstowej sesji programu Telnet (nazwa serwera określa komputer, z którym należy się połączyć, a selektor zawiera identyfikator użytkownika);
9    plik binarny;
g    grafika w formacie GIF;
h    dokument HTML;
I    plik grafiki;
i    tekst wyświetlany w menu, pełniący funkcję separatora;
M    dokument poczty w standardzie MIME;
P    plik dokumentacji w formacie PDF firmy Adobe;
s    dźwięk;
T    wskaźnik do sesji programu Telnet 3270 (nazwa serwera określa kompu-ter, z którym należy się połączyć, a selektor zawiera identyfikator użyt-kownika);
System Gopher używa kilku innych programów, niezbędnych do prawidłowego działania; są to:
- tn3270 lub podobny emulator 3270 - używany przy połączeniach Telnet 3270;
- program komunikacyjny kermit lub zmodem, używany do ładowania pli-ków; odpowiednie pliki wykonywalne zwykle nazywają się kermit, sz, sb i sx;
- program graficzny - jeśli zezwolisz na wyświetlanie grafiki, niezbędny będzie program do jej obsługi, taki jak na przykład xv.
Powyższe wymagania można dostosować do własnych potrzeb, jeśli system działa tylko w sieci lokalnej, ale jeśli usługa ma być ogólnodostępna, wymienione programy powinny znaleźć się w Twoim systemie.
Konfigurowanie usługi Gopher
Instalowanie i konfiguracja systemu Gopher (lub Gopher+) wymaga zwykle ustawienia pewnych opcji konfiguracyjnych jeszcze przed przystąpieniem do kompilowania opro-gramowania (które zwykle jest rozprowadzane w postaci kodu źródłowego) i modyfi-kacji kilku standardowych plików. Konfiguracja systemu Gopher+ przebiega prawie dokładnie tak samo - trzeba tylko podać kilka dodatkowych informacji. Ponieważ w systemach linuxowych częściej używa się systemu Gopher, a nie Gopher+, właśnie na nim się skoncentrujemy. W tym podrozdziale nie będziemy używać pełnych ścieżek dostępu do plików, ponie-waż punkt zainstalowania oprogramowania obsługującego system Gopher nie ma żadnego znaczenia, o ile ścieżki przeszukiwania są odpowiednio skonfigurowane. Poza tym nie wyklarował się żaden standard co do rozmieszczenia katalogów, więc Ty rów-nież masz wolną rękę przy ich tworzeniu.
Plik gopherd.conf
Parametry konfiguracyjne systemu Gopher (i Gopher+) zapisane są w pliku gopherd.conf, odczytywanym przez program rezydentny gopherd. Wartości do-myślne tych parametrów zwykle wymagają niewielkich modyfikacji, ale większość z nich polega tylko na usunięciu lub dodaniu symbolu komentarza. Pierwszym krokiem konfiguracji jest utworzenie aliasu dla usługi Gopher w Twoim sys-temie. W pliku gopherd.conf powinien znajdować się wpis o następującej postaci:
hostalias: tpci
Alias ten jest potrzebny, aby serwer Gopher mógł zostać odnaleziony w danym syste-mie. Nie powinien on wskazywać na komputer bezpośrednio, dzięki czemu łatwiej bę-dzie wprowadzać zmiany w konfiguracji. Najlepszym rozwiązaniem jest utworzenie aliasu i powiązanie go z fizycznym komputerem za pomocą DNS. Jeśli Twój komputer nie działa w sieci, musisz użyć albo aliasu powiązanego z nazwą Twojego komputera, albo bezpośrednio nazwy komputera. Możliwe jest również określenie maksymalnej dopuszczalnej liczby jednoczesnych po-łączeń Gopher. Takie rozwiązanie okazuje się czasem niezbędne, aby uniknąć nad-miernego obciążania systemu. Liczba jednoczesnych połączeń zwykle zdefiniowana jest w pliku w katalogu określonym przez wartość zmiennej PIDS_Directory. Odpo-wiedni wiersz w pliku gopherd.conf jest zwykle zaznaczony jako komentarz, ponie-waż wcześniejsze wersje systemu nie obsługiwały poprawnie takiego ograniczenia. Jeśli chcesz skorzystać z tej możliwości, powinieneś upewnić się, że katalog wskazywany przez zmienną PIDS_Directory istnieje i zawiera odpowiednie dla Twojej wersji sys-temu Gopher pliki, a następnie usunąć symbol komentarza z wiersza
#PIDS_Directory: /pids
Lepszym sposobem kontrolowania obciążenia systemu jest użycie słowa kluczowego MaxConnections, które pozwala określić liczbę obsługiwanych równocześnie klientów. Aby dobrać odpowiednią wartość, zapewniającą równowagę pomiędzy obciążeniem systemu i wygodą użytkowników, musisz nieco poeksperymentować - dobrym punk-tem wyjścia dla systemów opartych o procesory 80486 czy Pentium jest ok. 15 - 25 użytkowników. Jeśli jednak równocześnie w systemie działa serwer WWW, liczba ta powinna być nieco mniejsza, co pozwoli ograniczyć zużycie zasobów systemu. Odpo-wiedni wpis w pliku konfiguracyjnym ma postać:
MaxConnections: 15
Jeśli liczba użytkowników zostanie przekroczona, przy próbie połączenia generowany będzie komunikat o błędzie. Można również skorzystać z możliwości oferowanych przez programy dekodujące. Używane są one wtedy, gdy użytkownik zleca załadowa-nie pliku, dodając do jego nazwy rozszerzenie (takie jak .Z, .zip czy .gz), które po-woduje przesłanie danych w postaci skompresowanej. Dekoder rozpoznaje przekaza-ne przez użytkownika rozszerzenie i wywołuje odpowiedni program użytkowy, dzięki czemu dane są przesyłane w żądanym formacie. W większości plików gopherd.conf znajdują się następujące wpisy:
decoder: .Z /usr/ucb/zcat
decoder: .gz /usr/gnu/bin/zcat
#decoder: .adpcm /usr/openwin/bin/adpcm_dec
#decoder: .z /usr/gnu/bin/zcat
Wpisy dotyczące dwóch ostatnich dekoderów są zaznaczone jako komentarz, ale można usunąć symbol #, jeśli chcesz umożliwić korzystanie z plików w formatach .adpcm i .z poprzez usługę Gopher. Możesz również dodać obsługę innych formatów plików, wpisując dane o odpowiednich dekoderach (nazwę wraz z pełną ścieżką dostę-pu). Należy również ustawić czas, przez jaki pliki mają być buforowane. Odpowiedni wpis znajduje się w wierszu rozpoczynającym się od słowa kluczowego Cachetime; roz-sądną wartością jest ok. 180 sekund. W pliku gopherd.conf powinien więc znajdo-wać się wpis:
Cachetime: 180
Podając odpowiednie dane w pliku gopherd.conf można również ograniczyć dostęp do niektórych plików w systemie, używając słowa kluczowego ignore. Zwykle znaj-dują się tam wpisy takie jak:
ignore: lib
ignore: bin
ignore: etc
ignore: dev
Wszystkie pliki o rozszerzeniach lib, bin, etc i dev będą przez system Gopher ignorowane. Jeśli istnieje potrzeba ograniczenia dostępu do innego typu plików, na przykład jeśli w księgowości używa się plików o rozszerzeniu .acct, które nie powinny być one widoczne dla klientów Gopher, powinieneś dodać wpis:
ignore: acct
Słowo kluczowe ignore pozwala ukryć pliki tylko na podstawie ich rozszerzenia - ta-kie rozwiązanie bywa czasem niewystarczające. Na szczęście po słowie kluczowym ignore_patt (ang. ignore pattern, ignoruj według wzorca) możliwe jest użycie sym-boli wieloznacznych. Przykładowo, aby uniemożliwić klientom Gopher dostęp do pli-ków o nazwach rozpoczynających się od liter usr, powinieneś do pliku gopherd.conf dodać wpis:
ignore_patt: ^usr$
Plik gopherdlocal.conf
W pliku gopherdlocal.conf należy dokonać co najmniej dwóch modyfikacji, dzięki którym system przestanie generować komunikaty o błędach, które po pewnym czasie zaczynają być denerwujące. W pliku tym domyślnie znajdują się między innymi dwa wpisy:
Admin: blank
AdminEmail: blank
Jeśli ich nie zmodyfikujesz, dostosowując do swojego systemu, Gopher będzie zgłaszał komunikaty o różnych (czasem dość dziwnych) błędach. Po słowie kluczowym Admin podaje się zwykle imię i nazwisko administratora, czasem również numer telefonu. Po słowie AdminEmail - adres e-mailowy administratora. Oto przykładowe wartości: Admin: Yvonne Chow, 555-1212
AdminEmail: ychow@chatton.com
W pliku gopherdlocal.conf należy również uzupełnić dane następujące po słowie kluczowym Abstract - jest to krótki opis tego, co można znaleźć w Twoim systemie. Jeśli nie zmienisz wartości domyślnej, użytkownicy będą otrzymywać informację, że powinni zażądać uzupełnienia opisu, powinieneś więc zrobić to jak najszybciej. Jeśli opis ma być dłuższy niż jeden wiersz tekstu, na końcu każdego wiersza powinien zna-leźć się znak \, który pozwala na kontynuację tekstu w nowym wierszu. Oto przykładowy opis zawartości serwera:
Abstract: This server provides sound and graphics files \
collected by the administrator on a recent trip to Outer \
Mongolia.
Informacje dostarczane użytkownikom o Twoim serwerze zawierają również takie da-ne, jak nazwa węzła, nazwa organizacji zajmującej się jego prowadzeniem, lokaliza-cja geograficzna komputera, szerokość i długość geograficzna oraz strefa czasowa. Nie trzeba podawać tych informacji, ale dzięki nim użytkownicy mogą zorientować się, z kim mają do czynienia. Oto przykładowe dane:
Site: Explore_Mongolia
Org: Mongolia Tourist Bureau
Loc: North Bay, Ontario, Canada
Geog: blank
TZ: EDT
Tekst blank w polu Geog oznacza, że wartość nie została podana - mało który admi-nistrator zna dokładne współrzędne geograficzne miejsca, w którym znajduje się komputer. Można również podać, w jakim języku dostępna jest większość dokumentów w syste-mie - ułatwi to użytkownikom korzystanie z usługi Gopher. Jeśli jest to na przykład amerykańska odmiana języka angielskiego, w pliku gopherdlocal.conf powinien znaleźć się wiersz:
Language: En_US
Po słowie kluczowym BummerMsg należy wpisać treść informacji, która będzie poda-wana użytkownikowi próbującemu połączyć się w sytuacji, gdy obsługiwana jest maksymalna liczba użytkowników, lub gdy połączenie powoduje błąd. Oto przykładowy wpis:
BummerMsg: Sorry, we have exceeded the number of permissible users.
Można oczywiście wpisać tu dowolny tekst, pamiętaj jednak o tym, że nigdy nie wiadomo, kto będzie go czytał.
Ostatnim krokiem konfigurowania pliku gopherdlocal.conf jest podanie informacji o ograniczeniach praw dostępu do serwera. Służy do tego słowo kluczowe access, po którym należy podać dane w następującym formacie:
access: nazwa_komputera prawa_dostępu liczba_użytkowników
nazwa_komputera to nazwa domenowa lub numer IP komputera, z którego następuje połączenie, pole prawa_dostępu pozwala określić prawa dostępu obowiązujące dla użytkowników łączących się z tego systemu, a liczba_użytkowników jest maksy-malną liczbą użytkowników, którzy mogą jednocześnie korzystać z usługi Gopher. Pole określające prawa dostępu może zawierać dowolną kombinację czterech poda-nych niżej wyrazów; każdy z nich może być poprzedzony wykrzyknikiem, co oznacza brak określonego prawa.
browse     Pozwala na przeglądanie zawartości katalogów. Jeśli użytkownik nie posiada tego prawa, ma dostęp do poszczególnych plików, ale nie może uzyskać informacji o zawartości katalogu.
ftp    Pozwala, by serwer zachowywał się jako bramka dla usługi FTP.
read    Pozwala na dostęp do plików. Jeśli użytkownik nie posiada tego prawa, przy próbie dostępu otrzyma informację określoną po sło-wie kluczowym BummerMsg.
search    Pozwala na dostęp do indeksów. Jeśli użytkownik nie posiada tego prawa, dostęp do indeksów nie jest możliwy. Słowo to jest używane głównie w systemie Gopher+. Jeśli na przykład chcesz zezwolić na pełny dostęp do serwera Gopher maksymalnie 10 użytkownikom z sieci chatton.com, powinieneś dodać do pliku gopherdlocal.conf wiersz:
access: chatton.com browse ftp read search 10
Pomiędzy każdymi dwoma wyrazami, nie wyłączając specyfikacji praw dostępu, po-winna wystąpić co najmniej jedna spacja. Oto inny przykład:
access: bignet.org !browse !ftp read search 3
Taki wpis pozwala na odczyt plików i dostęp do indeksów co najwyżej trzem użyt-kownikom sieci bignet.org, jednocześnie nie zezwalając na korzystanie z bramki FTP i przeglądanie zawartości katalogów. Jeśli zamiast nazw domenowych używasz numerów IP, możesz użyć niepełnego nume-ru, aby zapewnić dostęp całym podsieciom. Zakładając, że numerem sieci bi-gnet.org jest 147.12, można umożliwić dostęp z niej dodając do pliku gopherdlo-cal.conf wiersz:
access: 147.12. !browse !ftp read search 3
Ważne jest, by po częściowym numerze IP wpisać kropkę. W przeciwnym przypadku, dostęp do usługi Gopher otrzymaliby również użytkownicy sieci o numerach od 147.120 do 147.129 (ponieważ podane cyfry początkowe pasowałyby również do tych numerów). Jeśli chcesz umożliwić dostęp z jednego konkretnego komputera, możesz podać jego pełną nazwę, na przykład jeśli chcesz udostępnić usługę Gopher przyjacielowi admini-strującemu systemem darkstar, możesz do pliku gopherdlocal.conf dodać wiersz:
access: darkstar.nazwa.domeny browse ftp read search 1
Większość serwerów Gopher jest dostępna dla wszystkich użytkowników, więc możliwe jest również globalne określenie praw dostępu dla wszystkich systemów, dla których nie określono tych praw wprost. Można to zrobić na przykład tak:
access: default !browse !ftp read search 15
Powyższy wpis pozwala każdemu użytkownikowi korzystać z usługi Gopher, dając mu prawo do odczytu plików i przeglądania indeksów, ale zabraniając używania bramki FTP i przeglądania zawartości katalogów.
Konfigurowanie pliku Makefile
Aby proces kompilacji mógł przebiec poprawnie, należy odpowiednio zmodyfikować zawartość plików Makefile.conf oraz conf.h. W wielu wersjach systemu Gopher dla Linuxa domyślne wartości wszystkich potrzebnych parametrów są prawidłowe, ale mimo wszystko warto je przejrzeć, aby uniknąć problemów. Plik Makefile.conf (używany przez plik Makefile przy tworzeniu plików wykony-walnych) jest dość długi, więc należy poruszać się po nim ostrożnie, by uniknąć przy-padkowych zmian. Obszarami, które należy sprawdzić, są przede wszystkim definicje ścieżek dostępu do poszczególnych katalogów oraz ustawienia serwera i klienta - zo-staną one omówione bardziej szczegółowo. Jedną z opcji, które możesz chcieć zmienić, jest opcja ułatwiająca wyszukiwanie błę-dów, w większości systemów domyślnie załączona. Jest ona przydatna w trakcie uru-chamiania systemu, ale gdy wszystko działa poprawnie, powinieneś ponownie skompi-lować kod źródłowy wyłączając tę opcję, dzięki czemu nie będą generowane niepo-trzebne już informacje, a program będzie mniejszy i szybszy. Aby wyłączyć tę opcję, wstaw symbol komentarza na początku wiersza, w którym definiowana jest wartość DEBUGGING:
#DEBUGGING = -DDEBUGGING
W większości systemów w tym wierszu domyślnie nie ma symbolu komentarza. Definicje ścieżek dostępu do katalogów zebrane są zwykle w bloku składającym się z pięciu do siedmiu wpisów, zależnie od liczby dołączonych stron man. Oto typowy blok definicji katalogów:
PREFIX = /usr/local
CLIENTDIR = $(PREFIX)/bin
CLIENTLIB = $(PREFIX)/lib
SERVERDIR = $(PREFIX)/etc
MAN1DIR = $(PREFIX)/man/man1
MAN5DIR = $(PREFIX)/man/man5
MAN8DIR = $(PREFIX)/man/man8
Zwykle modyfikacji wymaga tylko wartość zmiennej PREFIX, określająca katalog, w którym system Gopher ma zostać zainstalowany. Domyślną wartością tej zmiennej jest przeważnie /usr/local, ale można podać dowolnie wybraną ścieżkę dostępu (na przykład /usr/gopher). Pozostałe zmienne definiują podkatalogi, w których znajdą się poszczególne pliki systemu Gopher i zwykle nie trzeba modyfikować ich wartości, choć oczywiście można dostosować je do swoich upodobań, na przykład umieszcza-jąc wszystkie pliki w jednym katalogu. Znaczenie poszczególnych zmiennych jest na-stępujące:
CLIENTDIR    katalog, w którym przechowywane będzie oprogramowanie klienta Gopher;
CLIENTLIB     katalog, w którym znajdzie się plik pomocy przeznaczony dla użytkownika (gopher.hlp);
SERVERDIR     katalog, w którym znajdzie się serwer gopherd i plik konfigu-racyjny (gopherd.conf);
MAN1DIR     katalog, w którym znajdą się strony man dotyczące programu klienta Gopher;
MAN8DIR     katalog, w którym znajdą się strony man dotyczące serwera gopherd.

Jeżeli w systemie ma działać poprawnie również klient Gopher, należy odpowiednio zmodyfikować wartość zmiennej CLIENTOPTS w pliku Makefile.config. Oto opcje, które można podać: -DNOMAIL    nie pozwala użytkownikom zdalnym wysyłać plików pocztą,
-DAUTOEXITONU    pozwala na zakończenie klienta Gopher za pomo-cą nie tylko polecenia q, ale również u.
Jeśli chcesz użyć którejś z tych opcji (lub obu), dopisz je w wierszu definiującym zmienną

CLIENTOPTS:
CLIENTOPTS = -DNOMAIL -DAUTOEXITONU
Należy również ustawić wartości czterech zmiennych zawierających dane o serwerze: nazwę serwera, numer portu używanego do połączeń Gopher, lokalizację plików z da-nymi i znaczniki. Nazwę domeny, do której należy serwer, należy podać jako wartość zmiennej DOMAIN, pozostawiając poprzedzającą ją kropkę:
DOMAIN = .tpci.com
Nie trzeba definiować wartości tej zmiennej, jeśli dostępna w systemie wersja polecenia hostname zwraca pełny adres domenowy komputera. W takim przypadku należy po-zostawić pole wartości puste. Zmienna SERVERPORT określa numer portu, który powinien być obsłużony przez usłu-gę Gopher - zwykle jest to port TCP o numerze 70. Odpowiedni wpis ma więc postać:
SERVERPORT = 70
Jeśli nie chcesz, by usługa Gopher była ogólnodostępna, możesz zmienić tę wartość. Jeżeli jednak chcesz udostępnić ją użytkownikom Internetu (nawet jeśli tylko niektó-rym), powinieneś użyć portu o numerze 70. W przypadku konfigurowania usługi Gopher do użytku w sieci lokalnej, można wybrać dowolny numer od 1024 do 9999, ale należy upewnić się, że wszystkie programy klientów Gopher używają tego samego numeru portu. Lokalizacja plików z danymi oferowanymi przez serwer Gopher określona jest przez wartość zmiennej SERVERDATA. Domyślnie jej definicja ma postać:
SERVERDATA = /gopher-data
Powinieneś dostosować tę wartość tak, by wskazywała na rzeczywiste położenie plików w systemie. Wartością zmiennej SERVEROPTS może być zestaw znaczników modyfikujących za-chowanie się usługi Gopher. Typowa definicja tej zmiennej ma postać:
SERVEROPTS = -DSETPROCTITLE -DCAPFILES # -DBIO -DDL
Część wiersza znajdującego się po symbolu komentarza (#) jest ignorowana, możesz więc dostosować opcje do własnych potrzeb zmieniając położenie tego symbolu (o ile porządek opcji pozwala na zastosowanie tak prostego rozwiązania). Dozwolone są na-stępujące znaczniki:
-DADD_DATE_AND_TIME    powoduje dodawanie do tytułów doku-mentów daty i czasu ich utworzenia;
-DBIO    używany tylko z wersją systemu WAIS opracowaną przez Dona Gilberta (wais8b5);
-DDL    umożliwia współpracę z programem obsługi baz danych dl (system dl musi znajdować się w kata-logu zdefiniowanym w zmiennej DLPATH, a zmien-na DLOBJS musi wskazywać na położenie plików getdesc.o i enddesc.o);
-DCAPFILES    powoduje, że system jest kompatybilny z wersją używającą katalogu cap;
-DLOADRESTRICT    umożliwia ograniczanie dostępu w zależności od liczby jednocześnie nawiązanych połączeń (możli-wość ta omówiona jest w następnym podrozdziale);
-DSETPROCTITLE    pozwala zdecydować, jaką postać będzie miała na-zwa procesu wyświetlana przez program ps (tylko w systemach opartych na BSD-UNIX). W pliku conf.h znajdują się inne, wykorzystywane w fazie kompilacji informacje konfigurujące usługę Gopher. Najważniejsze z nich dotyczą liczby odnośników zwra-canych użytkownikowi po zakończeniu wyszukiwania oraz ilości czasu, jaką należy odczekać przez uznaniem połączenia za przerwane. Zwykle wartości te definiowane są w końcowej części pliku conf.h. Zmienna WAISMAXHITS określa maksymalną liczbę odnośników, które może zwrócić w odpowiedzi na zapytanie baza danych WAIS; zwykle wartość ta wynosi około 40. Od-powiedni wpis w pliku conf.h ma więc postać:
#define WAISMAXHITS 40
Zwróć uwagę, że symbol # na początku wiersza nie oznacza tym razem komentarza, ponieważ plik conf.h jest napisany w języku C. Jest on częścią dyrektywy preproceso-ra i nie powinien być usuwany. W definicji zmiennej nie występuje również znak rów-ności. Zmienna MAXLOAD jest używana tylko wtedy, gdy częścią wartości zmiennej SERVEROPTS (definiowanej w pliku Makefile.config) jest znacznik -DLOADRESTRICT. Określa ona maksymalne średnie obciążenie serwera, przy którym połączenia Gopher będą jeszcze obsługiwane (wartość ta może być zmieniona przez podanie odpowiedniej opcji w wierszu poleceń). Zwykle jej definicja ma postać:
#define MAXLOAD 10.0
Zmienne READTIMEOUT i WRITETIMEOUT określają ilość czasu, jaką należy odczekać przed uznaniem, że połączenie zostało przerwane. Domyślne wartości są zwykle od-powiednie. Wiersze definiujące te zmienne mają postać:
#define READTIMEOUT (1*60)
#define WRITETIMEOUT (3*60)
Konfiguracja programu klienta Gopher jest prosta. Rozpocząć należy od zdefiniowa-nia serwerów Gopher, z którymi komputer lokalny będzie się łączył - służą do tego zmienne CLIENT_HOST1 i CLIENT_HOST2. Klient Gopher przy uruchomieniu sam wy-biera jeden z tych serwerów (o ile oba są zdefiniowane). Odpowiednie wpisy w pliku conf.h mogą mieć postać:
#define CLIENT1_HOST "serwer_gopher.tpci.com"
#define CLIENT2_HOST "inny_serwer_gopher.tpci.com"
Numery portów, których należy użyć do łączenia się z serwerami Gopher definiowane są w wierszach:
#define CLIENT1_PORT 70
#define CLIENT2_PORT 70
Jeśli usługa Gopher ma być dostępna tylko w sieci lokalnej i numery portów zostały zmienione (na przykład po to, by zabezpieczyć się przed dostępem poprzez Internet), należy podstawić odpowiednie wartości. Jeżeli używany jest tylko jeden serwer, war-tość zmiennej CLIENT2_PORT powinna wynosić zero. Język używany przez program klienta Gopher można wybrać spośród kilku obsługiwa-nych - jest on określony przez wartość zmiennej DEFAULT_LANG. Domyślnie jest to ję-zyk amerykański, ustawiany poleceniem:
#define DEFAULT_LANG "En_US"
Definicje innych języków znajdują się poniżej tego polecenia, zaznaczone jako ko-mentarze - jeśli chcesz użyć jednego z nich, usuń znacznik komentarza w odpowied-nim wierszu i wstaw go w wierszu definiującym język amerykański. Po wprowadzeniu wszystkich informacji konfiguracyjnych można uruchomić proces kompilacji programu klienta i serwera wydając polecenia:
make client
make server
Można również skompilować oba programy naraz, wydając polecenie make bez argu-mentów. Programy i dane muszą następnie zostać zainstalowane - w tym celu należy wydać polecenie:
make install
WAIS i Gopher
Klienci Gopher mają możliwość używania indeksów generowanych przez system WAIS do wyszukiwania interesujących ich plików, ale serwer musi być w tym celu od-powiednio skonfigurowany. System WAIS został omówiony w rozdziale 49. "Konfigu-racja węzła WAIS", więc założymy tu, że zainstalowałeś go już i posiadasz odpowied-nie pliki indeksowe, które chcesz udostępnić dla systemu Gopher. Jeśli chcesz udostępnić usługi systemu WAIS poprzez system Gopher, możliwe, że nie-zbędna będzie drobna modyfikacja plików źródłowych systemu WAIS. Poszukaj w plikach źródłowych wiersza:
if (gLastAnd) printf("search_word: boolean 'and' scored\n:"); Wiersz ten należy zaznaczyć jako komentarz, jeśli system WAIS ma współpracować z systemem Gopher. Wprowadź więc odpowiednie symbole na początek i koniec wier-sza:
/* if (gLastAnd) printf("search_word: boolean 'and' scored\n:"); */
Jeśli wiersz ten jest już zaznaczony jako komentarz lub po prostu go nie ma, nie musisz wprowadzać żadnych zmian. Po wprowadzeniu poprawki należy ponownie skompilo-wać system WAIS, wchodząc do katalogu z jego kodem źródłowym i uruchamiając polecenie make (które wykona polecenia zapisane w pliku makefile znajdującym się w tym katalogu). Następnie odszukaj w pliku Makefile.config znajdującym się w katalogu z kodem źródłowym systemu Gopher definicję zmiennej WAISTYPE. Powinna mieć ona postać:
WAISTYPE = # -DFREEWAIS_0_4
Na koniec należy połączyć usługi WAIS i Gopher. Zakładając, że katalog, w którym znajduje się kod źródłowy systemu Gopher to /usr/gopher/source, a kod źródłowy systemu WAIS znajduje się w katalogu /usr/wais/source, powinieneś wydać pole-cenia:
cd /usr/gopher/source
ln -s /usr/wais/source/include ./ir
ln -s /usr/wais/source/client/ui .
ln -s /usr/wais/source/bin .
Po ponownym skompilowaniu systemu Gopher, powstaną połączenia pomiędzy sys-temami freeWAIS i Gopher umożliwiające ich współpracę.
Katalogi systemu Gopher
Zakładanie katalogów dla systemu Gopher nie sprawia większych kłopotów; przeważ-nie nazwy katalogów odpowiadają ogólnie przyjętym konwencjom. Zanim zaczniesz, powinieneś zdecydować, które pliki i dokumenty zamierzasz udostępnić użytkowni-kom systemu Gopher i stworzyć krótki opis dla każdego z udostępnianych dokumen-tów (jeśli nie wiesz, co znajduje się w którymś z dokumentów, powinieneś się z nim za-poznać lub polecić streszczenie go autorowi). Dla uproszczenia założymy, że wszystkie udostępniane dokumenty znajdą się w jednym, wspólnym katalogu. Zacznij od przejścia do głównego katalogu z dokumentami systemu Gopher (jeśli taki katalog nie istnieje w systemie, powinieneś go założyć). Katalog ten nie powinien znaj-dować się w tym samym miejscu, co kod źródłowy czy pliki konfiguracyjne - wybierz jakiś katalog o łatwo dającej się zidentyfikować nazwie. Przykładowo, aby utworzyć katalog /usr/gopher/data, użyj standardowego polecenia mkdir:
mkdir /usr/gopher/data
Przejdź do katalogu systemu Gopher i skopiuj do niego wszystkie dokumenty, które chcesz udostępnić. Następnie zmień ich nazwy tak, by jak najlepiej oddawały zawar-tość pliku (ponieważ w systemie zwykle używa się zwięzłych, mało mówiących nazw) - ich długość nie powinna przekraczać 80 znaków. Przykładowo, jeśli chcesz udostęp-nić plik q1.sales, powinieneś zmienić jego nazwę na bardziej opisową, na przykład Company_ Sales_1997_Q1, dzięki czemu użytkownicy będą mogli nieco łatwiej zi-dentyfikować jego zawartość. Można również ułatwić identyfikację plików w inny sposób: tworząc podkatalog .cap w głównym katalogu z dokumentami systemu Gopher. Dla każdego udostępnianego pliku należy utworzyć w katalogu .cap plik o takiej samej nazwie, ale zawierający dwa wiersze tekstu: jeden z opisem pliku, a drugi z jego numerem. Zakładając, że udo-stępniasz plik o nazwie q1.sales w katalogu /usr/gopher/data, w katalogu /usr/gopher/data/ .cap powinieneś utworzyć plik o nazwie q1.sales, o następu-jącej zawartości:
Name=Company Sales for the First Quarter, 1997
Numb=1
Pozycja Name może zawierać spacje czy inne symbole, ponieważ jest wyświetlana jako zwykły tekst. Pole Numb zawiera numer, pod którym dany plik będzie wyświetlany w menu programu klienta Gopher. Przykładowo załóżmy, że oprócz wspomnianego wcześniej pliku udostępniasz jeszcze pliki q2.sales i q3.sales, a odpowiadające im pliki w katalogu .cap mają następującą zawartość:
$ cat q1.sales
Name=Company Sales for the First Quarter, 1997
Numb=1
$ cat q2.sales
Name=Company Sales for the Second Quarter, 1997
Numb=2
$ cat q3.sales
Name=Company Sales for the Third Quarter, 1997
Numb=3
W menu programu klienta Gopher dane o tych plikach będą wyglądały następująco:
1. Company Sales for the First Quarter, 1997
2. Company Sales for the Second Quarter, 1997
3. Company Sales for the Third Quarter, 1997
Porządek nazw plików w katalogu .cap nie ma znaczenia, ale numery w polu Numb nie powinny się powtarzać. Alternatywą dla katalogu .cap (dzięki któremu możliwe jest łatwe udostępnianie no-wych plików) jest użycie jednego pliku z opisami wszystkich udostępnianych doku-mentów. Plik ten powinien znaleźć się w głównym katalogu z dokumentami systemu Gopher i powinien nazywać się .names. Dla trzech plików z powyższego przykładu je-go zawartość wyglądałaby następująco:
$ cd /usr/gopher/data
$ cat .names
#My Gopher main .names file
Path=./q1.sales
Name=Company Sales for the First Quarter, 1997
Numb=1
Path=./q2.sales
Name=Company Sales for the Second Quarter, 1997
Numb=2
Path=./q3.sales Name=Company Sales for the Third Quarter, 1997
Numb=3
Jak widać, format wpisów w tym pliku jest taki sam, jak w plikach w katalogu .cap, dodatkowo podane są tylko nazwy dokumentów (które nie były potrzebne w katalogu .cap, ponieważ nazwy dokumentów były takie same, jak nazwy plików z opisami). Niewątpliwą zaletą użycia pliku .names jest łatwość reorganizacji wpisów menu, po-nieważ w tym celu wystarczy zmodyfikować zawartość tylko jednego pliku. Poza tym w pliku .names można umieścić krótkie streszczenie każdego z dokumentów. Oto przykładowy wpis:
Path=./gopher
Name=How to Set up A Gopher Service
Numb=16
Abstract=This document shows the steps you need to take to set up a Gopher service.
Można również zdefiniować pozycję menu prowadzącą do innego menu, bądź do całkiem innego serwera. Jest to możliwe dzięki dowiązaniom, które definiowane są w pliku dowiązań, o nazwie .link. Plik .link zawiera wpisy składające się z pięciu pól w formacie takim, jak w poniższym przykładzie:
Name=More Sales Info
Type=1
Port=70
Path=/usr/gopher/data/more_sales
Host=wizard.tpci.com
Zawartość pola Name określa tekst, który będzie wyświetlany w programie klienta Gopher, i może zawierać dowolny opis. Pole Type zawiera znacznik typu dokumentu, na który wskazuje dowiązanie. Dozwolone są następujące wartości:
0    plik tekstowy,
1    katalog,
2    serwer nazw CSO,
7    pełny indeks tekstowy,
8    sesja programu Telnet,
9    plik binarny,
h    dokument w formacie HTML,
I    plik zawierający grafikę,
M    plik MIME,
s    plik dźwiękowy.
Są to te same typy plików, które zostały przedstawione w liście typów plików obsługi-wanych przez system Gopher, choć ta lista jest nieco krótsza. Pole Port określa port, którego należy użyć przy łączeniu się z systemem zdalnym (je-śli dowiązanie prowadzi do systemu zdalnego), natomiast pole Path zawiera ścieżkę dostępu do pliku w systemie lokalnym lub zdalnym. Pole Host zawiera nazwę serwera, na którym znajduje się dany plik. Jeśli dowiązanie do innego serwera ma prowadzić poprzez usługę FTP lub WAIS, w polu Path musisz podać również nazwę usługi i od-powiednie argumenty. Przykładowo, jeśli w menu systemu Gopher ma znaleźć się po-zycja odsyłająca użytkownika do pliku na innym serwerze poprzez FTP, odpowiedni wpis w pliku .link powinien mieć postać:
Name=More Sales Info
Type=1
Port=+
Path=ftp:chatton.bigcat.com@/usr/gopher/cats
Host=+
Symbol + w polach Port i Host oznacza, że serwer FTP powinien zwrócić odpowied-nie wartości używając domyślnych numerów portów (na przykład portu 21 dla FTP). Dowiązanie do katalogu WAIS ma postać:
Name=More Sales Info
Type=7
Port=+
Path=waisrc:/usr/wais/data
Host=+
Można również w menu systemu Gopher umieścić pozycję powodującą uruchomienie jakiegoś programu. W tym celu w polu Path należy wpisać polecenie exec:
Path=exec:"argumenty" : nazwa_programu
nazwa_programu jest nazwą pliku wykonywalnego, natomiast argumenty zostaną przekazane do programu tak, jakby zostały podane w wierszu poleceń. Jeśli program ma być wywołany bez argumentów, pozostaw cudzysłów pusty. Format ten jest może nieco dziwny, ale bywa przydatny.
Uruchamianie usługi Gopher
Usługę Gopher można uruchomić z jednego z plików rc, z wiersza poleceń bądź też za pomocą programu rezydentnego inetd. Odpowiednie polecenie (wpisane w wierszu poleceń lub w pliku rc) może mieć postać:
/usr/local/etc/gopherd /usr/gopher/gopher-data 70
Jego argumentami są ścieżka dostępu do katalogu zawierającego dane oraz numer portu, którego należy używać do połączeń. Do programu gopherd można również przekazać kilka opcji modyfikujących jego za-chowanie - większość z nich ma swoje odpowiedniki w plikach konfiguracyjnych. Oto dostępne opcje:
-C    wyłącza buforowanie katalogów;
-c    wyłącza ograniczenia chroot;
-D    włącza generowanie informacji diagnostycznych;
-I    informuje program gopherd, że będzie wywoływany przez program inetd;
-L    pozwala określić maksymalne średnie obciążenie systemu (wymaga po-dania wartości liczbowej);
-l    pozwala podać nazwę pliku, do którego rejestrowane będą informacje o połączeniach (jego nazwę należy podać po opcji -l);
-o    pozwala na użycie pliku konfiguracyjnego o nazwie innej niż gopherd.conf (nazwę tę należy podać po opcji -o);
-u    pozwala ustalić identyfikator użytkownika, który będzie właścicielem programu gopherd (po tej opcji musi być podany prawidłowy identyfi-kator).
Aby poprawić bezpieczeństwo systemu, powinieneś - używając polecenia chroot - stworzyć wyizolowany podsystem plików dla programu Gopher (jak trzeba to zrobić, pokazaliśmy w rozdziale 48 "Konfigurowanie anonimowego węzła FTP"). Użycie opcji -c jest mniej bezpieczne, niż uruchamianie programu gopherd z aktywnym progra-mem chroot. Poza tym należy stosować opcję -u tak, by właścicielem procesu był zwykły użytkownik, a nie administrator. Takie rozwiązanie zabezpiecza przed wyko-rzystaniem przez hakerów ewentualnych błędów w programie. Jeśli chcesz, aby gopherd był uruchamiany przez program rezydentny inetd za każ-dym razem, gdy nastąpi próba połączenia, powinieneś zmodyfikować zawartość pli-ków /etc/services i /etc/inetd.conf, dodając do nich wpisy dla programu gopherd. Odpowiedni wiersz w pliku /etc/services zwykle ma postać:
gopher 70/tcp
Wpis w pliku /etc/inetd.conf może natomiast wyglądać tak:
gopher stream tcp nowait root /usr/local/etc/gopherd gopherd -I -u
ĺ id_użytkownika
id_użytkownika to identyfikator użytkownika, który będzie właścicielem procesu gopherd (warto założyć do tego celu osobne konto, o standardowych prawach dostę-pu). Po zainstalowaniu i skonfigurowaniu procesu serwera Gopher przyszedł czas na jego przetestowanie. Najpierw jednak potrzebny będzie program klienta Gopher. Po uru-chomieniu go i połączeniu się z serwerem Gopher (przez podanie nazwy serwera) po-winna zostać wyświetlona zawartość głównego katalogu z danymi systemu Gopher. Innym sposobem przetestowania systemu jest użycie programu Telnet. Połącz się za jego pomocą z portem obsługiwanym przez system Gopher, wydając polecenie:
telnet gopher 70
Jeśli połączenie zostanie nawiązane poprawnie, na ekranie wyświetlona zostanie za-wartość systemu Gopher. Jeszcze inną metodą sprawdzenia, czy Gopher został zainstalowany prawidłowo, jest użycie polecenia gopherls, którego argumentem jest nazwa katalogu z danymi sys-temu Gopher. Polecenie to może więc mieć postać:
gopherls /usr/wais/gopher/data
Przydaje się ono również do testowania katalogów dodawanych do systemu Gopher już w trakcie jego działania.
Daj światu znać o sobie
Poświęciłeś sporo czasu na konfigurację usługi Gopher, więc warto poinformować in-nych użytkowników Internetu o tym fakcie (oczywiście powinieneś zrobić to tylko wtedy, gdy chcesz udostępnić swoje dokumenty wszystkim użytkownikom sieci i masz pewność, że system działa prawidłowo - nie podejmuj opisanych niżej kroków jeśli chcesz udostępnić usługę Gopher tylko w sieci lokalnej). Jeśli chcesz, by dane o Twoim serwerze Gopher znalazły się w głównej liście katalogów Gopher, wyślij pocztą elektroniczną wiadomość na adres:
gopher@boombox.miro.umn.edu
W treści wiadomości powinna znaleźć się pełna nazwa usługi (tak, jak pojawia się ona w menu głównym), nazwa i numer IP serwera, numer portu używanego do połączeń Gopher (jeśli usługa ma być ogólnodostępna, powinien być to port TCP o numerze 70), adres e-mailowy administratora systemu Gopher i krótki opis tego, co można znaleźć w systemie. Jeśli chcesz, możesz również podać tekst określający ścieżkę dostępu do katalogu z danymi, ale nie jest to konieczne, ponieważ większość systemów Gopher uruchamia się w katalogu głównym (choć możliwość taka może być przydatna, jeśli udostępniasz kilka różnych systemów menu do różnych celów).

Konfigurowanie węzła WWW
Nie ma chyba nikogo, kto nie słyszałby jeszcze o stronach WWW (ang. World Wide Web). Jest to najpopularniejszy aspekt Internetu. Właśnie z powodu popularności WWW coraz więcej użytkowników sieci decyduje się na założenie własnych serwerów WWW i utworzenie swoich stron głównych. Obecnie dostępnych jest coraz więcej wy-rafinowanych pakietów oprogramowania działających jako serwery WWW dla róż-nych systemów operacyjnych. Linux, oparty na systemie UNIX, również zawiera opro-gramowanie potrzebne do założenia własnego serwera WWW. Do skonfigurowania węzła WWW nie jest potrzebne żadne wymyślne oprogramowanie - wystarczy trochę czasu i odpowiednie dane konfiguracyjne. O tym właśnie traktuje ten rozdział. Przyjrzymy się bliżej zagadnieniu konfiguracji serwera WWW w systemie linuxowym, przeznaczonego dla przyjaciół, użytkowników sieci lokalnej czy też dla całego Internetu. Jednym z najważniejszych powodów popularności stron WWW, oprócz możliwości multimedialnych, są hiperłącza. Pozwalają one przenosić się jednym kliknięciem z jednego dokumentu do drugiego, z serwera na serwer, od grafiki do filmów i tak dalej. Instrukcje powodujące odpowiednie przejścia są zapisane w kodzie stron WWW. Strony WWW obsługiwane są przez dwie warstwy oprogramowania: oprogramowanie klienta WWW (nazywane często przeglądarką WWW) i oprogramowanie serwera. Bar-dzo popularne są programy klientów WWW takie jak Netscape czy Mosaic, ale do-stępne są również inne pakiety, niektóre przeznaczone do pracy wyłącznie pod kontro-lą Linuxa czy X Window.
Oprogramowanie serwera WWW
Dla systemu Linux dostępne są trzy główne wersje serwera WWW, pochodzące odpo-wiednio z organizacji NCSA, CERN i Plexus. Najłatwiejszy w użyciu jest system opra-cowany przez NCSA; organizacja ta opracowała również przeglądarkę Mosaic. Jest on niewielki i szybki, może działać jako program rezydentny, może też być uruchamiany przez proces inetd; poza tym zapewnia dość wysoki poziom bezpieczeństwa. W tym rozdziale omówimy proces konfiguracji pakietu pochodzącego właśnie z NCSA, choć z łatwością użyć można również dwóch pozostałych pakietów (dostosowując odpo-wiednio dane konfiguracyjne). W wielu węzłach FTP i BBS dostępny jest również dość popularny serwer WWW o nazwie Apache - zajmiemy się nim w następnym podroz-dziale, po omówieniu bardziej tradycyjnych serwerów WWW. Oprogramowanie pochodzące z NCSA dostępne jest zarówno w postaci kodu źródło-wego, jak i w wersji skompilowanej. Użycie wersji skompilowanej jest znacznie prost-sze, ponieważ nie trzeba konfigurować i kompilować kodu źródłowego. Pliki wykony-walne przeważnie dostępne są w postaci zarchiwizowanej programem tar i skompre-sowanej, więc należy je rozpakować. Często spotykane są również gotowe do użycia wersje dostarczane na płytach CD-ROM. Jeśli posiadasz skompresowaną wersję pro-gramu serwera WWW, powinieneś, trzymając się wskazówek zawartych w pliku README lub podobnym, rozpakować pliki do odpowiednich katalogów.
Rozpakowywanie plików z oprogramowaniem serwera WWW
Jeśli oprogramowanie w postaci kodu źródłowego lub skompilowane otrzymałeś z wę-zła FTP czy BBS, prawdopodobnie będziesz je musiał najpierw rozpakować (za po-mocą programów tar i unzip - powinieneś jednak sprawdzić to w dołączonych pli-kach README, w przeciwnym przypadku może okazać się, że robisz to niepotrzebnie). Zwykle należy utworzyć osobny katalog dla oprogramowania WWW, przejść do niego i rozpakować otrzymane pliki, na przykład wydając polecenie
zcat httpd_X.X_XXX.tar.Z | tar xvf -
W nazwie tych plików często znajduje się, oprócz numeru wersji, nazwa platformy, dla której przeznaczone jest oprogramowanie - na przykład httpd_1.5_linux.tar.Z. Jako argument polecenia zcat powinieneś podać pełną nazwę otrzymanego pliku. In-strukcje dotyczące instalacji czasem dostarczane są w postaci osobnego pliku tar, na przykład Install.tar.Z, który powinieneś również zdobyć i rozpakować poleceniem
zcat Install.tar.Z
Podczas wydawania powyższego polecenia katalogiem bieżącym powinien być kata-log docelowy - inaczej będziesz musiał przenosić ręcznie sporą liczbę plików. Pliki z oprogramowaniem serwera WWW można umieścić w dowolnym miejscu, ale dobrym pomysłem jest utworzenie dla nich odrębnego katalogu, na przykład /usr/web czy /var/web, dzięki czemu łatwiej będzie kontrolować prawa dostępu do tych plików. Po zdekompresowaniu odpowiednich plików i umieszczeniu bibliotek we właściwych katalogach, warto przyjrzeć się podkatalogom utworzonym automatycznie. Wśród nich powinny znaleźć się następujące podkatalogi:
cgi-bin    standardowy interfejs pomiędzy stronami WWW a programami i skryptami;
conf    pliki konfiguracyjne;
icons    ikony przeznaczone do użycia na stronach głównych;
src    kod źródłowy i (czasem) pliki wykonywalne;
support    aplikacje wspierające obsługę WWW.

Kompilowanie oprogramowania serwera WWW
Jeśli nie musisz modyfikować i rekompilować kodu źródłowego dostosowując go do potrzeb Linuxa (ponieważ posiadasz linuxową wersję programu), możesz pominąć szczegółowe omówienie konfiguracji znajdujące się w dalszej części tego podrozdziału. Z drugiej strony warto jednak wiedzieć, co znajduje się w kodzie źródłowym, ponieważ dzięki temu można lepiej zrozumieć współdziałanie systemu i oprogramowania serwe-ra. Jeśli posiadasz ogólną wersję kodu źródłowego serwera WWW opracowanego przez NCSA, nie dostosowaną do Twojego systemu, musisz przed kompilacją skonfigurować kod źródłowy. Rozpocznij od wprowadzenia do pliku src/Makefile informacji o systemie. Powi-nieneś sprawdzić wartości kilku zmiennych:
AUX_CFLAGS    pozwala podać dodatkowe opcje kompilatora - usuń komentarz z wiersza definiującego wersję dla Linuxa (zwykle odpowiednie wiersze są opatrzone komentarzem umożliwiającym ich identyfikację);
CC    pozwala na podanie nazwy kompilatora języka C (zwykle cc lub gcc);
EXTRA_LIBS    pozwala na dołączenie dodatkowych bibliotek (które nie są wymagane w systemie Linux);
FLAGS    pozwala podać dodatkowe opcje dla konsolidatora (większość wersji linuxowych nie wymaga żadnych dodatkowych opcji).
Należy również przyjrzeć się wartości zmiennej CFLAGS, zawierającej listę znaczników kompilatora. Niektóre z nich mogą być już ustawione. Oto dostępne wartości:
-DSECURE_LOGS    zabezpiecza przed zakłócaniem procesu rejestrowania danych, prowadzonego przez serwer WWW, przez skrypty CGI;
-DMAXIMUM_DNS    pozwala na użycie bezpieczniejszego systemu tłumaczenia nazw (kosztem wydajności);
-DMINIMAL_DNS    nie zezwala na zwrotne tłumaczenie nazw, co poprawia wydajność;
-DNO_PASS    zabezpiecza przed uruchamianiem wielu procesów po-omnych;
-DPEM_AUTH    uaktywnia schematy autoryzacji PEM/PGP
-DXBITHACK    pozwala na sprawdzanie, czy plik HTML jest wykonywalny;
-O2    załącza optymalizację.
Najprawdopodobniej nie będziesz musiał modyfikować wartości zmiennej CFLAGS, ale powinieneś być świadomy jej przeznaczenia. Po sprawdzeniu i ewentualnym popra-wieniu danych zapisanych w pliku src/Makefile należy skompilować kod źródłowy, wydając polecenie:
make linux
Jeśli jego wykonanie spowoduje wyświetlenie komunikatów o błędach, powinieneś jeszcze raz dokładnie sprawdzić dane w pliku konfiguracyjnym. Najczęściej przyczyną problemów jest źle zdefiniowana platforma (lub wybranie kilku platform jednocze-śnie).
Konfiguracja oprogramowania serwera WWW
Po zainstalowaniu kodu źródłowego w odpowiednich katalogach i skompilowaniu go dla Linuxa należy skonfigurować system. Proces ten powinieneś rozpocząć od pliku httpd.conf-dist. Skopiuj go do pliku o nazwie httpd.conf - jest to nazwa pliku konfiguracyjnego programu httpd. Zanim zaczniesz go modyfikować, powinieneś zdecydować, czy chcesz uruchamiać program httpd jako program rezydentny, czy też ma on być uruchamiany przez proces inetd. Jeśli przewidujesz częste użycie tego programu, po-winieneś wybrać pierwszą wersję. W przeciwnym przypadku obie możliwości są równie dobre. W pliku httpd.conf zdefiniowanych jest kilka wartości, które wymagają sprawdzenia lub wprowadzenia jakichś danych. Każda z definicji zmiennych ma składnię:
zmienna wartość
Pomiędzy nazwą zmiennej a wartością nie pojawia się znak równości ani żaden inny specjalny symbol. Oto kilka przykładowych wierszy:
FancyIndexing    on
HeaderName    Header
ReadmeName    README
Ścieżki dostępu do plików i katalogów zwykle podawane są nie jako pełne ścieżki do-stępu, ale względem katalogu serwera WWW. Poniżej podajemy zmienne, których war-tości należy dostosować do wymagań systemu.
AccessConfig    Lokalizacja pliku konfiguracyjnego access.conf - do-myślnie jest to conf/access.conf. W tym miejscu moż-na użyć zarówno pełnej, jak i względnej ścieżki dostępu.
AgentLog    Nazwa pliku, w którym rejestrowane będą dane o typie i wersji przeglądarki WWW używanej do połączenia się z serwerem. Domyślna wartość to logs/agent_log.
ErrorLog    Nazwa pliku, do którego zapisywane będą dane o błędach. Domyślną wartością jest logs/error_log.
Group    Identyfikator grupy będącej właścicielem procesu serwera (używany tylko, jeśli serwer działa jako program rezydent-ny). Może to być zarówno nazwa, jak i identyfikator nu-meryczny grupy, z tym, że należy poprzedzić go symbolem #. Domyślna wartością jest #-1.
MaxServers    Maksymalna dozwolona liczba procesów potomnych.
PidFile    Nazwa pliku, w którym przechowywane będą identyfikato-ry procesów wszystkich kopii programu httpd. Domyślna wartość to logs/httpd.pid. Wartość ta jest używana tyl-ko wtedy, gdy serwer działa jako program rezydentny.
Port    Numer portu, pod którym należy oczekiwać na połączenia programów klientów WWW. Domyślnie jest to port 80. Jeśli nie chcesz, by serwer WWW był ogólnodostępny, zmień tę wartość.
ResourceConfig    Ścieżka dostępu do pliku srm.conf, zwykle conf/srm.conf.

ServerAdmin    Adres e-mailowy administratora.
ServerName    Pełna nazwa domenowa serwera.
ServerRoot    Ścieżka dostępu do katalogu, powyżej którego użytkowni-cy nie będą mogli się dostać (zwykle jest to katalog główny serwera WWW lub katalog /usr/local/etc/httpd).
ServerType    Typ serwera: standalone (samodzielny program rezy-dentny) lub inetd (uruchamiany przez proces inetd).
StartServers    Liczba procesów serwera, które uruchamiane są przy uru-chamianiu programu rezydentnego.
TimeOut    Czas (w sekundach), przez jaki należy czekać na odpo-wiedź klienta przed przerwaniem połączenia (domyślnie zmienna ta ma wartość 1800 i należy ją zmniejszyć).
TransferLog    Ścieżka dostępu do pliku, w którym rejestrowane będą da-ne o dostępie do plików. Domyślną wartością jest logs/access_ log.
TypesConfig    Ścieżka dostępu do pliku konfiguracyjnego MIME. Do-myślnie jest to conf/mime.conf.
User    Identyfikator użytkownika będącego właścicielem procesu serwera WWW (używany tylko wtedy, gdy serwer działa jako program rezydentny). Można tu podać identyfikator tekstowy lub liczbowy, ale poprzedzony symbolem #. Domyślna wartość to #-1.
Należy również sprawdzić dane o zasobach serwera, zapisane w pliku srm.conf. Oto lista zmiennych, których wartości mogą wymagać modyfikacji.
AccessFileName    Zawiera nazwę pliku z danymi o prawach dostępu (do-myślnie .htaccess).
AddDescription    Pozwala wprowadzić opis typu pliku, na przykład AddDe-scription PostScript file *.ps. Dozwolone jest wprowadzenie większej liczby takich wpisów.
AddEncoding    Pozwala podać, że określony typ plików jest w jakiś sposób zakodowany, na przykład AddEncoding compress Z. Podobnie jak poprzednio, dozwolone jest wprowadzenie większej liczby takich wpisów.
AddIcon    Pozwala na podanie nazwy ikony wyświetlanej jako sym-bol pliku każdego z typów.
AddIconType    Pozwala na określenie wyświetlanej ikony na podstawie typu MIME.

AddType Pozwala wyłączyć rozpoznawanie typu MIME dla plików o określonym rozszerzeniu.
Alias Pozwala na zastąpienie ścieżki dostępu krótszą nazwą, na przykład Alias data /usr/www/data.
DefaultType Definiuje domyślny typ MIME - zwykle text/plain.
DefaultIcon Określa, która ikona ma być używana domyślnie, jeśli ak-tywna jest opcja FancyIndexing (domyślnie jest to ikona zapisana w pliku icons/unknown.xbm).
DirectoryIndex Pozwala określić nazwę pliku, który należy zwrócić jeśli użytkownik nie zażądał żadnego konkretnego pliku. Do-myślnie jest to plik index.html.
DocumentRoot Zawiera pełną ścieżkę dostępu do katalogu zawierającego dokumenty HTML. Domyślna wartość to /usr/local/etc/ httpd/htdocs.
FancyIndexing Pozwala na dodanie do listy indeksowanych plików ikon i nazw plików. Domyślną wartością jest on (załączone). Opcja ta jest potrzebna dla zapewnienia kompatybilności z pierwszą wersją HTTP.
HeaderName Zawiera nazwę pliku wyświetlanego na początku listy in-deksowanych plików. Domyślnie jest to plik o nazwie Hea-der.
IndexOptions Zawiera parametry indeksowania (między innymi Fancy-Indexing, IconsAreLinks, ScanHTMLTitles, Suppres-sLastModified, SupressSize i SuppressDe-scription).
ReadmeName Zawiera nazwę pliku wyświetlanego jako stopka wraz z danymi o zawartości katalogów. Domyślnie jest to plik o nazwie README.
Redirect Odwzorowuje ścieżkę dostępu na inny adres URL.
ScriptAlias Pozwala na zastąpienie ścieżki dostępu krótszą nazwą, po-dobnie jak polecenie Alias. Polecenie ScriptAlias używane jest w skryptach.
UserDir Zawiera nazwę katalogu, który może być użyty przez użytkowników do dostępu do httpd. Domyślnie jest to katalog public_html. Przeważnie należy wpisać tu nazwę katalogu zawierającego stronę główną użytkownika. Można również użyć wartości DISABLED (wyłączone).
Trzecim plikiem, którego zawartość należy przejrzeć i ewentualnie zmodyfikować, jest plik access.conf-dist, definiujący usługi dostępne dla przeglądarek WWW. Zwykle dostępne są wszystkie usługi, możesz jednak chcieć zmodyfikować ten plik dla zapewnienia wyższego poziomu bezpieczeństwa lub po to, by wyłączyć usługi nie obsługiwane przez Twój węzeł WWW. Format pliku conf-dist jest nieco inny niż format dwóch poprzednich plików. Używane są w nim polecenia dzielące cały plik na sekcje, w któ-rych znajdują się dyrektywy. Ogólnie format pojedynczego wpisu jest następujący:
< Directory nazwa_katalogu >
...
< /Directory >
Wszystko, co znajduje się pomiędzy ogranicznikami i , to dyrektywy. Sprawa komplikuje się jeszcze bardziej, ponieważ w obrębie pliku może wystąpić kilka rodzajów dyrektyw. Najlepszym sposobem na dostosowanie pliku ac-cess. conf-dist w przypadku typowej instalacji serwera WWW jest trzymanie się poniższych rad.
1. Znajdź dyrektywę Options i usuń opcję Indexes. Dzięki temu użytkownicy nie będą mogli przeglądać zawartości katalogu httpd. Inne opcje podawane po dyrektywie Options omówione zostaną za chwilę.
2. Znajdź pierwszą dyrektywę Directory i sprawdź ścieżkę dostępu do katalogu ze skryptami cgi. Domyślnie jest to wartość /usr/local/etc/httpd/cgi-bin.
3. Znajdź definicję zmiennej AllowOverride i ustaw jej wartość na None (żad-ne), dzięki czemu użytkownicy nie będą mogli zmieniać ustawień. Domyślną wartością jest All (wszystkie). Dostępne wartości zostaną krótko omówione w dalszej części tego podrozdziału.
4. Znajdź dyrektywę Limit i nadaj jej żądaną wartość.
Dyrektywa Limit pozwala ograniczyć dostęp do serwera. Poniżej przedstawiamy listę dostępnych wartości.
allow    Pozwala na dostęp do serwera WWW z systemu o nazwie podanej po słowie allow.
deny    Nie pozwala na dostęp do serwera WWW z systemu o nazwie po-danej po słowie deny.
order    Określa porządek, w jakim odczytywane będą dyrektywy allow i deny (zwykle deny, allow, ale może również być odwrotnie).
require    Umożliwia żądanie autoryzacji poprzez plik użytkownika, określo-ny na podstawie wartości zmiennej AuthUserFile.
Dyrektywa Option zawiera kilka wartości o różnym przeznaczeniu. Domyślnie zawie-ra ona wpisy:

Options Indexes FollowSymlinks
Wpis Indexes powinien zostać usunięty już wcześniej. Wszystkie wpisy odnoszą się do katalogu, w którym znajduje się pole Options. Dostępne wartości to:
All    Włączenie wszystkich opcji.
ExecCGI    Umożliwienie wykonywania skryptów CGI z określo-nego katalogu.
FollowSymLinks    Umożliwienie użycia przez program httpd dowiązań symbolicznych.
Includes    Włączenie obsługi przez serwer plików include.
IncludesNoExec    Włączenie obsługi przez serwer plików include, ale przy wyłączeniu opcji exec.
Indexes    Umożliwienie użytkownikom przeglądania indeksów generowanych przez serwer (nie dotyczy indeksów skompilowanych wcześniej).
None    Wyłączenie wszystkich opcji.
SymLinksIfOwnerMatch    Umożliwienie użycia przez program httpd dowiązań symbolicznych pod warunkiem, że identyfikator wła-ściciela dowiązania jest taki sam jak identyfikator właściciela pliku, do którego prowadzi dowiązanie.
Zmienna AllowOverride domyślnie ma wartość All, którą należy zmienić; dla więk-szości systemów zalecana jest wartość none. Poniżej przedstawiamy wszystkie dostęp-ne wartości.
All    Umożliwienie kontroli dostępu przez pliki konfiguracyjne znajdu-jące się w każdym katalogu.
AuthConfig    Załączenie obsługi kilku procedur zabezpieczających. Dostępne wartości to: AuthName (weryfikacja nazwy katalogu), AuthType (weryfikacja typu katalogu, choć dozwolony jest tylko jeden typ - Basic), AuthUserFile (określenie nazwy pliku zawierającego identyfikatory i hasła użytkowników) i AuthGroupFile (okre-ślenie nazwy pliku zawierającego nazwy grup).
FileInfo    Uaktywnienie dyrektyw AddType i AddEncoding.
Limit    Uaktywnienie dyrektywy Limit.
None    Wyłączenie kontroli dostępu poprzez pliki konfiguracyjne.
Options    Uaktywnienie dyrektywy Options.
Teraz w plikach konfiguracyjnych powinny już znajdować się prawidłowe dane. Choć składnia tych plików nie jest zbyt intuicyjna, przyjrzenie się wartościom domyślnym pozwala łatwo zorientować się, jaki format powinny mieć wprowadzane modyfikacje. Można przystąpić do uruchomienia oprogramowania serwera WWW.
Uruchamianie serwera WWW
Po zakończeniu procesu konfiguracji przyszła pora na wypróbowanie oprogramowa-nia serwera WWW. Dane o tym, czy ma ono działać jako program rezydentny, czy też będzie uruchamiane przez proces inetd, zapisane zostały w odpowiednich plikach konfiguracyjnych. Sposób uruchamiania oprogramowania jest nieco inny w obu tych przypadkach, ale w wierszu poleceń zawsze można użyć następujących opcji:
-d ścieżka dostępu do katalogu głównego serwera (używana tylko wtedy, jeśli wartość domyślna nie jest prawidłowa),
-f nazwa pliku konfiguracyjnego, o ile nie ma to być domyślny plik httpd. conf,
-v wyświetlenie numeru wersji.
Jeśli do uruchamiania oprogramowania serwera WWW chcesz używać procesu inetd, musisz do pliku /etc/services dopisać wiersz
http port/tcp
zezwalający programowi inetd na uruchamianie serwera WWW (port to numer używanego portu, zwykle 80). Następnie do pliku /etc/inetd.conf należy dodać polecenie pozwalające na uru-chomienie programu httpd:
httpd stream tcp nowait nobody /usr/web/httpd
Ostatnia pozycja określa ścieżkę dostępu do programu serwera WWW. Po zrestartowa-niu procesu inetd (można to zrobić używając polecenia kill i uruchamiając go po-nownie lub restartując system) usługa powinna być już dostępna przez port o numerze określonym w pliku /etc/services. Jeśli oprogramowanie serwera WWW ma działać jako program rezydentny, można uruchomić je bezpośrednio z wiersza poleceń:
httpd &
Lepiej jednak dodać odpowiednie polecenia do jednego z plików rc przetwarzanych podczas uruchamiania systemu. Odpowiedni wpis ma zwykle postać:
#start httpd
if [ -x /usr/web/httpd ]
then
/usr/web/httpd
fi
Powinieneś oczywiście dostosować ścieżkę dostępu do programu httpd do wymagań swojego systemu. Po ponownym uruchomieniu systemu oprogramowanie serwera po-winno obsługiwać port o numerze domyślnym. Aby przetestować działanie serwera WWW, uruchom dowolną przeglądarkę stron WWW i w polu URL wprowadź adres
http://nazwa_serwera
gdzie nazwa_serwera to nazwa Twojego serwera WWW. Możesz to zrobić zarówno przez Internet, jak i z dowolnego komputera w sieci lokalnej (jeśli jesteś podłączony do sieci lokalnej). Jeżeli wyświetlona zostanie zawartość pliku index.html znajdującego się w katalogu głównym serwera WWW, wszystko jest w porządku. W przeciwnym przypadku poszukaj informacji o problemie w plikach, do których rejestrowane są błędy i przejrzyj jeszcze raz pliki konfiguracyjne. Jeśli nie zainstalowałeś jeszcze żadnej przeglądarki internetowej, możesz za pomocą programu telnet sprawdzić, czy serwer WWW działa prawidłowo. Wydaj następujące polecenie, podstawiając nazwę swojego serwera i numer portu, jeśli jest inny niż 80:
telnet www.wizard.tpci.com 80
O ile serwer działa prawidłowo, powinny zostać wyświetlone następujące informacje:
Connected to wizard.tpci.com
Escape character is '^]'.
HEAD/HTTP/1.0
HTTP/1.0 200 OK
Powinny również pojawić się informacje o dacie i zawartości serwera. Prawdopodobnie nie będziesz miał dostępu do żadnego pliku, ale dzięki temu wiesz, że serwer działa prawidłowo.
Apache
Apache to pakiet oprogramowania zawierający serwer WWW. Staje się on coraz popu-larniejszy, głównie dzięki jego elastyczności i istnieniu wersji przeznaczonych dla wielu platform sprzętowych i systemów operacyjnych. Apache jest oparty na serwerze Mo-saic, o którym wspomniano już wcześniej w tym rozdziale, ale zawiera dość sporo no-wego kodu. Został napisany jako program darmowy i jest ogólnodostępny. W sieci In-ternet działa spora grupa użytkowników służących pomocą w razie problemów, a w księgarniach dostępnych jest również kilka książek na jego temat. Użycie programu make z pakietem Apache Serwer Apache rozprowadzany jest czasem tylko w postaci nie skompilowanego kodu źródłowego. W niektórych dystrybucjach Linuxa dostarczanych na dyskach CD-ROM dostępne są również pliki wykonywalne, co pozwala na pominięcie etapu kompilacji. Jeśli jednak załadowałeś oprogramowanie Apache z węzła FTP czy poprzez stronę WWW, najprawdopodobniej będziesz musiał je skompilować sam. Nie jest to trudne, ponieważ cały proces kompilacji został zautomatyzowany za pomocą programu użytkowego make. Program make zostanie omówiony dokładniej w rozdziale 56. "Za-rządzanie kodem źródłowym", ale w tym podrozdziale nie musisz przejmować się szczegółami jego działania. Najpierw upewnijmy się, że oprogramowanie Apache jest gotowe do zainstalowania. Jeśli pobrałeś je z Internetu, posiadasz prawdopodobnie pojedynczy, skompresowany plik (o nazwie apache.tar i z rozszerzeniem .Z lub .gz), który należy skopiować do katalogu tymczasowego (o dowolnej nazwie) i rozpakować wydając jedno z poleceń:
uncompress apache.tar.Z
gunzip apache.tar.gz
zależnie od rozszerzenia posiadanego pliku (programy do kompresji i dekompresji pli-ków zostały omówione w części drugiej "Poznawanie Linuxa" i części czwartej "Linux dla administratorów"). Jeśli używasz wersji programu tar rozprowadzanej na licencji GNU (która jest dołączana do większości systemów linuxowych), możesz za jednym zamachem zdekompresować plik i wydobyć pliki z archiwum tar wyda-jąc polecenie:
tar zxvf apache.tar.gz
Po zdekompresowaniu plik będzie miał nazwę apache.tar (tę samą, którą miał przed dekompresją, ale bez rozszerzenia .Z czy .gz; poniżej założymy, że jest to nazwa apa-che.tar - jeśli w Twoim przypadku jest inaczej, powinieneś podstawić odpowiednią nazwę). Plik tar zawiera wszystkie pliki wymagane przez Apache - należy je z niego wydobyć wydając polecenie:
tar xvf apache.tar
Spowoduje ono utworzenie sporej liczby plików, o nazwach składających się w więk-szości z małych liter, choć nazwy kilku z nich, na przykład pliku README, składają się z również wielkich liter. W pliku README znajdują się wskazówki dotyczące kompilo-wania serwera Apache po skonfigurowaniu systemu. Prawidłowe informacje konfigu-racyjne, dotyczące oprogramowania i sprzętu dostępnego w Twoim systemie, powinny znaleźć się w pliku Configuration, który można edytować dowolnym edytorem tek-stów zapisującym pliki w standardzie ASCII. Plik Configuration ma dość dziwną składnię, umożliwiającą bardzo dokładne skonfigurowanie systemu; niuanse konfiguracji są jednak zbyt skomplikowane, by wy-jaśniać je w rozdziale takim jak ten. Na szczęście większością drobiazgów nigdy nie będziesz musiał się przejmować. Plik Configuration jest używany przez skrypt o nazwie Con-figure, który generuje plik Makefile, używany z kolei przez program make do skompilowania kodu źródłowego. W pliku Configuration znajdują się zasadniczo dane czterech typów:
- komentarze - wszystkie wiersze rozpoczynające się od symbolu #,
- polecenia programu make - wiersze nie rozpoczynające się niczym szczególnym,
- moduły - grupy wierszy rozpoczynające się słowem kluczowym Module,
- reguły - wiersze rozpoczynające się słowem Rule.
Nie powinieneś edytować pliku Makefile bezpośrednio. Wszystkie wprowadzone modyfikacje i tak zostaną utracone po uruchomieniu skryp-tu Configure. Plik Makefile jest generowany automatycznie przez skrypt Configure na podstawie informacji zawartych w pliku Confi-guration. Praktycznie we wszystkich przypadkach jedyne modyfikacje pliku Configuration, których trzeba dokonać, polegają na usunięciu bądź wstawieniu symbolu komentarza w odpowiednich wierszach. Wpisy dotyczące modułów i reguł można pominąć, chyba że zamierzasz zagłębić się w szczegóły konfiguracji systemu. Jeśli spojrzysz na zawar-tość pliku Configuration, zauważysz, że większość odniesień do sekcji Module jest zaznaczona jako komentarz - można usunąć odpowiednie symbole komentarza, dzięki czemu podczas generowania pliku Makefile moduły będą również brane pod uwagę. Standardowa wersja serwera Apache dla Linuxa zawiera plik Configuration, w którym wszystkie opcje mają prawidłowe wartości - możesz jednak przejrzeć ten plik, aby zorientować się, jakie opcje są dostępne. Choć usuwanie symboli komentarza poprzedzających większość sekcji pliku Configuration nie wymaga żadnego wysiłku, trzy z sekcji po-winny pozostać w formie komentarza. Moduł cern_meta_module używany jest dla zapewnienia kompatybilności ze starą wersją serwera CERN. Moduł dld_module pozwala na obsługę dynamicznego dołą-czania kodu i nie jest używany w systemie Linux. Trzeci moduł, msql_auth_module, umożliwia obsługę dużych plików z hasłami użytkowników za pomocą mechanizmów SQL i jest bezużyteczny, o ile nie jest zainstalowany system Minerva SQL. Aby uruchomić proces generowania pliku Makefile na podstawie danych zapisanych w pliku Configuration, należy uruchomić skrypt Configure (zauważ, że polecenie to rozpoczyna się od wielkiej litery - musi być wpisane dokładnie tak, jak pojawia się na wydruku zawartości katalogu). W tym celu upewnij się, że jesteś zalogowany jako root i po prostu wpisz nazwę skryptu:
Configure
Na ekranie pojawi się kilka komunikatów, najprawdopodobniej takiej postaci:
Using Configuration as config file
Configured for FreeBSD platform
Informacje wyświetlane w drugim wierszu mogą być nieco inne, zależnie od wersji sys-temu Apache. Na koniec należy uruchomić program użytkowy make (który wymaga, by zainstalowany był kompilator języka C i kilka programów użytkowych):
make
Domyślnie, program make przetwarza plik o nazwie Makefile znajdujący się w kata-logu bieżącym. Następnie wyświetlonych zostanie kilka komunikatów generowanych przez kompilator (o ile został on zainstalowany - w przeciwnym przypadku pojawią się komunikaty o błędach) i program make, po czym program ten zakończy działanie. Wygenerowany zostanie plik wykonywalny o nazwie httpd, który zawiera program rezydentny do obsługi serwera HTTP. Jeśli spróbujesz go uruchomić, prawdopodobnie otrzymasz komunikat, że brakuje jakiegoś pliku - program httpd próbuje bowiem znaleźć plik konfiguracyjny (który zwykle nazywa się httpd.conf).
Edycja pliku konfiguracyjnego
Po samodzielnym skompilowaniu serwera Apache (albo jeśli otrzymałeś gotową, skompilowaną wersję) należy wprowadzić odpowiednie informacje do pliku konfigura-cyjnego, który zwykle nazywa się httpd.conf. W katalogu z systemem Apache powi-nien znajdować się podkatalog o nazwie conf, a w nim trzy pliki konfiguracyjne o na-zwach srm.conf-dist, access.conf-dist i httpd.conf-dist. Należy skopiować je, zmieniając nazwy plików w następujący sposób:
cp srm.conf-dist srm.conf
cp access.conf-dist access.conf
cp httpd.conf-dist httpd.conf
Otwórz plik httpd.conf za pomocą dowolnego edytora tekstu ASCII. Plik ten zawiera ogólne informacje o serwerze, takie jak numer portu, którego należy użyć, identyfika-tor użytkownika, który ma być właścicielem procesu itp. Większość tych informacji nie wymaga korekty, ale jeśli chcesz, możesz dostosować je do własnych wymagań. Na-stępnie otwórz plik srm.conf, zawierający dane o drzewie dokumentów dla stron głównych i specjalne instrukcje HTML. Również ten plik nie wymaga modyfikacji. Ostatni z plików konfiguracyjnych, access.conf, pozwala zdefiniować podstawowe poziomy dostępu do systemu - możesz dostosować go do własnych wymagań lub po-zostawić wartości domyślne. Serwer Apache dostarczany jest z trzema plikami konfiguracyjnymi, ale wszystkie zawarte w nich dane można umieścić w jednym pliku o nazwie httpd.conf. Przy konfigurowaniu systemu łatwiej jest jednak edytować trzy mniejsze pliki. Jeśli chcesz, aby Apache zignorował pliki ac-cess.conf i srm.conf, dodaj do pliku httpd.conf następujące polecenia:
AccessConfig /dev/null
ResourceConfig /dev/null
i usuń pliki access.conf i srm.conf. Aby uruchomić program httpd z przygotowanymi plikami konfiguracyjnymi, wydaj polecenie:
httpd -f sciezka/httpd.conf
sciezka to pełna ścieżka dostępu do katalogu, w którym znajduje się plik konfigura-cyjny. Opcja -f pozwala na użycie pliku konfiguracyjnego o dowolnej nazwie. Powyż-sze polecenie spowoduje uruchomienie programu rezydentnego httpd - możesz sprawdzić poleceniem ps, że faktycznie pozostaje on w pamięci.
Opcje serwera Apache httpd
Jedną z dostępnych opcji serwera httpd w wersji Apache poznałeś przed chwilą. Poza nią istnieje jeszcze tylko kilka innych opcji, oto ich lista:
-d pozwala podać główny katalog dokumentów,
-f umożliwia podanie nazwy pliku konfiguracyjnego serwera,
-h pozwala wyświetlić listę obowiązujących dyrektyw (pochodzących z pliku Configuration),
-v podaje numer wersji,
-X załącza wyświetlanie informacji przydatnych w czasie uruchamiania systemu.
W nowych wersjach serwera Apache pojawia się zwykle kilka innych opcji, ale większość z nich powoduje tylko drobne zmiany w zachowaniu lub też ułatwia uruchamia-nie systemu. Pełną listę opcji możesz otrzymać wydając polecenie:
httpd -?
lub też przeglądając strony man czy dokumentację dostępną w węźle apache.org w katalogu /docs.
Konfigurowanie serwera Apache w niewielkim węźle WWW
Aby nie komplikować niepotrzebnie zagadnienia, założymy że chcesz używać Apache jako serwera WWW dla sieci lokalnej. Komputery w tej sieci będą łączyć się z serwe-rem za pomocą przeglądarek internetowych. Podany poniżej prosty przykład pokazuje, w jaki sposób można skonfigurować serwer Apache w prostej sieci; można z łatwością zmodyfikować konfigurację tak, by udostępniać strony WWW w sieci Internet. Rozpoczniemy od skonfigurowania głównego katalogu z dokumentami. Załóżmy, że serwer ma działać w systemie o nazwie darkstar. Według konwencji używanej przez Apache komputer ten nazywany będzie site.darkstar. Pliki konfiguracyjne znajdą się w podkatalogu conf katalogu site.darkstar (na przykład /usr/web/site.darkstar/ conf). Katalog główny dokumentów można zdefiniować za pomocą opcji -d polecenia httpd:
httpd -d /usr/web/site.darkstar
Wszystkie dokumenty udostępniane w węźle WWW powinny znajdować się w katalo-gu głównym dokumentów lub w którymś z jego podkatalogów - w dokumentach HTML muszą wówczas znaleźć się odpowiednie odnośniki. Możliwe jest również dostosowanie wielu innych aspektów działania serwera Apache, ale jest to proces dość czasochłonny i jego wyjaśnienie zajęłoby pewnie ze sto stron. Jeśli chcesz dowiedzieć się więcej o systemie Apache, zapoznaj się z dokumentacją do-stępną w węźle apache.org albo zaopatrz się w jedną z książek poświęconych temu tematowi

Skrypty CGI
Przy omawianiu zagadnień związanych ze stronami WWW często używa się terminu GCI (ang. Common Gateway Interface, wspólny interfejs bramkowy). Na pewno nie uda się nam w tym rozdziale wyjaśnić wszystkich zagadnień związanych z tym inter-fejsem, postaramy się jednak przedstawić jego zastosowania i przybliżyć sposoby uży-cia. Jeśli zaangażujesz się w tworzenie bardziej złożonych stron WWW (językom HTML i Java przyjrzymy się w jednym z następnych rozdziałów), w końcu na pewno zechcesz skorzystać z możliwości oferowanych przez mechanizmy CGI - pozwalają one w znacznym stopniu rozszerzyć funkcjonalność stron WWW. Dlatego przyjrzymy się te-mu interfejsowi nieco bardziej szczegółowo.
Co to jest CGI?
Rozwinięcie skrótu CG
I - Common Gate Interface, wspólny interfejs bramkowy - nie ułatwia zrozumienia, do czego w rzeczywistości służy ten interfejs. Jego nazwa może być nieco myląca. Zasadniczo CGI pozwala na uruchamianie aplikacji za pośrednic-twem stron WWW. Można na przykład na stronie WWW umieścić przycisk uruchamia-jący program, którego zadaniem jest wyświetlanie danych statystycznych o częstości odwiedzania Twojego węzła WWW. Po kliknięciu na tym przycisku zostanie urucho-miony program wykonujący odpowiednie obliczenia. CGI jest interfejsem pomiędzy takim programem a kodem w języku HTML; pozwala on na przesyłanie danych w obie strony pomiędzy kodem HTML i aplikacjami, nie muszącymi wcale stanowić czę-ści strony WWW. CGI wykonuje jeszcze inne operacje, ale są one zwykle ukryte przed użytkownikiem. Programy CGI nie muszą w zasadzie być uruchamiane za pośrednictwem stron WWW, choć rzadko uruchamia się je w inny sposób, głównie ze względu na fakt, że do prawi-dłowego działania wymagają one dość specyficznego i dość trudnego do emulacji śro-dowiska. Co to oznacza w praktyce? Kiedy uruchamiasz stronę WWW napisaną w języku HTML, serwer ustawia wartości wielu zmiennych środowiskowych. Są one używane do kontrolowania programów i komunikowania się z nimi, jak również do wielu innych ce-lów. Kiedy użytkownik klika na przycisku uruchamiającym program zewnętrzny, war-tości tych zmiennych środowiskowych są wykorzystywane do przesyłania odpowied-nich danych (takich jak na przykład identyfikator użytkownika, który uruchomił pro-gram, czas systemowy itp.). Uruchamiany program odsyła przetworzone informacje z powrotem do serwera WWW również za pośrednictwem odpowiednich zmiennych śro-dowiskowych. Mówiąc o programowaniu skryptów CGI mamy na myśli pisanie programów wykorzy-stujących interfejs pomiędzy stronami w języku HTML i innymi aplikacjami. CGI jest właśnie tym interfejsem. Można by zapytać: no i co z tego? Możliwości oferowane przez język HTML są dość ograniczone. CGI pozwala obejść te ograniczenia i umieszczać na stronach WWW obiekty zachowujące się w zasadzie w dowolny sposób. Jeśli na przykład chcesz na stronie WWW umożliwić obliczenie parametrów statystycznych danych dostarczanych przez użytkownika, bardzo wygodnie będzie zrobić to za pomocą interfejsu CGI, prze-kazując wprowadzone dane jako wartość odpowiednich zmiennych środowiskowych i zwracając gotowe wyniki do serwera WWW. Nawet na najprostszej stronie WWW można zamieścić mnóstwo elementów, które mogłyby zostać wykonane za pomocą interfejsu CGI - właśnie dlatego jest on tak popularny. Mechanizmy obsługi CGI są zwykle wbudowane w serwery WWW, choć nie muszą one istnieć we wszystkich programach tego typu. Prawie wszystkie dostępne obecnie serwery WWW (za wyjątkiem bardzo wczesnych wersji i kilku wersji okrojonych), na przykład oferowane przez NCSA, Netscape czy CERN, obsługują interfejs CGI. CGI i HTML
Aby uruchomić aplikację CGI ze strony WWW, musisz wysłać odpowiednie żądanie do serwera WWW. Żądanie to realizowane jest za pośrednictwem odpowiedniej meto-dy, odpowiadającej za wywoływanie programów CGI (przez metodę rozumie się od-powiednią procedurę lub funkcję). Protokół HTTP (HyperText Markup Language) za-wiera wiele metod, a to, którą z nich należy wywołać do uruchomienia programu CGI zależy od typu danych, jakie mają zostać przekazane do tegoż programu. Do tego za-gadnienia wrócimy za chwilę, najpierw pokażemy, w jaki sposób można osadzić kod CGI w dokumentach HTML. Język HTML generalnie opiera się na zastosowaniu znaczników (ang. tags) - dokład-niej problem ten omówimy w następnym rozdziale. Do uruchomienia programu CGI również używa się jednego ze znaczników, podając nazwę programu, który ma zostać wykonany, i tekst, który zostanie wyświetlony na stronie WWW po przetworzeniu kodu w języku HTML. Przykładowo, poniższy znacznik spowoduje wyświetlenie na stronie WWW tekstu Kliknij tu, aby wyświetlić informacje statystyczne:
< a href="licz_stat" > Kliknij tu, aby wyświetlić informacje statystyczne < /a >
Kiedy użytkownik kliknie na wyświetlanym tekście, uruchomiony zostanie program o nazwie licz_stat (znaczniki i definiują zakotwiczenie - ang. anchor - tekst zawarty pomiędzy nimi jest traktowany jako odnośnik do jakiegoś innego obiek-tu; rozmieszczenie tego typu znaczników decyduje o ostatecznej formie strony WWW). Jak przekonasz się czytając następny rozdział, poświęcony językowi HTML, można w ten sposób uruchomić również program dostępny w innym systemie, podając jego na-zwę domenową. Przykładowo, poniższy fragment kodu w języku HTML definiuje od-nośnik, po kliknięciu którego uruchamiany jest skrypt zapisany w systemie www.tpci.com bez względu na to, w jakim systemie zapisana jest sama strona WWW:
< a href="www.tpci.com/stats.cgi" > Wyświetl informacje statystyczne < /a >
Jeśli użytkownik wybierze tekst Wyświetl informacje statystyczne, zostanie nawiązane połączenie z serwerem www.tpci.com i uruchomiony zostanie odpowiedni program, nawet jeśli serwer ten znajduje się w innym kraju (pod warunkiem, że da się nawiązać połączenie). Do uruchamiania programów CGI zwykle wykorzystuje się trzy metody: GET, HEAD i POST (wszystkie one są elementami języka HTTP). Każdej z tych metod używa się w nieco inny sposób, więc przyjrzymy się im z osobna. Metoda GET używana jest wówczas, gdy aplikacja CGI spodziewa się przesłania da-nych poprzez zmienną środowiskową QUERY_STRING. Aplikacja odczytuje i dekoduje wartość tej zmiennej, interpretując ją odpowiednio według potrzeb. Metoda GET jest używana zwykle wtedy, gdy aplikacja powinna otrzymać jakieś dane, ale nie musi zwracać żadnych wyników. Metoda HEAD jest bardzo podobna do metody GET, z tym że serwer transmituje do klienta tylko nagłówki HTTP. Informacje wchodzące w skład głównej części wiado-mości są ignorowane. Taka metoda może przydać się na przykład do przesyłania iden-tyfikatora użytkownika. Metoda POST jest o wiele bardziej elastyczna i pozwala użyć standardowego urządze-nia wejściowego (stdin) do odbierania danych. Wartość zmiennej środowiskowej o nazwie CONTENT_LENGTH pozwala aplikacji zorientować się, jakiej liczby danych ma się spodziewać. Metoda POST została opracowana po to, by umożliwić zmianę zacho-wania się serwera, ale wielu programistów używa jej do wszelkich zadań, ponieważ po-zwala ona uniknąć obcinania adresów URL, co może zdarzyć się podczas wykorzy-stywania metody GET. Interfejs CGI korzysta z wielu zmiennych środowiskowych, są one omówione ze szcze-gółami w każdej książce poświęconej programowaniu z wykorzystaniem tego interfej-su. Opisywanie tych zmiennych w naszej książce bez podania przykładów ich zasto-sowania byłoby stratą czasu.
CGI i Perl
Jeśli zainteresuje Cię programowanie z wykorzystaniem CGI, szybko zorientujesz się, że większość tego typu aplikacji tworzona jest za pomocą języka Perl (który został omówiony w rozdziale 28 "Perl"). Takie programy mogą być pisane w dowolnym języ-ku (wielu projektantów stron WWW tworzy programy CGI w takich językach, jak np. C, C++ czy Visual Basic, ponieważ języki te są im lepiej znane), ale Perl zdaje się być ulubionym językiem twórców stron WWW pracujących w systemach UNIX-owych. Przyczyna takiej popularności języka Perl staje się oczywista w momencie, gdy nau-czysz się nim posługiwać. Jest on językiem bardzo prostym, a jednocześnie potężnym i wydajnym. Jest również przenośny, dzięki czemu programy używające interfejsu CGI mogą praktycznie bez przeróbek działać w różnych systemach operacyjnych. Na stronach WWW można znaleźć mnóstwo skryptów w języku Perl. Wpisanie odpo-wiedniego zapytania w którejś z wyszukiwarek, na przykład Altavista, powoduje zna-lezienie setek dokumentów zawierających przykładowe skrypty, czekające tylko na to, abyś je załadował i przestudiował. Jednym z najczęściej używanych skryptów Perl jest skrypt obsługujący książkę gości (ang. GuestBook). Pozwala on użytkownikowi na wpisanie się do książki gości i pozostawienie komentarza dotyczącego odwiedzanej strony WWW. Zwykle skrypt taki rejestruje dane o imieniu i nazwisku użytkownika, je-go adres e-mail, pochodzenie (zwykle tylko miasto czy nawet kraj) i komentarze. Jest to dobry sposób na zorientowanie się, co też użytkownicy sądzą o udostępnianych przez Ciebie stronach WWW. Kiedy program obsługujący książkę gości zostanie uruchomiony, wyświetla na ekranie formularz, który należy wypełnić, a następnie uaktualnia bazę danych serwera w oparciu o wprowadzone dane. W Sieci dostępnych jest bardzo wiele wersji tego pro-gramu, na rysunku 52.1 przedstawiamy wyniki działania jednej z nich. Każdy ze skryptów obsługi książki gości nieco inaczej prezentuje się w oknie przeglą-darki, ale zazwyczaj ma on postać zbliżoną do tego przedstawionego na rysunku 52.1. Informacje wprowadzone przez użytkownika są zapisywane w bazie danych po stro-nie serwera, dzięki czemu administrator systemu ma do nich dostęp. Uruchomienie skryptu dostarczającego informacji o domenie (domain name lookup) powoduje przesłanie serii standardowych żądań HTTP pomiędzy serwerem i klientem i ostatecznie wyświetlenie danych . Jak widać, dane te przedstawione są za pomocą czcionki o standardowych parametrach, ponieważ skrypt nie stara się sformatować ich w żaden określony sposób. Takie rozwiązanie jest wystarczające w przypadku prostych aplikacji CGI.

Podstawy języka HTML
Utrzymywanie serwera WWW w sytuacji, gdy nie udostępniamy żadnych stron WWW, nie ma większego sensu, więc trzeba skonfigurować go tak, by inni użytkownicy sieci mieli możliwość przeglądania naszych zasobów. Do tego celu używane są adresy w formacie URL (ang. Uniform Resource Locator, jednolity lokator zasobów) wskazu-jące na poszczególne pliki. Użytkownik chcący uzyskać dostęp do danego pliku (zaso-bu) musi znać tylko jego URL. Jeśli nie prowadzisz zbyt rozbudowanej strony głównej, sprawa jest prosta: każdy, kto łączy się z Twoim systemem za pomocą przeglądarki WWW, zobaczy stronę o nazwie index.html, zapisaną w głównym katalogu z doku-mentami HTML, lub też informacje o zawartości tegoż katalogu w przypadku, gdy plik o nazwie index.html nie istnieje. Nie jest to jednak zbyt atrakcyjne rozwiązanie, dla-tego wielu użytkowników chce udostępniać bardziej wyszukane strony główne. Jeśli chcesz utworzyć własną stronę WWW, musisz nauczyć się posługiwać językiem HTML (HyperText Markup Language). Strona główna pełni zwykle funkcję głównego menu. Możliwe, że niektórzy użytkow-nicy nigdy jej nie zobaczą, wchodząc bezpośrednio do podkatalogów systemu lub też uzyskując dostęp do plików za pośrednictwem hiperłączy umieszczonych na jakichś innych stronach WWW. Mimo tego, wielu użytkowników woli rozpocząć przeglądanie zasobów od strony głównej. Strona główna ma zwykle nazwę index.html i znajduje się w głównym katalogu z dokumentami HTML. Tworzenie dokumentu w języku HTML nie jest zbyt trudne. Język ten opiera się na znacznikach (ang. tags), określających w jaki sposób mają być traktowane poszcze-gólne fragmenty dokumentu (na przykład jako nagłówki, jako główny tekst dokumen-tu, jako wykres itp.). Najtrudniejszym aspektem języka HTML jest prawidłowe umieszczanie wszystkich tych znaczników. Jego składnia jest bardzo ścisła - jeśli chcesz uzyskać dobre rezultaty, musisz się jej dokładnie trzymać Kiedyś wszystkie dokumenty HTML tworzone były za pomocą prostych edytorów tekstów. W miarę, jak strony WWW zdobywały coraz większą popularność, zaczęły powstawać edytory przystosowane do języka HTML, potrafiące rozpoznać i odpo-wiednio obsłużyć jego składnię. Wkrótce powstały dziesiątki edytorów HTML, filtrów i innych programów użytkowych wspierających i ułatwiających projektowanie stron WWW. Edytory HTML dostępne są dla wielu systemów operacyjnych. Programy do tworzenia dokumentów HTML Dokumenty HTML można tworzyć na wiele sposobów. Można używać do tego celu zwykłych edytorów tekstów, można również użyć narzędzi przeznaczonych specjalnie do pracy z tym językiem. Wybór jednej z tych metod zależy od indywidualnych prefe-rencji. Nie bez znaczenia jest również doświadczenie w tworzeniu stron WWW i to, czy akurat masz dostęp do odpowiednich narzędzi. Główną zaletą wspomnianych progra-mów narzędziowych jest fakt, że potrafią one sprawdzić poprawność składniową do-kumentu HTML. Są również zwykle nieco łatwiejsze w użyciu niż edytory nie dosto-sowane do obsługi języka HTML. Z drugiej strony, programiści mające większe do-świadczenie w tworzeniu stron WWW często używają edytora tekstów, do którego są przyzwyczajeni, posiłkując się co najwyżej filtrem lub programem kontrolującym po-prawność składniową dokumentu. Jeśli szukasz edytora lub filtra HTML, powinieneś odwiedzić węzeł CERN. Zajrzyj pod adres htpp://info.cern.ch/WWW/Tools i obejrzyj zawartość pliku Overview.html. Warto również zajrzeć do węzła NCSA, w którym pod adresem http://www.ncsa.uiuc.edu/SDG/ Software/Mosaic/Docs znajduje się dokument faq-software. html, zawierający aktualną listę dostępnych programów tego typu. Do tworzenia stron WWW można użyć dowolnego edytora tekstów, nie wyłączając ta-kich programów, jak vi czy emacs. Każdy edytor pozwala na wstawienie do tekstu dowolnego znacznika HTML, ale znaczniki te są traktowane na równi z pozostałym tekstem. Proste edytory nie potrafią sprawdzić, czy w dokumencie nie występują jakieś błędy składniowe, ponieważ nie "rozumieją" języka HTML. Dla edytora emacs i nie-których innych edytorów dostępne są rozszerzenia umożliwiające kontrolę składni w oparciu o proste szablony, ale nie wymuszają one poprawnej składni. Jeśli chcesz używać jednego z prostych edytorów tekstów, musisz bardzo uważnie sprawdzać składnię swojego dokumentu. Najłatwiej robić to importując dokument do jednego z edytorów HTML umożliwiającego sprawdzanie składni. Można również uruchomić przeglądarkę WWW i sprawdzić, czy dokument przedstawia się zgodnie z oczekiwaniami. Programy narzędziowe przeznaczone specjalnie do tworzenia dokumentów HTML pod kontrolą systemu Linux są dostępne w różnych zakątkach Internetu, ale nie są one aż tak popularne, jak analogiczne aplikacje przeznaczone do pracy w systemie DOS i Windows (dla tych systemów dostępne są dziesiątki programów tego typu). Jeśli w Twoim systemie zainstalowany jest DOS czy Windows, możesz po prostu wykorzy-stać odpowiednie oprogramowanie, a następnie przenieść stworzoną stronę WWW do systemu linuxowego. Dla systemu Windows dostępnych jest kilka popularnych edyto-rów HTML, takich jak HTML Assistant, HTMLed czy HoTMetaL (a także polski Pa-jączek - przyp. tłum.). Niektóre z tych programów, na przykład HoTMetaL, działają również w systemie X, czyli pod kontrolą Linuxa. Programy tego typu albo opierają się w całości na interfejsie graficznym i technologii przeciągnij-i-upuść, albo bazują na edycji pliku źródłowego w trybie tekstowym. Prawie wszystkie jednak posiadają me-chanizmy umożliwiające kontrolę składniową tworzonego dokumentu.
Tworzenie stron WWW w systemie Windows
Jak wspomnieliśmy wcześniej, programów przeznaczonych do tworzenia dokumentów HTML pracujących pod kontrolą Windows jest o wiele więcej niż linuxowych. Jeśli po-siadasz oba te systemy, możesz z łatwością tworzyć strony WWW pod Windows, a na-stępnie przenosić je do systemu Linux. Narzędzia do tworzenia dokumentów HTML w systemach DOS i Windows można podzielić na trzy kategorie: programy typu WYSIWYG (ang. What You See Is What You Get - To, co widzisz, jest tym, co otrzy-masz), pozwalające na bezpośrednią obserwację efektów pracy, programy nie oferują-ce takiej możliwości oraz filtry umożliwiające konwersję do formatu HTML dokumen-tów innego typu (na przykład tworzonych przez programy Word for Windows czy WordPerfect). Prawdopodobnie najpopularniejszym edytorem HTML dla systemu Windows jest pro-gram HTML Assistant. Jest to edytor tekstów wzbogacony o kilka dodatkowych me-chanizmów i interfejs graficzny pozwalający łatwo wstawiać najpopularniejsze znacz-niki języka HTML. Możliwa jest także równoczesna edycja kilku dokumentów, jak również przenoszenie i kopiowanie fragmentów tekstu pomiędzy nimi. Jeśli chcesz załadować program HTML Assistant za pomocą FTP, zaloguj się jako anonimowy użytkownik do systemu ftp.cuhk.hk i poszukaj w katalogu /pub/www/windows/util pliku o nazwie htmlasst.zip. Program HTML Assistant ma jedno dość poważne ograniczenie: rozmiar tworzonych za jego pomocą plików nie może przekraczać 32 kB. W związku z tym nie nadaje się on do tworzenia większych stron WWW, chyba że podzielone zostaną one na kilka części, a następnie połączone za pomocą innego edytora. Przy próbie edycji pliku o rozmiarze większym niż 32 kB lub utworzenia pliku zawierającego większą ilość da-nych wyświetlany jest komunikat Out of Memory (brak pamięci) i może się zdarzyć, że efekty pracy zostaną utracone. HTML Assistant posiada dobrej jakości pomoc dostępną podczas pracy, a także inne przydatne możliwości, takie jak na przykład możliwość automatycznego ładowania edytowanego dokumentu do przeglądarki, dzięki czemu można na bieżąco śledzić efekty swojej pracy. Przełączanie się pomiędzy edytowanym kodem a wynikiem jego sformatowania nie stanowi żadnego problemu, co pozwala obejść niektóre z niedo-godności edytowania dokumentu w trybie tekstowym. HTML Assistant ułatwia również tworzenie odnośników hipertekstowych, przechowu-jąc listę ostatnio używanych adresów w formacie URL i pozwalając na łatwe przecho-dzenie pomiędzy nimi. Innym programem służącym do tworzenia stron WWW jest HTMLed, również działa-jący pod kontrolą systemu Microsoft Windows. Jest to szybki edytor, obsługujący znaki międzynarodowe i potrafiący zapisywać i odczytywać pliki zarówno w formacie DOS-owym, jak i UNIX-owym. Użyteczna jest możliwość konwersji adresów URL przechowywanych w pliku MOSAIC.INI do dokumentu HTML z zachowaniem jego oryginalnej struktury. Względnie prosta (w porównaniu z edytorem HTML Assistant) jest również konwersja plików tekstowych do formatu HTML. Kopię programu HTMLed można załadować za pośrednictwem anoni-mowego FTP z serwera ftp.cuhk.hk - program ten znajduje się w pliku o nazwie htmed10.zip (lub nieco innej, zależnie od wersji programu) w katalogu /pub/www/windows/util. Program HTMLed nie jest obsługiwany za pomocą wielowierszowego paska z przyci-skami odpowiadającymi poszczególnym znacznikom HTML, jak miało to miejsce w przypadku programu HTML Assistant. Zamiast tego poszczególne znaczniki wybiera się z rozwijanego menu lub paska narzędzi, który można również dostosować do wła-snych potrzeb. Można również utworzyć kilka pasków narzędzi, osadzając w nich po-szczególne znaczniki reprezentowane przez ikony. Paski narzędzi mogą być swobodnie rozmieszczane w obrębie okna aplikacji. Aktualna wersja programu HTMLed nie za-wiera pomocy dostępnej podczas pracy, ale w przyszłych wersjach pomoc taka ma zostać wprowadzona. HTMLed dość sprytnie wstawia znaczniki do dokumentu, zapobiegając umieszczaniu wielu znaczników w jednym wierszu tam, gdzie nie jest to dozwolone. Pozwala to uni-kać najczęściej występujących błędów składniowych dokumentów HTML. Podobnie jak program HTML Assistant, HTMLed udostępnia przycisk pozwalający obejrzeć efekty pracy bezpośrednio w przeglądarce kodu HTML. Program HoTMetaL firmy Softquad pracuje w trybie zbliżonym do WYSIWYG, w związku z czym jest on prawdopodobnie najatrakcyjniejszy z punktu widzenia użyt-kowników nie mających doświadczenia w tworzeniu dokumentów HTML. HoTMetaL pracuje pod kontrolą systemu Windows i w niektórych systemach UNIX-owych. Wer-sja o nieco ograniczonej funkcjonalności (ale wciąż o całkiem sporych możliwościach) jest dostępna za darmo, natomiast pełną wersję komercyjną o nazwie HoTMetaL Pro można zakupić od firmy Softquad. Kopię programu HoTMetaL można załadować w większości węzłów roz-prowadzających oprogramowanie użytkowe, takich jak NCSA czy CERN. Zajrzyj na przykład na stronę http://info.cren.ch/hypertext/ WWW/Tools/HoTMetaL.html HoTMetaL to edytor zintegrowany z przeglądarką WWW. Nie działa on w pełni w try-bie WYSIWYG, ale pozwala dobrze ocenić widok końcowy tworzonego dokumentu. HoTMetaL prawie że wymusza użycie prawidłowej składni języka HTML, sprawdza-jąc czy na końcu i początku dokumentu występują odpowiednie znaczniki i pozwala-jąc wstawiać znaczniki tylko tam, gdzie są one dozwolone (pozwala to oszczędzić spo-ro czasu nowym użytkownikom języka HTML). HoTMetaL potrafi również sprawdzić składnię dokumentu i poinformować o występu-jących problemach ze znacznikami (ta możliwość przydaje się szczególnie przy impor-towaniu dokumentów stworzonych za pomocą innych edytorów, ponieważ HoTMetaL po prostu nie pozwoli na wstawienie nieprawidłowego znacznika). Niestety, sygnaliza-cja błędów nie działa doskonale - nie zawsze wiersz, w którym wskazywane jest wy-stąpienie błędu, jest faktycznie tym powodującym problemy. HoTMetaL ma również kilka innych wad. Obrazki GIF wstawiane do dokumentu nie są widoczne w oknie tego programu (aby je obejrzeć, trzeba uruchomić przeglądarkę stron WWW). Poza tym niektóre dokumenty nie odpowiadające dokładnie składni ję-zyka HTML nie mogą zostać załadowane do edytora, co może być problemem w przypadku modyfikowania starszych dokumentów HTML. Rozwiązaniem alternatywnym do zastosowania dedykowanego edytora HTML jest wzbogacenie edytora pracującego w trybie WYSIWYG o możliwość obsługi kodu HTML. Najczęściej tego typu rozwiązania używane są z takimi programami, jak Word for Windows, WordPerfect czy Word for DOS. Dostępnych jest kilka takich rozszerzeń, różniących się swoją złożonością. Większość z nich działa w systemie Windows, choć kilka przeniesiono również na platformy linuxowe. Główną zaletą użycia tego typu rozwiązań jest fakt, że przy tworzeniu dokumentów HTML można posługiwać się ulubionym i dobrze znanym edytorem korzystając z ofe-rowanego przez niego trybu WYSIWYG. Choć programy te nie są w stanie przedstawić dokumentu dokładnie tak, jak pojawi się on w przeglądarce WWW, mogą zrobić to na tyle precyzyjnie, by umożliwić uniknięcie większości poważniejszych problemów. Dla programu Microsoft Word for Windows dostępny jest szablon o nazwie CU_HTML, który umożliwia tworzenie stron WWW niemalże w trybie WYSIWYG. Pod względem wyglądu CU_HTML nie różni się zasadniczo od programu Word w zwykłej postaci, dodając tylko nowy pasek narzędzi i pozycję rozwijanego menu. CU_HTML udostępnia zestaw predefiniowanych stylów i pasek narzędzi umożliwiający łatwy do-stęp do najczęściej wykorzystywanych funkcji. Upraszcza również wstawianie odno-śników hipertekstowych i inne zadania spędzające sen z powiek nowym użytkowni-kom języka HTML. W wielu przypadkach wykorzystywane są odpowiednie okna dia-logowe, znacznie ułatwiające obsługę programu. Najważniejszą wadą szablonu CU_HTML jest fakt, że nie umożliwia on edycji istnie-jących dokumentów HTML nie zapisanych w formacie programu Word. Przy tworze-niu dokumentu HTML za pomocą szablonu CU_HTML zapisywane są dwie wersje dokumentu, jedna w formacie HTML, a druga w formacie .DOC. Dokument nie może być edytowany, jeśli nie są dostępne obie wersje pliku. Istniejący dokument można za-importować, ale niestety powoduje to utratę wszystkich znaczników. ANT_HTML to podobny do CU_HTML szablon rozszerzający funkcjonalność pro-gramu Word for Windows. Pod niektórymi względami szablon ten jest lepszy od CU_HTML, pod innymi zaś nieco mu ustępuje. Zawiera lepszy system pomocy i wy-godniejszy pasek narzędzi, potrafi również automatycznie otwierać i zamykać znacz-niki w zależności od potrzeb.
Tworzenie dokumentów HTML w systemie Linux
Wśród użytkowników Linuxa popularność zdobył program narzędziowy o nazwie tkWWW, oparty na języku Tcl i jego rozszerzeniu pozwalającym na korzystanie z inter-fejsu X o nazwie Tk. Jest to kombinacja przeglądarki WWW i edytora HTML pracują-cego w trybie zbliżonym do WYSIWYG. Choć program ten pierwotnie przeznaczony był tylko dla systemów UNIX-owych, powstały jego wersje dla innych systemów ope-racyjnych, w tym Windows i Macintosh. Program tkWWW można załadować poprzez anonimowe FTP z węzła ftp.aud.alcatel.com - znajduje się on w katalogu /tcl. Tcl i Tk można załadować z różnych serwerów, w zależności od systemu operacyj-nego, ale języki te są dołączone do większości standardowych dystrybucji Linuxa. Jeśli chcesz załadować wersje tych języków z sieci Internet, za-cznij poszukiwania od anonimowego węzła FTP ftp.aud. alca-tel.com - zajrzyj do katalogu tcl/extension. Warto również zaj-rzeć na oficjalną stronę poświęconą językom Tcl/Tk pod adresem http://www.sunscript.com Podczas tworzenia strony WWW w trybie edycji programu tkWWW można w każdej chwili przełączyć się w tryb przeglądarki i sprawdzić, czy dokument jest sformatowany prawidłowo. Również w trybie edycji większość formatowania jest odpowiednio od-wzorowywana na ekranie, ale widoczne są także znaczniki. Takie rozwiązanie umożli-wia szybkie opracowywanie nowych stron WWW. Niestety program tkWWW korzysta z interfejsu udostępnianego przez system Tk, co powoduje że na przeciętnych komputerach działa on dość wolno. Poza tym przeglą-darka wbudowana w tkWWW również nie jest najwyższych lotów, opiera się na standar-dowych ramkach oferowanych przez Tk. Mimo tego tkWWW jest bardzo atrakcyjnym narzędziem do tworzenia stron WWW - jeśli nie w całości, to przynajmniej w ogólnym zarysie, szczególnie wtedy, gdy znasz język Tcl. Innym rozwiązaniem jest użycie filtra HTML. Program tego typu pozwala utworzyć dokument HTML w oparciu o dokument pochodzący z jakiegoś edytora tekstów (nie wyłączając oczywiście zwykłych plików ASCII). Filtry są przydatne w przypadku, gdy używasz edytora potrafiącego formatować tekst w odpowiedni sposób, jak na przy-kład Microsoft Word. Filtry HTML są szczególnie użyteczne, jeśli zamierzasz nadal pracować w swoim edy-torze tekstów, a potrzebujesz tylko narzędzia umożliwiającego konwertowanie doku-mentów do formatu HTML. Są one dość szybkie i łatwe w obsłudze - zwykle wymagają tylko podania nazwy dokumentu, na podstawie którego ma być wygenerowany plik w for-macie HTML. Poziom sprawdzania poprawności składniowej i raportowania zależy od konkretnej implementacji filtra. Filtry HTML są dostępne dla większości typów dokumentów, a wiele z nich działa bez-pośrednio pod kontrolą Linuxa; czasem są one również rozprowadzane w postaci kodu źródłowego, dającego się bez żadnych modyfikacji skompilować w systemie Linux. Dokumenty programu Word w wersji dla Windows i DOS można przełożyć na język HTML za pomocą omówionych wcześniej szablonów CU_HTML i ANT_HTML. Po-jawiają się również samodzielne programy do konwersji dokumentów .DOC. Program o nazwie WPTOHTML pozwala utworzyć dokument HTML na podstawie dokumentu w formacie programu Word Perfect. Jest on w zasadzie zestawem makropoleceń pro-gramu Word Perfect w wersji 5.1 i 6.0. Filtra tego można również używać z innymi for-matami plików, które mogą być zaimportowane do edytora Word Perfect. Pliki LaTeX i TeX mogą zostać przełożone na język HTML za pomocą kilku różnych programów. Dla systemu Linux dostępnych jest sporo tego typu aplikacji, na przykład LATEXTOHTML, który potrafi obsłużyć nawet równania znajdujące się w wierszu tekstu i odnośniki. Przy konwertowaniu prostszych dokumentów użyteczny może oka-zać się program VULCANIZE, który jest szybszy, ale nie potrafi radzić sobie z równa-niami matematycznymi. Oba te programy są skryptami napisanymi w języku Perl. Program LATEXTOHTML dostępny jest poprzez anonimowe FTP na ser-werze ftp.tex.ac.uk w katalogu pub/archive/support, pod na-zwą latextohtml. Program VULCANIZE natomiast można otrzymać na stronie WWW pod adresem http://plover.com/ vulcanize. Program RTFTOHTML pozwala tworzyć dokumenty HTML w oparciu o dokumenty w formacie RTF, obsługiwanym przez wiele edytorów tekstów - można więc zapisać dokument ze swojego ulubionego edytora do formatu RTF, a następnie przekonwerto-wać go do formatu HTML za pomocą programu RTFTOHTML. Program RTFTOHTML jest dostępny na stronie WWW pod adresem http://kali.usask.ca/r2h68k/html/overview.htm
Konserwacja dokumentów HTML
Rola autora strony WWW nie sprowadza się tylko do jej utworzenia i udostępnienia ca-łemu światu. Jeśli strona nie ma postaci prostego dokumentu tekstowego, to najpraw-dopodobniej znajduje się na niej sporo odnośników do innych stron i serwerów. Odno-śniki te muszą być regularnie weryfikowane. Co jakiś czas należy również sprawdzać prawidłowość udostępnianych stron, mając na uwadze fakt, że mogą czytać je ludzie z całego świata. Na szczęście istnieje kilka programów wspomagających sprawdzanie istniejących na stronie WWW hiperłączy. Pozwalają one również na wyszukiwanie innych węzłów czy dokumentów, do których odnośniki mógłbyś chcieć zamieścić na swojej stronie. Pro-gramy takie, często nazywane pająkami lub robotami, potrafią samodzielnie prze-mieszczać się w sieci, tworząc listę odpowiednich adresów (pająki są podobne do pro-gramów użytkowych Archie i Veronica, które jednak nie potrafią poruszać się w całym Internecie). Choć uważa się je za przydatne tylko dla użytkowników stron WWW (można za ich pomocą uzyskać listę węzłów, które warto odwiedzić), pająki i programy pokrewne mogą również przydać się autorom stron WWW, dostarczając informacji o potencjal-nie interesujących odnośnikach, które można zamieścić na stronie WWW. Jednym z bardziej znanych programów tego typu jest program o nazwie World Wide Web Worm, w skrócie WWWW. Pozwala on na wyszukiwanie słów kluczowych i używanie operato-rów logicznych. Potrafi przeszukiwać zarówno tytuły dokumentów, jak i same doku-menty; możliwe jest również użycie kilku innych trybów wyszukiwania (włącznie z wy-szukiwaniem wszystkich znanych stron WWW). Podobnym narzędziem jest program o nazwie WebCrawler, pozwalający dodatkowo na wyszukiwanie dowolnych słów kluczowych w treści dokumentów. Lista znalezio-nych dokumentów uporządkowana jest od najlepiej spełniających kryteria wyszuki-wania. Program World Wide Web Worm można załadować ze strony http:// guano.cs.colorado.edu/home/mcbryan/WWWWguano.html, natomiast WebCrawler dostępny jest pod adresem http://www. bio-tech.washington.edu/WebCrawler/WebCrawler.html. W przypadku dokumentów HTML bardzo często zdarza się, że w miarę upływu czasu umieszczone w nich hiperłącza tracą ważność, wskazując na pliki lub serwery które w rzeczywistości już nie istnieją (ponieważ zmieniła się ich lokalizacja albo zostały usunięte). Z tego powodu warto regularnie sprawdzać i uaktualniać wszystkie odnośniki na stronach WWW. Pomoże w tym program o nazwie HTML_ANALYZER, który po-trafi sprawdzić, czy wszystkie odnośniki na danej stronie są prawidłowe. Po sprawdze-niu danego dokumentu tworzy on plik tekstowy, do którego zapisuje listę wszystkich adresów, również tych nie będących odnośnikami. Przy następnym uruchomieniu sprawdza, czy odnośniki nadal prowadzą w te same miejsca. HTML_ANALYZER wykonuje trzy rodzaje testów: sprawdza, czy dokument wska-zywany przez odnośnik jest dostępny (ang. validation), sprawdza występujące w bazie danych adresy nie będące hiperłączami (ang. completness) i sprawdza, czy zostały za-chowane odpowiednie relacje pomiędzy hiperłączami i wskazywanymi przez nie do-kumentami (ang. consistency). Wszelkie odchylenia od normy są przedstawiane użyt-kownikowi. Użytkownicy programu HTML_ANALYZER muszą dość dobrze znać język HTML, system operacyjny i potrafić używać analizatorów sterowanych z wiersza poleceń. Program ten należy przed użyciem skompilować za pomocą programu narzędziowego make. Przed uruchomieniem programu HTML_ANALYZER trzeba utworzyć kilka ka-talogów, a podczas działania tworzy on kilka plików tymczasowych, które nie są usu-wane. Z tych powodów nie jest to program łatwy w obsłudze dla mniej doświadczo-nych użytkowników.
Podstawy języka HTML
Język HTML (HyperText Markup Language) jest dość prosty do opanowania i uży-wania, a ponieważ ostatnimi czasy pojawiły się nowe wersje tego języka, jest on rów-nież dość potężny. Nie będziemy nawet próbować nauczyć Cię języka HTML w tym jednym niewielkim rozdziale - spróbujemy jednak dokonać swego rodzaju przeglądu możliwości przez niego oferowanych i podać podstawowe informacje odnośnie jego używania na przykładzie prościutkich stron WWW. Jeśli widziałeś kiedykolwiek jakąś stronę WWW, widziałeś wyniki zastosowania języka HTML. HTML to język używany do opisu stron WWW - z jego pomocą definiuje się wygląd stron WWW pojawiających się w przeglądarce po połączeniu się z serwerem. Serwer przesyła instrukcje języka HTML do przeglądarki, która odpowiednio je inter-pretuje i formatuje wyświetlany dokument. Do wyświetlania dokumentów napisanych w języku HTML zwykle używa się przeglądarek WWW, choć zadanie to mogą również wykonać inne programy. Obecnie dostępna jest cała gama różnorakich przeglądarek WWW, rozpoczynając od najstarszej chyba aplikacji stworzonej w NCSA - Mosaic. Najczęściej używanymi przeglądarkami są Netscape Navigator i Microsoft Explorer. Jednak to, jakiego programu używasz do przeglądania stron WWW, nie ma w większo-ści przypadków większego znaczenia, ponieważ wszystkie one spełniają tę samą funk-cję - wyświetlają kod HTML odebrany od serwera. Przeglądarka WWW prawie zawsze działa jako klient, wysyłając żądania przesłania odpowiednich danych do serwera. Język HTML jest oparty na innym języku o nazwie SGML (Standard Generalized Markup Language), używanym do opisywania struktury dokumentu i ułatwiającym przenoszenie dokumentów pomiędzy różnymi edytorami tekstów. Język HTML nie określa sposobu, w jaki strona będzie wyświetlana - nie jest to język opisu strony, taki jak na przykład PostScript. Język HTML opisuje strukturę dokumentu. Pozwala wy-znaczyć fragment tekstu pełniący rolę nagłówka, zdefiniować treść dokumentu, okre-ślić położenie obrazków w tekście. Nie zawiera jednak dokładnych informacji o wy-glądzie strony - za to odpowiedzialna jest przeglądarka WWW. Dlaczego warto używać języka HTML? Przede wszystkim dlatego, że jest to mały ję-zyk, dzięki czemu możliwe jest szybkie przesyłanie jego poleceń za pośrednictwem sie-ci. Choć ze względu na swój niewielki rozmiar jest on nieco ograniczony, nowsze wersje coraz bardziej rozszerzają jego możliwości. Inną bardzo ważną zaletą tego języka (z której nie wszyscy zdają sobie sprawę) jest jego niezależność od urządzenia. Nie ma znaczenia, jakiego systemu używasz do przeglądania stron WWW - przeglądarka po-trafi przetworzyć plik HTML i wyświetlić go w danym systemie. To przeglądarka jest zależna od urządzenia, natomiast tworząc strony WWW, nie musisz zastanawiać się nad tym, w jakich systemach będą one przeglądane.
Jak wygląda język HTML?
Jak za chwilę się przekonasz, kod w języku HTML jest bardzo prosty. W większości składa się on z zestawu znaczników (ang. tags), opisujących początek i koniec elemen-tu struktury dokumentu (takiego jak na przykład nagłówek, akapit, obrazek, tabela itp.). Każdy z elementów powinien być otoczony znacznikiem rozpoczynającym (otwiera-jącym) i kończącym (zamykającym). Zanim zaczniemy, wyjaśnijmy kilka ważnych kwestii dotyczących znaczników. W ich nazwach nie są rozróżniane małe i wielkie litery i prawie zawsze występują one parami: znacznik otwierający i znacznik zamykający. Najczęściej spotykanym błędem skła-dniowym w dokumentach HTML jest nieprawidłowo zamknięty lub nie zamknięty znacznik. W wielu przypadkach strona z takim błędem będzie wyświetlana poprawnie, ale w innych okolicznościach może to spowodować poważne problemy z jej sforma-towaniem. Ten typ błędów można wyeliminować przez dokładne sprawdzanie kodu źródłowego. Nie wszystkie znaczniki występują w parach. Istnieje kilka znaczników "pojedynczych", istnieją również znaczniki będące swego rodzaju pojem-nikami (ang. containers) przechowującymi dodatkowe informacje. Tego typu znaczniki nie posiadają swych odpowiedników zamykających. Znaczniki zapisuje się w pojedynczych nawiasach trójkątnych. Nawiasy te informują przeglądarkę o tym, że ich zawartość należy traktować jako instrukcję języka HTML. Fragmenty kodu w języku HTML mają więc zwykle postać:
< nazwa_znacznika_otwierającego > tekst tekst tekst < nazwa_znacznika_zamykającego >
Tego typu para znaczników określa, w jaki sposób traktowany będzie tekst zawarty pomiędzy nimi. Jeśli na przykład są to znaczniki początku i końca nagłówka, tekst za-pisany pomiędzy nimi w przeglądarce będzie odpowiednio wyróżniony, np. wytłusz-czony czy powiększony. W jaki sposób tworzy się kod w języku HTML? Można to robić na kilka sposobów. Najprostszym z nich jest użycie dowolnego edytora ASCII. Upewnij się, że nie zapisu-jesz dokumentu HTML w jakimś specjalnym formacie, na przykład jako dokument programu Word, ponieważ przeglądarki WWW radzą sobie tylko i wyłącznie z plikami w formacie ASCII. Dostępne są również wyspecjalizowane edytory pozwalające na wstawianie znaczników po wybraniu ich z menu i śledzenie na bieżąco efektów forma-towania tworzonego dokumentu, które są bardzo przydatne przy pisaniu większych stron WWW, ale dla większości użytkowników prosty edytor tekstów w zupełności wy-starczy do poznania podstawowych zasad używania języka HTML.
Początek dokumentu HTML
Dokument HTML powinien rozpoczynać się od znacznika informującego, że jest on napisany właśnie w tym języku. Znacznik ten ma postać i na jego podstawie przeglądarka internetowa może zorientować się, że ma do czynienia z początkiem do-kumentu w języku HTML. Oto fragment kodu źródłowego przykładowej strony WWW:
< HTML >
< HEAD >
< TITLE > To jest moja strona WWW! < /TITLE > < /HEAD>
< BODY >
< H1 > To pierwszy nagłówek mojej strony głównej. < /H1 >
To fragment tekstu zamieszczonego na mojej stronie głównej. Mam nadzieję, że przypadła Ci ona do gustu.
< /BODY >
< /HTML >
Pierwszy i ostatni znacznik - czyli < HTML > i < /HTML > - wyznacza początek i koniec kodu w języku HTML. Ukośnik wchodzący w skład drugiego ze znaczników symboli-zuje koniec elementu strukturalnego. Znaczniki < HEAD > i < /HEAD > oznaczają część wstępną pliku; zwykle umieszcza się pomiędzy nimi tytuł strony i słowa kluczowe, które będą wyświetlane w wyszukiwarkach internetowych (pomiędzy tymi znacznikami dozwolone jest użycie tylko kilku innych znaczników). Znaczniki < TITLE > i < /TITLE > pozwalają zdefiniować tytuł dokumentu. Pomiędzy znacznikami < BODY > i < /BODY > umieszcza się treść dokumentu. Znaczniki < H1 > i < /H1 > pozwalają wstawić do dokumentu nagłówek pierwszego poziomu. Powyższy kod może zostać zinterpretowany przez dowolną przeglądarkę internetową . Przedstawiony powyżej przykładowy plik składa się z kilku wierszy tekstu - taki po-dział nie jest jednak konieczny i ma na celu tylko zwiększenie czytelności kodu. Jeśli chcesz, możesz wszystkie instrukcje umieścić w jednym, długim wierszu, ponieważ w języku HTML znaki białe są domyślnie ignorowane. Jednak ze względu na łatwość wyszukiwania ewentualnych usterek i czytelność kodu warto organizować kod w przej-rzysty sposób. Znacznik < TITLE > powinien zawsze występować w kontekście znacznika nagłówka (< HEAD > i < /HEAD >); używa się go do definiowania tytułu strony, który powinien opi-sywać jej zawartość. Strona może posiadać tylko jeden tytuł. Pomiędzy znacznikami początku i końca nagłówka nie mogą występować żadne inne znaczniki. Tytuł strony powinien być w miarę krótki, a jednocześnie dawać jasne informacje o zawartości strony, dzięki czemu użytkownicy przeglądający dany dokument będą mogli go łatwo zidentyfikować. Znaczniki < BODY > i < /BODY > określają początek i koniec treści dokumentu. Zwykle w dokumencie występuje dokładnie jedna taka para. Wszystkie instrukcje określające zawartość strony, tekst, odnośniki, grafiki itd. powinny znaleźć się pomiędzy tymi znacznikami. W języku HTML zdefiniowanych jest kilka poziomów nagłówków, dzięki czemu możliwe jest tworzenie rozdziałów, podrozdziałów itd. W przedstawionym wcześniej przykładzie użyliśmy nagłówka definiowanego przez znacznik < H1 >, czyli nagłówka pierwszego, najwyższego poziomu. Jeśli struktura dokumentu jest wielopoziomowa, warto zastosować kilka rodzajów nagłówków. Oto przykładowy dokument:
< HTML>
< HEAD>
< TITLE> To jest moja strona WWW! < /TITLE> < /HEAD>
< BODY>
< H1> To nagłówek typu H1. < /H1>
To fragment tekstu.
< H2> To nagłówek typu H2. < /H2>
To inny fragment tekstu.
< H3> To nagłówek typu H3. < /H3>
Fragment tekstu opisany nagłówkiem poziomu trzeciego.
< H3> To kolejny nagłówek typu H3. < /H3>
Inny fragment tekstu opisany nagłówkiem poziomu trzeciego.
< H2> Następny nagłówek typu H2. < /H2>
Tekst opisany nagłówkiem H2.
< /BODY>
< /HTML>
Poszczególne nagłówki różnią się nieco od siebie - nagłówki wyższego poziomu są zwykle nieco większe i bardziej się wyróżniają. Dzięki temu możliwe jest podzielenie zawartości strony WWW na jednostki logiczne i przydzielenie każdej z nich nagłówka odpowiedniego poziomu. Nagłówków można używać tak, jak byłyby one stosowane w książce: tekst opisany nagłówkiem pierwszego poziomu (< H1 >) może zawierać kilka fragmentów opisanych nagłówkami drugiego poziomu (< H2 >), zawierających z kolei fragmenty opisane nagłówkami trzeciego poziomu (< H3 >) itd. Choć nie ma żadnych formalnych ograniczeń co do używania i mieszania poziomów nagłówków (nic nie stoi na przeszkodzie, aby na przykład używać tylko nagłówków trzeciego poziomu), zdro-wy rozsądek zwykle pomaga w określeniu prawidłowej struktury tworzonego dokumentu.
Akapity
A co z akapitami? Istnieje kilka sposobów uzyskania prawidłowego podzielenia tekstu na akapity, ponieważ reguły zmieniały się w kolejnych wersjach języka HTML. Naj-prostszym podejściem jest jednak użycie znaczników < P > i < /P > (ang. paragraph), wyznaczających zakres tekstu wchodzącego w skład pojedynczego akapitu. Oto przy-kładowy dokument w języku HTML zawierający trzy akapity:
< HTML>
< HEAD>
< TITLE> Witamy na pierwszej stronie WWW! < /TITLE> < /HEAD>
< BODY>
< H1> To nagłówek pierwszego poziomu. < /H1>
< P> To jest pierwszy akapit. Jest on bardzo interesujący i ze względu na jego ogromne walory dydaktyczne warto go przeczytać kilka razy. < /P>
< P> To drugi akapit. Nie jest on już aż tak ekscytujący jak pierwszy akapit, ale trudno pisać bardzo ekscytujące akapity tak późno w nocy. < /P>
< P> Oczywiście ostatni akapit musi wstrząsnąć czytelnikiem - tylko wtedy będzie on zadowolony. Ale nie zawsze musimy spełniać wszystkie zachcianki czytelników. < /P>
< /BODY>
< /HTML>
Zauważ, że poszczególne akapity są rozdzielone, a pomiędzy nimi zostały wstawione odpowiednie odstępy. Co jednak stało by się, gdyby znaczniki akapitów zostały pominięte? Ponieważ znaki białe - w tym symbole nowego wiersza -są ignorowane przez przeglądarkę stron WWW, cały tekst zostałby wyświetlony jako pojedynczy akapitDo rozdzielania poszczególnych akapitów należy więc używać znaczników < P > i < /P >. Pamiętaj o tym, że wstawienie nawet większej liczby pustych wierszy pomiędzy fragmentami tekstu nie spowoduje potraktowania ich jako osobnych akapitów - znaki nowego wiersza zostaną zignorowane i tekst zostanie potraktowany jako pojedynczy akapit. Mówiąc ściślej, użycie znacznika

do oznaczenia końca akapitu nie jest konieczne, ponieważ znacznik < P > powoduje wymuszenie rozpoczę-cia nowego akapitu. Znacznik < P > jest więc jednym ze znaczników, które nie muszą występować wraz ze swym odpowiednikiem zamykającym (czyli < /P >). Mimo tego, dobrym zwyczajem jest zamykanie również tego znacznika. A co z komentarzami w kodzie dokumentów HTML? Przecież może zdarzyć się, że będziesz chciał zapisać w dokumencie informację o jego autorstwie, skomentować fragment kodu itp. Komentarz można wstawić do dokumentu w następujący sposób:
< !- To jest komentarz - >
Komentarz powinien być otoczony nawiasami trójkątnymi, jego pierwszym znakiem powinien być symbol wykrzyknika, a na początku i końcu komentarza powinien wy-stąpić myślnik. Oto przykład kodu w języku HTML zawierającego komentarze:
< HTML>
< !- Autor: TJP, 12/12/95; v1.23 - >
< HEAD>
< TITLE> Witam na mojej stronie WWW! < /TITLE> < /HEAD>
< BODY>
< H1> To nagłówek pierwszego poziomu. < /H1>
< !- ta sekcja dotyczy znaczników akapitu - >
< P> To jest pierwszy akapit < /P>
< /BODY>
< /HTML>
Hiperłącza
Odnośniki pozwalające łatwo przejść do innego fragmentu dokumentu czy innego dokumentu są bardzo ważnym aspektem stron WWW. W języku HTML odnośniki takie tworzy się w bardzo prosty sposób. Rozpoczynają się one od znacznika początku odnośnika < A>, a kończą znacznikiem < /A> (ang. anchor - zakotwiczenie; nazwa ta wzięła się od faktu, że odnośnik jest "zakotwiczony" pomiędzy tymi znacznikami). Znacznik < A > różni się nieco od innych przedstawionych wcześniej znaczników, ponieważ pomiędzy nawiasami trójkątnymi może znaleźć się dodatkowy tekst. Oto przykład:

< A HREF="strona_2.html">Idź do strony 2< /A>
W powyższym przykładzie tekst znajdujący się pomiędzy znacznikami zostanie wy-świetlony na ekranie, dzięki czemu użytkownik zobaczy tekst Idź do strony 2, zwykle podkreślony czy wyróżniony w jakiś inny sposób wskazujący, że jest on odno-śnikiem. Jeśli użytkownik kliknie na takim odnośniku, zostanie odczytana wartość pola HREF wchodzącego w skład znacznika , po czym do przeglądarki zostanie zała-dowany dokument o nazwie strona_2.html. Skrót HREF pochodzi od angielskich słów Hypertext Reference; można po nim podać nazwę pliku lub URL, do którego bę-dzie prowadził dany odnośnik. Odnośników można używać zarówno w tekście dokumentu, jak i na przykład jako osobnych pozycji menu. Poniższy dokument HTML prezentuje możliwość wstawienia odnośnika znajdującego się w osobnym akapicie.
< >
< HEAD>
< TITLE> To jest moja strona WWW! < /TITLE> < /HEAD>
< BODY>
< H1> To pierwszy nagłówek mojej strony głównej. < /H1>
To fragment tekstu zamieszczonego na mojej stronie głównej. Mam nadzieję, że przypadła Ci ona do gustu. Jeśli chcesz dowiedzieć się o mnie czegoś więcej, wybierz < A HREF="o_autorze.html"> informacje o autorze, < /A> a przedstawię Ci wszystkie moje zalety. < /P>
< P>< A HREF="biblio.html">Bibliografia< /A>
< /BODY>
< /HTML>
Każdy z odnośników jest podkreślony, dzięki czemu łatwo jest go zidentyfikować (w niektórych przeglądarkach zamiast podkreślenia stosowana jest zmiana koloru tekstu lub też wyróżnienie innego typu). Kiedy odnośnik prowadzi do innego dokumentu, trzeba poprawnie podać nazwę pliku, w którym jest on zapisany. Można to zrobić na dwa sposoby: podając nazwę pełną lub względną. Nazwa pełna zawiera ścieżkę dostępu do pliku, natomiast nazwa względna jest odniesiona do bieżącego położenia dokumentu. Oto przykład odnośnika do pliku określonego za pomocą nazwy pełnej:
A HREF="/usr/tparker/html/home.html">
Względne ścieżki dostępu odniesione są do bieżącego położenia dokumentu i mogą zawierać polecenia służące do przemieszczania się w strukturze katalogów, na przy-kład:
< A HREF="../home.html" >
< A HREF="../../html/home.html" >
Odnośniki do innych dokumentów dostępnych za pomocą adresów w formacie URL definiuje się w ten sam sposób - wystarczy tylko zamiast nazwy pliku podać lokator URL. Oto przykładowy odnośnik prowadzący do strony głównej wyszukiwarki Ya-hoo!:
< A HREF="http://www.yahoo.com">Yahoo!< /A>
W dokumencie można osadzić dowolną liczbę odnośników. Warto dołączać do nich jak najbardziej treściwe komentarze, dzięki czemu użytkownicy nie będą trafiać na strony, których być może wcale nie mieli zamiaru odwiedzać. Jeśli tworzysz odnośniki do innych stron WWW, powinieneś od czasu do czasu sprawdzać, czy nadal są one dostępne. Wiele stron WWW zmienia lokalizację lub też całkowicie kończy działanie, więc odnośniki powinny być kontrolowane, aby zapobiec nieporozumieniom.
Wyliczenia
Język HTML pozwala na użycie kilku różnych formatów list i wyliczeń, na przykład numerowanych, oznaczanych odpowiednimi etykietami lub symbolami graficznymi. Listy otacza się takimi znacznikami, jak na przykład < OL> i < /OL> (ang. ordered list, lista uporządkowana) czy < MENU> i < /MENU>. Każda pozycja listy powinna rozpoczynać się od znacznika < LI > lub też innego znacznika o podobnej funkcji. Dostępnych jest również kilka specjalnych znaczników służących na przykład do formatowania słowników, ale nie będziemy ich tu omawiać. Oto przykład prostej listy definiowanej za pomocą znaczników < UL > i < /UL> (ang. unordered list, lista nieuporządkowana):
< HTML>
< HEAD>
< TITLE> Witam na mojej stronie WWW! < /TITLE> < /HEAD>
< BODY>
< H1> Oto lista książek mojego autorstwa. < /H1>
Książki, które napisałem w trakcie zeszłorocznych wakacji:
< UL>
< LI> Gryzą mnie komary
< LI> Zabawy z niedźwiedziami
< LI> Co można zjeść gdy nie ma co jeść
< LI> Dlaczego ciągle pada
< LI> Poradnik dla zagubionych w lesie
< /UL>
< /BODY>
< /HTML>
Lista nieuporządkowana jest podobna do uporządkowanej, z tym że jej elementy nie są numerowane Ten sam dokument może zostać sformatowany w postaci listy uporządkowanej - służą do tego znaczniki < OL> i < /OL>. Elementy takiej listy są poprzedzone odpowiednimi numerami.Pozostała część dokumentu nie została zmodyfikowana - zamiast znaczników < UL> i < /UL> wstawiono odpowiednio < OL> i < /OL>.
Zmiana kroju pisma
W języku HTML zdefiniowano również zestaw znaczników służących do modyfikowania wyglądu znaków. Pozwalają one zarówno na bezpośrednie określenie kroju znaków (na przykład wymuszenie zastosowania kursywy, wytłuszczenia itp.), jak i na logiczne wyróżnienie fragmentu tekstu (na przykład dla zaakcentowania jakiegoś wy-razu, zaznaczenia kodu programu czy tekstu innego typu). Wymuszanie kroju pisma zwykle nie jest najlepszym pomysłem, ponieważ niektóre przeglądarki mogą wyświe-tlać tekst w sposób inny, niż zamierzony. Mimo tego, można używać tej możliwości, jeśli wiadomo, że dokument będzie wykorzystywany tylko przez użytkowników dys-ponujących przeglądarkami formatującymi tekst w sposób zgodny z zamierzeniami. O wiele lepszym pomysłem jest zastosowanie znaczników pozwalających na logiczne wyróżnienie fragmentu tekstu, ponieważ w takim przypadku przeglądarka może samodzielnie zdecydować jaki krój pisma będzie najodpowiedniejszy dla danej platformy. Z tego powodu tym właśnie znacznikom przyjrzymy się nieco bliżej. Język HTML udostępnia osiem powszechnie wykorzystywanych znaczników pozwalających logicz-nie wyróżniać fragmenty tekstu:
- < CITE> - cytat
- < CODE> - fragment kodu źródłowego (zwykle czcionka Courier)
- < DFN> - wyróżnienie definicji
- < EM> - zaakcentowanie fragmentu tekstu (zwykle wyróżnienie kursywą)
- < KBD> - fragment tekstu, który użytkownik powinien wprowadzić z klawiatury
- < SAMP> - tekst przykładowy, formatowany podobnie jak < CODE>
- < STRONG> - tekst wyróżniony (zwykle wytłuszczony) - < VAR> - nazwa zmiennej, wyświetlana kursywą lub podkreślona (zwykle w kontekście znacznika < CODE>) Poniższy kod źródłowy dokumentu przedstawia zastosowanie niektórych przedstawionych wyżej stylów
< HTML>
< HEAD>
< TITLE> Witam na mojej stronie WWW! < /TITLE> < /HEAD>
< BODY>
< H1> To jest nagłówek pierwszego poziomu. < /H1>
< P> To przykładowy tekst zawierający < EM > fragment wyróżniony za pomocą znacznika EM < /EM> i inny fragment wyróżniony < STRONG > za pomocą znacznika STRONG. < /STRONG> < /P>
< /BODY>
< /HTML>
Jak widać, przedstawiona na rysunku przeglądarka (Internet Explorer) interpretuje znacznik < EM> wyróżniając fragment tekstu kursywą, a znacznik < STRONG> - wy-tłuszczeniem. Większość przeglądarek interpretuje te znaczniki właśnie w taki sposób, ale inne znaczniki mogą być różnie interpretowane w różnych przeglądarkach. Jeśli chcesz wymusić określony krój pisma, możesz zastosować znaczniki < B> i < /B> (wytłuszczenie, ang. bold), < I> i < /I> (kursywa, ang. italics) oraz < TT> i < /TT> (czcionka maszyny do pisania, używana zwykle do prezentacji kodu źródłowego).
Inne znaczniki
Przy tworzeniu stron WWW przydaje się również kilka innych znaczników. Jednym z nich jest znacznik < PRE>, umożliwiający poinformowanie przeglądarki, że fragmentu tekstu został sformatowany wcześniej (ang. preformatted). W tekście zawartym po-między znacznikami < PRE> i < /PRE> znaki białe nie są ignorowane. Pozwala to na ręczne sformatowanie tabeli czy tekstu innego typu dokładnie w wymagany sposób. Oto przykładowy dokument zawierający te znaczniki:
< HTML>
< HEAD>
< TITLE> Witam na mojej stronie WWW! < /TITLE> < /HEAD>
< BODY>
< H1> To jest nagłówek pierwszego poziomu. < /H1>
< P> To przykładowy tekst zawierający < EM> fragment wyróżniony za pomocą znacznika EM < /EM> i inny fragment wyróżniony < STRONG> za pomocą znacznika STRONG. < /STRONG> < /P>
< PRE>
To fragment
     tekstu który został sformatowany wcześniej
       i w oknie przeglądarki pojawi się tak, jak został tu wpisany.
< /PRE>
< /BODY>
< /HTML>
We fragmencie otoczonym znacznikami < PRE > zachowane zostały nadmiarowe spacje i znaki nowego wiersza, a nawet zachowana została czcionka użyta do napisania kodu źródłowego (Courier). Innym prostym, ale bardzo użytecznym znacznikiem jest znacznik < HR>, pozwalający wstawić do dokumentu poziomą linię. Spróbujmy wzbogacić o ten element przedstawiony powyżej przykładowy dokument:
< HTML>
< HEAD>
< TITLE> Witam na mojej stronie WWW! < /TITLE> < /HEAD>
< BODY>
< H1> To jest nagłówek pierwszego poziomu. < /H1>
< P> To przykładowy tekst zawierający < EM> fragment wyróżniony za pomocą znacznika EM < /EM> i inny fragment wyróżniony < STRONG> za pomocą znacznika STRONG. < /STRONG> < /P>
< HR>
< PRE>
To fragment
     tekstu który został sformatowany wcześniej
       i w oknie przeglądarki pojawi się tak, jak został tu wpisany.
< /PRE>
< HR>
< /BODY>
< /HTML>

Podstawy języków Java i JavaScript
Zanim rozpoczniemy, wyjaśnijmy jedną rzecz: celem nie jest nauczyć Cię progra-mownia w języku Java. Temat ten wymagałby o wiele obszerniejszego omówienia. W tym rozdziale chcemy przedstawić koncepcję tego języka, jego zastosowania i niektóre aspekty posługiwania się nim. Co to jest Java? Jest to język programowania opracowany przez firmę Sun Microsys-tems. W komunikatach dla prasy był on przedstawiany jako język "prosty, obiektowy, łatwy do zastosowania w systemach rozproszonych, interpretowany, mocny, bez-pieczny, niezależny od architektury, przenośny, wydajny, wielowątkowy i dynamicz-ny". Co to tak naprawdę oznacza? Zacznijmy od tego, że język Java został zaprojek-towany jako język obiektowy prostszy w użyciu niż C++ czy Smalltalk, które są języ-kami bardzo rozległymi i dość skomplikowanymi. Dzięki temu, że język Java jest pro-sty, jest on również mniej podatny na błędy niż inne języki programowania. To właśnie oznacza prostota i moc tego języka. Niewielki rozmiar przyczynia się również do wzrostu wydajności. Java jest językiem interpretowanym, co oznacza, że każdy z wierszy kodu źródłowego jest kolejno odczytywany i wykonywany przez interpreter języka Java, nie jest nato-miast tworzony nadający się do bezpośredniego uruchomienia plik wykonywalny. W zasadzie sprawa jest nieco uproszczona, ponieważ programy w języku Java są jakby połowicznie skompilowane (ang. pseudo-compiled) i są rozprowadzane w postaci bi-narnych plików pośrednich - rozszerzenie nazw plików zawierających tego typu kod ma postać .class. Takie rozwiązanie może być nieco wolniejsze niż użycie w pełni skompilowanych plików, ale dzięki użyciu języka niezależnego od platformy sprzęto-wej (co oznacza, że w kodzie programu nie występują żadne instrukcje specyficzne dla danego sprzętu) kod źródłowy w języku Java może działać w dowolnym systemie wyposażonym w interpreter tego języka. O tym właśnie mówią przymiotniki "niezależny od architektury" oraz "przeno-śny". Łatwość zastosowania w systemach rozproszonych wynika bezpośrednio z prze-nośności i niezależności od architektury - kod źródłowy w języku Java, który ma zo-stać wykonany, może z łatwością być przesyłany z jednego systemu do innego za po-średnictwem sieci. Dzięki temu serwery mogą wysyłać kod programu do klientów, two-rząc system rozproszony (program w języku Java działa po stronie klienta i odsyła wyniki działania do serwera). Ponieważ programy w języku Java mogą zostać uruchomione praktycznie w każdym systemie operacyjnym, mogą wykorzystywać zalety tychże systemów - na przykład możliwość zastosowania wielowątkowości w systemach UNIX-owych. Choć sam język Java może być uważany za wielowątkowy, w praktyce wszystko zależy od systemu operacyjnego, w którym wykonywany jest program. Pozostało jeszcze bezpieczeństwo tego języka - było ono jednym z celów przyświecających jego twórcom. Potrzebna by-ła metoda bezpiecznego przesyłania danych pomiędzy klientem i serwerem, więc język Java został zaprojektowany tak, by sprostać tym wymaganiom. Aby zapewnić odpowiednie oprogramowanie po stronie klienta i serwera, odpowiedni komponent języka Java jest dołączany do aplikacji innego typu, głównie do przeglą-darek internetowych. Zarówno Microsoft Internet Explorer, jak i Netscape Navigator zawierają interpreter języka Java (w postaci wtyczki, ang. plug-in). Kiedy wykryta zo-stanie transmisja kodu w języku Java, uruchamiany jest interpreter tego języka obsłu-gujący nadchodzące dane. JavaScript został wprowadzony na rynek nieco później niż sam język Java. Jest on wbudowany w większość przeglądarek internetowych obsługujących język Java. Poza nazwami, JavaScript i Java nie mają ze sobą wiele wspólnego. Wiele osób uważa, że JavaScript to okrojona wersja języka Java, ale jest to pogląd błędny. JavaScript to swego rodzaju rozszerzenie języka HTML pozwalające na tworzenie interaktywnych stron WWW w systemach o architekturze klient-serwer. JavaScript ma wiele zastosowań decydujących o jego atrakcyjności - na przykład z jego pomocą można określić, co w danej chwili robi użytkownik. Kiedy opuszcza on stronę WWW albo wybiera któryś z przycisków, klient JavaScript może obsłużyć gene-rowane komunikaty i uruchomić odpowiednie procedury. JavaScript nadaje się rów-nież znakomicie do zadań porządkowych i obsługi niektórych aspektów programowa-nia wykraczających poza zakres języka HTML, na przykład obsługi łańcuchów zna-ków.
Co będzie Ci potrzebne?
Jeśli chcesz tworzyć programy w języku Java, będziesz potrzebował pakietu JDK (Java Development Kit). Zawiera on komplet programów niezbędnych do tworzenia, kompi-lowania i testowania apletów Javy. Oprócz JDK potrzebna będzie również przeglądarka WWW obsługująca język Java, dzięki której będziesz mógł oglądać efekty swojej pra-cy. Interpreter języka Java jest zaimplementowany w nowszych wersje przeglądarek Internet Explorer, Netscape Navigator i innych. Firma Sun opracowała również własną przeglądarkę obsługującą ten język, o nazwie HotJava, dostępną na stronach WWW firmy Sun. Pakiet JDK jest dostępny na wielu stronach WWW i w węzłach FTP. Szu-kanie możesz rozpocząć od strony WWW firmy Sun, pod adresem http://java.sun.com, choć w większości węzłów oferujących opro-gramowanie dla Linuxa (na przykład www.blackdown.org) dostępne są odnośniki prowadzące również do innych serwerów oferujących pakiet JDK. Jeśli potrzebna Ci jest przeglądarka WWW obsługująca język Java, zajrzyj na strony firm Netscape lub Microsoft lub na stronę firmy Sun (przeglądarka HotJava). Informacji o innych przeglądarkach i narzędziach wspomagających tworzenie programów w języku Java szukaj na stronach WWW poświęconych systemowi Linux. Jeśli chcesz załadować JDK za pośrednictwem FTP, połącz się z węzłem java.sun.com i przejdź do katalogu /pub, w którym znajdziesz potrzebne pliki. Niestety - jeśli spodziewasz się, że firma Sun wspiera JDK dla Linuxa, będziesz rozczarowany - odmawiają oni wszelkiego rodzaju pomocy. Na serwerze firmy Sun dostępne są również inne materiały przydatne przy tworzeniu aplikacji w języku Java, takie jak przykładowe programy, porady czy dokumenty za-wierające odpowiedzi na często zadawane pytania. Dokument dostępny pod adresem http://java.sun.com/tutorial/java/index.html zawiera opis języka i jest do-skonałym punktem wyjścia do jego nauki. Pakiet Java Development Kit jest darmowy, pod warunkiem, że nie jest wykorzystywany w celach komercyjnych; jeśli jednak za-mierzasz publikować strony WWW oparte na języku Java, możesz potrzebować licen-cji. Szczegółowe informacje rozprowadzane są wraz z JDK. Jeśli instalujesz JDK, upewnij się, że zainstalowane pliki wykonywalne znajdują się w katalogach wchodzących w skład ścieżki przeszukiwania. Najlepiej utwórz dowią-zania do nich w katalogu /usr/bin. Początkujący programiści najczęściej popełniają błędy związane z używaniem klas i z tym, że nie przestrzegają właściwej wielkości liter. W języku Java, podobnie jak w systemach UNIX-owych, wielkość liter ma znaczenie, należy więc zwracać uwagę na ten aspekt tworzenia kodu źródłowego. Rozwiązania dotyczące użycia klas pochodzą z języka C++ i trzeba je opanować. Nie sposób nau-czyć się języka Java bez dobrego podręcznika - na szczęście na rynku jest obecnie sporo książek na ten temat. Jeśli chcesz używać języka JavaScript, będziesz potrzebował przeglądarki potrafiącej go obsłużyć (takiej jak na przykład Netscape Navigator w wersji 3.0 lub wyższej), do-wolnego edytora tekstów potrafiącego zapisywać pliki w formacie ASCII i połączenia TCP/IP pozwalającego komunikować się z innymi komputerami w sieci lokalnej czy Internecie.
Język Java
Z punktu widzenia programisty Java jest bardzo okrojonym obiektowym językiem programowania. Język Java jest językiem obiektowym głównie dlatego, że obiektowe metody programowania sprawdzają się przy tworzeniu aplikacji opartych o architektu-rę klient-serwer. Dzięki temu uniknięto tworzenia struktur charakterystycznych dla ję-zyków proceduralnych, powodujących znaczne zwiększenie objętości programów i spowol-nienie ich działania. Również dzięki programowaniu obiektowemu można obejść wiele problemów, które wymagałyby tworzenia odpowiednich procedur inicjalizacyjnych. Pozwala to w jeszcze większym stopniu zmniejszyć i przyspieszyć programy w języku Java. Opanowanie tego języka nie jest szczególnie trudne, prawdopodobnie jednak ła-twiej będzie Ci zrozumieć panujące w nim reguły, jeśli znasz już jakiś język obiektowy, na przykład C++, ponieważ Java nie ma wiele wspólnego z takimi językami procedu-ralnymi, jak C czy BASIC. Java nie jest do końca językiem obiektowym. Język Smalltalk, dla przykładu, uważa-ny jest za język czysto obiektowy, ponieważ każdy jego aspekt opiera się na zastoso-waniu obiektów i komunikatów, a wszystkie dane są reprezentowane przez obiekty. Ję-zyk Java nie jest aż tak "ortodoksyjny", dzięki czemu tworzone programy mogą być mniejsze. W języku Java proste typy danych dostępne również w języku C (liczby cał-kowite, rzeczywiste i znaki) są zaimplementowane w sposób nieobiektowy, ale wszyst-kie inne rozwiązania mają charakter obiektowy. Zaletą takiego rozwiązania jest fakt, że pozwala ono tworzyć mniejsze i szybsze programy. Jak wspomniano wcześniej, Java jest językiem interpretowanym. Program w tym języ-ku tworzy się tak samo jak w innych językach programowania, następnie przetwarza się go za pomocą swego rodzaju translatora, tworzącego binarny plik pośredni. Plik taki nazywa się klasą i nie nadaje się do bezpośredniego przeglądania, ale może być prze-słany szybciej, niż kod źródłowy, na podstawie którego został on wytworzony. Kiedy przeglądarka zawierająca interpreter Javy odbiera plik klasy, uruchamia interpreter, który dekoduje poszczególne instrukcje i wykonuje je. W pewnym sensie Java jest za-równo językiem kompilowanym, jak i interpretowanym, podobnie jak wiele wcześniej-szych języków programowania - programy w nich napisane były rozprowadzane w postaci pseudokodu wymagającego do poprawnego działania odpowiednich bibliotek czasu wykonania (kiedyś w taki sposób działało wiele kompilatorów języka Pascal). Program klienta, który dekoduje plik klasy, przeprowadza tłumaczenie ogólnych in-strukcji zapisanych w tym pliku na instrukcje specyficzne dla sprzętu i systemu opera-cyjnego, w którym program ma zostać uruchomiony. Oswojenie się z programowaniem w języku Java może zabrać dłuższą chwilę. Progra-my mogą często wydawać się zlepkiem instrukcji z języków C i C++, dlatego doświad-czenie w programowaniu w obu tych językach będzie dość pomocne. Mimo tego, Java jest językiem dość prostym i może być w krótkim czasie opanowana nawet przez użytkowników nie posiadających żadnego doświadczenia programistycz-nego. Najtrudniejszym aspektem zwykle okazuje się zrozumienie reguł rządzących programowaniem obiektowym i przyzwyczajenie się do nieco dziwnie wyglądającej składni (znanej z języków C i C++). Oto przykład króciutkiego programu w języku Ja-va:
// AhojApp.java
class AhojApp {
public static void main (String args[]) {
System.out.println("Ahoj, przygodo!");
}
}
Powyższy program (nazwany AhojApp) definiuje tylko jedną metodę o nazwie main, która nie zwraca żadnej wartości (void), a jej treścią jest pojedyncza instrukcja powo-dująca wyświetlenie komunikatu Ahoj, przygodo. Pierwszy wiersz powyższego przy-kładu jest komentarzem. Jeśli chcesz skompilować powyższy kod źródłowy do pliku klasy, powinieneś uruchomić kompilator javac
javac AhojApp.java
który wygeneruje plik o nazwie AhojApp.class, nadający się do uruchomienia w do-wolnej przeglądarce WWW obsługującej język Java lub też za pomocą programu klienta uruchamianego z wiersza poleceń:
java AhojApp
Powyższe polecenie nakazuje interpreterowi załadowanie pliku o nazwie AhojApp. class i uruchomienie go. Ten aplet musi być uruchamiany z wiersza poleceń, jeśli chcesz zobaczyć rezultaty jego działania. Jak się pewno domyślasz, język Java jest o wiele bardziej złożony niż można by sądzić na podstawie tego przykładu, ale jeśli masz jakieś doświadczenie w programowaniu, zauważysz mnóstwo cech wspólnych z innymi językami (szczególnie takimi jak C i C++). Język Java jest dość bogaty i aby go opanować w pełni być może będziesz po-trzebował nawet kilku tygodni, ale mimo wszystko dla większości użytkowników jest on łatwiejszy niż inne języki programowania.
JavaScript i HTML
Polecenia języka JavaScript są osadzane w dokumentach HTML przez otoczenie ich znacznikami < SCRIPT> i < /SCRIPT>. Mówiąc najbardziej ogólnie, składnia programu w języku JavaScript osadzonego w dokumencie HTML jest następująca:
< SCRIPT language="JavaScript">
polecenia języka JavaScript
< /SCRIPT>
Pole language znacznika < SCRIPT > jest opcjonalne, ale warto je wstawiać by mieć pewność, że program zostanie prawidłowo rozpoznany przez przeglądarkę. Jeśli chcesz załadować skrypt w języku JavaScript podając jego adres URL, również ten adres powinieneś umieścić wewnątrz znacznika < SCRIPT>:
< SCRIPT language="JavaScript" src="http://www.jakis.adres.com" >
Jeśli źródło JavaScript jest osadzone w pliku HTML, można pominąć pole src. Oto bardzo prosty przykładowy skrypt osadzony w dokumencie HTML (który również ze względu na przejrzystość przykładu został ograniczony do niezbędnego minimum):
< HTML>
< HEAD>
...
< SCRIPT language="JavaScript" >
alert("Witaj na mojej stronie WWW!");
< /SCRIPT>
< /HEAD>
< /HTML>
Funkcja alert() języka JavaScript powoduje wyświetlenie okienka dialogowego za-wierającego prócz tekstu piktogram przedstawiający symbol wykrzyknika. Jest ona używana do przyciągnięcia uwagi użytkownika w sytuacjach, gdy podejmowana ak-cja ma kluczowe znaczenie, jest nieprawidłowa lub może spowodować problemy. Jak widać, funkcje w języku JavaScript wykorzystywane są podobnie jak w języku C. Możliwe jest również umieszczenie treści funkcji w osobnym pliku i odwołanie się do niej w dokumencie HTML. Jeśli wywołujesz z dokumentu HTML funkcję zapisaną w jakimś innym pliku, powi-nieneś do jego nazwy dodać rozszerzenie .js. Warto trzymać się tej konwencji, ponie-waż niektóre aplikacje (również MIME) potrafią poprawnie rozpoznać i obsłużyć pliki z rozszerzeniem .js. Niestety, nie mamy do dość miejsca na to, aby zagłębiać się w szczegóły programowa-nia w języku JavaScript - na szczęście na rynku dostępnych jest obecnie wiele książek poświęconych temu tematowi.

Projektowanie spójnych stron WWW
Pokazaliśmy już, w jaki sposób można skonfigurować system linuxowy, aby działał jako serwer usług internetowych, takich jak FTP, Gopher, Wais czy WWW. W poprzed-niej części omówiliśmy również konfigurowanie poczty i grup dyskusyjnych. Większość użytkowników łączących się z Internetem chce jednak korzystać z WWW, bądź to łą-cząc się z innymi serwerami, bądź też udostępniając własne strony WWW. Internet bardzo się rozrósł w ciągu kilku ostatnich lat, co spowodowało, że wielu użyt-kowników postanowiło udostępnić w tej sieci informacje dotyczące interesujących ich tematów. Wiele stron WWW jest jednak źle zorganizowanych, co powoduje, że ładują się one bardzo powoli. W tym rozdziale przyjrzymy się kilku podstawowym zasadom, których należy przestrzegać przy tworzeniu własnej strony WWW w systemie linuxo-wym. Tematowi prawidłowego projektowania stron WWW poświęcane są całe książki, niemniej postaramy się tu króciutko naświetlić najważniejsze aspekty tego zagadnie-nia. Nie ma żadnego znaczenia, czy zakładasz stronę WWW po to, by pochwalić się reszcie świata faktem, że zainstalowałeś Linuxa, czy też zamierzasz poświęcić ją swojemu ulubionemu programowi telewizyjnemu. Każda strona WWW, która będzie udostęp-niana użytkownikom Sieci, powinna spełniać kilka podstawowych warunków doty-czących działania serwera i wyglądu samej strony.
Dostępność systemu
Jednym z najbardziej drażniących problemów występujących podczas korzystania z Sieci jest fakt, że niektóre strony WWW ładują się potwornie długo (a nawet pojawia-ją się komunikaty mówiące o tym, że danej strony w ogóle nie można odnaleźć). Dłu-gie czekanie na załadowanie strony bardzo skutecznie zniechęca użytkowników do jej odwiedzania. W grę wchodzą dwa czynniki: dostępność systemu i czas oczekiwania na odpowiedź. System jest dostępny wtedy, gdy strony WWW są dostępne w Internecie. Jeśli wyłą-czasz swój serwer w czasie, gdy z niego nie korzystasz, nikt inny również nie będzie miał do niego dostępu. Każdy, kto będzie próbował obejrzeć Twoją stronę WWW, otrzyma komunikat o nieprawidłowym adresie URL. Większość użytkowników w ta-kiej sytuacji po prostu usunie odnośnik do Twojej strony ze swojego zbioru adresów i już nigdy jej nie odwiedzi. Rozwiązanie nasuwa się samo: serwer powinien pozostawać włączony 24 godziny na dobę, co najwyżej za wyjątkiem krótkich przerw poświęconych na konserwację syste-mu. Nawet jeśli nie spodziewasz się, aby ktokolwiek chciał oglądać Twoją stronę o czwartej nad ranem, musisz pamiętać o fakcie, że Sieć ma zasięg ogólnoświatowy i dla kogoś w innej strefie czasowej jest właśnie późne popołudnie. Zastosowanie systemu UPS (Uninetrruptible Power Supply, system podtrzymania zasilania) pozwoli również uniezależnić się w pewnym stopniu od krótkotrwałych awarii zasilania czy wahań na-pięcia sieciowego - warto więc w niego zainwestować. Innym problemem jest czas oczekiwania na odpowiedź. Zależy on głównie od dwóch czynników: prędkości komputera i prędkości połączenia z siecią. Jeśli używasz mode-mu o maksymalnej prędkości przesyłu 1200 bodów, bez względu na to, jak szybka będzie reszta Twojego sprzętu, połączenia będą kuleć z powodu zbyt małej wydajno-ści łącza. Nie oznacza to wcale, że musisz od razu inwestować w łącza ISDN czy T1 - zwykły modem asynchroniczny o prędkości 28.8 kbps lub większej powinien w zupeł-ności wystarczyć do obsługi większości rzadko odwiedzanych serwerów WWW. Jeśli jednak zaczyna odwiedzać Cię coraz więcej użytkowników i połączenia są realizowa-ne coraz wolniej, powinieneś rozważyć zakup szybszego łącza. Mimo wszystko zdecy-dowana większość stron WWW jest odwiedzana bardzo rzadko. Jeśli połączenie z Internetem jest wystarczająco szybkie, prędkość komputera zwykle nie odgrywa decydującej roli. Komputer klasy 80486 może wysyłać dane do modemu o wiele szybciej, niż ten potrafi transmitować je poprzez linię telefoniczną, nie ma więc większego znaczenia, czy używasz komputera Pentium, czy nie, chyba że prowadzisz bardzo popularną stronę WWW - wówczas wszystkie elementy muszą być bardzo szybkie.
Utrzymywanie porządku na stronach WWW
Jednym z największych błędów popełnianych przez użytkowników udostępniających swoje pierwsze strony WWW jest ich zbytnie komplikowanie. Oczywiście, jeśli stworzy-łeś jakąś zwalającą z nóg animację w języku Java i chcesz, by wszyscy ją obejrzeli, wszystko jest w porządku, ale pamiętaj o tym, że każdy, kto połączy się z Twoją stro-ną, będzie musiał załadować cały kod. Może to zabrać sporo czasu, szczególnie za po-średnictwem modemu asynchronicznego. Jeśli zaprojektowałeś wspaniale wyglądającą w Twoim systemie stronę z purpurowym tekstem na zielonym tle, musisz pamiętać o tym, że w innym systemie może ona być zupełnie nieczytelna, ponieważ nie zawsze kolory zostaną oddane prawidłowo. Wszystkie te wskazówki trzeba mieć na uwadze przy projektowaniu stron WWW. Podstawową regułą jest, że strony WWW powinny być możliwie najprostsze.
Umieszczaj najważniejsze informacje na początku strony
Przy projektowaniu stron WWW bardzo ważne jest, aby wszystko, co próbujesz prze-kazać, było jasne i zrozumiałe. Jeśli tworzysz stronę prezentującą wyroby Twojej fir-my, jej nazwa i rodzaj działalności powinny pojawić się w widocznym miejscu, tak, by były dostrzegalne na pierwszy rzut oka. Pamiętaj o tym, że większość ludzi czyta tekst od góry do dołu, więc istotne informacje umieszczaj na początku dokumentu. Ta sa-ma zasada obowiązuje przy drukowaniu ogłoszeń i artykułów prasowych: nagłówki i ważne informacje prezentowane są w górnej części strony, czyli tam, gdzie przeciętny czytelnik spojrzy najpierw, po to, aby przyciągnąć jego uwagę i sprowokować do prze-czytania reszty informacji. Większość czytelników zaczyna czytanie od początku stro-ny, przerywając je po natknięciu się na coś, co ich zniechęci - wynika stąd, że zapro-jektowanie prostej i niezaśmieconej strony daje większe szanse na to, że użytkownik dobrnie do jej końca. Dla przykładu rozważmy sytuację, w której chcesz udostępnić użytkownikom jakieś oprogramowanie dla systemów linuxowych. Jeśli odnośnik do tego oprogramowania umieścisz na końcu swojej strony WWW, większość użytkowników prawdopodobnie go przegapi, szczególnie jeśli zauważenie go będzie wymagało przewinięcia zawartości strony. Choć wiele stron WWW jest dość długich, tak naprawdę mało kto ma ochotę przewijać je do samego końca. Z tego powodu zwykle dobrym pomysłem jest ograni-czenie konieczności przewijania strony do niezbędnego minimum; idealną sytuacją by-łoby całkowite wyeliminowanie przewijania. Umieszczenie odnośników do oferowane-go oprogramowania na początku strony znacznie zwiększa szansę na to, że ktoś poku-si się o jego załadowanie - o wiele łatwiej kliknąć na wyróżniającym się odnośniku niż przewijać zawartość strony szukając go gdzieś na dole czy też pomiędzy innymi ele-mentami.
Dzielenie dokumentu na wiele stron
Jeśli treść, którą chcesz przekazać, nie mieści się w obrębie jednej strony, jak najbar-dziej wskazane jest dołączenie kolejnej strony i umieszczenie na każdej z nich odpo-wiednich odnośników. Należy jednak zwrócić uwagę na to, by użytkownik poszukują-cy konkretnych informacji nie musiał przechodzić przez zbyt wiele poziomów odno-śników. Jeśli na przykład chcesz za pośrednictwem sieci sprzedać swoje wyroby lub usługi, nie jest najlepszym pomysłem zmuszenie czytelnika do przejścia przez sześć czy siedem poziomów odnośników, zanim będzie mógł dowiedzieć się czegoś konkret-nego o Twojej ofercie. Przeciętny użytkownik po prostu nie jest aż tak cierpliwy. Bar-dziej przemyślane zaplanowanie strony i kilka eksperymentów pozwoli stworzyć stronę dobrze zaprojektowaną i wygodną w użyciu. Pamiętaj o tym, by wszystkie informacje organizować w możliwie logiczny sposób, dzięki czemu odwiedzający będą mogli szybko oswoić się ze strukturą Twojej strony. Istnieje kilka prostych sposobów przyciągnięcia uwagi czytającego do pewnych elementów strony WWW. Jednym z nich jest umieszczenie za pomocą znacznika < HR > poziomej linii w odpowiednim miejscu strony. Li-nia taka jest definiowana przez zaledwie kilka znaków, więc nie wprowa-dza w zasadzie żadnego opóźnienia przy przesyłaniu danych. Mimo tego, powinieneś utrzymywać liczbę takich linii na rozsądnym poziomie, ponie-waż ich nadmiar może przytłoczyć użytkownika.
Ikony
Ikony to doskonały sposób zwrócenia uwagi czytelnika na najważniejsze elementy Twojej strony głównej. Niestety, wielu projektantów stron WWW przesadza i umiesz-cza na stronie mnóstwo porozrzucanych bezładnie ikon. Nie daje to zamierzonego efektu - rozprasza uwagę czytelnika nie pozwalając ocenić, które z ikon są istotne, a które nie. Niewielkie piktogramy nadają się również do wyróżniania kolejnych elementów wyli-czeń, pod warunkiem że są to krótkie wyliczenia, które można łatwo ogarnąć wzro-kiem. Również tu trzeba zdecydować się na coś prostego, a jednocześnie przyciągają-cego wzrok. Użycie innego piktogramu dla każdego elementu listy nie jest najlepszym pomysłem. Najprostszy z takich piktogramów może mieć postać kulki, ale niektóre przeglądarki automatycznie dodają tego typu piktogram przed elementami list. Atrakcyjny piktogram wskazujący na istotne elementy strony może na-prawdę ją ożywić. Biblioteki klipartów są pełne obrazków przedstawiają-cych różnego rodzaju strzałki czy dłonie z wyciągniętym palcem wskazu-jącym (bywają też inne palce, ale one średnio nadają się one do zamiesz-czenia na stronie WWW), które można zastosować do zaakcentowania ważnych fragmentów tekstu. Tego typu elementy przyciągają wzrok czy-tającego. Potencjalne przyczyny problemów warto oznaczyć piktogramem przedstawiającym znak ostrzegający o niebezpieczeństwie (zwykle żółty trójkąt z symbolem wykrzykni-ka) lub znak stop. One szczególnie zwracają na siebie uwagę, ale należy używać ich z umiarem i tylko tam, gdzie są uzasadnione. Ikona "Nowość" w najróżniejszych formach jest przydatna do wyróżniania elemen-tów, które pojawiły się na stronie WWW niedawno - dzięki temu osobom regularnie odwiedzającym stronę WWW łatwiej będzie orientować się we wprowadzanych mody-fikacjach. Powinieneś jednak upewnić się, że odnosi się ona do elementów, które rze-czywiście są nowe. Usuwaj takie ikony co parę tygodni, aby Twoja strona nie wydawa-ła się archaiczna i zaniedbana.
Prawidłowe stosowanie odnośników
Stosowanie odnośników to jeden z warunków utworzenia dobrej strony WWW, ale powinny one być dobrze przemyślane. Wielu projektantów stron WWW zaczyna od spo-rządzenia na kartce papieru diagramu obrazującego strukturę połączeń pomiędzy po-szczególnymi stronami, dzięki czemu mogą oni mieć pewność, że struktura jest jasna, logiczna i nie zawiera błędów takich jak na przykład przypadkowo utworzona pętla. Jeśli Twoja witryna ma składać się z więcej niż trzech czy czterech stron, powinieneś również pomyśleć o stworzeniu tego typu diagramu. Wybór tekstu, który będzie reprezentował dany odnośnik, również nie jest sprawą ba-nalną. Przykładowo, poniższy fragment tekstu nie spełnia najlepiej swego zadania:
Kliknij tu by zobaczyć nowe produkty.
O wiele lepiej prezentuje się tekst o następującej postaci:
Tu możesz obejrzeć informacje o naszych najnowszych produktach.
Prawidłowe stosowanie znaczników HTML
Osoby tworzące strony WWW często nieprawidłowo używają również nagłówków. Za ich pomocą można wyróżnić tytuł używając większej czy wytłuszczonej czcionki. Należy jednak stosować je z umiarem i zachowywać odpowiedni porządek. Po znacznikach < H1> i < H2> powinien wystąpić znacznik < H3> i tak dalej, w miarę potrzeb. Nie należy pomijać jednego z poziomów nagłówków, ponieważ niektóre przeglądarki na ich podstawie planują wygląd strony. Należy również unikać zagnieżdżania znaczników, szczególnie tych powodujących zmianę rodzaju czcionki. Dla przykładu, poniższy fragment kodu:
< STRONG > Ahoj, < EM> Przygodo! < /EM> < /STRONG>
może prezentować się poprawnie w jednej przeglądarce, ale inna może nie zinterpreto-wać go zgodnie z zamierzeniami autora. Zawsze zamykaj otwarte znaczniki i unikaj mieszania ich. Znaczniki powodujące zmianę kroju pisma powinny zawsze znajdować się wewnątrz znaczników akapitu, a nie odwrotnie. Oto przykład prawidłowego umieszczenia znacznika powodującego podkreślenie fragmentu tekstu:
< A HREF="Najświeższe wiadomości">
< UL>
< LI> Wiadomości dzisiejsze
...
< /UL>
< /A>
Unikaj używania znacznika < BR>, wymuszającego przejście do nowego wiersza. Zamiast tego pozwól przeglądarce rozmieścić tekst według własnego uznania - w przeciwnym przypadku może okazać się, że Twoja strona w niektórych sytuacjach wygląda dość dziwnie. Pamiętaj o tym, że fakt, że strona wygląda dobrze w Twoim systemie, nie oznacza, że będzie ona prezentować się tak samo przeglądającym ją użytkownikom korzystającym z innej przeglądarki czy systemu.

Zarządzanie kodem źródłowym
Duże projekty programistyczne, w których skład wchodzi wiele plików źródłowych tworzonych przez różnych programistów, mogą sprawiać mnóstwo kłopotów, szcze-gólnie jeśli to właśnie Ty jesteś odpowiedzialny za zarządzanie całością projektu. Oto najczęściej występujące problemy: - skąd można mieć pewność, że plik zawierający np. biblioteki wejścia / wyjścia napisane przez innego programistę zawiera najnowszą wersję procedur?
- jak poradzić sobie w sytuacji, gdy trzeba przekompilować aplikację, ale nie bardzo wiadomo, które z 50 plików wchodzących w skład kodu źródłowego zostały zmodyfikowane?
Okazuje się, że śledzenie najnowszych wersji plików i szukanie w razie potrzeby wersji sprzed godziny czy też sprzed kilku dni może zająć więcej czasu niż samo programo-wanie. Nawet niewielkie aplikacje zwykle tworzone są na podstawie więcej niż jednego pliku zawierającego kod źródłowy. Podczas kompilowania programów w języku C musisz posługiwać się nie tylko plikami z kodem źródłowym, ale również plikami nagłówko-wymi i plikami bibliotek. Na szczęście, dla systemu Linux dostępne jest środowisko programistyczne znakomicie upraszczające większość zadań związanych z zarządzaniem kodem źródłowym.
Program make
Program make, będący prawdopodobnie najważniejszym programem użytkowym wykorzystywanym podczas tworzenia oprogramowania, pozwala określać zależności pomiędzy plikami i uaktualniać tylko te pliki, które tego wymagają. Uaktualnianie zwykle sprowadza się do kompilacji odpowiednich plików źródłowych czy też konsoli-dacji plików pośrednich, ale w skład tego procesu może wchodzić również usuwanie plików tymczasowych. Proces uaktualniania może być powtarzany dziesiątki razy w trakcie tworzenia aplikacji. Zamiast zajmowania się związanymi z nim zadaniami ręcznie, można zlecić je programowi make, zyskując więcej czasu na ważniejsze czyn-ności, takie jak tworzenie samego kodu źródłowego czy oglądanie telewizji. Program make generuje odpowiednie polecenia na podstawie pliku opisu nazywanego najczęściej makefile. Wygenerowane polecenia są następnie przetwarzane przez in-terpreter poleceń powłoki. Zawartość pliku makefile to w zasadzie zestaw zadań (zwanych regułami), które należy wykonać przy uaktualnianiu projektu. Definiowanie reguł sprowadza się do określenia zależności pomiędzy plikami. W przypadku tworze-nia pliku wykonywalnego z kodu w języku C w systemie Linux zwykle oznacza to kompilację plików źródłowych do postaci pośredniej, a następnie konsolidację plików pośrednich (być może wraz z dodatkowymi bibliotekami) do postaci wykonywalnej. Program make potrafi również sam określić, które z plików zostały zmodyfikowane i wymagają uaktualnienia (na podstawie czasu ostatniej modyfikacji pliku). Nazwa makefile czy Makefile jest faktycznie nazwą pliku, który program make spodziewa się znaleźć w katalogu bieżącym. Można zażą-dać przetwarzania pliku o innej nazwie, ale zgodnie z tradycją (a kto chciałby się spierać z ponad trzydziestoletnią tradycją?) programiści uży-wają pliku o nazwie makefile. Program make jest zdecydowanie najlepiej przystosowany do programowania w języ-ku C, ale można również wykorzystywać go przy pracy z innymi językami programo-wania dla Linuxa, na przykład z asemblerem czy językiem FORTRAN.
Przykładowy plik makefile
Przyjrzyjmy się prostemu przykładowi zastosowania programu make. Polecenie
$make cosnowego
powoduje, że zostanie utworzona nowa wersja programu cosnowego. W naszym przypadku będzie to plik wykonywalny, w związku z czym proces ten będzie składał się z kompilacji i konsolidacji odpowiednich plików. Plik cosnowego określa się jako plik docelowy (ang. target) programu make. Pliki pośrednie konsolidowane do jednego pliku wykonywalnego nazywane są plikami pierwotnymi (ang. dependents) pliku cosnowego. Pliki zawierające kod źródłowy są kompilowane do postaci pośredniej, są więc również (choć nie wprost) plikami pierwotnymi pliku cosnowego. Oto lista plików, które będą potrzebne do utworzenia programu cosnowego (ich zawartość jest dla naszego przykładu nieistotna):
- dwa pliki zawierające kod źródłowy w języku C, main.c i zrobto.c;
- trzy pliki nagłówkowe, tak.h, nie.h i moze.h;
- jeden plik zawierający bibliotekę funkcji, /usr/nowe/lib/swiezy.a;
- plik zawierający kod źródłowy w asemblerze, szybciej.s.
Jak widać, nasz projekt nie jest duży, więc nie byłoby szczególnie trudno ręcznie kom-pilować i konsolidować odpowiednie pliki. Zamiast tego jednak spróbujmy utworzyć odpowiedni plik makefile, pozwalający zautomatyzować te niezbyt fascynujące czynności. Używając swojego ulubionego edytora tekstów, utwórz plik makefile o następującej treści:
cosnowego: main.o zrobto.o szybciej.o /usr/nowe/lib/swiezy.a
cc -o cosnowego main.o zrobto.o szybciej.o /usr/nowe/lib/swiezy.a
main.o: main.c
cc -c main.c
zrobto.o: zrobto.c
cc -c zrobto.c
szybciej.o: szybciej.s
as -o szybciej.o szybciej.s
sprzataj:
rm *.o
moze.h: tak.h nie.h cp tak.h nie.h /usr/reksio/
Format pliku makefile
Załóżmy, że wszystkie wspomniane pliki znajdują się w tym samym katalogu, co plik makefile; co zyskaliśmy, tworząc go? Każdy plik makefile (więc również ten, który przed chwilą utworzyłeś) składa się z pewnej liczby wpisów. Przykładowy plik składa się z sześciu wpisów. Pierwszy wiersz każdego wpisu definiuje zależności pomiędzy pli-kami. Pozwala on określić (po dwukropku), jakie pliki są niezbędne do utworzenia pli-ku (obiektu) docelowego o nazwie zapisanej przed dwukropkiem. Następne wiersze określają zestaw poleceń, które zostaną wykonane przez program make, gdy zajdzie potrzeba uaktualnienia danego pliku docelowego. Pojedynczy wpis ma więc postać:
plik docelowy: pliki potrzebne do jego utworzenia
(TAB) lista poleceń
Wiersze określające polecenia, które mają zostać wykonane, muszą rozpoczynać się od znaku tabulacji - jest to jedna z reguł składniowych pliku makefile. Wierszy okre-ślających polecenia może być więcej, ale każdy z nich jest wykonywany oddzielnie, w swoim własnym środowisku. Wynika stąd, że następujące polecenia:
cd gdzies
mv *.c gdzieindziej
nie zadziałają zgodnie z oczekiwaniami. Aby zapobiec tego rodzaju sytuacjom, należy polecenia, które mają zostać wykonane wspólnie, zapisywać w jednym wierszu, roz-dzielając je średnikami. Można to zrobić na dwa sposoby:
plik docelowy: pliki potrzebne do jego utworzenia
polecenie1; polecenie2; polecenie3;...
albo:
plik docelowy: pliki potrzebne do jego utworzenia
polecenie1; \
polecenie2; \
polecenie3;
i tak dalej. Jeśli używasz drugiego sposobu, ukośnik musi być ostatnim znakiem wiersza, dzięki czemu zapobiegnie on interpretacji znaku końca wiersza. Można również określić kilka rodzajów zależności pomiędzy plikami, definiując kilka wpisów dla tej samej nazwy pliku docelowego. Program make ma o wiele większe możliwości, niż opisane w tym rozdziale, ale prawdo-podobnie nie będą Ci one potrzebne, dopóki nie będziesz pracował z na-prawdę dużymi projektami, uwikłanymi w mnóstwo wzajemnych zależno-ści. Pierwszy wpis naszego pliku makefile jest kluczowy dla utworzenia pliku wykonywalnego cosnowego. Stwierdza on, że plik cosnowego może zostać uaktualniony w przypadku, gdy wszystkie pliki pośrednie i pliki biblioteki, od których jest on zależny, istnieją i którykolwiek z nich jest nowszy niż ostatnia wersja pliku cosnowego. Oczywi-ście, jeśli plik cosnowego nie istnieje, również zostaną podjęte wszystkie działania prowadzące do jego utworzenia. Najpierw program make sprawdzi, czy któryś z plików pierwotnych wymaganych do utworzenia pliku cosnowego wymaga uaktualnienia i, w razie potrzeby, podejmie odpowiednie działania. Proces ten powtarzany jest rekuren-cyjnie - program make sprawdza zależności dla plików docelowych na kolejnych po-ziomach, zgodnie z danymi zapisanymi w pliku makefile. Ostatni wpis jest dość nietypowy - powoduje on skopiowanie plików tak.h i nie.h (zależnych w jakiś sposób od pliku moze.h) do katalogu domowego użytkownika reksio pod warunkiem, że zostały one zmodyfikowane. Takie rozwiązanie może być przydatne na przykład w przypadku, gdy reksio pracuje nad jakimś programem związanym z naszym projektem i powinien zawsze mieć dostęp do najnowszej wersji plików nagłówkowych. Jak widać, program make może być wykorzystany do celów innych niż tylko kompilowanie i konsolidacja programów - potrafi on wykonywać różne polecenia w oparciu o zadeklarowane zależności. W naszym pliku makefile zdefiniowany jest również plik docelowy o nazwie sprza-taj, którego uaktualnienie nie powoduje kompilowania żadnych plików. Plik ten nie wymaga istnienia żadnych plików pierwotnych - dla programu make nie stanowi to żadnego problemu. Jeśli w katalogu bieżącym nie ma pliku o nazwie sprzataj, pro-gram make wykona wszystkie polecenia powiązane z tym identyfikatorem - a więc usunie pliki pośrednie (z rozszerzeniem .o). Plik sprzataj, choć dość nietypowy (po-nieważ z założenia nie jest nigdy tworzony), jest traktowany na równi z wszystkimi po-zostałymi obiektami docelowymi. Jeśli wydasz polecenie W naszym pliku makefile zdefiniowany jest również plik docelowy o nazwie sprza-taj, którego uaktualnienie nie powoduje kompilowania żadnych plików. Plik ten nie wymaga istnienia żadnych plików pierwotnych - dla programu make nie stanowi to żadnego problemu. Jeśli w katalogu bieżącym nie ma pliku o nazwie sprzataj, pro-gram make wykona wszystkie polecenia powiązane z tym identyfikatorem - a więc usunie pliki pośrednie (z rozszerzeniem .o). Plik sprzataj, choć dość nietypowy (po-nieważ z założenia nie jest nigdy tworzony), jest traktowany na równi z wszystkimi po-zostałymi obiektami docelowymi. Jeśli wydasz polecenie
$ make cosnowego
program make wygeneruje serię poleceń, które spowodują uaktualnienie wszystkich plików pierwotnych pliku docelowego cosnowego, a następnie uaktualni sam ten plik. Wszystkie przetwarzane polecenia są wyświetlane na ekranie. Taki sam efekt da wpi-sanie polecenia
$ make
ponieważ program make wywołany bez argumentów uaktualnia pierwszy plik docelo-wy napotkany w pliku makefile. Przetwarzane polecenia są wyświetlane na ekranie, a po wystąpieniu ewentualnego błędu działanie programu make jest wstrzymywane. Jeśli wszystkie pliki pierwotne i plik cosnowego nie wymagają uaktualnienia, żadne po-lecenia nie zostaną wykonane i program make wygeneruje komunikat:
'cosnowego' is up to date
Parametrem programu make może być dowolna nazwa (lub nazwy) pliku docelowego zdefiniowanego w pliku makefile. Poszczególne pliki docelowe są uaktualniane w ta-kiej kolejności, w jakiej pojawiły się w wierszu poleceń, z zachowaniem wszystkich re-guł określonych w pliku makefile. Jeśli podana nazwa pliku docelowego nie zostanie odnaleziona w pliku makefile, zostanie wygenerowany komunikat:
$ make cosinnego
make: Don't know how to make cosinnego. Stop.
Tworzenie kilku wersji programu
Załóżmy, że chcesz utworzyć dwie wersje programu cosnowego, w większości oparte na tym samym kodzie źródłowym, ale korzystające z różnych bibliotek. Biblioteki te są zapisane w plikach źródłowych w języku C o nazwach zrobto.c i zrobtamto.c. Zamiast tworzyć oddzielne pliki makefile dla obu wersji programu, można po prostu zdefiniować dwie wersje pliku docelowego, tworzone w nieco odmienny sposób. Plik makefile miałby wówczas postać (pierwsze dwa wiersze są komentarzem, oznaczo-nym za pomocą symbolu #):
$ make cosnowego
program make wygeneruje serię poleceń, które spowodują uaktualnienie wszystkich plików pierwotnych pliku docelowego cosnowego, a następnie uaktualni sam ten plik. Wszystkie przetwarzane polecenia są wyświetlane na ekranie. Taki sam efekt da wpi-sanie polecenia
$ make
ponieważ program make wywołany bez argumentów uaktualnia pierwszy plik docelo-wy napotkany w pliku makefile. Przetwarzane polecenia są wyświetlane na ekranie, a po wystąpieniu ewentualnego błędu działanie programu make jest wstrzymywane. Jeśli wszystkie pliki pierwotne i plik cosnowego nie wymagają uaktualnienia, żadne po-lecenia nie zostaną wykonane i program make wygeneruje komunikat:
'cosnowego' is up to date
Parametrem programu make może być dowolna nazwa (lub nazwy) pliku docelowego zdefiniowanego w pliku makefile. Poszczególne pliki docelowe są uaktualniane w ta-kiej kolejności, w jakiej pojawiły się w wierszu poleceń, z zachowaniem wszystkich re-guł określonych w pliku makefile. Jeśli podana nazwa pliku docelowego nie zostanie odnaleziona w pliku makefile, zostanie wygenerowany komunikat:
$ make cosinnego
make: Don't know how to make cosinnego. Stop.
Tworzenie kilku wersji programu
Załóżmy, że chcesz utworzyć dwie wersje programu cosnowego, w większości oparte na tym samym kodzie źródłowym, ale korzystające z różnych bibliotek. Biblioteki te są zapisane w plikach źródłowych w języku C o nazwach zrobto.c i zrobtamto.c. Zamiast tworzyć oddzielne pliki makefile dla obu wersji programu, można po prostu zdefiniować dwie wersje pliku docelowego, tworzone w nieco odmienny sposób. Plik makefile miałby wówczas postać (pierwsze dwa wiersze są komentarzem, oznaczo-nym za pomocą symbolu #):
# Plik makefile sluzacy do tworzenia
# dwoch wersji programu cosnowego
cosnowego1: main.o zrobto.o szybciej.o /usr/nowe/lib/swiezy.a
cc -o cosnowego main.o zrobto.o szybciej.o /usr/nowe/lib/swiezy.a
cosnowego2: main.o zrobtamto.o szybciej.o /usr/nowe/lib/swiezy.a
cc -o cosnowego main.o zrobto.o szybciej.o /usr/nowe/lib/swiezy.a
main.o: main.c
cc -c main.c
zrobto.o: zrobto.c
cc -c zrobto.c
zrobtamto.o: zrobto.c
cc -c zrobtamto.c
szybciej.o: szybciej.s
as -o szybciej.o szybciej.s
sprzataj:
rm *.o
moze.h: tak.h nie.h
cp tak.h nie.h /usr/reksio/
Dzięki takiemu rozwiązaniu za pomocą jednego pliku makefile można utworzyć dwie różne wersje programu. Polecenie
$ make cosnowego1
powoduje utworzenie wersji wykonywalnej programu, używającej funkcji zapisanych w pliku zrobto.c. Program korzystający z funkcji zapisanych w pliku zrobtamto.c może zostać skompilowany za pomocą polecenia
$ make cosnowego2
Wymuszanie uaktualnienia
Możliwe jest wymuszenie uaktualnienia pliku docelowego lub też wymuszenie zanie-chania jego uaktualnienia. Przykładem sytuacji, w której możesz chcieć zabronić po-nownej kompilacji plików, może być skopiowanie plików źródłowych do nowego kata-logu. Taka operacja powoduje zmianę czasu ostatniej modyfikacji plików, choć w rze-czywistości nie wymagają one rekompilacji. Jeśli chcesz uaktualnić czas modyfikacji plików docelowych określonych w pliku makefile, możesz posłużyć się programem touch lub uruchomić program make z opcją -t. Jeśli chcesz przetestować swój plik makefile, możesz uruchomić program make z opcją -n. Spowoduje to wyświetlenie wszystkich poleceń, które byłyby wykonane, ale bez ich faktycznego wykonywania. Wyświe-tlone zostaną również komunikaty o ewentualnych błędach składniowych. Dzięki takiemu rozwiązaniu nie trzeba czekać na zakończenie trwającej czasem dość długo kompilacji.
Makropolecenia
Program make pozwala również na definiowanie makropoleceń, rozwijanych do pełnej postaci przed wykonaniem poleceń zapisanych w pliku makefile. Definicje makropo-leceń mają następującą postać:
nazwa_makra = tekst
Pole tekst może zawierać na przykład nazwę pliku, katalogu, programu, który należy uruchomić, czy dowolny inny tekst. Może to również być lista plików lub stała napiso-wa ujęta w podwójny cudzysłów. Oto przykłady definicji makropoleceń:
LIBFILES = /usr/nowe/lib/swiezy.a
posrednie = main.o zrobto.o
CC = /usr/bin/cc
1wersja = "To jest pierwsza wersja programu cosnowego"
OPTIONS =
Zgodnie z powszechnie przyjętą konwencją, nazwy makropoleceń składają się tylko z wielkich liter, choć - jak widać w powyższym przykładzie - nie jest to wymagane. Zauważ, że w definicji makropolecenia OPTIONS po znaku równości nie występuje ża-den tekst. Oznacza to, że w miejsce jego wystąpienia nie zostanie wstawiony żaden ciąg znaków. Podobnie potraktowane zostanie użycie makropolecenia, które w ogóle nie zostało zdefiniowane. W definicjach makropoleceń można używać innych makropoleceń, na przykład tak:
KSIAZKA_DIR = /usr/book/
MOJE_ROZDZ = ${KSIAZKA_DIR}/reksio/ksiazka
Makropolecenia muszą być definiowane przed ich użyciem w wierszu określającym zależności pomiędzy plikami, ale mogą odnosić się do siebie wzajemnie w dowolnym porządku. Program make rozpoznaje również kilka predefiniowanych makropoleceń, ułatwiają-cych użycie najczęściej wykorzystywanych programów. Kompilator języka C jest zde-finiowany w makropoleceniu CC, natomiast znaczniki, z którymi będzie on urucho-miony, w makropoleceniu CFLAGS. Wywołanie makropolecenia wymaga otoczenia jego nazwy nawiasami klamrowymi i poprzedzenia nawiasu otwierającego symbolem dolara ($). Oto plik makefile z po-przedniego przykładu, w którym wykorzystano możliwość definiowania makropole-ceń:
# Pora przecwiczyc makropolecenia
CC = /usr/bin/cc
AS = /usr/bin/as
OBJS = main.o zrobto.o szybciej.o
TN = tak.h nie.h
#
LIB_DIR = /usr/nowe/lib
LIB_FILES = ${LIB_DIR}/swiezy.a
cosnowego: ${OBJS} ${LIB_FILES}
${CC} -o cosnowego ${OBJS} ${LIB_FILES}
main.o: main.c
${CC} -c main.c
zrobto.o: zrobto.c
${CC} -c zrobto.c
szybciej.o: szybciej.s
${AS} -o szybciej.o szybciej.s
sprzataj:
rm *.o
moze.h: ${TN}
cp tak.h nie.h /usr/reksio/
W taki sam sposób jak makropolecenia traktowane są nazwy zmiennych środowisko-wych, o ile są one zdefiniowane w tym samym środowisku, w którym został urucho-miony program make. Jeśli na przykład w powłoce C zdefiniowana jest zmienna śro-dowiskowa o nazwie KOPIA
$ setenv KOPIA /usr/nowe/backup
można użyć jej w pliku makefile. Definicja
INNA_KOPIA = ${KOPIA}/zeszly_tydz
spowoduje więc, że makropolecenie INNA_KOPIA będzie równoważne tekstowi
/usr/nowe/backup/zeszly_tydz
Możliwe jest dalsze zmniejszenie rozmiaru pliku makefile. Nie trzeba na przykład określać położenia kompilatorów języka C i asemblera - są one znane programowi make. Można również używać dwóch wewnętrznych makropoleceń o nazwach $@ i $?. Makropolecenie $@ jest zawsze równoważne nazwie aktualnie przetwarzanego pliku docelowego, natomiast w skład makropolecenia $? wchodzą nazwy wszystkich pli-ków pierwotnych nowszych od bieżącego pliku docelowego. Oba te makropolecenia mogą być używane tylko w wierszach określających polecenia, które mają zostać wy-konane w celu uaktualnienia pliku. Przykładowy wpis:
cosnowego: ${OBJS} ${LIB_FILES}
${CC} -o $@ ${OBJS} ${LIB_FILES}
jest więc przy wywołaniu polecenia make cosnowego równoważny następującemu:
/usr/bin/cc -o cosnowego main.o zrobto.o szybciej.o /usr/nowe/lib
ĺ/swiezy.a
Makropolecenie $? ma jeszcze większe możliwości. Można je na przykład zastosować do kopiowania plików tak.h i nie.h do katalogu domowego użytkownika reksio tylko w przypadku, gdy zostały one zmodyfikowane. Zapisane w pliku makefile po-lecenie
moze.h: ${TN}
cp $? /usr/reksio/
będzie więc równoważne poleceniu
cp nie.h /usr/reksio/
w przypadku, gdy od czasu ostatniej aktualizacji programu cosnowego zmodyfiko-wany zostanie tylko plik nie.h; natomiast w przypadku, gdy oba pliki nie.h i tak.h zostaną zmodyfikowane, zostanie ono rozwinięte do postaci
cp tak.h nie.h /usr/reksio/
Używając podanych wyżej informacji, można nieco zredukować rozmiar pliku make-file:
# Nowa wersja pliku makefile
OBJS = main.o zrobto.o szybciej.o
TN = tak.h nie.h
LIB_DIR = /usr/nowe/lib
LIB_FILES = ${LIB_DIR}/swiezy.a
cosnowego: ${OBJS} ${LIB_FILES}
${CC} -o $@ ${OBJS} ${LIB_FILES}
main.o: main.c
${CC} -c $?
zrobto.o: zrobto.c
${CC} -c $?
szybciej.o: szybciej.s
${AS} -o $@ $?
sprzataj:
rm *.o
moze.h: ${TN}
cp $? /usr/reksio/
Reguły przyrostkowe

Jak wspomniano wcześniej w podrozdziale "Makropolecenia", program make nie wy-maga określenia reguł dla każdego z plików docelowych z osobna. Ponieważ program ten został zaprojektowany z myślą o uproszczeniu pracy związanej z tworzeniem oprogramowania w systemie Linux, wie on, w jaki sposób działają kompilatory (w szczególności kompilator języka C). Program make wie na przykład, że kompilator ję-zyka C spodziewa się otrzymania pliku źródłowego w języku C (którego nazwa ma rozszerzenie .c) i na jego podstawie generuje plik pośredni z rozszerzeniem .o. Tego typu reguła (nazywana regułą przyrostkową) oparta jest na rozszerzeniu nazwy pliku - na jego podstawie podejmowana jest decyzja o tym, jakie polecenia mają zostać wy-konane. Program make opiera swoje działanie na wielu zdefiniowanych wewnętrznie regułach przyrostkowych; większość z nich określa sposoby kompilacji kodu źródłowego i kon-solidacji plików pośrednich. Oto reguły przyrostkowe stosowane domyślnie w Twoim pliku makefile:
. SUFFIXES: .o .c .s
.c.o:
${CC} ${CFLAGS} -c $<
.s.o:
${AS} ${ASFLAGS} -o $@ $<
Pierwszy wiersz określa, dla jakich rozszerzeń plików należy zastosować reguły przy-rostkowe jeśli żadne reguły nie zostały zdefiniowane bezpośrednio. Drugi wiersz naka-zuje programowi make uruchomić kompilację plików z rozszerzeniem .c w przypadku, gdy odpowiadające im pliki z rozszerzeniem .o są nieaktualne. Trzeci pełni funkcję taką, jak drugi, ale dla plików asemblera z rozszerzeniem .s. Makropolecenie $< ma funkcję zbliżoną do omówionego wcześniej $?, ale może być używane tylko w regu-łach przyrostkowych. Reprezentuje ono nazwę aktualnie opracowywanego pliku doce-lowego Dzięki regułom przyrostkowym zadanie programisty ogranicza się do wprowadzenia do pliku makefile nazw wszystkich plików pośrednich; program make sam zajmuje się resztą. Jeśli plik main.o jest nieaktualny, program make automatycznie skompiluje plik main.c. Taka sama reguła odnosi się do pliku szybciej.o. Po uaktualnieniu pli-ków pośrednich można przystąpić do uaktualnienia pliku cosnowego. Możliwe jest również tworzenie własnych reguł przyrostkowych, dzięki czemu można wymusić podejmowanie innych niż domyślne działań. Jeśli na przykład po skompilo-waniu pliki powinny również zostać skopiowane do oddzielnego katalogu, można w pliku makefile umieścić następującą regułę:
.c.o:
${CC} ${CFLAGS} -c $<
cp $@ kopia
Makropolecenie $@, jak już wiesz, odpowiada nazwie aktualnie opracowywanego pliku docelowego. W powyższym poleceniu plik docelowy ma rozszerzenie .o, natomiast plik pierwotny - .c. Spróbujmy przepisać nasz plik makefile (już po raz ostatni), korzystając z reguł przy-rostkowych.
# Ostatnia wersja
OBJS = main.o zrobto.o szybciej.o
TN = tak.h nie.h
LIB_FILES = /usr/nowe/lib/swiezy.a
cosnowego: ${OBJS} ${LIB_FILES}
${CC} -o $@ ${OBJS} ${LIB_FILES}
sprzataj:
rm *.o
moze.h: ${TN}
cp $? /usr/reksio/
Powyższy plik makefile działa dokładnie tak samo, jak pierwsza z przedstawionych wersji - program cosnowego można skompilować wydając polecenie
$ make cosnowego
Można również skompilować jeden z jego fragmentów, na przykład tak:
$ make szybciej.o
Program make został w tym rozdziale omówiony bardzo pobieżnie. Jeśli chcesz dowie-dzieć się czegoś więcej o jego możliwościach, powinieneś przejrzeć dotyczące go strony man.
RCS
Innym bardzo ważnym aspektem tworzenia oprogramowania jest zarządzanie kodem źródłowym w trakcie jego ewoluowania. Bez względu na rodzaj tworzonej aplikacji, często zdarza się, że jej opracowywanie jest kontynuowane i pojawiają się nowe, po-prawione i ulepszone wersje. Przy tworzeniu większych aplikacji pracuje zwykle kilku programi-stów, co dodatkowo komplikuje zagadnienie zarządzania kodem źródłowym. Jeśli nie zostanie zastosowany żaden program zajmujący się tymi zadaniami, bardzo łatwo zagubić się przy aktualizowaniu wersji plików. Może to prowadzić do sytuacji, w której modyfikacje są tracone albo powtórnie opracowywane przez różnych programistów. Na szczęście w systemie Linux z pomocą przychodzą takie programy, jak RCS (Revi-sion Control System, system kontroli wersji). RCS to tylko jeden z licznych programów tego typu - istnieje również wiele innych; niektóre z nich są darmowe, inne komercyjne. Pierwszym UNIX-owym programem do zarządzania kodem źródłowym nadającym się do poważniejszych zastosowań był SCCS (Source Code Control System), używany zresztą po dziś dzień. RCS jest syste-mem o nieco większych możliwościach, implementującym rozwiązania, których bra-kowało w SCCS. Systemy RCS dostępne są w wersjach dla większości platform, włą-czając wszystkie wersje UNIX-a, DOS, Windows i Windows NT. Jeśli pracujesz nad pro-jektem tworzonym przez większą liczbę programistów, przyda Ci się wersja pozwalają-ca na pracę w sieci, o nazwie CVS (Concurrent Versions System). CVS jest dołączany do wielu wersji Linuxa. Polecenia używane w systemie CVS różnią się od poleceń wy-korzystywanych podczas pracy z RCS, ale ponieważ większość czytelników nie będzie na razie potrzebowała wersji sieciowej, w tym rozdziale skoncentrujemy się na syste-mie RCS. Jeśli gryzie Cię ciekawość, z wersjami Linuxa wyposażonymi w system CVS dostarczane są też odpowiednie strony man. Program RCS rejestruje informacje o wersjach plików, kontrolując dostęp do nich. Każdy użytkownik próbujący zmodyfikować określony plik musi zarejestrować się w systemie RCS i podać powód modyfikacji. RCS zapisuje te informacje i dane o wpro-wadzonych poprawkach w osobnym pliku. Ponieważ poprawki są rejestrowane w pliku innym niż oryginalny, można w razie potrzeby z łatwością wrócić do pierwotnej wersji kodu źródłowego. Takie rozwiązanie pozwala również zaoszczędzić miejsce na dysku, ponieważ nie trzeba wykonywać kopii całych plików. Jest to szczególnie widoczne przy modyfikacjach obejmujących tylko kilka wierszy kodu źródłowego, natomiast mało przydaje się, gdy istnieje tylko kilka znacznie różniących się między sobą wersji pro-gramu.
Delty
Zestaw modyfikacji zapisywanych przez system RCS do odpowiedniego pliku nazywany jest deltą. Numer wersji może mieć dwie formy. Pierwsza z nich składa się z nu-meru wydania i numeru poziomu. Numer wydania zmieniany jest zwykle po wprowadzeniu jakichś znaczących zmian w kodzie źródłowym. Po utworzeniu pliku RCS, otrzymuje on numer 1.1, oznaczający pierwszy poziom pierwszego wydania. RCS bę-dzie następnie przy wprowadzaniu modyfikacji odpowiednio zwiększał numer pozio-mu (na 1.2, 1.3 itd.). Można również wymusić zmianę numeru wydania programu. Druga forma numeru wersji programu również zawiera numer wydania i poziom, ale dodatkowo zawiera jeszcze numer kolejny poprawki. Można używać go, jeśli na przykład opracowałeś program, co do którego klient zgłasza zastrzeżenia, ale kolejnych poprawionych wersji nie chcesz numerować tak, jakby były wersjami "oficjalnymi". Choć następna wersja może również zawierać wprowadzone poprawki, jej wydanie może zostać opóźnione przez prace nad dodaniem nowej funkcjonalności programu. Z tego powodu czasem warto dodać do numeru wersji nowy składnik, zwiększany wraz z wprowa-dzaniem poprawek. Jeśli na przykład planowałeś wydanie wersji o numerach 3.1, 3.2, 3.3, 3.4 itd., a w którymś momencie zorientowałeś się, że w wersji 3.3 jest błąd, który wymaga wydania nowej wersji, nie zawierającej jeszcze rozwiązań planowanych w wersji 3.4, możesz wydać wersję o numerze 3.3.1.1, następnie 3.3.1.2 itd. Zwykle każdy nowy numer wersji powinien określać kompletny zestaw poprawek. Oznacza to, że kod w każdej z wersji powinien być przetesto-wany i powinny zostać z niego usunięte wszystkie błędy. Nie powinieneś zmieniać numeru wersji z 2.0 na 3.0 tylko dlatego, że usunąłeś kilka błę-dów w wersji 2.0. Główne numery wersji są zmieniane po dodaniu do pro-gramów nowych funkcji, a nie po skorygowaniu występujących usterek. Czy istnieją programy nie zawierające błędów? Na pewno nie są ich pozbawione większe aplikacje, w których niektóre usterki ujawniają się dopiero po scaleniu fragmentów kodu tworzonych przez różnych programi-stów. Celem programisty powinno być usunięcie wszystkich błędów w two-rzonej przez niego części programu. Choć prawdopodobnie nigdy nie uda się wyeliminować wszystkich usterek, można ograniczyć ich liczbę, dzięki czemu łatwiej będzie wykrywać i usuwać pozostałe.
Tworzenie pliku RCS
Załóżmy, że chcesz pracować nad programem, którego kod źródłowy zapisany w pliku loty.c ma postać:
/* Plik przykladowy dla systemu RCS
#include < stdio.h >
main()
{
printf("Program najwyższego lotu...\n");
}
Pierwszym krokiem powinno być utworzenie katalogu RCS:
$mkdir RCS
W tym katalogu będą przechowywane pliki systemu RCS. Następnie należy poinfor-mować ten system, że dany plik ma być nadzorowany. Służy do tego polecenie ci (ang. check-in):
$ ci loty.c
Po jego wydaniu należy wprowadzić odpowiedni komentarz dotyczący modyfikacji - wraz z innymi informacjami zostanie on zapisany w pliku o nazwie loty.c,v w kata-logu RCS. Zawartość oryginalnego pliku zostanie skopiowana do pliku oznaczonego numerem wersji 1.1. Po wydaniu kolejnego polecenia ci system RCS usunie kopię roboczą z ka-talogu RCS.
Odzyskiwanie pliku RCS
Jeśli chcesz uzyskać kopię pliku nadzorowanego przez RCS, powinieneś użyć polecenia co (ang. check-out). Polecenie to wydane bez żadnych argumentów daje wersję pliku przeznaczoną tylko do odczytu, której nie można edytować. Jeżeli chcesz modyfiko-wać otrzymany plik, powinieneś użyć opcji -l:
$ co -l loty.c
Po zakończeniu modyfikowania pliku można ponownie załączyć nadzorowanie go za pomocą polecenia ci. Zostaniesz poproszony o komentarz dotyczący wprowadzo-nych zmian. Nadzorowany plik zostanie oznaczony numerem wersji 1.2. Oznaczenia numeru wersji stosowane przez system RCS składają się z numeru wyda-nia, poziomu (ang. level) i dwóch składników określających numer poprawki (ang. branch i sequence). Polecenia RCS operują domyślnie na najświeższej wersji pliku, ale można wymusić użycie innej wersji. Jeśli na przykład najnowsza wersja pliku loty.c ma numer 2.7, a modyfikacje, które wprowadziłeś, są na tyle znaczące, że postanowi-łeś zmienić numer wydania, powinieneś wydać polecenie ci z opcją -r i numerem no-wego wydania:
$ ci -r3 loty.c
Powyższe polecenie spowoduje oznaczenie pliku numerem wersji 3.1. Można również otworzyć nową gałąź poprawek rozpoczynającą się na poziomie 2.7 za pomocą pole-cenia:
$ ci -r2.7.1 loty.c
Polecenie rcs z opcją -o służy do usuwania niepotrzebnych, nieaktualnych wersji pli-ków. Aby na przykład usunąć wersję o numerze 2.6, powinieneś wydać polecenie
$ rcs -o2.6 loty.c
Słowa kluczowe
Częścią pliku nadzorowanego przez system RCS mogą być również słowa kluczowe. Służą one do osadzania w pliku takich informacji, jak dane o autorze, data utworzenia poszczególnych wersji pliku itp. - dane te mogą być odczytane za pomocą polecenia ident. Słowa kluczowe należy wprowadzać bezpośrednio do aktualnie opracowywa-nej kopii pliku. Przy wydawaniu poleceń ci i co do słów kluczowych systemu RCS do-łączane są odpowiednie wartości. Słowa kluczowe należy otaczać z obu stron symbo-lami dolara:
$słowo_kluczowe$
Są one przekształcane do postaci:
$słowo_kluczowe: wartość $
Oto niektóre ze słów kluczowych rozpoznawanych przez system RCS:
$Author$    użytkownik, który jest autorem danej wersji;
$Date$    data i czas zarejestrowania wersji;
$Log$    wszystkie komentarze odnoszące się do danego pliku;
$Revision$     numer wersji pliku.
Jeśli słowa te byłyby używane w pliku loty.c, polecenie ident mogłoby zwrócić na przykład takie informacje:

$ ident loty.c
$Author: reksio $
$Date: 97/01/15 23:15:32 $
$Log: loty.c,v $
# Revision 1.2 97/01/15 23:15:32 reksio
# Drobne modyfikacje
#
# Revision 1.1 97/01/15 23:10:12 reksio
# Utworzenie pliku loty.c
#
$Revision: 1.2 $
Uzyskiwanie informacji o wersji z pliku RCS
Czasem zamiast informacji opartych na słowach kluczowych RCS bardziej potrzebne są ogólniejsze, podsumowujące dane, podawane przez polecenie rlog z opcją -t:
$ rlog -t loty.c
RCS file: loty.c,v; Working file: loty.c
head: 3.2
locks: reksio: 2.1; strict
access list: rick tim
symbolic names:
comment leader: " * "
total revisions: 10;
description:
Tak... Program najwyzszego lotu...
=================================================================
Pole head zawiera informację o numerze ostatniej wersji pliku. W polu locks zawarte są identyfikatory użytkowników, którzy modyfikowali plik oraz typ stosowanego za-bezpieczenia (bezpośredni czy pośredni dla właściciela pliku RCS). Pole access list zawiera identyfikatory użytkowników, którzy mają prawo tworzenia delt danego pliku.
Dostęp do plików RCS
Jedną z ważniejszych funkcji systemu RCS jest ograniczanie dostępu do tych plików, które nie powinny być modyfikowane przez danego użytkownika. RCS przechowuje li-stę użytkowników uprawnionych do modyfikacji każdego pliku z osobna. Początkowo lista ta jest pusta, co oznacza, że wszyscy użytkownicy mogą wprowadzać poprawki do nadzorowanego pliku. Aby umożliwić modyfikowanie pliku tylko określonym użyt-kownikom lub grupom, należy wydać polecenie rcs z opcją -a. Przykładowe polece-nie
$ rcs -arick,tim loty.c
spowoduje, że prawo modyfikacji pliku loty.c będą mieli tylko użytkownicy o iden-tyfikatorach tim i rick. Jeśli zmienisz zdanie i uznasz, że rick nie powinien jednak wtrącać się do tworzenia Twojego wspaniałego programu, możesz zabronić mu dostę-pu do niego za pomocą opcji -e programu rcs:
$ rcs -erick loty.c
Jeśli w przypływie paranoi stwierdzisz, że nikt nie powinien mieć możliwości modyfi-kowania Twojego programu, możesz po prostu go zablokować (co uniemożliwi wpro-wadzanie zmian nawet właścicielowi pliku). Aby zablokować modyfikowanie drugiego wydania programu loty.c, wydaj polecenie:
$ rcs -e -L2 loty.c
Właściciel pliku może wprowadzić modyfikacje tylko po jawnym zablokowaniu pliku, zarówno przy wydawaniu polecenia ci, jak i co.
Porównywanie wersji i łączenie poprawek
System RCS umożliwia porównywanie poszczególnych wersji plików, co pozwala ła-two zorientować się, jakie zmiany zostały wprowadzone. Dzięki takiemu rozwiązaniu można bezpiecznie łączyć poprawki wprowadzane do pliku przez różne osoby. Do wy-świetlania różnic pomiędzy poszczególnymi wersjami pliku nadzorowanego przez RCS bądź też pomiędzy którąś z wersji pliku a wersją najnowszą służy polecenie rcsdiff. Polecenie
$ rcsdiff -r1.2 -r1.5 loty.c
powoduje wyświetlenie różnic pomiędzy wersjami 1.2 i 1.5 pliku loty.c, na przykład tak:
RCS file: loty.c,v
retrieving revision 1.1
rdiff -r 1.2 -r1.5 loty.c
6a7,8
>
> /* Choc w zasadzie nie jest szczegolnie ciekawy */
Powyższe dane wskazują, że poszczególne wersje różnią się tylko tym, że po wierszu szóstym zostały dodane dwa nowe wiersze (które zostały wyświetlone). Jeśli chcesz sprawdzić, czym pierwotna wersja pliku (określona w polu head) różni się od wersji za-rejestrowanej ostatnio, wydaj polecenie:
$ rcsdiff loty.c
Po stwierdzeniu, że pomiędzy poprawkami wniesionymi przez Ciebie i innych progra-mistów nie ma potencjalnych konfliktów, możesz zdecydować się na połączenie po-szczególnych wersji. Służy do tego polecenie rcsmerge. Składnia tego polecenia wy-maga podania nazwy jednego lub dwóch plików, określających wersje, które należy połączyć i trzeciej nazwy, określającej nazwę pliku roboczego (w poniższym przykła-dzie - loty.c). Wydanie polecenia
$ rcsmerge -r1.3 -r1.6 loty.c
powoduje wygenerowanie następujących komunikatów:

RCS file: loty.c,v
retrieving version 1.3
retrieving version 1.6
Merging differences between 1.3 and 1.6 into loty.c
Jeśli wprowadzone modyfikacje kolidują ze sobą, program rcsmerge wstawia do pliku obie wersje, oznaczając odpowiednio ich pochodzenie. Zaistniały konflikt trzeba roz-wiązać ręcznie, edytując powstały plik przed ponownym nakazaniem nadzorowania go przez system RCS. Porządek, w jakim podawane są wersje plików, które należy połączyć, jest istotny. Jeśli po opcji -r najpierw podany zostanie numer późniejszej wer-sji, wszystkie wprowadzone w niej zmiany (w stosunku do wersji wcześniej-szej) zostaną wycofane.
Praca z programem make i systemem RCS
Program make jest przystosowany do współpracy z systemem RCS, wraz z którym tworzy kompletne pod wieloma względami środowisko programistyczne. Mimo wszystko jednak używanie obu tych programów równocześnie może stwarzać pewne problemy, szczególnie jeśli nad projektem pracuje kilku programistów. Ujawniają się one szczególnie na etapie testowania programu - wtedy programista potrzebuje stabil-nych, nie zmieniających się wersji plików. Testowanie może stwarzać większe trudności natury organizacyjnej niż jakakolwiek inna faza tworzenia projektu. Dla pojedyncze-go programisty jednak problemy te nie mają żadnego znaczenia, a współpraca pro-gramu make i systemu RCS znakomicie ułatwia tworzenie aplikacji, szczególnie w sys-temie Linux. Aby umożliwić opracowywanie plików RCS przez program make, należy w pliku make-file zdefiniować regułę przyrostkową dla rozszerzenia ,v. Pliki z rozszerzeniem ,v są właśnie plikami systemu RCS. Jeśli pliki nadzorowane przez system RCS mają być kompilowane za pomocą kompilatora języka C, w pliku makefile powinny znaleźć się następujące reguły:
CO = co
.c,v.o:
${CO} $<
${CC} ${CFLAGS} -c $*.c
- rm -f $*.c
Makropolecenie CO jest równoważne poleceniu co. Makropolecenie $*.c jest niezbęd-ne, ponieważ program make automatycznie usuwa rozszerzenie .c. Myślnik poprze-dzający polecenie rm powoduje, że program make będzie kontynuował działanie na-wet w przypadku, gdy wykonanie polecenia rm zakończy się błędem. Jeśli na przykład system RCS nadzorowałby plik o nazwie main.c, program make wygenerowałby na-stępujące polecenia:
co main.c
cc -O -c main.c
rm -f main.c

Jądro systemu
Poza przypadkami takimi jak instalowanie nowej wersji systemu, instalowanie nowych składników sieci (takich jak NFS czy NIS) czy nowych sterowników urządzeń wyma-gających specjalnego traktowania nie ma konieczności modyfikowania jądra systemu. Szczegółowe informacje na temat instalowania sterowników urządzeń zwykle są roz-prowadzane wraz z oprogramowaniem. Nie jest tak jednak w każdym przypadku. Na początek powiedzmy wyraźnie, że nie powinieneś modyfikować jądra systemu, jeśli nie wiesz, co chcesz przez to osiągnąć. Jeśli kod źródłowy lub pliki konfiguracyjne zostaną uszkodzone, kernel może być niestabilny, co w najgorszym przypadku może prowadzić do uszkodzenia systemu pli-ków. Uważnie zapoznaj się z przedstawionymi poniżej informacjami i przestrzegaj podanych wskazówek. Modyfikowanie jądra systemu wyma-ga sporej wiedzy, a w tym rozdziale możemy przedstawić tylko podstawo-we informacje. Obecnie używa się powszechnie kilku różnych wersji Linuxa, nie do końca zgodnych pomiędzy sobą. Z tej przyczyny przedstawione poniżej instrukcje mogą nie działać prawidłowo w Twojej wersji Linuxa. Mimo tego idea pozostaje ta sama, różnice mogą wystąpić tylko w przypadku nazw programów użytkowych i ścieżek dostępu do nich. Do większości wersji Linuxa dołączana jest dokumentacja omawiająca proces kompi-lowania jądra i zawierająca informacje o położeniu kodu źródłowego i skompilowa-nych programów. Zanim podejmiesz jakiekolwiek kroki upewnij się, że posiadasz odpowied-ni zestaw dyskietek startowych. Warto również wykonać pełną kopię za-pasową systemu plików. Choć proces modyfikowania jądra nie jest trudny, jeśli coś pójdzie nie tak, może okazać się, że nie da się ponownie urucho-mić systemu. W takiej sytuacji najprostszym rozwiązaniem jest użycie dyskietek startowych, warto więc posiadać przynajmniej jeden zapasowy ich zestaw. Ponieważ jądro systemu jest kompilowane za pomocą kompilatora języka C wcho-dzącego w skład każdej dystrybucji Linuxa, to właśnie na nim skoncentrujemy się w dalszej części tego rozdziału, omawiając jego znaczniki i sposoby stosowania. Nie bę-dzie to oczywiście kompletny opis kompilatora języka C, ale powinien być wystarcza-jący przy podstawowych czynnościach związanych z modyfikowaniem jądra systemu (i kompilowaniem dowolnych programów napisanych w języku C).
Uaktualnianie i instalowanie nowych składników jądra systemu
Linux jest systemem rozwijającym się bardzo dynamicznie. Nowe wersje jądra systemu bądź też innych komponentów dołączanych do jądra są co jakiś czas udostępnia-ne dla użytkowników. Decyzję o tym, czy należy uaktualnić wersję jądra systemu, mu-sisz podjąć sam - zwykle opiera się ona na danych dotyczących błędów usuniętych w nowej wersji czy też oferowanych przez nią nowych możliwościach. Po dołączeniu nowego oprogramowania prawdopodobnie będzie trzeba odnowić wszystkie dowiąza-nia do jądra systemu, chyba że nowe komponenty są sterownikami urządzeń czy nie-zależnymi programami użytkowymi. Mimo wszystko, należy jednak zdecydowanie unikać uaktualniania systemu wraz z każdą nową wersją, i to z kilku powodów. Może na przykład zdarzyć się, że zainstalo-wane oprogramowanie nie jest zgodne z nową wersją programów użytkowych czy ją-dra systemu. Może również okazać się, że nowa wersja posiada poważny błąd. Tego typu sytuacje mogą powodować nie kończące się problemy. Większość nowych wersji programów nie zachowuje istniejących informacji konfiguracyjnych, więc konieczna jest także ponowna konfiguracja wszystkich pakietów, które zostały zainstalowane na nowo. Poza tym, nowe wersje programów pojawiają się na tyle często, iż nie jest wykluczone, że więcej czasu spędziłbyś na ich ładowaniu i instalowaniu niż na faktycznym korzy-staniu z systemu. Taka sytuacja może być bardzo męcząca. Liczba zmian wprowa-dzanych w kolejnych wersjach systemu różniących się tylko numerem pobocznym jest zwykle niewielka, dlatego należy przejrzeć dołączone do niej informacje i upewnić się, że faktycznie warto poświęcić czas na jej instalację. Z praktycznego punktu widzenia dobrze jest aktualizować system raz lub dwa razy do roku, tylko wtedy, gdy nowa wersja zawiera rozwiązania, które znacznie zmienią spo-sób, w jaki używasz system. Posiadanie zawsze najnowszej wersji systemu jest kuszące, ale trzeba również brać pod uwagę korzyści wynikające z utrzymywania stabilnego i funk-cjonalnego systemu operacyjnego. Jeśli uaktualniasz wersję oprogramowania, powinieneś zdawać sobie sprawę z faktu, że nie musisz uaktualniać wszystkiego. W kilku ostatnich wersjach Linuxa zmieniało się co najwyżej 5% systemu operacyjnego. Zamiast wymiany całego oprogramowania warto więc rozważyć zainstalowanie tylko tych fragmentów, które faktycznie uległy znaczącym zmianom, czyli zwykle jądra systemu, kompilatora, bibliotek i często wy-korzystywanych programów użytkowych. Takie rozwiązanie pozwoli uniknąć ko-nieczności ponownego konfigurowania pozostałych części systemu.
Kompilowanie kodu źródłowego jądra systemu
Uaktualnienie, wymiana czy dodanie nowego kodu do jądra systemu jest zwykle pro-cesem dość prostym. Sprowadza się do zdobycia odpowiedniego kodu źródłowego, do-stosowania informacji konfiguracyjnych, skompilowania a następnie umieszczenia skompilowanych programów w odpowiednim miejscu tak, by system mógł działać prawidłowo. Proces ten zwykle jest zautomatyzowany za pomocą skryptu powłoki lub programu instalacyjnego - w niektórych przypadkach wszystko sprowadza się do wy-dania jednego polecenia. Kod źródłowy nowych wersji jądra systemu dostępny jest zwykle z dystrybucjami roz-prowadzanymi na płytach CD-ROM, w węzłach FTP, grupach dyskusyjnych i w wielu innych miejscach. Większość wersji jądra posiada numer składający się z głównego i pobocznego numeru wersji (dwie pierwsze liczby) oraz numeru poprawki (trzecia licz-ba), na przykład 1.12.123. W większości węzłów FTP czy BBS równocześnie udostęp-nianych jest kilka wersji jądra - musisz wziąć to pod uwagę, jeśli chcesz załadować je-go najnowszą wersję. Poprawki do kodu źródłowego jądra systemu zwykle nie zawierają całego kodu. Ich instalacja powoduje nadpisanie fragmentów istniejącego kodu źródłowego. Po jego ponownym skompilowaniu poprawka jest już zainstalowana. Tego typu poprawki udostępniane są dość często. Podczas instalowania poprawki należy ograniczyć do minimum liczbę otwartych plików i działających procesów oraz aplikacji. Pozwoli to unik-nąć problemów związanych z pozostawieniem otwartych plików, co może prowadzić nawet do uszkodzenia tablicy I-node. Ponieważ aby zainstalo-wać poprawkę i tak musisz być zalogowany jako root, możesz zakoń-czyć wszystkie niepotrzebne procesy i aplikacje. W większości przypadków kod źródłowy jest rozprowadzany w postaci skompresowanego (zwykle programem gzip) archiwum programu tar. Taki plik należy rozpakować do katalogu /usr/src, w którym zwykle przechowywany jest kod źródłowy programów. W niektórych wersjach Linuxa do tego celu przeznaczony jest inny katalog - powinieneś więc przejrzeć dokumentację rozprowadzaną z posiadaną przez Ciebie wersją Linuxa lub poszukać w katalogu /usr/src pliku README, w którym powinny znajdować się dokładniejsze informacje. Często zdarza się, że rozpakowanie pliku do katalogu /usr/src powoduje utworzenie podkatalogu /usr/src/linux, co może prowadzić do nadpisania obecnej w systemie wersji kodu źródłowego jądra. Przed rozpoczęciem rozpakowywania warto więc zmie-nić nazwę istniejącego katalogu lub skopiować jego zawartość w bezpieczne miejsce, dzięki czemu w przypadku problemów łatwo będzie wrócić do wersji poprzedniej. Po rozpakowaniu kodu źródłowego należy utworzyć dwa dowiązania symboliczne (o ile nie zostały one utworzone przez program instalacyjny) do katalogu /usr/include. Można to zrobić wydając polecenia:
ln -sf /usr/src/linux/include/linux /usr/include/linux
ln -sf /usr/src/linux/include/asm /usr/include/asm
Jeśli w Twoim systemie używane są inne ścieżki dostępu, podstaw zamiast /usr/src/linux odpowiednią wartość. Jeśli takie dowiązania nie istnieją, poprawne uaktualnienie jądra systemu nie będzie możliwe. Po rozpakowaniu kodu źródłowego i utworzeniu odpowiednich dowiązań można roz-począć proces kompilacji. W tym celu niezbędny będzie kompilator gcc lub g++ (kompilator GNU języka C i C++) lub inny zgodny z nimi kompilator. Należy sprawdzić w dokumentacji dołączonej do nowej wersji kodu źródłowego czy używana wersja kompilatora jest odpowiednia, ponieważ zdarza się, że nowe wersje jądra nie dają się skompilować za pomocą starszych wersji kompilatorów. Następnie należy przejrzeć plik /usr/src/linux/Makefile (w niektórych dystrybu-cjach może on znajdować się w innym katalogu). Znajdź w nim wiersz definiujący zmienną ROOT_DEV, określającą urządzenie, na którym zapisany jest główny system plików. Zwykle definicja ta ma postać
ROOT_DEV = CURRENT
Jeśli wartość zmiennej ROOT_DEV jest inna, upewnij się, że jest ona odpowiednia dla Twojego systemu. Jeżeli w pliku Makefile nie ma takiej definicji, należy ją dodać. Proces kompilacji rozpoczyna się po przejściu do katalogu /usr/src/linux i wydaniu polecenia
make config
uruchamiającego program make, generujący odpowiednie polecenia kompilujące pliki źródłowe. W niektórych wersjach Linuxa proces ten może wyglądać nieco inaczej - odpowiednich informacji należy szukać w dokumentacji dołączonej do plików źró-dłowych. W następnym kroku program config zadaje serię pytań dotyczących różnych aspektów konfiguracji jądra, na które należy odpowiedzieć przed rozpoczęciem właściwej kompilacji. Pytania te dotyczą między innymi typu dysku twardego, procesora, typów używanych partycji czy innych urządzeń dołączonych do komputera, na przykład napędów CD-ROM. Powinieneś odpowiedzieć na nie najlepiej, jak potrafisz. Jeśli masz wątpliwości co do którejś z odpowiedzi, wybierz odpowiedź domyślną albo tę, która wydaje się być naj-odpowiedniejsza. W najgorszym przypadku - jeśli system nie będzie działał prawidło-wo - będzie trzeba powtórzyć cały proces od początku (oczywiście pod warunkiem, że przygotowałeś dyskietki startowe). Następnie należy ustalić wszystkie zależności pomiędzy plikami kodu źródłowego. Ten etap często jest pomijany, ale takie postępowanie może powodować mnóstwo proble-mów. Aby ustalić zależności dla zainstalowanej wersji kodu źródłowego jądra systemu, wydaj polecenie:
make dep
Jeśli w skład instalowanego oprogramowania nie wchodzi plik zależności (o nazwie dep), powinieneś upewnić się, że odpowiednie czynności podejmowane są w czasie wykonywania innych etapów konfiguracji oprogramowania (informacje takie znajdu-ją się w dokumentacji dołączonej do plików źródłowych). Na koniec pora rozpocząć kompilację nowego jądra - w tym celu należy wydać pole-cenie
make Image
które spowoduje skompilowanie jądra i pozostawienie go w katalogu bieżącym (zwy-kle /usr/src/linux). Jeśli chcesz utworzyć skompresowaną wersję jądra systemu, wydaj polecenie
make zImage
Nie wszystkie dystrybucje Linuxa pozwalają na kompresowanie jądra systemu w trak-cie jego kompilacji. Ostatnim krokiem jest skopiowanie nowej wersji jądra systemu na dysk, z którego uru-chamiany jest system, lub też na dyskietkę startową. Polecenie
cp Image /dev/fd0
spowoduje umieszczenie kopii jądra systemu na dyskietce. Jeśli chcesz umieścić ją gdzieś indziej, podstaw odpowiednią nazwę urządzenia. Jeżeli natomiast do urucha-miania systemu używany jest program LILO, wówczas aby zainstalować nowe jądro, należy uruchomić program instalacyjny lub program /usr/lilo/lilo . Teraz pozostaje tylko uruchomić ponownie system i sprawdzić, czy nowe jądro prawidłowo ładuje się do pamięci. Jeśli wystąpią jakieś problemy, należy uruchomić system z dyskietki startowej i powtórzyć cały proces. W dołączonej do kodu źródłowego dokumentacji znajdziesz wskazówki dotyczące rozwiązywania niektórych problemów oraz informacje o ewentualnych zmianach w procesie kompilacji jądra. Dodawanie sterowników urządzeń Nowe sterowniki urządzeń można również dołączać do istniejącej wersji jądra bez ko-nieczności jego konfiguracji i kompilowania. Z taką sytuacją można często zetknąć się w przypadkach, gdy do systemu dodane zostanie takie urządzenie, jak karta multiport czy dysk optyczny, do których obsługi niezbędne jest załadowanie odpowiednich ste-rowników podczas uruchamiania systemu. Może również zdarzyć się, że będziesz chciał zainstalować jakiś rodzaj oprogramowania podnoszącego poziom bezpieczeń-stwa systemu i wymagającego modyfikacji samego jądra systemu. Sterowniki wymagające kompilacji jądra przeważnie rozprowadzane są wraz z odpo-wiednią dokumentacją. Zwykle otrzymany kod źródłowy należy umieścić w tym sa-mym katalogu, w którym znajduje się kod źródłowy jądra systemu (na przykład /usr/src). Aby dodać do jądra systemu nowy fragment kodu, trzeba zmodyfikować plik Makefile - ręcznie bądź też za pomocą odpowiedniego skryptu instalacyjnego. W niektórych przypadkach do kodu źródłowego sterowników dodawany jest osobny plik Makefile. Następnym krokiem jest skompilowanie jądra wraz z nowymi sterownikami. Proces ten nie różni się od opisanego w poprzednim podrozdziale - skompilowane jądro należy skopiować na dyskietkę startową lub zainstalować za pomocą programu LILO. Zwy-kle cały proces nie zabiera więcej niż dziesięć minut i raczej nie sprawia kłopotów, chyba że dostawca oprogramowania kiepsko wywiązał się ze swych obowiązków. Przed instalacją upewnij się, że nowe sterowniki będą działać z Twoją wersją jądra sys-temu - odpowiednie informacje znajdziesz w plikach tekstowych dołączonych do ko-du źródłowego oraz w plikach dotyczących zgodności z różnego typu oprogramowa-niem, rozprowadzanych z większością wersji Linuxa.
Uaktualnianie bibliotek
Większość programów przeznaczonych dla systemów linuxowych korzysta z bibliotek współużytkowanych (ang. shared libraries; jest to zestaw podprogramów, które mogą być wykorzystywane przez różne aplikacje). Jeśli po uaktualnieniu jądra systemu przy uruchomianiu programów wyświetlany jest komunikat
Incompatible library version
oznacza to, że biblioteki również wymagają uaktualnienia. Większość bibliotek jest kompatybilna wstecz, co oznacza, że programy wykorzystujące starsze wersje biblio-tek będą działać poprawnie również po zainstalowaniu nowych wersji bibliotek. Nowe wersje bibliotek pojawiają się rzadziej niż nowe wersje jądra systemu i są roz-prowadzane w ten sam sposób. Zwykle do nowych wersji jądra dołączane są pliki tek-stowe zawierające informacje o wymaganych bibliotekach i wskazujące miejsca, w których można zaopatrzyć się w ich najnowsze wersje. Nowe wersje bibliotek rozprowadzane są najczęściej w postaci skompresowanego ar-chiwum programu tar, więc proces ich rozpakowywania jest taki sam, jak plików za-wierających kod źródłowy jądra systemu, z tym że katalogami docelowymi są zwykle katalogi /lib, /usr/lib i /usr/include. Pliki z rozszerzeniami .a i .aa trafiają przeważnie do katalogu /usr/lib, natomiast pliki obrazów bibliotek współużytkowa-nych, których nazwy mają postać libc.so.wersja, do katalogu /lib. Po zainstalowaniu nowych wersji bibliotek czasem zachodzi konieczność ręcznej mo-dyfikacji dowiązań symbolicznych, tak by prowadziły do najnowszych wersji biblio-tek. Przykładowo, jeśli używasz biblioteki libc.so w wersji 4.4.1 i uaktualniłeś jej wersję do 4.4.2, powinieneś zmodyfikować odpowiednie dowiązanie, wydając pole-cenie:
ln -sf /lib/libc.so.4.4.1 /lib/libc.so.4
Ostatni argument jest nazwą uaktualnianej biblioteki - nazwy te mogą być różne w za-leżności od dystrybucji - należy to sprawdzić w dokumentacji. W taki sam sposób należy zmodyfikować również dowiązanie dla biblioteki libm.so. Dowiązań symbolicznych nie należy usuwać, ponieważ programy korzystające z bi-bliotek współużytkowanych (m.in. program ls) nie będą działać poprawnie.
Kompilator języka C dla systemu Linux
W systemie Linux kompilator języka C jest wykorzystywany do kompilowania wszystkich wersji jądra systemu i znacznej większości programów użytkowych. Dla wszystkich wersji Linuxa dostępny jest kompilator GNU C, o nazwie gcc. Powstał on w ramach projektu Free Software Foundation, w związku z czym jest darmowy. Kompilator GNU C rozprowadzany wraz z dystrybucją Slackware jest w pełni funk-cjonalnym kompilatorem spełniającym standardy ANSI C. Jeśli znasz już jakiś kompi-lator języka C z innej platformy, będziesz w stanie opanować gcc w bardzo krótkim czasie. Przy wywoływaniu kompilatora GCC należy podać szereg argumentów, na które skła-dają się różne opcje i przynajmniej jedna nazwa pliku. Najogólniej rzecz ujmując, składnia polecenia uruchamiającego kompilator gcc jest następująca:
gcc [opcje] [nazwy_plików]
Działania określone przez opcje podane w wierszu poleceń zostaną wykonane w od-niesieniu do każdego z wyszczególnionych plików. Opcji rozpoznawanych przez kom-pilator gcc jest ponad setka. Większości z nich prawdopodobnie nigdy nie będziesz musiał użyć, ale kilka jest niezbędnych nawet przy najprostszych czynnościach. Wiele nazw opcji programu gcc składa się z więcej niż jednego znaku. Z tego powodu każda z opcji musi zostać poprzedzona oddzielnym myślnikiem. Nie można grupować opcji po wspólnym myślniku, jak ma to miejsce w przypadku większości poleceń sys-temu Linux. Podane poniżej dwa przykładowe polecenia mają różne znaczenie:
gcc -p -g test.c
gcc -pg test.c
Pierwsze z nich nakazuje programowi gcc skompilować plik test.c, dołączając do pliku wykonywalnego kod pozwalający na wykonanie profilu dynamicznego progra-mu (-p) oraz informacje pozwalające na współpracę z debugerem (-g), natomiast dru-gie polecenie (z opcją -pg) powoduje skompilowanie pliku test.c i dołączenie do nie-go informacji pozwalających na profilowanie za pomocą polecenia gprof. Kiedy kompilujesz program nie używając żadnych opcji, w bieżącym katalogu two-rzony jest plik wykonywalny (o ile kompilacja zakończy się bez błędów) o nazwie a.out. Jeśli chcesz, by nazwa tworzonego pliku wykonywalnego była inna, powinieneś użyć opcji -o. Przykładowo, aby skompilować program zapisany w pliku licznik.c do pliku wykonywalnego o nazwie licznik należy wydać polecenie:
gcc -olicznik licznik.c
Nazwa pliku wyjściowego musi pojawić się bezpośrednio po opcji -o. Nie należy wstawiać pomiędzy nie innych opcji. Inne opcje kompilatora decydują o tym, na jakim etapie należy zakończyć proces kompilacji. Opcja -c powoduje zakończenie procesu po utworzeniu pliku pośredniego (domyślnie z rozszerzeniem .o), z pominięciem asemblacji i konsolidacji. Jest ona używana dość często, ponieważ umożliwia przyśpieszenie kompilacji złożonych, wie-loplikowych programów. Opcja -S powoduje zakończenie kompilacji po wygenerowaniu plików asemblera (domyślnie z rozszerzeniem .s). Opcja -E powoduje, że kompilator tylko wstępnie przetworzy pliki wejściowe, wykonując zawarte w nich dyrektywy preprocesora. W ta-kim przypadku dane wyjściowe wysyłane są na ekran, a nie do pliku. Kompilator GCC stara się utworzyć kod wynikowy w możliwie najkrótszym czasie w taki sposób, by łatwo było znaleźć w nim ewentualne błędy. Oznacza to, że kolejność operacji pozostaje taka sama jak w pliku źródłowym i nie jest dokonywana żadna op-tymalizacja. Istnieje wiele opcji, dzięki którym możesz nakazać tworzenie mniejszych czy szybszych wersji programów, kosztem czasu ich kompilacji oraz łatwości wyszu-kiwania błędów. Najczęściej używa się opcji -O oraz -O2. Opcja -O powoduje zastosowanie podstawowych technik optymalizacyjnych. Owocu-je to zwykle powstaniem szybciej działających wersji programów. Opcja -O2 powodu-je, że wygenerowany zostanie możliwie krótki oraz szybki kod. Czas kompilacji w tym przypadku jest dłuższy, ale za to program wynikowy działa szybciej. Poza tymi opcjami istnieje jeszcze wiele opcji niskiego poziomu, których można użyć do dalszego przyspieszania działania programu. Są one jednak bardzo specyficzne i powinieneś używać ich tylko wtedy, gdy dokładnie zdajesz sobie sprawę z tego, co powodują, i jakie mogą być ich konsekwencje. Bardziej szczegółowe informacje o tych opcjach znajdziesz na stronach man.
Opcje współpracy z debugerem i programem profilującym
Spośród kilku opcji dotyczących wstawiania dodatkowego kodu służącego do określa-nia szybkości wykonywania programu i ułatwiającego uruchamianie i testowanie, naj-częściej używane są dwie: -g oraz -pg. Opcja -g powoduje dołączenie do pliku wykonywalnego informacji dla debugera gdb, który często okazuje się niezbędny w procesie wyszukiwania błędów. GCC oferuje coś, czego nie daje większość innych kompilatorów: możliwość łącznego użycia opcji -g oraz -O (która powoduje wygenerowanie zoptymalizowanej wersji programu). Jest to bardzo przydatne, szczególnie jeśli chcesz testować produkt jak najbardziej zbliżony do wersji końcowej. Powinieneś jednak zdawać sobie sprawę, że część kodu zostanie przez kompilator nieco zmodyfikowana. Opcja -pg pozwala na dołączenie do programu wykonywalnego dodatkowego kodu, który, po uruchomieniu programu, wygeneruje informacje o czasie wykonania po-szczególnych sekcji programu. Dane te mogą być przeglądane za pomocą programu gprof. Więcej informacji na jego temat znajdziesz w podrozdziale "gprof".
Wyszukiwanie błędów - debuger gdb
Wraz z Linuxem rozprowadzany jest program gdb, który jest bardzo potężnym debu-gerem, służącym do wyszukiwania błędów w programach napisanych w językach C i C++. Umożliwia dostęp do struktur danych i pamięci wykorzystywanej przez program podczas jego działania. Oto jego podstawowe zalety:
- pozwala śledzić wartości zmiennych podczas wykonywania programu,
- pozwala ustawiać pułapki, które zatrzymują program po osiągnięciu danego wiersza kodu,
- pozwala wykonywać program krokowo, wiersz po wierszu.
Przy uruchamianiu programu gdb można również podać różne parametry w wierszu poleceń. Zwykle program ten uruchamia się podając nazwę pliku wykonywalnego, w którym chcemy szukać błędów:
gdb
W takim przypadku plik wykonywalny zostanie załadowany automatycznie. Można również uruchomić gdb w taki sposób, by możliwe było oglądanie zawartości pliku ze zrzutem pamięci (ang. core dump) wygenerowanego przez program; można też dołą-czyć gdb do działającego już procesu. Aby obejrzeć listę dostępnych opcji z ich krót-kim opisem, zajrzyj na stronę man lub uruchom gdb z opcją -h. Aby program gdb mógł działać poprawnie, do pliku wykonywalnego muszą zostać dołączone przez kompilator informacje o typach i nazwach zmiennych, o mapowaniu kodu na linie programu źródłowego itd., które pozwolą na powiązanie kodu źródłowe-go i skompilowanego kodu programu. W tym celu w poleceniu kompilującym plik źró-dłowy należy podać również opcję -g.

Tworzenie sterowników urządzeń
Sterownik urządzenia stanowi interfejs pomiędzy systemem operacyjnym a urządze-niem dołączonym do systemu. Typowy sterownik składa się z pewnej liczby funkcji potrafiących obsługiwać operacje wejścia / wyjścia zlecane przez system. Takie roz-wiązanie pozwala na ujednolicenie interfejsu pomiędzy jądrem systemu i urządzenia-mi. Nie możemy niestety omówić wszystkich aspektów tworzenia sterowników urządzeń w jednym rozdziale. Na ten temat napisano kilka całkiem pokaźnych książek. Ponie-waż sterowniki urządzeń nie są raczej tworzone przez zwykłych użytkowników, a przez utalentowanych programistów, informacje przedstawione poniżej mają jedynie cha-rakter przedstawienia zagadnienia. Fragmenty kodu pochodzą z zestawu przykładowych sterowników napisanych w ję-zyku C. Sterowniki te są przenośne i choć zostały zaprojektowane dla systemu UNIX, będą działać poprawnie również w Linuxie. Jeśli zdecydujesz się na tworzenie wła-snych sterowników, podane tu przykłady powinieneś traktować tylko jako wskazówki. Jeżeli zamierzasz zająć się tym zagadnieniem na poważnie, powinieneś zaopatrzyć się w jedną ze specjalistycznych książek poświęconych mu w całości. Tworzenie sterowników urządzeń jest teoretycznie całkiem proste. Mimo tego przy próbie napisana pierwszego sterownika będziesz zaskoczony liczbą problemów, z którymi się zetkniesz. Wiele osób uważa tworzenie ste-rowników za swego rodzaju sztukę, ale tak naprawdę wymaga to jedynie odrobiny praktyki i doświadczenia. Napisanie dobrego sterownika daje ogromną satysfakcję.
Sterowniki urządzeń
System Linux używa sterownika dla każdego urządzenia podłączonego do systemu. Najbardziej podstawowe sterowniki są częścią jądra systemu i są ładowane podczas jego uruchamiania. Dzięki sterownikom urządzenia mogą być traktowane przez sys-tem tak samo jak pliki - można je adresować, przekierowywać do nich dane czy uży-wać podczas wykorzystywania mechanizmu potoków, zupełnie tak, jak w przypadku zwykłych plików. Każde urządzenie podłączone do systemu linuxowego jest opisane w pliku programu sterownika, a niektóre parametry są również zapisane w pliku urządzenia, przechowy-wanym zwykle w katalogu /dev. Jeśli do systemu zostanie dodane nowe urządzenie, należy zainstalować lub też napisać własnoręcznie odpowiedni sterownik. Każdemu urządzeniu musi również odpowiadać plik w katalogu /dev. Jeśli warunki te nie zosta-ną spełnione, urządzenie nie będzie mogło zostać wykorzystane w systemie linuxo-wym. Do każdego pliku urządzenia przypisany jest numer urządzenia, pozwalający syste-mowi operacyjnemu jednoznacznie je zaadresować. W systemie Linux numer urzą-dzenia składa się z dwóch części: numeru głównego, określającego ogólny typ urzą-dzenia, na podstawie którego wybierany jest odpowiedni sterownik, oraz numeru po-bocznego pozwalającego wyszczególnić każde z urządzeń obsługiwanych przez jeden sterownik. Dla przykładu, kilka dysków twardych w systemie może posiadać taki sam numer główny urządzenia (ponieważ są obsługiwane przez ten sam sterownik), ale każdy z nich musi posiadać inny numer poboczny, jednoznacznie go identyfikujący. Istnieją dwa podstawowe typy sterowników urządzeń: blokowe i znakowe. Każde urządzenie w systemie UNIX-owym używa jednego lub obu tych typów sterowników. Najczęściej spotykane są sterowniki blokowe. Pozwalają one na przesyłanie do i z urządzenia danych buforowanych przez jądro systemu (kopiowanych w odpowiednie miejsce w pamięci operacyjnej). Pierwotnie sterowniki takie były wykorzystywane tyl-ko dla dysków twardych, ale szybko znalazły zastosowanie również do obsługi innych urządzeń pamięci masowej, takich jak napędy taśmowe, magnetooptyczne, a nawet modemy synchroniczne i niektóre szybkie drukarki. Urządzenia pracujące w trybie znakowym różnią się od blokowych pod dwoma za-sadniczymi względami. Po pierwsze, wyniki operacji wejścia / wyjścia mogą być prze-kazywane bezpośrednio do przestrzeni adresowej procesu, z pominięciem buforowania przez jądro systemu. Po drugie, żądania operacji wejścia / wyjścia zwykle przekazy-wane są bezpośrednio do urządzenia. Przykładami urządzeń znakowych są terminale i drukarki, podobnie jak modemy asynchroniczne i niektóre modele napędów taśmo-wych. Urządzenia blokowe opierają swe działanie na funkcji "strategii", pozwalającej na od-czytanie i zapisanie do urządzenia bloku danych. Dla urządzeń znakowych dostępny jest szereg specjalnych funkcji pozwalających na bezpośrednią komunikację, nazy-wanych ioctl(). Urządzenia blokowe czasem również działają jako znakowe, wła-śnie po to, by możliwe było użycie funkcji ioctl(). Dobrym przykładem jest napęd taśmowy, który może współpracować zarówno ze sterownikiem znakowym, jak i blo-kowym, zależnie od typu zapisywanych danych. Niezależnie od typu, sterownik urządzenia podejmuje szereg podstawowych kroków za każdym razem, gdy ma nawiązać komunikację z urządzeniem. Najpierw sprawdza on, czy urządzenie jest gotowe i dostępne. Jeśli tak, jest ono "otwierane", co umożliwia procesowi dostęp do niego. Następnie zwykle wywoływane są funkcje read i write, służące odpowiednio do odczytu i zapisywania danych do urządzenia, po czym urzą-dzenie jest "zamykane", dzięki czemu inne procesy mogą mieć do niego dostęp.
Przerwania
Przerwania to sygnały przesyłane przez urządzenia do systemu operacyjnego, powia-damiające go o konieczności obsługi danego urządzenia. Przerwania są generowane przy wszystkich operacjach wejścia / wyjścia. System przerwań wykorzystywany w Li-nuxie jest podobny do DOS-owego, więc jeśli jesteś obeznany z przerwaniami DOS-owymi, znasz już większą część teorii. Po odebraniu sygnału przerwania system operacyjny wstrzymuje wszystkie wykony-wane procesy i obsługuje przerwanie. W większości przypadków przerwania są obsłu-giwane przez sterownik urządzenia. Przerwania nie powinny w żaden sposób zaburzać działania innych procesów, za wyjątkiem co najwyżej chwilowego ich wstrzymania. Pewien problem stwarza fakt, że wywołanie przerwania nie powinno prowadzić do za-wieszenia działania jądra systemu ani procesu obsługi urządzenia, za wyjątkiem ściśle określonych sytuacji. Przerwania, które nie są prawidłowo obsługiwane lub sprawdza-ne, mogą prowadzić do zawieszenia sterownika urządzenia, który obsługiwał komuni-kację z nim. Obsługa przerwań jest zwykle wstrzymywana tylko na czas wykonywania operacji o istotnym znaczeniu. Obszary kodu sterownika, które nie powinny być przerywane, nazywane są sekcjami krytycznymi lub niewstrzymywalnymi. Zwykle zawieszenie ob-sługi przerwań na czas realizacji sekcji krytycznych realizowane jest przez podniesienie priorytetu procesora do poziomu równego lub wyższego od priorytetu przerwań. Po za-kończeniu wykonywania takiej sekcji priorytet procesora jest obniżany do poprzedniej wartości. Priorytet przerwań można modyfikować za pomocą funkcji spl5(), spl6(), spl7() i splx(). Wywołanie jednej z trzech pierwszych funkcji powoduje zablokowanie ob-sługi przerwań. Funkcja spl5() wyłącza obsługę przerwań generowanych przez dyski, drukarki i klawiaturę, funkcja spl6() wyłącza zegar systemowy, natomiast spl7() wyłącza obsługę wszystkich przerwań, w tym pochodzących od urządzeń szeregowych. Funkcje te zwracają kod oznaczający wartość poziomu przerwań, do którego można wrócić za pomocą funkcji splx(). Przed wejściem do sekcji krytycznej kodu należy więc wykonać polecenie
pierw_poz = spl5();
które spowoduje zawieszenie obsługi przerwań aż do momentu wywołania funkcji
splx(): splx(pierw_poz); Poniższy przykład przedstawia wielokrotne zmiany poziomu obsługiwanych przerwań w sterowniku urządzenia.
int poz_a, poz_b;
poz_a = spl5();
/* kod, ktory nie powinien byc */
/* przerywany przez dyski */
poz_b = spl7();
/* instrukcje, ktore nie mogą */
/* byc w ogole przerywane */
splx(poz_b);
/* kod koncowy, ktory nie moze */
/* byc przerwany przez dyski */
splx(poz_a);
Ta dość dziwaczna na pierwszy rzut oka żonglerka poziomami przerwań jest niezbęd-na, aby uniknąć wstrzymania obsługi sterownika urządzenia i jądra systemu, co może prowadzić do nieprawidłowej pracy systemu. Mechanizmy zabezpieczające powinny być uruchamiane na tak krótko, jak tylko jest to możliwe. Zwykle nie należy używać funkcji spl6() i spl7(). W niektórych przypadkach wy-wołanie funkcji spl6() może spowodować opóźnienie zegara systemowego, nato-miast wywołanie funkcji spl7() może spowodować utratę danych przesyłanych przez urządzenia szeregowe, chyba że blokada jest aktywna przez bardzo krótki okres czasu. Mimo wszystko jednak w większości przypadków przed wejściem do sekcji kry-tycznej wystarcza wywołanie funkcji spl5().
Struktura sterownika urządzenia dla systemu Linux
Kod źródłowy sterownika urządzenia pod względem struktury nie odbiega od kodu zwykłych programów. W systemie Linux sterowniki w zasadzie tworzone są w języku C, choć czasem korzysta się również z asemblera i języka C++.
Pliki nagłówkowe
Typowy sterownik urządzenia zawiera plik nagłówkowy, w którym znajdują się dyrek-tywy włączające do kodu deklaracje funkcji systemowych, adresów rejestrów urzą-dzeń, definicje zawartości oraz definicje zmiennych globalnych używanych przez ste-rownik. W większości sterowników wykorzystuje się następujący zestaw plików na-główkowych:
param.h parametry jądra systemu;
dir.h parametry katalogów;
user.h definicje użytkownika
tty.h definicje terminali i bufora clist
buf.h informacje o buforowaniu
Plik tty.h jest wykorzystywany w sterownikach pracujących w trybie znakowym, na-tomiast plik buf.h - w trybie blokowym. Adresy rejestrów urządzenia, definiowane w jednym z plików nagłówkowych, są za-leżne od samego urządzenia. Dla urządzeń znakowych odpowiadają one zwykle adre-som portów, takich jak port wejścia / wyjścia czy zawierający bity stanu u kontrolne. Polecenia zmieniające stan urządzenia są zdefiniowane jako kody urządzenia. Oto przykład inicjalizacji rejestrów urządzenia dla sterownika terminalu standardowe-go (UART):
/* definicja rejestrow */
#define RRDATA 0x01 /* odbior */
#define RTDATA 0x02 /* nadawanie */
#define RSTATUS 0x03 /* stan */
#define RCONTRL 0x04 /* bity kontrolne */
...itd.
/* definicja rejestrow stanu */
#define SRRDY 0x01 /* dane odebrane */
#define STRDY 0x02 /* nadajnik gotowy */
#define SPERR 0x03 /* blad parzystosci */
#define SCTS 0x04 /* gotowy do wyslania inf. o stanie */
...itd.
Funkcje, które musi udostępniać sterownik, zależą od natury samego urządzenia. Wszystkie sterowniki muszą posiadać funkcje open() i close(), pozwalające na rea-lizację operacji wejścia / wyjścia.
Otwieranie urządzenia
Podprogram open() musi sprawdzać, czy wybrane urządzenie jest prawidłowe, czy proces wywołujący może uzyskać do niego dostęp (czy ma prawo dostępu i czy urzą-dzenie jest gotowe) oraz inicjalizować urządzenie. Podprogram open() jest wywoły-wany za każdym razem, gdy jakiś proces korzysta z urządzenia. Poniżej prezentujemy procedurę open() obsługującą ogólne urządzenie terminalu o nazwie td.

tdopen (device, flag)
int device, flag;
{
/* definicje zmiennych lokalnych oraz szczegoly */
/* zostaly pominiete */
/* sprawdz numer urzadzenia /
if (UNMODEM (device) >= NTDEVS)
{
seterror(ENXIO);
return;
}
/* sprawdz, czy urzadzenie jest uzywane */
/* jeśli tak, to wymus zwolnienie jesli */
/* uzytkownikiem jest root (suser) */
tp = &td_tty[UNMODEM(device)];
adres = td_address[UNMODEM(device)];
if ( ( tp->t_lflag & XCLUDE ) && !suser() )
{
seterror(EBBUSY);
return;
{
/* Jesli urzadzenie nie jest otwarte, zainicjalizuj je */
/* wywolujac funkcje ttinit() */
if ( (tp->t_state & (ISOPEN|WOPEN)) == 0 )
{
ttinit(tp);
/* inicjalizacja znacznikow i wywolanie tdparam() */
/* aby ustalic parametry linii */
tdparam (device);
}
/* Jesli uzywany jest modem, sprawdz stan nosnej */
/* Jesli polaczenie bezposrednie, ustal */
/* wartosc znacznika wykrywania nosnej */
/* ustal priorytet przerwan aby zapobiec nadpisania */
/* czekaj na sygnal wykrycia nosnej */
/* na potrzeby tego przykladu */
/* implementacja zostala pominieta */
Zamykanie urządzenia
Podprogram close() używany jest tylko po zakończeniu komunikacji z urządzeniem. Powoduje on wyłączenie obsługi przerwań pochodzących od urządzenia oraz przesła-nie odpowiednich informacji kończących jego pracę. Wszystkie wewnętrzne odniesie-nia do urządzenia są usuwane. Podprogram close() w większości przypadków nie jest wymagany, ponieważ urządzenia są traktowane jako dostępne przez cały czas. Wyją-tek stanowią dyski wymienne i urządzenia wymagające wyłączności na używanie. Również niektóre modemy wymagają, aby w procedurze close() umieścić kod po-zwalający na zwolnienie linii telefonicznej. Również tu posłużymy się przykładem pochodzącym ze sterownika obsługującego terminal.
tdclose (device)
{
register struct tty *tp;
tp = &td_tty[UNMODEM(device)];
(*linesw[tp->t_line].l_close) (tp);
if (tp->t_cflag & HUPCL)
tdmodem(device, TURNOFF);
/* usun znacznik wylacznosci */
ip->t_lflag &= ~XCLUDE;
}
Funkcje strategii
Funkcje strategii (używane tylko przez sterowniki urządzeń blokowych) są wywoływa-ne z parametrem prowadzącym do nagłówka bufora, do którego jądro systemu składa dane. Nagłówek bufora zawiera informacje dotyczące odczytu czy zapisu danych, wraz z adresem miejsca pamięci, w którym znajdują się dane do wysłania lub mają znaleźć się odbierane dane. Rozmiar bufora jest zwykle ustalany podczas instalacji i waha się pomiędzy 512 i 1024 bajtami. Rozmiar ten definiowany jest w pliku param.h jako wartość zmiennej BSIZE. Rozmiar bloku danych używanego przez urządzenie może być mniejszy od rozmiaru bufora - w takim przypadku sterownik wykona kilka operacji odczytu czy zapisu pod rząd. Funkcja strategii zostanie przedstawiona na przykładzie prostego sterownika dysku twardego. Nie zamieszczamy samego kodu źródłowego, a jedynie szkieletowe infor-macje o działaniu funkcji.
int hdstrategy (bp)
register struct buf *bp;
{
/* inicjalizuj dysk i numery partycji */
/* ustal wartosci zmiennych lokalnych */

/* sprawdz, czy dysk i partycja sa prawidlowe */
/* ustal numer cylindra docelowego */
/* wylacz przerwania */
/* wstaw zadanie do kolejki */
/* sprawdz kontroler, jesli nie jest aktywny, uruchom go */
/* przywroc poprzedni poziom przerwan */
}
Funkcje write()
Urządzenia pracujące w trybie znakowym używają funkcji write(), która sprawdza, czy jej argumenty są poprawne, a następnie kopiuje dane z obszaru pamięci procesu do bufora sterownika urządzenia. Po skopiowaniu wszystkich danych lub zapełnieniu bufora uruchamiane są procedury wejścia / wyjścia aż do opróżnienia bufora, po czym proces się powtarza. Dane z pamięci procesu są odczytywane za pomocą prostej funk-cji (cpass) zwracającej -1 w przypadku, gdy osiągnięty zostanie koniec obszaru pa-mięci. Zapisywanie danych do pamięci procesu odbywa się za pośrednictwem funkcji komplementarnej (passc). Oto przykładowa funkcja write() obsługująca urządzenie terminalu:
tdwrite (device)
{
register struct tty *tp;
tp = &td_tty[UNMODEM(device)];
(*linesw[tp->t_line].l_write) (tp);
}
Większe ilości danych są obsługiwane przez proces o nazwie copyio, który pobiera ar-gumenty określające adres danych źródłowych i miejsca, do którego mają one zostać skopiowane, oraz liczbę bajtów i znacznik stanu.
Funkcje read()
Funkcja read() dla urządzenia znakowego przesyła dane z urządzenia do pamięci procesu. Jest to operacja analogiczna do działania procedury write(). Kod źródłowy tej procedury dla urządzenia terminalu ma następującą postać:
tdread (device)
{
register struct tty *tp;
tp = &td_tty[UNMODEM(device)];
(*linesw[tp->t_line].l_read) (tp);
}
Jeśli funkcje read() i write() mają skopiować kilka bajtów, używany jest niewielki bufor, o nazwie clist. Używa on szeregu powiązanych list, które z kolei do usuwania i wstawiania znaków do bufora używają funkcji getc i putc. Nagłówek bufora clist zawiera również informację o liczbie przechowywanych znaków.
Podprogramy start i ioctl
Podprogram start używany jest zarówno przez urządzenia blokowe, jak i znakowe. Pobiera on dane z kolejki urządzenia i kieruje je kolejno do urządzenia. Urządzenia blokowe do kolejkowania danych używają funkcji strategii, natomiast urządzenia znakowe - prostego bufora clist. Podprogram start w czasie przesyłania danych do urządzenia automatycznie obsługuje znaczniki mówiące o tym, że urządzenie jest za-jęte. Po zakończeniu procesu urządzenie wywołuje podprogram intr, który inicjalizu-je je ponownie, przygotowując do obsługi następnego procesu. Podprogram ioctl(), używany w sterownikach urządzeń znakowych, pozwala prze-słać do sterownika specjalne instrukcje, umożliwiające na przykład zmianę metody komunikacji pomiędzy sterownikiem a systemem operacyjnym czy wykonanie opera-cji ściśle zależnych od urządzenia (jak przewinięcie taśmy czy alokacja pamięci). Funkcję ioctl() zilustrujemy przykładem pochodzącym ze sterownika terminal. W tym przypadku do ustalenia parametrów urządzenia wywoływana jest inna funkcja. Nie przedstawiamy jej kodu źródłowego, tylko ogólny zarys pozwalający zorientować się w zasadach działania.
tdioctl (device, cmd, arg, mode)
int device;
int cmd;
int mode;
faddr_t arg;
{
if (ttiocom(&td_tty[UNMODEM(device)], cmd, arg, mode))
tdparam (device);
}
tdparam(device)
{
/* inicjalizacja zmiennych */
/* pobierz adres i znaczniki linii, do ktorej */
/* odnosi się polecenie */
adr = td_addr[UNMODEM(device)];
cflag = td_tty[UNMODEM(device)].t_cflag;
/* sprawdz predkosc; jeśli zero to zwolnij linie */
/* zmien predkosc */
/* ustal zarzadzanie linia */
/* obsluz przerwania */
}
Używanie nowego sterownika
Proces dodawania do systemu nowego sterownika urządzenia składa się z kilku eta-pów. Najpierw identyfikowany jest podprogram obsługi przerwania, a następnie punk-ty wejścia do programu sterownika (na przykład adres procedury open) są dodawane do tabeli punktów wejścia sterownika. Cały sterownik jest kompilowany i dołączany do jądra systemu, a następnie umieszczany w katalogu /dev (w rozdziale 57. "Jądro systemu" znajdziesz dodatkowe informacje dotyczące dodawania sterowników do ją-dra systemu). Na koniec system musi zostać zrestartowany, po czym można przete-stować działanie nowego sterownika. Oczywiście wprowadzenie modyfikacji do kodu sterownika wymaga powtórzenia całego procesu, więc usuwanie błędów może być dość męczące i prawdziwą sztuką jest osiągnięcie jak najmniejszej liczby restartów. Przy tworzeniu sterowników urządzeń nie należy używać funkcji sle-ep() i seterror() oraz operacji zmiennoprzecinkowych we fragmen-tach, podczas wykonywania których zawieszona jest obsługa przerwań. Czas, na jaki wstrzymywane są przerwania, powinien być jak najkrótszy; należy również uważać, by nie uszkodzić danych przechowywanych w buforze. Bardzo ważne jest także wykorzystanie jak najmniejszej liczby komórek stosu. Można ułatwić sobie proces usuwania błędów ze sterowników urządzeń, umieszczając w kodzie źródłowym wywołania funkcji printf czy getchar w odniesieniu do innego urządzenia, na przykład konsoli. Takie rozwiązanie pozwala na pozostawienie śladu wykonania sterownika. Jeśli testujesz sterownik jako root, możesz również wykorzy-stać debuger adb, pozwalający na obserwację pamięci używanej przez jądro systemu w czasie pracy sterownika. Ostrożne korzystanie z tego programu pozwala na bezpośred-nie śledzenie zmian wartości zmiennych czy zawartości komórek pamięci; bądź jednak uważny, ponieważ nieprawidłowe użycie debugera adb może prowadzić do załamania się systemu. Jednym z najczęstszych problemów występujących przy tworzeniu sterowników (prócz oczywiście błędów w kodzie źródłowym) jest "gubienie" przerwania lub uśpienie urzą-dzenia podczas jego obsługi. Takie sytuacje powodują, że urządzenie się zawiesza. W większości przypadków do sterowników urządzeń dołącza się procedurę ograniczającą czas, przez jaki należy oczekiwać na odpowiedź urządzenia, dzięki czemu unika się zawieszania urządzenia. Jeśli spodziewane przerwanie nie zostanie zgłoszone w okre-ślonym czasie, urządzenie jest sprawdzane bezpośrednio, aby upewnić się, że przerwa-nie nie zostało "zgubione". Jeśli okaże się, że przerwanie zostało zgubione, może ono zostać zasymulowane przez sterownik. Używanie funkcji spl() w czasie testowania zwykle ułatwia wyizolowanie tego typu problemów. Sterowniki urządzeń blokowych najczęściej tworzone są w oparciu o przerwania. Jed-nak coraz więcej programistów używa ostatnio techniki zwanej odpytywaniem, nada-jącej się do obsługi urządzeń znakowych. Technika ta polega na regularnym spraw-dzaniu stanu urządzenia. Sterownik nie czeka więc na zgłoszenie przerwania, co pocią-ga za sobą nieco większe zużycie czasu procesora. Odpytywanie nie jest właściwym rozwiązaniem dla większości urządzeń, takich jak pamięci masowe, ale w przypadku urządzeń znakowych może przynieść pewne korzyści. Urządzenia szeregowe są zwykle obsługiwane za pomocą odpytywania, co pozwala na zmniejszenie liczby wywołań przerwań. Terminal połączony z systemem linią o prędkości transmisji 19200 bodów generuje około 1920 przerwań na sekundę, co powoduje wielokrotną obsługę samego przerwa-nia i wchodzenie oraz wychodzenie z funkcji jego obsługi. Jeśli zamiast przerwań za-stosowany zostanie mechanizm odpytywania, przedział czasowy pomiędzy kolejnymi zgłoszeniami konieczności obsługi przez procesor może być znacznie zwiększony, na przykład przez zastosowanie niewielkiego bufora przechowującego dane wysyłane do lub odbierane z urządzenia. Urządzenia czasu rzeczywistego również nadają się do ob-sługi za pomocą mechanizmów odpytywania, ponieważ zmniejsza to znacznie liczbę wywoływanych przerwań. Jeśli chcesz używać tego mechanizmu w swoich sterowni-kach urządzeń, powinieneś zaopatrzyć się w jedną z książek poświęconych w całości sterownikom, ponieważ jest to temat dość złożony.

Projekt Wine
Wine to skrót od słów Windows Emulator. Program ten pozwala na uruchamianie apli-kacji przeznaczonych dla MS-Windows w środowisku X Window działającym w sys-temach UNIX-owych. Podobnie jak DOSemu, przy uruchamianiu programów dla Win-dows Wine wykorzystuje bezpośrednio możliwości oferowane przez architekturę proce-sorów 386 firmy Intel. Program Wine po prostu tłumaczy wszystkie wywołania funkcji MS-Windows na odpowiadające im wywołania funkcji systemowych UNIX-a i X Win-dow. Podobnie jak w systemie OS/2, programy dla systemu Windows uruchamiane w środowisku Wine mogą korzystać z możliwości oferowanych przez system operacyjny. Wine jest po prostu jednym z wielu procesów użytkownika w systemie linuxowym, więc również jest zabezpieczony przed uszkodzeniem przez inne procesy. W systemie OS/2 ta właściwość nazywana jest po angielsku crash-protection, czyli zabezpieczenie przed załamaniem. Ponieważ wielozadaniowość jest podstawą systemu Linux, procesy Wine mogą współistnieć z innymi procesami, nie stwarzając problemów spotykanych przy pracy z systemem MS-Windows
Obecny stan projektu Wine Podobnie jak większość programów linuxowych, Wine jest tworzony przez grupę ochotników. Program Wine jest obecnie w fazie wczesnych testów. Tylko niektóre prostsze aplikacje MS Windows działają bez żadnych problemów. Mój ulubiony ze-staw gier dla Windows, Pipe Dream firmy Lucas Arts, działa zupełnie zadawalająco pod kontrolą Wine. Choć da się grać w Pipe Dream i inne proste gry, nie wszystko działa doskonale. Można zauważyć pewien spadek prędkości, zdarzają się również problemy z odświeżaniem ekranu. Firma Sun Soft opracowała produkt dość podobny do Wine, o nazwie WABI, przezna-czony dla UNIX-owych stacji roboczych. WABI jest na rynku od 1994 roku i obsługu-je nawet tak złożone aplikacje jak Microsoft Excel czy Lotus Smart Suite dla systemu Windows 3.11. Program WABI nie obsługuje jednak aplikacji systemu Windows 95. Można się spodziewać, że za jakiś czas program Wine będzie również dobrze sobie ra-dził z aplikacjami Windows ogólnego przeznaczenia.
Konfiguracja Wine
Program Wine jest rozprowadzany tylko w postaci kodu źródłowego. Jeśli posiadasz odpowiednie oprogramowanie i nieco cierpliwości, konfigurowanie Wine nie powinno sprawić Ci większych kłopotów - nawet jeśli nie jesteś programistą.
Wymagania systemowe
Aplikacje Wine będą działać z rozsądną prędkością w każdym systemie linuxowym, w którym działa system X Window. Teoretycznie Wine powinien posiadać pewną przewagę nad systemem Windows, który jest zależny od środowiska MS-DOS. Mimo wszystko dane doświadczalne wskazują, że pod kontrolą obecnej wersji Wine aplika-cje działają wolniej niż w środowisku Windows. Aby wykorzystywać program Wine, trzeba posiadać zainstalowaną na partycji do-stępnej dla Linuxa wersję systemu MS-Windows 3.1. Wygodnie jest również urucha-miać dostępne aplikacje MS-Windows z tych samych katalogów, w których są one za-instalowane w ich rodzimym środowisku DOS i Windows. Typowy użytkownik Linuxa posiada również zainstalowany system DOS i Windows, więc konfiguracja sprowadza się tylko do udostępnienia odpowiednich katalogów dla systemu Linux. Wersje jądra do 1.1.83 nie obsługują skompresowanych za pomocą programów stacker czy drvspace systemów plików MS-DOS. Niektóre programy instalacyjne systemu Linux pozwalają na zainstalowa-nie partycji DOS-owej w jednym z podkatalogów systemu plików. Jeśli nie skonfigurowałeś partycji w ten sposób, powinieneś dodać do pliku /etc/fstab następujący wiersz:
/dev/hda1 /c MSDOS defaults
hda1 to nazwa partycji, która zawiera system MS-DOS , natomiast /c to podkatalog, w którym dostępny będzie tenże system. W tym przykładzie założyliśmy, że katalog /c został wcześniej utworzony - jeśli nie, należy to zrobić za pomocą polecenia mkdir. Program Wine jest rozprowadzany w postaci kodu źródłowego, który przed użyciem musi zostać skompilowany. Potrzeba do tego około 10 MB wolnego miejsca na dysku. Sam kod źródłowy zajmuje ok. 3.5 MB. Aby skompilować Wine, będziesz potrzebo-wał:
- kompilatora GCC,
- biblioteki LibC,
- systemu X Window wraz z elementami dla programistów (ang. development),
- wersji jądra nowszej niż 0.99.13
Skąd można załadować Wine
Nowe wersje systemu Wine opracowywane są średnio raz w tygodniu. Główne węzły FTP oferujące oprogramowanie linuxowe zwykle udostępniają najnowszą wersję Wine. Dla przykładu, w węźle sunsite.unc.edu programu Wine należy szukać w katalogu /pub/Linux/ALPHA/Wine. Kolejne wersje tego programu opatrzone są numerami opartymi na dacie ich powstania - na przykład wersja Wine-950727 pochodzi z 27 lip-ca 1995 roku. Nowsze wersje mają oczywiście bardziej aktualne daty. Więcej informa-cji można znaleźć na stronie WWW pod adresem
http://daedalus.dra.hmg.gb/gale/wine/wine.html.
Jak zainstalować Wine
W przeciwieństwie do programu DOSemu, program Wine nie musi być instalowany w żadnym konkretnym katalogu. Dla wygody warto utworzyć dowiązanie symboliczne o nazwie np. /usr/wine do katalogu, w którym Wine jest faktycznie zainstalowany (dajmy na to /usr/src/Wine950122), wydając polecenie ln w następujący sposób:
ln -s /usr/src/Wine950122 /usr/wine
Kod źródłowy programu Wine rozprowadzany jest w postaci spakowanego archiwum programu tar. Aby je rozpakować, należy wydać polecenie o następującej formie:
tar -zxvf nazwapliku.tar.gz
Jak skonfigurować Wine przed kompilacją
Kod źródłowy programu Wine przed kompilacją wymaga skonfigurowania. Skrypt o nazwie Configure pozwala zautomatyzować ten proces, pobierając od użytkowni-ka potrzebne informacje i na ich podstawie tworząc właściwe pliki konfiguracyjne. Konfiguracja Wine składa się z trzech zasadniczych etapów:
1. konfiguracja procesu kompilacji,
2. podanie parametrów czasu wykonania,
3. automatyczna konfiguracja dostosowująca Wine do konkretnego systemu.
Skrypt konfiguracyjny zadaje następujące pytania:
Build Wine as emulator or library (E/L) [E]?
Short filenames (Y/N) [N]?
Use the XPM library (Y/N) [N]?
Language [En/De/No] ?
Global configfile name /usr/local/etc/wine.conf
(czy skompilować Wine jako bibliotekę, czy emulator, czy używać krótkich nazw pli-ków, czy wykorzystać bibliotekę XPM, jakiego użyć języka i jaką nazwę ma mieć glo-balny plik konfiguracyjny?). Bezpiecznie jest zaakceptować sugerowane wartości do-myślne wciskając Enter w odpowiedzi na każde z pytań. Podane parametry są zapi-sywane do globalnego pliku konfiguracyjnego o nazwie autoconf.h. Jeśli konieczna okaże się ich modyfikacja, należy ponownie uruchomić skrypt Configure, dzięki czemu można uniknąć błędów mogących powstać podczas ręcznej edycji pliku auto-conf.h.
Wstępna konfiguracja parametrów czasu wykonania za pomocą skryptu Configure
Pytania zadawane w tej części procesu konfiguracyjnego odnoszą się do odpowiednich wpisów w globalnym pliku konfiguracyjnym /usr/local/etc/wine.conf. Poszcze-gólne pytania są dość oczywiste:
Which directory do you want to use as A:
(który katalog ma być traktowany jako napęd A:)
Which directory do you want to use as C:
(który katalog ma być traktowany jako napęd C:)
W odpowiedzi na nie należy podać nazwy katalogów, w których są zamontowane DOS-owe dyski A: i C:. Jeśli na przykład partycja zawierająca system MS-Windows zamontowana jest w katalogu /c, właśnie ten katalog należy wskazać w odpowiedzi na drugie pytanie. Jeśli nie planujesz używać stacji dyskietek, nie musisz przejmować się faktem, że napęd A: nie będzie prowadził do prawidłowego katalogu. Następne pytania dotyczą ścieżek dostępu do katalogów systemowych - katalogu Windows, katalogu System, katalogu, w którym mają być przechowywane pliki tym-czasowe i ścieżek przeszukiwania dla programów i bibliotek DLL.
Where is the Windows directory 'c:\windows'
Where is the System directory 'c:\windows\system'
Where should Windows apps store temp files 'c:\windows\temp'
Which path should be used to find progs/DLL's 'c:\windows;c:\windows\system'
Podane tu ścieżki dostępu powinny odpowiadać ścieżkom używanym w systemie MS-Windows. Ponieważ domyślnie system ten instalowany jest w katalogu c:\windows, podpowiadane odpowiedzi będą w większości przypadków odpowiednie. Następne pytanie dotyczy ścieżki dostępu do pliku sysres.dll, zawierającego zaso-by systemu Wine, takie jak obrazki czy okienka dialogowe wyświetlane podczas pracy Wine.
Where is sysres.dll '/usr/wine/sysres.dll'
Również tu w większości przypadków nie są potrzebne żadne modyfikacje.
Podobnie jak w programie DOSemu, w Wine porty szeregowe i równoległe mogą zostać powiązane z dowolnymi zainstalowanymi w systemie Linux portami podobnego typu. Najprościej jest powiązać porty COM i LPT w taki sam sposób, jak są one skonfiguro-wane w systemie DOS:
Where is COM1" CF_Com1 '/dev/cua0'
Where is COM2" CF_Com2 '/dev/cua1'
Where is LPT1" CF_Lpt1 '/dev/lp0'
Następne pytanie dotyczy nazwy pliku, w którym rejestrowane będą komunikaty ge-nerowane podczas pracy Wine. Wybranie pliku o nazwie CON spowoduje przesyłanie ich do standardowego urządzenia wyjściowego, czyli najczęściej konsoli - takie roz-wiązanie umożliwia przekierowanie ich do dowolnego pliku podczas uruchamiania Wi-ne.
Log messages to which file (CON = stdout) 'CON'
Domyślnie Wine generuje mnóstwo komunikatów, które mogą nieco zwalniać jego działanie. Jeśli chcesz tego uniknąć, możesz skierować je do urządzenia /dev/null, podając jego nazwę zamiast nazwy pliku. Następnie wyświetlana jest długa lista typów komunikatów i pytanie:
Exclude which messages from the log 'WM_SIZE;WM_TIMER'
Jeśli nie zależy Ci na informacjach o stanie systemu Wine, możesz pozostawić wartość domyślną. Poszczególne klasy komunikatów o błędach mogą być osobno włączane i wyłączane, mogą również być przekierowywane z wiersza poleceń. Na koniec skrypt Configure wyświetla zawartość globalnego pliku konfiguracyjnego utworzonego na podstawie dostarczonych informacji i daje możliwość edytowania go za pomocą domyślnego edytora tekstów:
Doyou want to edit it using vi (Y/N) [N]?
Można oczywiście później edytować utworzony plik dowolnym edytorem tekstów, dla-tego w tym miejscu można zrezygnować z tej możliwości.
Automatyczna konfiguracja
Po utworzeniu pliku wine.conf skrypt Configure rozpoczyna modyfikowanie kodu źródłowego za pomocą programu xmkmf. Jest to program, który służy do generowania plików makefile dla X Window - tworzy on plik Makefile na podstawie informacji zapisanych w pliku Imakefile, biorąc pod uwagę szczegóły konfiguracji konkretnego systemu X Window.
Tworzenie pliku wykonywalnego
Aby utworzyć plik wykonywalny programu Wine, wystarczy wydać polecenie
make
Najtrudniejsza część konfiguracji Wine jest już za tobą. Mimo tego to właśnie kompi-lacja zabiera najwięcej czasu - w systemie opartym na procesorze Pentium z zegarem 90 MHz trwa ona około ośmiu minut. Aby program mógł zostać poprawnie skonsoli-dowany, potrzebne będą biblioteki -lXext, więc zainstaluj je najpierw z dysku CD-ROM.
Używanie programu Wine
Używanie Wine sprowadza się do wydania polecenia
wine nazwa_programu
Parametry konfiguracyjne
Globalny plik konfiguracyjny programu Wine o nazwie wine.conf można zwykle znaleźć w katalogu /usr/local/etc. Zapisane w nim parametry są w większości oparte na informacjach podanych podczas wcześniejszej konfiguracji i są zorganizo-wane w sposób przypominający format plików .ini używanych w systemie Windows. Poniżej przedstawiamy przykładową zawartość tego pliku, wraz z krótkimi komenta-rzami. Poniższe wpisy określają, do których katalogów systemu Linux prowadzić będą DOS-owe litery dysków:
[drives]
A=/a
C=/c
Następne parametry określają położenie plików systemu Windows i Wine:
[wine]
Windows=:\windows
System=c:\windows\system
Temp=c:\temp
Path=c:\windows;c:\windows\system
SystemResources=/users/wine/wine950122/sysres.dll
Kolejna sekcja dotyczy odwzorowania czcionek MS-Windows i czcionek systemu X (gwiazdka jest używana jako symbol wieloznaczny w nazwach czcionek systemu X).
[fonts]
system=*-helvetica
mssansserif=*-helvetica
msserif=*-times
fixedsys=*-fixed
arial=*-helvetica
helv=*-helvetica
roman=*-times
default=*-*
Fragmenty przedstawione poniżej definiują odwzorowania odpowiednich portów sze-regowych i równoległych systemu Linux na ich DOS-owe odpowiedniki.
[serialports]
Com1=/dev/cua0
Com2=/dev/cua1
[parallelports]
Lpt1=/dev/lp0
Poniższe parametry określają klasy rejestrowanych komunikatów diagnostycznych i miejsce, w którym mają one być zapisywane.
[spy]
File=CON
Exclude=WM_SIZE;WM_TIMER
Można również konfigurować ten program za pomocą rozlicznych opcji podawanych w wierszu poleceń, pozwalających na przykład na uruchomienie debugera umożliwia-jącego wyszukiwanie usterek tkwiących w tym programie.
Opcje dostępne z wiersza poleceń
Wiersz poleceń przy uruchamianiu programu Wine ma następujący format:
wine opcje_wine program opcje_programu
na przykład:
bash# /usr/wine/wine -debugmsg +all /c/windows/winmine.exe
Dostępne opcje zostały zebrane w tabeli
Opcja    Znaczenie
-depth n    Pozwala zmienić głębię koloru, dzięki czemu Wine może używać innej niż domyślna liczby kolorów. Osiem planów bitowych daje 256 kolorów, co wystarcza do większości zastosowań.
-desktop geom    Uruchamia aplikację MS-Windows na pulpicie o podanym rozmiarze, na przykład podanie liczb 850x620 spowodowałoby otwarcie okna o rozmiarach 850 na 620 punktów. Uruchomienie pulpitu powoduje również wyeliminowanie modalnego zachowania się okienek programów systemu Windows.
-display nazwa    Pozwala wyświetlić okno na innym niż domyślny widoku, dzięki czemu można uruchamiać aplikacje MS-Windows na innym terminalu X podłączonym do sieci.
-iconic   Uruchamia aplikację zminimalizowaną do postaci ikony. Opcja ta ma taką samą funkcję, jak opcja "Uruchom zminimalizowane" Menedżera Programów systemu MS-Windows.
-debug    Załącza debuger przed uruchomieniem właściwej aplikacji.
-name nazwa    Ustala nazwę aplikacji. Dzięki temu rozwiązaniu można określić inną niż domyślną (wine) nazwę aplikacji widzianą w systemie X Window.
-privatemap    Powoduje użycie prywatnej palety kolorów. Ta opcja ma zastosowanie szczególnie w przypadku aplikacji wykorzystujących dużą liczbę kolorów. Jej użycie może spowodować nieprawidłowe wyświetlanie kolorów w innych oknach w czasie, gdy okno programu Wine jest aktywne.
-synchronous    Załącza tryb wyświetlania synchronicznego. Ta opcja może poważnie zwolnić działanie aplikacji, ponieważ powoduje, że system X Window będzie przed wysłaniem każdego polecenia czekał na zakończenie wykonywania poprzedniego. Aplikacje systemu X mogą przesyłać polecenia do serwera, który może - ale nie musi - działać w tym samym systemie. W niektórych sytuacjach załączenie synchronizacji okazuje się niezbędne, aby zapobiec optymalizacji operacji graficznych przez serwer X.
-backingstore    Jest to opcja optymalizacyjna, umożliwiająca serwerowi X obsługę zdarzeń expose bez przerywania działania programu klienta.
-spy plik    Załącza rejestrowanie informacji diagnostycznych do pliku o podanej nazwie. Podobny efekt można uzyskać używając mechanizmów przekierowania danych wyjściowych.
-debugmsg nazwa    Załącza lub wyłącza informacje diagnostyczne poszczególnych typów. Aby otrzymać listę obsługiwanych klas informacji diagnostycznych, wydaj polecenie: wine -debugmsg help help
Debuger programu Wine
Program Wine jest wyposażony w wewnętrzny debuger, umożliwiający wyszukiwanie przyczyn problemów wynikających z tkwiących w nim usterek. Jeśli program systemu MS-Windows zakończy działanie ze względu na błąd, w oknie terminalu, z którego uruchomiony został program Wine, uruchamiany jest debuger. Jeśli nie jesteś zaintere-sowany wyszukiwaniem przyczyny problemu, możesz zakończyć jego działanie wyda-jąc polecenie quit i przejść do następnego podrozdziału. Debuger programu Wine jest podobny do programu gdb. Umożliwia zakładanie pułapek, sprawdzanie i modyfikowanie wartości rejestrów oraz poszczególnych komórek pamięci. Mimo tego jego funkcjonalność jest dość ograniczona - tabela zawiera wszystkie dostępne polecenia. Polecenie    Funkcja
break    Ustawia pułapkę pod wskazanym adresem, który może również być reprezentowany przez wartość symboliczną. Po wykonaniu instrukcji znajdującej się pod tym adresem, wykonanie programu Wine zostanie wstrzymane.
Przykładowo, polecenie break * GDI_Ordinal_24 spowoduje zatrzymanie programu po wejściu do procedury systemu Windows rysującej elipsę, dostępnej pod wewnętrzną nazwą GDI.24.
bt    Wyświetlenie drogi, która prowadziła do aktualnego miejsca wykonania programu (ang. backtrace). Wyświetlane adresy są adresami powrotu, a nie wywołania podprogramów.
cont    Powoduje kontynuowanie wykonania programu po osiągnięciu pułapki lub wystąpieniu błędu.
define    Podstawia wartość pod nazwę symboliczną, na przykład define mojaproc 0x000001c6
disable    Powoduje wyłączenie określonej pułapki. Pułapki ustawiane za pomocą polecenia break są numerowane. Aby którąś z nich wyłączyć, należy określić jej numer za pomocą polecenia info, a następnie wykorzystać go podając jako parametr polecenia disable, na przykład aby wyłączyć pułapkę o numerze 1 należy wydać polecenie disable 1
enable    Umożliwia załączenie pułapki o określonym numerze - polecenie to ma działanie odwrotne do polecenia disable. Aby załączyć wyłączoną poprzednio pułapkę o numerze 1, należy wydać polecenie enable 1.
help    Wyświetla tekst pomocy dotyczącej dostępnych poleceń.
info    Wyświetla informacje o następujących parametrach:
reg - dane o wartościach przechowywanych w rejestrach;
stack - zawartość stosu;
break - dane o poszczególnych pułapkach;
segments - informacje o rozmieszczeniu w pamięci używanych segmentów.
mode    Pozwala przełączyć się pomiędzy trybem 16 i 32-bitowym.
print    Wyświetla wartość podanego wyrażenia.
quit    Umożliwia zakończenie działania debugera i uruchomionego programu MS-Windows.
set    Pozwala zapisywać dowolne wartości do poszczególnych rejestrów i komórek pamięci.
symbolfile    Ładuje plik zawierający wartości symboliczne. Odpowiedni plik o nazwie wine.sym jest rozprowadzany wraz z programem Wine.
x    Wyświetla zawartość pamięci w kilku różnych formatach. Składnia tego polecenia jest następująca: x / format adres. Parametr format może przyjmować następujące wartości:
x    32-bitowa liczba całkowita szesnastkowa
d    32-bitowa liczba całkowita dziesiętna
w    16-bitowa liczba szesnastkowa
b    bajt
c    pojedynczy znak
s    napis ASCII zakończony zerem
I    instrukcja procesora i386
Przed formatem można również podać liczbę, określającą ilość powtórzeń, na przykład aby wyświetlić 10 kolejnych instrukcji rozpoczynając od danego adresu, należy wydać polecenie:
x / 10 I 0x00001cd
Aby móc wykorzystać możliwości tkwiące w tym debugerze, trzeba rozumieć ogólne zasady działania debugerów programów asemblerowych dla platformy i386. Jeśli na-prawdę chcesz szukać usterek w programie Wine, niezbędny będzie kod asemblerowy generowany przez kompilator GCC.
Zasady działania programu Wine
Program Wine składa się z części ładującej programy systemu MS-Windows do pamięci i z biblioteki funkcji systemu MS-Windows.
Ładowanie programów do pamięci
Program Wine zaczyna swoje działanie od załadowania obrazu pliku wykonywalnego systemu MS-Windows do pamięci. Dodatkowo ładowane są wszystkie wymagane bi-blioteki DLL i zasoby. Pliki wykonywalne systemu MS-Windows mają inną strukturę, niż uruchamiane w systemie DOS, nazywaną NE (ang. New Executable). Biblioteki DLL i pliki czcionek również używają struktury NE, co nieco upraszcza zadanie posta-wione przed programem Wine. Do pamięci muszą zostać załadowane poszczególne segmenty obrazu pliku NE, a na-stępnie należy rozwiązać wszystkie odniesienia do innych bibliotek DLL i wywołań funkcji systemu Windows. Odwołania do funkcji nie zdefiniowanych wewnątrz obrazu składają się z nazwy modułu i numeru porządkowego funkcji, na przykład wywołanie funkcji rysującej elipsę ma postać GDI.24. W module GDI zapisane są funkcje gra-ficzne systemu Windows, natomiast numer 24 jest właśnie numerem porządkowym funkcji rysującej elipsę. Po załadowaniu do pamięci obrazu pliku wykonywalnego, Wine po prostu przechodzi do wykonania zdefiniowanej w nim funkcji WinMain(). Ponieważ zarówno Linux, jak i MS-Windows działają w oparciu o instrukcje procesorów rodziny i386, nie jest ko-nieczna emulacja rozkazów. W momencie, gdy wystąpi wywołanie funkcji systemu Windows, jest ono przechwytywane przez program Wine i przekazywane do odpo-wiedniej biblioteki.
Biblioteka Wine
Program Wine zamienia wywołania standardowych funkcji MS-Windows na odpowia-dające im wywołania funkcji systemu X lub UNIX. Dla przykładu, wywołanie funkcji rysującej elipsę w systemie MS-Windows ma następującą postać:
Ellipse (hdc, xLeft, yTop, xRight, yBottom);
Parametry xLeft, yTop, xRight, i yBottom określają rozmiar prostokąta otacza-jącego elipsę. Natomiast w systemie X odpowiadające polecenie ma postać:
XDrawArc (display, d, gc, x, y, width, height, angle1, angle2);
Jak widać, podstawienie odpowiednich współrzędnych wymaga przeprowadzenia pewnych obliczeń. Pozostałe parametry funkcji XDrawArc można wyznaczyć bezpo-średnio. Parametr d określa obszar, na którym można rysować - zwykle jest to po pro-stu uchwyt okienka. W systemie Windows jest on jednym z elementów struktury prze-kazywanej przez parametr hdc. Parametr gc określa kontekst graficzny, który funk-cjonalnie odpowiada parametrowi hdc w systemie Windows. Ponieważ w systemie X możliwe jest wyświetlanie okien na innym terminalu podłączonym do sieci, parametr display określa widok, którego należy użyć. Wartość tego parametru pozostaje stała w ciągu całej sesji programu Wine. Ostatnim elementem, na który program Wine musi zwrócić uwagę, jest fakt, że funkcja Ellipse może również zostać wywołana w celu narysowania wypełnionej elipsy - program Wine sprawdza to w strukturze hdc i ewentualnie zamiast XDrawArc wywołuję funkcję XFillArc. W systemie MS-Windows dostępnych jest prawie 300 podstawowych funkcji graficz-nych, dla których muszą zostać wykonane podobne translacje. Choć może wydawać się to dość pracochłonne, konwersje funkcji graficznych okazują się być jednym z prostszych zadań, które trzeba podejmować podczas emulacji systemu MS-Windows.
Gdzie kończy się Wine, a zaczyna MS-Windows?
Ponieważ do poprawnego działania program Wine potrzebuje pewnych elementów sys-temu MS-Windows, nie jest łatwo od razu powiedzieć, w którym miejscu kończy się Wine, a zaczyna MS-Windows. Wine w obecnej wersji zapewnia poprawną obsługę wywołań funkcji wchodzących w skład następujących modułów systemu MS-Windows:
commdlg    Common Windows Dialog, najpopularniejsze okna dialogowe;
gdi    Graphics Device Interface, moduł z funkcjami graficznymi;
kernel    interfejs jądra systemu operacyjnego;
mmsystem    interfejs podsystemu obsługi multimediów;
mouse    funkcje obsługi myszy;
shell    biblioteka funkcji powłoki systemu Windows 3.1;
sound    podsystem obsługi dźwięku;
toolhelp    funkcje ułatwiające wyszukiwanie usterek;
user    funkcje biblioteki Microsoft Windows User Interface;
win87em    moduł obsługi i emulacji koprocesora;
winsock    moduł Windows Socket (obsługa TCP/IP).
Aby używać funkcji, które nie są zaimplementowane w samym programie Wine, niezbędny jest dostęp do poszczególnych części systemu MS-Windows. Jednym z przy-kładów jest biblioteka OLECLI, która obsługuje klientów OLE. Autorzy programu Wine znacznie ograniczyli liczbę wymaganych plików. Projekt zakłada całkowite uniezależ-nienie się od plików systemu MS-Windows, włączając w to programy użytkowe i struk-tury plików tworzone podczas instalacji aplikacji MS-Windows. Niektóre z najprostszych aplikacji, na przykład WINMINE.EXE czy SOL.EXE już dziś działają nie wymagając żadnego dodatkowego kodu systemu MS-Windows czy do-stępu do katalogów tego systemu. Choć nie jest wymagana żadna konkretna organizacja katalogów, możesz na przykład spróbować uruchomić aplikację WINMINE.EXE w następu-jący sposób:
1. skopiuj pliki winmine.exe i win.ini do katalogu linuxowego, na przykład /users/windows;
2. zmodyfikuj wartość zmiennej Windows przechowywaną w pliku wine.conf tak, by wskazywała na odpowiedni katalog - w naszym przypadku /users/windows;
3. odmontuj partycję DOS-ową;
4. uruchom program Wine.
Ograniczenia programu Wine
Tylko kilka programów systemu MS-Windows działa prawidłowo pod kontrolą pro-gramu Wine. Na szczęście można z dość dużą pewnością przewidzieć, czy dany pro-gram będzie działać poprawnie bez konieczności uruchamiania go. Niestety, istnieje dość spora grupa aplikacji, które najprawdopodobniej nigdy nie będą działać pod kon-trolą emulatora Wine.
Działające oprogramowanie
Obecna wersja programu Wine obsługuje wiele programów użytkowych i gier rozpro-wadzanych wraz z systemem Windows 3.1. Pomiędzy poszczególnymi wersjami Wine występują jednak dość znaczne różnice - zmiany, które umożliwiają obsługę jednych aplikacji, mogą uniemożliwić poprawne działanie innych. Oto lista programów i gier, które działają zadowalająco dobrze pod kontrolą Wine:
calc.exe
- clock.exe
- cruel.exe
- golf.exe
- notepad.exe
- pipe.exe
- pegged.exe
- reversi.exe
- winmine.exe
Używanie programu winestat do analizy programów systemu Windows
W skład pakietu Wine wchodzi również program użytkowy o nazwie winestat. Jest to w zasadzie ten sam program co Wine, tyle że zamiast uruchamiania programu MS-Windows poprzestaje on na załadowaniu go do pamięci i wyświetleniu informacji o powodzeniu tego przedsięwzięcia. Ładowane są również potrzebne biblioteki DLL i w razie ich braku generowane są odpowiednie komunikaty. winestat analizuje też wszystkie odwołania do funkcji systemowych i zapisanych w bibliotekach DLL, wery-fikując ich istnienie. Dla przykładu, uruchomienie programu winestat z aplikacją Pa-intbrush systemu MS-Windows daje następujące rezultaty:
KERNEL.1 not implemented
KERNEL.54 not implemented
KERNEL.113 not implemented
KERNEL.114 not implemented
KERNEL.121 not implemented
KERNEL.154 not implemented
KERNEL.178 not implemented
KERNEL.207 not implemented
KERNEL: 52 of 66 (86.7 %)
USER: 150 of 150 (100.0 %)
GDI.151 not implemented
GDI.307 not implemented
GDI.366 not implemented
GDI.439 not implemented
GDI: 80 of 84 (95.2 %)
SHELL: 9 of 9 (100.0 %)
KEYBOARD: 2 of 2 (100.0 %)
TOTAL: 293 of 305 winapi functions implemented (96.1 %)
Program winestat określa poszczególne niezaimplementowane funkcje za pomocą modułu, w którym są one zapisane, oraz numeru porządkowego. Jeśli wolałbyś znać nazwy tych funkcji, możesz zajrzeć do pliku o nazwie odpowiadającej nazwie modułu (z rozszerzeniem .spec) zapisanego w podkatalogu if1632 katalogu z kodem źró-dłowym programu wine. Oto fragment pliku
kernel.spec:
#1 FATALEXIT
#2 EXITKERNEL
3 pascal GetVersion() GetVersion()



#54 pascal16 GETINSTANCEDATA
Wiersze rozpoczynające się od symbolu # są traktowane jako komentarze, co ozna-cza, że poszczególne funkcje nie są zaimplementowane. W powyższym przykładzie, są to między innymi funkcje FATALEXIT oraz GETINSTANCEDATA. Funkcja FATALEXIT używana jest do testowania programów w systemie MS-Windows w nieprawidłowych warunkach i rzadko jest przedmiotem zainteresowania większości użytkowników sys-temu MS-Windows. Funkcja GETINSTANCEDATA kopiuje dane konfiguracyjne z po-przedniego egzemplarza danej aplikacji. Jeśli uruchamiany jest tylko jeden egzemplarz, nie jest ona wykorzy-stywana. Na koniec program winestat wyświetla procentową informację o liczbie obsługiwa-nych funkcji, która jest dość dobrą miarą tego, jak dobrze dana aplikacja może dzia-łać pod kontrolą programu wine. Niestety, jeśli nie jest obsługiwana choćby jedna funkcja niezbędna do zainicjalizowania danej aplikacji, jakikolwiek wynik poniżej 100% będzie niezadowalający. Aplikacje, które w teście winestat uzyskają wynik ponad 95%, mają szansę na po-prawne działanie. W przeciwieństwie do programu DOSemu, Wine nie ma skłonności do pozostawiania Linuxa w stanie niestabilnym. Mimo tego zawsze należy zamykać kończące się błędem sesje programu Wine. Najłatwiej jest w tym celu uruchamiać Wi-ne z osobnym pulpitem, na przykład za pomocą polecenia wine -desktop 800x600 nazwa_programu. Zwykłe metody wyłączania procesu systemu Windows za pomocą menedżera okienek powinny działać prawidłowo. Kiedy zawiodą wszystkie inne metody zakończenia pracy błędnie działa-jącego programu Wine, najlepiej przełączyć się na inną konsolę wirtualną i zamknąć proces Wine za pomocą polecenia kill. Dla przykładu, wci-śnięcie klawiszy Alt+Control+F2 uaktywnia drugą konsolę wirtualną. Po zalogowaniu się można użyć polecenia ps -ax |grep wine, które po-zwoli na znalezienie numeru procesu odpowiadającego sesji Wine. Następ-nie należy wydać polecenie kill -15 pid, gdzie pid jest wspomnia-nym wcześniej numerem. Do sesji X Window można wrócić przełączając się na konsolę, na której jest ona uruchomiona. Jeśli nie wiesz, która to konsola, po prostu przełą-czaj się kolejno pomiędzy nimi, trzymając klawisze Alt i Control oraz wci-skając kolejno klawisze funkcyjne.
Najważniejsze braki programu Wine
Prawdopodobnie najbardziej rzucającym się w oczy niedociągnięciem jest brak możliwości drukowania. Ponieważ jednak jest to proces skomplikowany, opracowanie inter-fejsu drukarki nie jest wcale proste. Ogromnym zadaniem byłoby umożliwienie obsługi wszystkich typów drukarek działających w systemie MS-Windows. Prawdopodobnie zaimplementowany zostanie tylko sterownik dla drukarek postscriptowych. Istniejące programu użytkowe dla systemu Linux, na przykład Ghostscript, potrafią następnie zamienić dokument postscriptowy na nadający się do wydrukowania za pomocą dru-karek różnych typów, na przykład laserowych czy atramentowych drukarek HP. Również 32-bitowy interfejs Windows API (win32) nie jest w większości obsługiwany. Obraz pliku wykonywalnego systemu Windows NT i Windows 95 ma format PE (ang. Portable Executable, przenośny plik wykonywalny) - wine potrafi co prawda ładować pliki zasobów (na przykład czcionki) w tym formacie, ale nie radzi sobie z plikami wykonywalnymi i bibliotekami DLL.
Oprogramowanie, które prawdopodobnie nigdy nie będzie działać
Projekt Wine nie zakłada obsługi wirtualnych sterowników urządzeń (Virtual Device Drivers, VDD). Wiąże się to z faktem, że pliki VDD wykorzystują inny format - LE (ang. Linear Executable), który nie jest obsługiwany przez moduł ładujący pro-gramu Wine. Ponieważ w plikach VDD często występują bezpośrednie odwołania do sprzętu, ich współdziałanie z systemem Linux stwarzałoby poważne problemy. Jed-nym z zastosowań plików VDD w systemie Windows jest implementacja stosów TCP/IP. W programie Wine TCP/IP jest obsługiwane za pomocą biblioteki winsock, która z kolei wykorzystuje mechanizmy TCP/IP wbudowane w jądro systemu Linux.

HylaFAX
Możliwość wysłania faksem dokumentu, który został napisany w ulubionym edytorze tekstów jest jednym z bardziej użytecznych aspektów pracy z komputerem. Pozwala zaoszczędzić czas, papier i wysiłek konieczny do wydrukowania kopii dokumentu, za-ładowania jej do faksu i ręcznego wysłania. Programy faksujące pozwalają zarówno wysyłać faksy z poziomu dowolnego programu umożliwiającego drukowanie, jak i przyjmować nadchodzące faksy. Choć najwydajniejsze programy obsługi faksu dla komputerów klasy PC przeznaczo-ne są dla systemu Windows, istnieje również kilka programów tego typu przeznaczo-nych dla Linuxa i systemów UNIX-owych. Komercyjne programy do obsługi faksów można zakupić u wielu dostawców oprogramowania, ale na szczęście kilka z nich jest dostępnych za darmo. Jeśli planujesz regularne używanie systemu linuxowego, możesz rozpatrzyć możliwość zainstalowania jednego z tych programów. Najczęściej używanym programem faksującym dla systemu Linux jest darmowy pro-gram HylaFAX, napisany przez Sama Leffera. Nie jest on jedynie imitacją produktów komercyjnych - jest to w pełni funkcjonalny i konkurencyjny w stosunku do komer-cyjnych zintegrowany system przyjmowania i wysyłania faksów. Program HylaFAX do obsługi obrazów faksów wykorzystuje system GhostScript
Instalacja programu HylaFAX
Program HylaFAX wchodzi w skład większości dystrybucji Linuxa rozprowadzanych na płytach CD-ROM. Można go również załadować w wielu węzłach FTP i WWW. Możesz też natknąć się na starszy program FlexFAX, na którym został oparty program HylaFAX. Jeśli możesz wybierać, zainstaluj HylaFAX. Do instalacji większości wersji programu HylaFAX niezbędny będzie kompilator języka C++ (na przykład kompilator GCC dostarczany wraz z większością wersji Linuxa), ponieważ program ten jest roz-prowadzany tylko w formie kodu źródłowego. Program HylaFAX jest dostępny w większości węzłów FTP, ale węzłem macierzystym jest ftp.sgi.com. W którymś z katalogów powinny znaj-dować się informacje dotyczące tego programu. Dokumentacja programu HylaFAX jest dostępna także w węzłach FTP i na stronie WWW pod adre-sem http://www.sgi.com. Jeśli chcesz obejrzeć dodatkowy opis programu HylaFAX i dokumentację dotyczącą jego rozwoju, zajrzyj na stronę http://www.vix.com/hylaFAX Skompresowaną lub spakowaną programem tar wersję pliku zawierającego kod źró-dłowy programu HylaFAX należy rozpakować do jakiegoś utworzonego wcześniej ka-talogu. Jeśli na przykład posiadasz w katalogu /tmp plik o nazwie HylaFax-v4.0-tar.gz, powinieneś skopiować go do katalogu docelowego i rozpakować wydając po-lecenia:
mkdir /usr/fax
cd /usr/fax
cp /tmp/ HylaFax-v4.0-tar.gz .
gunzip HylaFax-v4.0-tar.gz
tar xf HylaFax-v4.0-tar
Do wykonania tych poleceń niezbędne będą uprawnienia użytkownika root. Oczywi-ście zamiast katalogu /tmp należy podstawić faktyczną ścieżkę dostępu do pliku za-wierającego kod źródłowy. Jeśli nie odpowiada Ci nazwa katalogu docelowego (/usr/fax), możesz zmienić również ją.
Kompilacja programu HylaFAX
Po rozpakowaniu wszystkich plików do katalogu docelowego należy uruchomić kom-pilator języka C++, który wygeneruje plik wykonywalny. Wcześniej warto jednak przejrzeć plik z informacjami pomocniczymi, który zwykle ma nazwę README i prze-chowywany jest w podkatalogu port/linux - czasem zawarte są w nim istotne dane. Aby skompilować program HylaFAX, należy wydać następujące polecenia (będąc za-logowany jako użytkownik root):
configure
make clean
make install
Po wydaniu poleceń configure i make trzeba będzie podać jeszcze kilka dodatko-wych informacji - omówimy je za chwilę. Po wydaniu polecenia configure na ekra-nie wyświetlany jest szereg komunikatów dotyczących katalogów, których program HylaFAX będzie używał w czasie pracy.
HylaFAX configuration parameters are:
Directory for applications: /usr/local/bin
Directory for lib data files: /usr/local/lib/fax
Directory for lib executables: /usr/local/lib/fax
Directory for servers: /usr/local/etc
Directory for manual pages: /usr/local/man
Directory for documentation: /usr/local/doc/HylaFAX
Directory for spooling: /usr/spool/fax
Type of uucp lock files: /usr/spool/uucp
Mode for uucp lock files: 0444
Type of PostScript imager: gs
PostScript imager program: /usr/local/bin/gs
Default page size: North American Letter
Default vertical res (lpi): 98
Directory for font metrics: /usr/local/lib/afm
Location of sendmail program: /usr/lib/sendmail
Are these ok [yes]?
Nie należy modyfikować domyślnych lokalizacji katalogów, ponieważ są one używa-ne również przez wiele innych aplikacji linuxowych. Po wydaniu polecenia make należy odczekać kilka minut na zakończenie kompilacji, ponieważ składa się ona z kilku eta-pów i wymaga przetworzenia wielu plików rozsianych w całym systemie. Po zakończe-niu procedury instalacyjnej powinieneś upewnić się, że katalog /usr/local/bin/fax istnieje i zawiera odpowiednie pliki - tylko wówczas będzie można używać programu HylaFAX.
Dodawanie modemów
Następnym krokiem jest podanie programowi HylaFAX informacji o modemach. Można to zrobić za pomocą skryptu o nazwie faxaddmodem, który poprowadzi Cię krok po kroku przez ten proces. HylaFAX potrafi poprawnie współpracować z więk-szością faksmodemów zgodnych ze standardami Class 1 i Class 2, co w praktyce oznacza przeważająca większość dostępnych na rynku modemów umożliwiających obsługę faksu. Po uruchomieniu, skrypt faxaddmodem zadaje serię pytań; w większości przypadków odpowiedzi domyślne są prawidłowe (skrypt ten również należy urucha-miać posiadając uprawnienia użytkownika root):
# faxaddmodem
Verifying your system is set up properly for fax service...
There is no entry for the fax user in the password file.
The fax software needs a name to work properly; add it [yes]?
Added user "fax" to /etc/passwd
Added fax user to "/etc/passwd.sgi".
There does not appear to be an entry for the fax service in
either the yellow pages database or the /etc/services file;
should an entry be added to /etc/services [yes]?
There is no entry for the fax service in "usr/etc/inetd.conf";
should one be added [yes]?
Poking inetd so that it rereads the configuration file.
There does not appear too be an entry for the FaxMaster in
either the yellow pages database or the /usr/lib/aliases file;
should an entry be added to /usr/lib/aliases [yes]?
Users to receive fax-related mail [root]?
Rebuilding /usr/lib/aliases database.
46 aliases, longest 81 bytes, 923 bytes total
Done verifying system setup.
Serial port that modem is connected to []? cua1
Ok, time to set up a configuration file for the modem. The manual
page config(4F) may be useful during this process. Also be aware
that at any time you can safely interrupt this procedure.
No existing configuration. Let's do it from scratch.
Phone number of fax modem []? +1.613.838.1234
This is the phone number associated with the modem being configured.
It is passed as an "identity" to peer fax machines and it may
also appear on tag lines created by the fax server.
The phone number should be a complete international dialing specification
in the form +<country code> <area part>.
Any others characters included for readability are automatically
removed if they might cause problems.
Area code []? 613
Country code [1]?
Long distance dialing prefix [1]?
International dialing prefix [011]?
Tracing during normal server operation [1]?
Tracing during send and receive sessions [11]?
Protection mode for received fax [0600]?
Rings to wait before answering [1]?
Modem speaker volume [off]?
The server configuration parameters are
FAXNumber: +1.613.838.1234
AreaCode: 613
CountryCode: 1
LongDistancePrefix: 1
InternationalPrefix: 011
ServerTracing 1
SessionTracing 11
RecvFileMode 0600
RingsBeforeAnswer: 1
SpeakerVolume off
Are these ok [yes]?
Now we are going to probe the tty port to figure out the type
of modem that is attached. This takes a few seconds, so be patient.
Note that if you do not have the modem cabled to the port, or the
modem is turned off, this may hang (just go and cable up the modem
or turn it on, or whatever).
Hmm, this looks like a class 1 modem.
Product code is "1444".
Modem manufacturer is "USRobotics".
Modem model is "Courier".
Using prototype configuration file config.usr-courier...
The modem configuration parameters are:
ModemRate: 19200
ModemFlowControl: xonxoff
ModemFlowControlCmd: &H2
ModemSetupDTRCmd: S13=1&D2
ModemSetupDCDCmd: &C1
ModemDialCmd: DT%s@
ModemResultCodesCmd: x4
Are these ok [yes]?
Startup a fax server for this modem [yes]?
/usr/etc/faxd -m /dev/cua1
Jedyne punkty, na które należy zwrócić uwagę, to nazwa portu, do którego podłączony jest modem (użyty w przykładzie port /dev/cua1 to drugi port szeregowy, ponieważ do pierwszego zwykle dołączona jest mysz), oraz numer telefonu i kod kraju określa-jący linię, która ma być obsługiwana. Zauważ, że program HylaFAX tworzy nowe kon-to użytkownika o identyfikatorze fax, mającego ten sam numer identyfikacyjny (UID) co użytkownik uucp, ponieważ modemy są zwykle współużytkowane przez oba te programy. Program HylaFAX umożliwia konfigurację i używanie kilku różnych mo-demów, jeśli do systemu podłączonych jest kilka linii telefonicznych. Program HylaFAX używa procesu faxd.recv, który umożliwia aplikacjom klienckim łączenie się z serwerem HylaFAX. Program faxd.recv jest zwykle uruchamiany przez proces inetd w momencie, gdy system jest uruchamiany w trybie wielodostęp-nym. Program konfiguracyjny prawdopodobnie sam dodał odpowiednie wpisy do pli-ków startowych inetd. Jeśli nie, powinieneś dopisać do pliku inetd wiersz o następu-jącej treści: fax stream tcp nowait fax /usr/libexec/fax.d/faxd.recv faxd.recv Aby uruchomić program rezydentny HylaFAX, należy wydać polecenie (podstawiając właściwą dla systemu nazwę portu, do którego podłączony jest modem):
/usr/etc/faxd -m /dev/cua1
Aby uruchamiać ten program automatycznie podczas startu systemu, należy dopisać to polecenie do pliku /etd/rc.d. Do wysyłania i odbierania faksów przez system HylaFAX używany jest ten sam program rezydentny, faxd. Podczas odbierania faksu nie ma możliwości przerwania tego procesu - można co najwyżej wyłączyć modem.
Wysyłanie faksu
Aby wysłać faks za pomocą programu HylaFAX, należy uruchomić program send-fax. Zwykle za jego pomocą wysyła się dokumenty postscriptowe (lub ghostscriptowe) albo grafiki w formacie TIFF. Niektóre inne formaty plików (na przykład pliki ASCII czy pliki programu troff) są przed wysłaniem automatycznie konwertowane przez program sendfax do odpowiedniej postaci. W dokumentacji dostarczonej wraz z każ-dą wersją programu HylaFAX znajdują się dokładne dane co do obsługiwanych for-matów plików.
Opcje programu sendfax
Jak widać w tabeli, w wierszu poleceń programu sendfax można określić wiele różnych opcji. Poszczególne opcje można również łączyć ze sobą.
Opcja programu sendfax    Znaczenie
-c    Komentarz
-d    Określenie numeru telefonu
-f    Nadawca faksu
-h    Nazwa systemu
-i    Identyfikator, który zostanie umieszczony w faksie
-k    Czas, przez jaki należy ponawiać próby połączenia
-l    Tryb niskiej rozdzielczości
-m    Tryb średniej rozdzielczości
-n    Zapobiega wysyłaniu okładki
-p    Załącza numerowanie stron i okładki
-r    Nazwy odnośników
-s    Nazwa rozmiaru papieru (domyślnie 8.5x11)
-t    Liczba prób nawiązania połączenia
-v    Wyświetlanie informacji diagnostycznych na ekranie
-x    Nazwa firmy, do której wysyłany jest faks
-y    Adres odbiorcy
-D    Informowanie odbiorcy pocztą elektroniczną o nadejściu faksu
-R    Informowanie nadawcy pocztą elektroniczną o konieczności ponownego wysłania faksu
Przy wysyłaniu faksu program HylaFAX automatycznie generuje okładkę. Umiesz-czane są na niej informacje podane w wierszu poleceń przy uruchamianiu programu sendfax. Domyślnie używany jest tryb niskiej rozdzielczości (98 linii na cal), chyba że wartość ta zostanie zmieniona przez podanie opcji -m w wierszu poleceń (co daje 196 linii na cal - w programie HylaFAX rozdzielczość ta nazywana jest średnią). Program HylaFAX w razie niemożności nawiązania połączenia będzie próbował dodzwonić się do adresata przez 24 godziny - czas ten można zmienić podając inną wartość po opcji -k.
Okładki
Jeśli chcesz, by wysyłane okładki miały inną niż domyślna zawartość, powinieneś użyć polecenia faxcover. Pozwala ono utworzyć stronę w formacie PostScript, która będzie dołączana na początku każdego wychodzącego faksu. Program faxcover również obsługuje kilka opcji podawanych z wiersza poleceń - zo-stały one zebrane w tabeli. Opcje te mogą być łączone ze sobą w dowolnym porządku.
Opcja programu faxcover    Znaczenie
-c    Komentarz
-C    Nazwa pliku szablonu
-f    Identyfikator nadawcy
-l    Adres odbiorcy
-n    Numer faksu nadawcy
-p    Liczba stron
-r    Nazwy odnośników
-s    Nazwa rozmiaru papieru
-t    Odbiorca
-v    Numer docelowej linii głosowej
-x    Nazwa firmy odbierającej faks
Odbieranie faksu
Jeśli program HylaFAX będzie odbierał przychodzące faksy, będą one umieszczane w podkatalogu recvq katalogu, w którym zainstalowany jest program HylaFAX. Wszystkie nadchodzące faksy są zapisywane w postaci plików TIFF. Dostęp do kata-logu z odebranymi faksami może być regulowany przez administratora systemu. Po odebraniu faksu, HylaFAX przesyła go do użytkownika o identyfikatorze ustala-nym na podstawie wartości zmiennej FaxMaster. Można również napisać skrypt, któ-ry sprawdzi, do którego z użytkowników skierowany jest dany faks i poinformuje go o fakcie jego nadejścia pocztą elektroniczną lub też wyśle faks prosto do kolejki drukar-ki. Do odbierania faksów w systemie HylaFAX używany jest proces o nazwie faxrcvd. Program ten jest na tyle "sprytny", że potrafi sam ocenić, czy nadchodzące połączenie jest połączeniem głosowym, czy też jest to połączenie mające na celu przesłanie fak-su. Dzięki takiemu rozwiązaniu możliwe jest używanie tego samego modemu do odbie-rania faksów i połączeń modemowych pomiędzy systemami, które są normalnie ob-sługiwane przez uucp lub proces getty.

Gry
Na większości płyt CD-ROM z systemem Linux zamieszczane są różnego rodzaju gry, a jeszcze większą ich różnorodność można znaleźć w węzłach FTP i na płytach CD-ROM z oprogramowaniem. Gry można z grubsza podzielić na te działające w systemie X oraz te, które działają w trybie tekstowym. W tym rozdziale przedstawimy gry nale-żące do obu tych rodzajów. Ma on postać spisu wraz z krótkim omówieniem poszcze-gólnych gier tekstowych i działających w systemie X.
Które gry zainstalowałeś?
Gry przedstawione w tym rozdziale pochodzą z kilku różnych pakietów instalacyjnych, dlatego może się zdarzyć, że niektóre z nich nie będą dostępne w Twoim systemie - dla przykładu, graficzne wersje gier tetris, gnuchess i xfractint są zwykle instalowa-ne oddzielnie. Jeśli któraś z przedstawionych tu gier zaintryguje Cię, możesz zainstalować ją z płyty CD-ROM, jeśli do tej pory tego nie zrobiłeś.
Gry dla systemu X Window
Do uruchomienia przedstawionych poniżej gier niezbędny jest system X Window. Większość gier przeznaczonych dla tego systemu znajduje się w kilku katalogach, w zależności od używanej wersji Linuxa. Zwykle gry można znaleźć w katalogach:
- /var/lib/games
- /usr/games
- /usr/lib/games
- /usr/local/games
- /usr/share/games
W wielu przypadkach zdarza się, że we wszystkich tych katalogach znajduje się po kilka gier. Ponieważ system X jest okienkowym systemem graficznym, można się domyślić, że gry przeznaczone dla niego są oparte na grafice. Jest tak w rzeczywistości - prawie wszystkie z wymienionych niżej gier wykorzystują kolorowe grafiki bitmapowe. W wie-lu z nich można samemu określić paletę kolorów, która ma być wykorzystywana w grze. Musisz jednak pamiętać o kilku rzeczach.
- Gry przygodowe i gry wideo używają specjalnie dla nich zaprojektowanego sprzętu. System X Window jest środowiskiem przeznaczonym nie tylko do gier i dlatego nie może zapewnić grom maksymalnej wydajności. Nawet dzisiejsze szybkie komputery osobiste nie są w stanie dorównać urządzeniom zaprojek-towanym specjalnie do gier pod względem szybkości i płynności animacji.
- Gry wykorzystują zasoby sprzętowe i system operacyjny w stopniu o wiele większym, niż inne aplikacje. Dla osiągnięcia możliwie największej wydajno-ści, gry tworzone są często przy użyciu różnych sztuczek programowych i sprzętowych. Z tego powodu zdarza się, że niektóre gry nie działają poprawnie w pewnych konfiguracjach lub też mają dziwne skutki uboczne swego działa-nia.
- Gry przeznaczone dla systemu X to głównie aplikacje tworzone przez poje-dynczych programistów. Zezwolili oni na ich darmowe rozprowadzanie i wy-korzystanie i oczekują na sugestie oraz pomoc w dalszym rozwijaniu. Nie na-leży jednak porównywać tych gier do standardów komercyjnych, ponieważ nie są one produktami komercyjnymi.
- Na płycie CD-ROM zawierającej wersję Slackware systemu Linux znajdują się dwa zestawy gier. Jeden z nich - zapisany w zestawie dysków oznaczonym literą Y - zawiera gry pochodzące z systemu BSD, natomiast w zestawie XAP znajdują się między innymi gry przeznaczone dla systemu X. Można zainsta-lować oba pakiety, a następnie usunąć te z gier, które nie przypadną użyt-kownikom do gustu. Możliwe jest umieszczanie wszystkich gier w katalogu /usr/games, ale gry instalowane przez użytkowników powinny raczej trafić do katalogu /usr/local/games. Katalog /usr/games jest zarezerwowany dla gier rozprowadzanych wraz z systemem. Poniżej zamieszczamy omówienie gier działających w systemie X, które powinieneś znaleźć w swoim systemie. Pamiętaj, że w związku z różnicami pomiędzy poszczegól-nymi instalacjami może się okazać, że posiadasz więcej lub też mniej gier, niż tu oma-wiamy.
Gry dostępne w menu głównym menedżera xdm
Jeśli używasz menedżera okien systemu X Window o nazwie xdm, jego menu główne (zwykle dostępne po naciśnięciu prawego klawisza myszy w czasie, gdy kursor jest nad obszarem okna głównego) zawiera podmenu o nazwie Games. Z tego menu można na-stępnie wybrać kolejno podmenu Demo i Gadgets. Jeśli używasz innych menedżerów okienek, na przykład Motif, odpowiednie menu będą miały inną postać. Również sa-me gry dostępne w tym menu zależą od wersji Linuxa. Poniżej przedstawiamy listę niektórych z nich, wraz z krótkimi opisami.
Spider
Jest to odmiana pasjansa. Dostępne są dwie wersje tej gry - Small i Large, różniące się tylko rozmiarem używanych kart i, co się z tym wiąże, wielkością zajmowanego okna. Jeśli chcesz obejrzeć dokumentację dotyczącą tej gry, wydaj polecenie man spider. Aby uruchomić tę grę, wpisz w oknie konsoli polecenie spider. Celem gry spider jest ułożenie wszystkich kart jednakowego koloru w porządku od najstarszej do najmłodszej, co wymaga logicznego myślenia i planowania. Możliwe jest również układanie w porządku malejącym kart o różnych kolorach. Czasem takie postępowanie wydaje się poprawiać sytuację, w rzeczywistości powoduje znaczne wy-dłużenie rozgrywki. Dwie lub więcej kolejnych kart tego samego koloru przenoszone są grupowo. Spider jest wyzwaniem - nie próbuj grać w tę grę tylko dla zabicia czasu!
Puzzle
Jest to świetna wersja gry - najczęściej wykorzystywanej podczas dziecięcych przyjęć - której celem jest przestawianie 15 kwadratowych elementów w siatce 4x4 tak, aby ułożyć zapisane na nich cyfry w odpowiednim porządku. Jeśli chcesz obejrzeć dokumentację dotyczącą tej gry, wydaj polecenie man puzzle. Aby uruchomić grę, wpisz w oknie konsoli polecenie Puzzle. Wersja dla systemu X jest bardzo przyjemna w obsłudze, ponieważ elementy przesu-wają się bezproblemowo, w przeciwieństwie do wersji plastikowej, w której miały one tendencję do zacinania się. Po kliknięciu na prostokącie po lewej stronie elementy ustawiane są w przypadkowych pozycjach. Po kliknięciu po prawej stronie, gra sama się rozwiąże (spróbuj kliknąć na prostokącie po prawej stronie w sytuacji, gdy liczby są już w odpowiednim porządku).
GNU Chess
Jest to graficzna wersja programu GNU Chess, wykorzystująca program xboard.
Ostrzeżenie
Uruchomienie programu GNU Chess pod kontrolą xboard powoduje zużycie dużej ilo-ści zasobów systemowych i może spowodować nawet załamanie systemu. Utworzenie dodatkowego pliku lub partycji wymiany może zredukować czas oczeki-wania na odpowiedź programu - nie przejmuj się jednak, nie jest to wina Twojego sys-temu, tylko programu GNU Chess.
Xtetris
Jeśli nigdy nie wciągnął Cię Tetris, masz teraz jeszcze jedną szansę. Jest to przyjemna w obsłudze implementacja tej gry dla systemu X, nie tracąca uroku (w przeciwieństwie do innych wersji) po przeniesieniu jej z gier wideo na komputery domowe. Jeśli chcesz obejrzeć dokumentację dotyczącą tej gry, wydaj polecenie man xtetris. Aby uruchomić grę, wpisz w oknie konsoli polecenie xtetris. Gra oparta jest na przyjemnym dla oka zestawie kolorów, a animacja jest w miarę płynna. Jeśli jednak przywykłeś do innych wersji Tetrisa, powinieneś wziąć pod uwagę następujące wskazówki.
- Strzałki w lewo i prawo powodują przesunięcie spadających klocków w od-powiednich kierunkach, natomiast w górę i w dół - obrót zgodnie z kierunkiem ruchu wskazówek zegara i w kierunku przeciwnym. Większość osób preferuje jeden z kierunków obrotu - powinieneś więc poeksperymentować i stwierdzić sam, który z nich bardziej Ci odpowiada.
- Spacja, jak to zwykle bywa w implementacjach Tetrisa dla komputerów do-mowych, powoduje zrzucenie klocka na dno studni, zamiast przyspieszać jego ruch.
- Kolory poszczególnych elementów, choć dość ładne, czasem bywają nieco mylące. Dla przykładu, jeden z klocków w kształcie litery L, który jest w in-nych wersjach Tetrisa fioletowy, w tej jest żółty, natomiast drugi z nich - do-kładnie na odwrót. Jeśli jesteś przyzwyczajony do innych ustawień, może to być pewną niedogodnością.
Jaki jest cel tej gry? Należy tak ustawiać poszczególne klocki, by nie pozostawiać mię-dzy nimi żadnych luk. Po utworzeniu pełnej poziomej linii jest ona automatycznie usuwana. Gra kończy się po zapełnieniu całej studni klockami (niestety, gdy gra wy-myka się spod kontroli, nie pojawia się Kozak niszczący klocki swą wielką stopą).
Xlander
Jest to nowa wersja starej gry znanej z automatów, Lunar Lander. Na ekranie przed-stawiony jest widok z okna lądownika księżycowego. Należy miękko wylądować w wyznaczonym obszarze używając silnika głównego i kierunkowych. W przypadku nie-powodzenia, po prostu się rozbijesz… Jeśli chcesz obejrzeć dokumentację dotyczącą tej gry, wydaj polecenie man xlander. Aby uruchomić grę, wpisz w oknie konsoli polecenie xlander. Czasem zdarzają się problemy polegające na tym, że gra nieprawidłowo reaguje na wciskane klawisze - wówczas powierzchnia księżyca zbliża się bardzo szybko i nieu-chronnie.
Xmahjongg
Jest to implementacja starej, chińskiej gry. Posiada bardzo atrakcyjną oprawę graficz-ną - ideogramy na poszczególnych klockach są wykonane bardzo estetycznie. Kom-puter oczywiście buduje zamek za Ciebie, co znacznie przyspiesza rozgrywkę. Program Xmahjongg nie posiada własnej strony man.
Xvier
Xvier to gra zbliżona do popularnej gry w kółko i krzyżyk. Ruchy wykonuje się na zmianę na szachownicy o rozmiarach 5x5. Celem gry jest utworzenie rzędu złożonego z czterech elementów ułożonych poziomo, pionowo lub po przekątnej. Xvier różni się od gry w kółko i krzyżyk tym, że można wybrać tylko kolumnę, w której ma zostać umieszczony symbol - zostanie on automatycznie umieszczony na najniższej dostęp-nej pozycji. Jeśli chcesz obejrzeć dokumentację dotyczącą tej gry, wydaj polecenie man xvier. Aby uruchomić grę, wpisz w oknie konsoli polecenie xvier. Możliwa jest również zmiana poziomu "inteligencji" komputera przez wciśnięcie w czasie gry klawiszy od 0 do 9. Należy jednak wziąć pod uwagę fakt, że po wybraniu jednego z wyższych poziomów komputer zastanawia się przez długi czas. Z tego po-wodu nie warto zwiększać poziomu trudności o więcej niż jeden. Domyślnie urucho-miony jest poziom zerowy i prawdopodobnie nie będziesz chciał wychodzić poza trze-ci.
Ico
Po uruchomieniu gry ico na ekranie wyświetlany jest wielościan. W zależności od wy-branej opcji, zajmuje on obszar własnego okna lub też jest wyświetlany w obszarze okna głównego. Jeśli chcesz obejrzeć stronę man dotyczącą tej gry, wydaj polecenie man ico. Grę moż-na uruchomić wpisując w wierszu poleceń systemu X Window polecenie ico. W zasa-dzie należy uruchamiać ją z wiersza poleceń ze względu na dostępne opcje. Jeśli zosta-nie uruchomiona z menu menedżera xdm, wielościan zostanie wyświetlony w małym, niepozornym okienku. Jedną z interesujących opcji jest opcja -color, pozwalająca określić kolory ścianek wielościanu. Podając więcej niż jeden kolor, można otrzymać wielościan o ściankach różnych kolorów. Po opcji -color należy podać dane dotyczące samych kolorów w następującym for-macie: rgb://. Po-szczególne intensywności określane są w notacji szesnastkowej, 000 to wartość naj-niższa, natomiast wartością najwyższą jest fff. Oto przykładowe polecenie:
ico -color rgb:000/888/fff rgb:e000/400/b80 rgb:123/789/def
Program ico dość intensywnie korzysta z zasobów systemu i może zwolnić jego dzia-łanie.
Maze
Program maze rysuje labirynt, po czym go rozwiązuje. Nie ma sposobu na to, by roz-wiązać go samodzielnie, dlatego program ten jest raczej programem demonstracyjnym niż grą. W szybkich systemach labirynt rozwiązywany jest zbyt szybko, by to zaobser-wować!
Xeyes
Nie jest to gra w pełnym tego słowa znaczeniu, ale mimo to jest to bardzo miły pro-gramik. Po jego uruchomieniu na ekranie wyświetlana jest para oczu śledzących kursor myszy. Uruchomienie czterech czy pięciu kopii tego programu nadaje systemowi dość surrealistyczny wygląd. Jeśli chcesz obejrzeć dokumentację dotyczącą tego programu, wydaj polecenie man xeyes. Aby uruchomić grę, wpisz w oknie konsoli polecenie xeyes.
Xgas
Jest to program demonstrujący zachowanie się czystego gazu - aby można było popa-trzeć na niego z przyjemnością, nie jest jednak konieczne posiadanie doktoratu z ter-modynamiki czy mechaniki statystycznej. Okno programu podzielone jest na dwie części, pomiędzy którymi jest jeden niewielki otwór. W obu częściach można ustalić różne temperatury. Następnie należy umieścić kursor w którejś z części i wcisnąć lewy klawisz myszy - każde kliknięcie uwalnia nową molekułę gazu poruszającą się w przypadkowym kierunku. Jeśli chcesz obejrzeć dokumentację dotyczącą tej gry, wydaj polecenie man xgas. Aby uruchomić grę, wpisz w oknie konsoli polecenie xgas.
Xlogo
Jest to niewielki program wyświetlający oficjalne logo systemu X Window.
Xroach
Jest to coś pośredniego pomiędzy grą a programem demonstracyjnym. Nie uruchamiaj tej gry, jeśli brzydzisz się insektami! Jeśli mieszkałeś kiedykolwiek w budynku dotkniętym plagą karaluchów, ten program przywoła miłe (lub niezbyt miłe) wspomnienia. Za każdym razem, gdy uruchomisz eg-zemplarz programu xroach, nowe stado karaluchów zacznie biegać po ekranie, szuka-jąc okna, pod które można by się schować. W końcu chowają się wszystkie - przy-najmniej do czasu, aż zamkniesz lub przesuniesz któreś z okien. Jeśli chcesz obejrzeć dokumentację dotyczącą tej gry, wydaj polecenie man xroach. Aby uruchomić grę, wpisz w oknie konsoli polecenie xroach. Jeśli uruchamiasz program xroach z wiersza poleceń, możesz dodać opcję -squish, która umożliwi rozgniatanie insektów przez klikanie na nich. Niestety, są one dość szybkie, co nie ułatwia zadania. Można również określić kolor wnętrzności zabitych karaluchów.
Xhextris
Jest to wersja Tetrisa, w której poszczególne klocki składają się z sześciokątnych ele-mentów. Aby uruchomić tę grę, wydaj w wierszu poleceń systemu X Window polecenie xhextris. Dla tego programu nie jest dostępna strona man.
Xbombs
Jest to wersja powszechnie znanej gry w sapera. Plansza podzielona jest na szereg pól, z których kilka zawiera miny. Twoim zadaniem jest oflagowanie wszystkich pól zawie-rających miny. Grę tę uruchamia się wpisując w wierszu poleceń xbombs. Nie jest dostępna strona man dotycząca tej gry. Po uruchomieniu gry wyświetlane jest pole, podzielone na niewielkie prostokąty, oraz okno punktacji. Po kliknięciu na którymś z prostokątów jest on odkrywany. Gra kończy się w momencie, gdy trafisz na minę. Bardziej prawdopodobne jest jednak, że trafisz na pole nie zawierające miny. Wów-czas zostanie w nim wyświetlona liczba określająca, ile min znajduje się w polach są-siadujących z odkrytym z którejś ze stron lub po przekątnej. Jeśli na polu nie ma żad-nej cyfry, oznacza to, że żadne z pól sąsiednich nie zawiera miny. Takie pola zwykle odkrywają się w większych grupach. Przykładowo, jeśli na odkrytym polu pojawi się liczba 1, oznacza to, że na którymś z sąsiednich pól znajduje się mina. Jeśli odkryłeś już położenie miny sąsiadującej z polem zawierającym jedynkę, możesz bezpiecznie odkryć wszystkie pozostałe pola sąsiadujące z nim, ponieważ masz pewność, że żadne z nich nie zawiera już miny. W ten sposób można wydedukować położenie wszystkich min. Jeśli uda Ci się odkryć pole nie zawierające żadnej liczby (czyli nie sąsiadujące z żadna miną), gra automatycznie odkryje wszystkie takie pola sąsiadujące z odkrytym. Kiedy wydaje Ci się, że odkryłeś, w którym miejscu umieszczona jest mina, możesz oznaczyć podejrzane pole flagą klikając na nim prawym przyciskiem myszy (jeśli przez przypadek klikniesz na tym polu lewym klawiszem myszy i faktycznie znajduje się na nim mina, gra jest niestety skończona). Prawy przycisk myszy włącza i wyłącza oznaczenie miny. Zauważ, że gra nie daje żadnych wskazówek co do tego, czy flaga została umieszczona prawidłowo. Wkrótce zorientujesz się, że niektóre rozmieszczenia liczb dają pewną informację o położeniu miny; w innych przypadkach trzeba będzie nieco pogłówkować lub zdać się na łut szczęścia. Oczywiście, czasem zdarza się, że przez pomyłkę wylecisz w powietrze. Aby zrestarto-wać grę, kliknij dowolnym klawiszem myszy w obszarze okna punktacji. Jeśli uda Ci się odgadnąć położenie wszystkich min, czas, w jakim to zrobiłeś, zostanie zanotowa-ny.
Xpaint
Jest to program służący do tworzenia prostych, kolorowych rysunków. Można go uru-chomić wpisując w wierszu poleceń systemu X Window polecenie xpaint. Spowoduje to wyświetlenie menu zawierającego różnego typu narzędzia. Z menu File wybierz utworzenie nowego obrazka (ang. new canvas). W menu Tool zebrane są różne narzę-dzia, takie jak na przykład pędzle, ołówki, farba w aerozolu itp. Poniżej obrazka wy-świetlana jest paleta dostępnych kolorów. Jeśli chcesz obejrzeć stronę man dotyczącą tego programu, wydaj polecenie man xpa-int.
Xfractint
Dzięki programowi Xfractint można w łatwy i bezbolesny sposób rozpocząć zabawę z fraktalami. Jeśli nie wiesz dokładnie, co to jest fraktal, powinieneś pobawić się tym programem. Prawie na pewno widziałeś już kiedyś fraktale. Jeśli chcesz obejrzeć dokumentację dotyczącą tej gry, wydaj polecenie man xfrac-tint. Aby uruchomić grę, wpisz w oknie konsoli polecenie xfractint. Program xfractint ma duże możliwości konfiguracyjne. Bez zagłębiania się w szczegóły matematyczne można z łatwością generować fraktale różnego typu. Po uruchomieniu tego programu wyświetlane są dwa okna. Pierwsze z nich zawiera ob-raz fraktala (początkowo okno to jest puste), natomiast drugie pozwala wprowadzać polecenia. Można na przykład przejść do wybierania typu fraktala (ang. Type) i wy-brać jeden z wielu rodzajów fraktali, który chciałbyś obejrzeć. Możesz również rozpo-cząć generowanie obrazka wybierając pozycję Select video mode. Domyślnie rysowa-ny jest fraktal Mandelbrota. Po zakończeniu generacji obrazka (co może chwilę potrwać) można przejść do okna poleceń, wcisnąć klawisz t, a następnie wybrać z długiej listy inny typ fraktala. Na tym etapie nie warto zmieniać domyślnych wartości podpowiadanych przez program. Obej-rzenie fraktali wszystkich typów i tak zajęłoby sporo czasu. Aby zakończyć działanie programu xfractint, wciśnij dwukrotnie klawisz Escape w oknie poleceń.
Gry działające w trybie tekstowym
Gry działające w systemach UNIX-owych często mają za sobą długą historię. Wiele z nich powstało, zanim jeszcze rozpowszechniły się systemy potrafiące wyświetlać kolo-rową grafikę. Wszystkie te gry, za wyjątkiem gry Sasteroids, są oparte na trybie teksto-wym. Oznacza to, że wszystkie elementy graficzne (o ile w ogóle jakieś występują) są wyświetlane za pomocą standardowych znaków, takich ja na przykład A, *, |, x itp. Wszystkie dane wprowadzane są z klawiatury (również tu gra Sasteroids jest wyjąt-kiem). Zaletą gier pracujących w trybie tekstowym jest to, że do ich uruchomienia nie jest po-trzebne środowisko graficzne czy okienkowe, wystarcza w zupełności monochroma-tyczny terminal. Tekstowa natura niektórych gier (jak na przykład gra w szubienicę) sprawia, że środowisko tekstowe jest wszystkim, czego im potrzeba - wymyślna, kolo-rowa grafika wcale nie jest niezbędna. Inne gry mogą w tej chwili być tylko ciekawost-kami historycznymi: pokazują, jak wiele programista potrafił osiągnąć używając tylko i wyłącznie standardowego zestawu znaków, ale na pewno o wiele lepiej mogłyby być obsłużone w systemie graficznym. Dwie z bardziej interesujących (i klasycznych) gier tekstowych, Rogue i Hack, nie wchodzą w skład dystrybucji Linuxa. Gry te używają ekranu terminalu do wyświetlania pomieszczeń i korytarzy lochów. Gracz (wraz z psem w grze Hack) porusza się po tychże lochach, odkrywając korytarze, wchodząc do kolejnych pomieszczeń (przy wchodzeniu do ciemnych, nie-oświetlonych pokoi należy zachować szczególną ostrożność), zbierając ukryte skarby i magiczne przedmioty oraz walcząc z potworami (i ucieka-jąc przed nimi). Po odkryciu całego poziomu można zejść na poziom niż-szy, który jest trudniejszy od poprzedniego. Za każdym razem, gdy uruchamiana jest gra Hack lub Rogue, wygląd lo-chów jest inny. Każdy z potworów ma inne umiejętności walki, niektóre posiadają również specjalne możliwości. Magiczne przedmioty, takie jak pierścienie, pałeczki, zwoje i napoje mają najprzeróżniejsze właściwości. Niektóre ze znajdowanych przedmiotów, na przykład zbroje, mogą zostać zaczarowane czy usprawnione za pomocą mocy magicznych. Jeśli jednak znajdziesz przedmiot, który został przeklęty, lepiej pozostawić go na miej-scu. Zarówno Rogue jak i Hack mają swoich entuzjastów, ale gra Hack jest nowsza i bardziej rozbudowana, dlatego ma więcej zwolenników. Jeśli na-tkniesz się na którąś z tych gier w Internecie, spróbuj w nią zagrać! Dostęp-ne są również wersje tych gier przeznaczone dla systemu MS-DOS
Tekstowe gry przygodowe
Gry tego typu opierają się na prostej zasadzie: system informuje Cię o sytuacji, na przykład you are in a maze of small twisty passages, all alike (jesteś w labiryncie wąskich, pokręconych i podobnych do siebie korytarzy), pozwalając wybrać drogę, którą chcesz się udać, przez wpisanie nazwy kierunku (np. forward - naprzód, east - wschód itp.) czy też podjąć jakieś proste działania typu take sword (weź miecz). Jeśli lubisz układanie puzzli, tego typu gry będą Ci się podobać. Akcja podąża dokładnie określoną drogą, a liczba możliwych czynności jest zwykle dość ograniczo-na. Poniżej przedstawiamy przykładowy początek tekstowej gry przygodowej Battlestar, która zostanie omówiona w następnym podrozdziale. Polecenia są wpisywane po zna-ku zachęty, który ma postać >-:. Version 4.2, fall 1984.
First Adventure game written by His Lordship, the honorable
Admiral D.W. Riggle
This is a luxurious stateroom.
The floor is carpeted with a soft animal fur and the great wooden furniture is inlaid with strips of platinum and gold. Electronic equipment built into the walls and ceiling is flashing wildly. The floor shudders and the sounds of dull explosions rumble through the room. From a window in the wall ahead comes a view of darkest space. There is a small adjoining room behind you, and a doorway right.
>-: right
These are the executive suites of the battlestar.
Luxurious staterooms carpeted with crushed velvet and adorned with beaten gold open onto this parlor. A wide staircase with ivory banisters leads up or down. This parlor leads into a hallway left. The bridal suite is right.
Other rooms are behind you.
>-: up
You are at the entrance to the dining hall.
A wide staircase with ebony banisters leads down here.
The dining hall is to the ahead.
>-: bye
Your rating was novice.
Battlestar
Aby uruchomić tę grę, należy wydać polecenie battlestar. Przykładowa sesja tej gry przedstawiona została w poprzednim podrozdziale. Stronę man zawierającą informacje związane z tą grą można obejrzeć po wydaniu polecenia man battlestar.
Dungeon
Aby uruchomić tę grę, należy wydać polecenie dungeon. W trakcie gry wpisanie pole-cenia help pozwala uzyskać przydatne informacje. Zaczynasz na zewnątrz lochów i musisz znaleźć do nich wejście. Dla gry Dungeon nie jest dostępna strona man.
Paranoia
Aby uruchomić tę grę, należy wydać polecenie paranoia. W tej zabawnej grze wcie-lasz się w tajnego agenta wykonującego bardzo niebezpieczną misję. W przeciwień-stwie do większości innych gier tekstowych, Paranoia pozwala wybierać podejmowane akcje z menu. Dzięki temu nie trzeba szukać poleceń, które byłyby rozumiane przez grę. Dla gry Paranoia nie jest dostępna strona man.
Wump
Aby uruchomić tę grę, należy wydać polecenie wump. W tej grze wcielasz się w myśliwe-go polującego na potwora o imieniu Wumpus. Na początku jesteś zaopatrzony tylko w kilka wykonanych na zamówienie strzał, spryt i węch. Po rozpoczęciu gry możesz obej-rzeć instrukcję zawierającą informacje o jej obsłudze. Po wydaniu polecenia man wumpus można obejrzeć stronę man poświeconą tej grze.
Gry słowne
Dwie poniższe gry są wersjami popularnych zabaw polegających na odgadywaniu i tworzeniu wyrazów.
Boggle
Aby uruchomić tę grę, należy wydać polecenie bog. Gra ta jest wersją gry Boggle Delu-xe firmy Parker Brothers. Do dyspozycji masz litery umieszczone w szachownicy o wymiarach 5x5. W czasie do trzech minut musisz wpisywać słowa składające się z za-danych liter. Domyślnie trzeba używać liter, które łączą się poziomo, pionowo lub po przekątnej, bez powtarzania żadnej z nich. Liczba mnoga i różne formy czasowników liczone są jako różne słowa, na przykład różnymi wyrazami są use, uses, used czy user. Takie zasady są zgodne z oficjalnymi stosowanymi w grze Boggle - można jed-nak je modyfikować. Na koniec komputer wyświetla listę słów, które sam znalazł. Na pewno nie uda Ci się pobić komputera, ponieważ dopuszcza on wpisywanie tylko istniejących wyrazów. Jak się pewno przekonasz, słownik programu Boggle zawiera kilka niedopatrzeń - może to być nieco denerwujące, ale nie jest szczególnie poważną wadą. Gra Boggle nie wymaga kolorowego terminalu, ale niewielki rozmiar liter powoduje, że oczy po chwili dość mocno się męczą. Stronę man poświęconą programowi Boggle można obejrzeć po wydaniu polecenia man boggle.
Hangman
Aby uruchomić tę grę, należy wydać polecenie hangman. Kolorowa grafika nie jest w tym przypadku do niczego potrzebna. Gra jest angielską wersją popularnej również w Polsce gry w szubienicę (czy też wisielca), więc chyba nie trzeba tłumaczyć jej zasad. Na wszelki wypadek dostępna jest jednak strona man, którą można obejrzeć po wyda-niu polecenia man hangman. Hangman dobiera wyrazy w sposób przypadkowy; cza-sem są one bardzo trudne do odgadnięcia.
Gry karciane
Ze względu na brak grafiki, gry te nie są tak atrakcyjne jak gry słowne.
Canfield
Aby uruchomić tę grę, należy wydać polecenie canfield. Gra ta jest odmianą pasjan-sa. Poświęconą jej stronę man można obejrzeć po wydaniu polecenia man canfield. Nie posiada ona jednak tak wielkiej zdolności pożerania czasu, jaka charakteryzuje wersje oparte na interfejsie graficznym.
Cribbage
Aby uruchomić tę grę, należy wydać polecenie cribbage. Jeśli jesteś fanem gry Cribbage, aplikacja ta przypadnie Ci do gustu. Poświęconą jej stronę man można obej-rzeć po wydaniu polecenia man cribbage.
Go Fish
Aby uruchomić tę grę, należy wydać polecenie fish. Twoim przeciwnikiem jest kom-puter. Poświęconą jej stronę man można obejrzeć po wydaniu polecenia man fish. Dość uciążliwym aspektem tej gry jest fakt, że informacje o podejmowanych akcjach czasem wyświetlane są razem (przykładowo - jeśli Ty idziesz na ryby, komputer rów-nież musi to zrobić, a informacja o tym pojawia się w jednym bloku z poprzednią in-formacją).
Gry planszowe
Są to tekstowe wersje popularnych gier planszowych. Ich jakość jest dość różna; praw-dopodobnie najlepiej dopracowana jest gra backgammon.
Backgammon
Aby uruchomić tę grę, należy wydać polecenie backgammon. Jeśli natomiast chcesz uruchomić łatwy do opanowania przewodnik, wydaj polecenie teachgammon. Choć w grze tej w niczym nie przeszkadza brak grafiki, brak możliwości wykorzystania urzą-dzenia wskazującego, takiego jak na przykład mysz, jest dość irytujący, ponieważ wymusza wpisywanie danych o poszczególnych ruchach z klawiatury, na przykład w postaci 8-12 czy 4-5. Wpisanie polecenia ? w wierszu poleceń wyświetlanym podczas gry umożliwia dostęp do pomocy zawierającej wskazówki odnośnie wprowadzania danych o poszczególnych ruchach. Wydanie polecenia man backgammon pozwala obejrzeć strony man poświęcone pro-gramom backgammon i teachgammon.
Szachy
W skład pakietu gnuchess wchodzi kilka gier powiązanych z szachami. Jeśli chcesz zagrać w szachy mając za przeciwnika komputer, wydaj polecenie gnuchess. Dostęp-ny jest również program analizujący o nazwie gnuan. Gra potrafi drukować pozycje na szachownicy wykorzystując drukarkę postscriptową lub plik. Dane o poszczególnych ruchach wprowadza się używając notacji standardowej, na przykład e2-4. Pakiet gnuchess jest dość rozbudowany, dlatego zapoznawanie się z nim powinieneś rozpocząć od przejrzenia odpowiedniej strony man.
Mille Miglia
Aby uruchomić tę grę, należy wydać polecenie mille. Jest to linuxowa wersja gry sy-mulującej wyścigi stworzonej przez firmę Parker Brothers. Ponieważ polecenia wyma-gane do jej obsługi nie są zbyt intuicyjne, warto najpierw zajrzeć na stronę man, którą można obejrzeć po wydaniu polecenia man mille.
Monopoly
Aby uruchomić tę grę, należy wydać polecenie monop. Jest to oparta o interfejs teksto-wy wersja gry Monopoly firmy Parker Brothers. Komputer nie jest jednym z graczy - pełni on tylko rolę planszy, notując również informację o poszczególnych własno-ściach i finansach każdego z uczestników. Można oczywiście grać samemu, ale nieu-chronnie prowadzi to do wygranej. Niestety, podczas gry nie jest wyświetlana żadna reprezentacja planszy, co utrudnia panowanie nad sytuacją i powoduje, że gra nie jest zbyt ciekawa. Dostępna jest również opisująca ją strona man.
Symulatory
Opisane poniżej gry pozwalają Ci sprawdzić swoje umiejętności pracy w różnych służ-bach. Są to gry otwarte, to znaczy nie opierają się na zdefiniowanym odgórnie scena-riuszu. Wyświetlają zarówno komunikaty tekstowe, jak i elementy semigraficzne, takie jak na przykład ekran radaru.
Air Traffic Control
Aby uruchomić ten symulator stanowiska kontroli ruchu powietrznego, należy wydać polecenie atc. Najpierw należy jednak obejrzeć poświęconą mu stronę man, wydając polecenie man atc - w przeciwnym przypadku będziesz odpowiedzialny za jedną czy kilka katastrof lotniczych! Akcja gry rozgrywa się w czasie rzeczywistym. Większa dawka kofeiny prawdopodobnie pomoże w wypełnieniu misji.
Sail
Aby uruchomić tę grę, należy wydać polecenie sail. Wcielasz się w niej w kapitana statku, decydującego, jaki kurs należy przyjąć i jakiej broni użyć. Dostępnych jest po-nad 20 scenariuszy, opartych głównie na historycznych bitwach morskich. Warto zaj-rzeć na stronę man dotyczącą tej gry (dostępną po wydaniu polecenia man sail), po-nieważ niektóre z poleceń są niejasne i mylące.
Trek
Aby uruchomić tę grę, należy wydać polecenie trek. Grając w nią można polecieć tam, gdzie jeszcze nikt nie był, polować na Klingonów (lub stać się ich ofiarą) i tak da-lej. Jeśli nie chcesz przynieść wstydu Federacji, powinieneś zajrzeć na stronę man do-stępną po wydaniu polecenia man trek.
Gry "wideo"
Opisane niżej gry korzystają z całego ekranu terminalu, choć wyświetlana grafika składa się tylko ze standardowego zestawu znaków.
Robots
Aby uruchomić tę grę, należy wydać polecenie robots. Roboty wyświetlane na ekranie ścigają Cię; możesz bronić się przed nimi tylko powodując ich zderzanie się ze sobą - po takiej kolizji roboty wybuchają. Powstałe w wyniku zderzenia szczątki niszczą wszystkie roboty, które na nie wpadną. Po ekranie można poruszać się za pomocą klawiszy hjkl, czyli tak jak w edytorze vi; dozwolone są również ruchy po przekąt-nych, które można uzyskać wciskając klawisze yubn. Ty i roboty poruszacie się rów-nocześnie każdy Twój ruch powoduje ruch wszystkich robotów. Czasem może się jednak oka-zać, że jedynym wyjściem z sytuacji jest teleportowanie się w inne miejsce. Gra kończy się, gdy któremuś z robotów uda się Ciebie dogonić. Jeśli natomiast Tobie uda się po-zbyć wszystkich robotów, przechodzisz do następnej planszy, na której czyha na Cie-bie jeszcze liczniejsza ich zgraja. Dokumentacja tej gry jest dostępna na stronie man (wyświetlanej po wydaniu polecenia man robots). W niektórych wersjach Linuxa gra ta została zmodyfikowana w ten sposób, że nie jest możliwe wykonanie ruchu powodującego kolizję z robotem (czyli powodującego prze-graną), co odbiera całą przyjemność grania.
Snake
Aby uruchomić tę grę, należy wydać polecenie snake. Po ekranie możesz poruszać się za pomocą klawiszy hjkl, zbierając pieniądze ($) i unikając węża (składającego się z liter s). Im więcej pieniędzy zbierzesz, tym głodniejszy jest wąż. Pomieszczenie moż-na opuścić wchodząc na symbol # - jest to jedyna droga ucieczki przed wężem. W sy-tuacjach awaryjnych można również ratować się przeniesieniem na przypadkową po-zycję - w tym celu należy wcisnąć klawisz w. Dokumentację tej gry można obejrzeć po wydaniu polecenia man snake.
Tetris
Aby uruchomić tę grę, należy wydać polecenie tetris. Jak wskazuje nazwa, jest to wersja gry w Tetrisa, wykorzystująca możliwości terminalu znakowego. Choć na pew-no nie wygląda tak dobrze jak wersje dla systemu X Window czy innych systemów graficznych, jest bardzo wygodna w obsłudze, co powoduje, że gra jest bardzo przy-jemna. Klocki przesuwa się klawiszami "," oraz "/", natomiast do ich obracania (w kierunku przeciwnym do ruchu wskazówek zegara!) służy klawisz ".". Wciśnięcie spa-cji powoduje zrzucenie klocka na dno studni. Używając opcji programu tetris do-stępnych z wiersza poleceń, można zmienić przyporządkowanie klawiszy. Szczegółowe informacje możesz znaleźć na stronie man wyświetlanej po wydaniu polecenia man tetris.
Worm
Aby uruchomić tę grę, należy wydać polecenie worm. Sterujesz robakiem, poruszają-cym się po ekranie i zjadającym pojawiające się tu i ówdzie cyfry. Połknięcie każdej cyfry powoduje odpowiednie wydłużenie robaka. Wpadnięcie na własny ogon lub na ścianę kończy się jego śmiercią. Jak długo potrafisz utrzymać robaka przy życiu? Weź pod uwagę fakt, że porusza się on do przodu nawet wtedy, gdy nie wydajesz żadnych poleceń. Stronę man dotyczącą programu worm można obejrzeć po wydaniu polecenia man worm.
Gry matematyczne i programy użytkowe
Przedstawione poniżej programy są co prawda małe i interesujące, ale poza tym nie są szczególnie ekscytujące.
Arithmetic
Aby uruchomić ten program, należy wydać polecenie arithmetic. Gra polega na po-dawaniu wyników prostych działań matematycznych. Działanie programu można przerwać wciskając klawisze Control+C. Strona man jest dostępna po wydaniu pole-cenia man arithmetic.
Programy do kodowania tłoczonych kart BCD, alfabetu Morse'a i taśmy perforowanej.
Aby uruchomić program zamieniający wpisywany przez Ciebie tekst na postać odpo-wiadającą tej kodowanej na tłoczonych kartach BCD, wydaj polecenie bcd. Jeśli chcesz dowiedzieć się, jaka będzie postać tekstu po zakodowaniu go alfabetem Mor-se'a, wydaj polecenie morse, natomiast na postać używaną w taśmach perforowanych możesz zamienić go wydając polecenie ppt. Jeśli programy te zostaną uruchomione bez żadnego tekstu w wierszu poleceń (który jest interpretowany jako tekst do prze-tłumaczenia), wchodzą w tryb interaktywny. Po wciśnięciu klawisza Enter wprowa-dzony wiersz tekstu jest poddawany konwersji (kod klawisza Enter również jest kodo-wany). Strona man dotycząca programu bcd zawiera także informacje o dwóch pozo-stałych programach.
Factor
Aby uruchomić ten program, należy wydać polecenie factor. Potrafi on rozkładać liczby na czynniki pierwsze. Wydanie polecenia factor powoduje rozłoże-nie na czynniki podanej liczby, natomiast program wywołany bez argumentów działa w trybie interaktywnym. Liczby muszą mieścić się w przedziale od -2147483647 do 2147483648. Oto przykładowy wynik działania programu factor:
darkstar:/usr/games$ factor
123
123: 3 41
36
36: 2 2 3 3
1234567
1234567: 127 9721
63473882377743928323
factor: ouch
darkstar:/usr/games$
Primes
Aby uruchomić ten program, należy wydać polecenie primes. Jeśli w wierszu poleceń podana zostanie liczba, program primes wyświetli wszystkie liczby pierwsze nie więk-sze od podanej; jeśli nie, program najpierw czeka na wprowadzenie liczby określającej zakres. Program jest zadziwiająco szybki! Stronę man można obejrzeć wydając pole-cenie man primes.
Gra dla kilku graczy: Hunt
W tej grze musi brać udział kilku uczestników. Wymagane jest podłączenie co naj-mniej jednego dodatkowego terminala znakowego (na przykład poprzez port szerego-wy).
Gra graficzna: Sasteroids
Ta gra do poprawnego działania wymaga karty graficznej zgodnej ze standardem VGA. Aby ją uruchomić, wydaj polecenie sasteroids. Gra przejmuje kontrolę nad ekranem, przełączając terminal w tryb graficzny. Jest to wersja znanej z automatów do gier gry Asteroids. Do poruszania statkiem służą klawisze: strzałka w lewo    obrót zgodnie z kierunkiem ruchu wskazówek zegara
strzałka w prawo    obrót przeciwnie do kierunku ruchu wskazówek zegara
strzałka w górę    przyspieszenie
strzałka w dół    uruchomienie osłony (statek wyposażony jest tylko w jedną osłonę)
lewy Control    strzał
lewy Alt    hiperprzestrzeń
Przyzwyczajenie się do sposobu poruszania statkiem może zająć dłuższą chwilę. Wy-gląd gry jest zupełnie odmienny od jej pierwowzoru. Nie jest dostępna strona man.
Inne gry
Przedstawione poniżej gry mogą początkowo wydawać się trudne, ale mogą dostar-czyć wielu godzin uzależniającej rozrywki.
Sokoban
Wyobraź sobie, że znajdujesz się w magazynie mającym postać labiryntu, w którym przechowywane jest mnóstwo beli bawełny. Każda z nich jest na tyle ciężka, że mo-żesz ją poruszyć tylko pchając, nie da się natomiast jej pociągnąć. Nie należy więc we-pchnąć beli do kąta, z którego nie uda się jej już wydostać. Kolejne etapy gry są coraz trudniejsze - aby przejść do następnego etapu, należy przepchnąć wszystkie bele do obszaru załadunku. Kod źródłowy tej gry jest dostępny w węźle sunsite.unc.edu, w pliku sokoban-src. tar.gz.
DOOM
Ta wciągająca, choć kontrowersyjna ze względu na okrucieństwo gra, doczekała się również wersji linuxowej. Jest to pełna wersja gry, z wyborną grafika oraz obsługą dźwięku, nie odbiegająca od wersji dla systemu DOS. Jedynym problemem, na który należy zwrócić uwagę, jest fakt, że paleta kolorów systemu X Window może zostać zmieniona, jeśli przesuniesz kursor poza okno terminala X, w którym uruchomiony jest DOOM. Poza tym, aby móc posłuchać efektów dźwiękowych, należy przekompilować jądro dodając do niego obsługę karty dźwiękowej. Wersja 1.666 gry DOOM nie obsłu-guje zewnętrznych plików WAD (sugeruję zdobycie wersji zarejestrowanej).
Conquest
Jest to skomplikowana gra, polegająca na podbijaniu świata, wyposażona w równie złożoną instrukcję. Na szczęście przynajmniej pliki są rozprowadzane w postaci skom-pilowanej, więc nie trzeba tworzyć ich samodzielnie. Należy pamiętać o tym, aby uży-wając pliku xconq wydać polecenie xset fp rehash, które pozwoli na przywrócenie właściwych czcionek. Podobna gra, o nazwie Empire, jest dostępna w węźle tsx-11.mit.edu również w formie kodu źródłowego - ta wersja wymaga jednak połącze-nia sieciowego. Programy demonstracyjne i użytkowe Opisane poniżej programy mogą Cię zainteresować - informacje o fazach Księżyca są przydatne, szczególnie jeśli jesteś wilkołakiem.
Caesar
Aby uruchomić ten program, należy wydać polecenie caesar. Program ten próbuje od-szyfrować zakodowane słowa. Stronę man można obejrzeć po wydaniu polecenia man caesar.
Fortune
Wydanie polecenia fortune powoduje wyświetlenie aforyzmu, anegdoty czy powie-dzonka.
Number
Program number zamienia postać numeryczną liczby na odpowiadającą jej postać słowną w języku angielskim, na przykład wydanie polecenia number 41 spowoduje wyświetlenie tekstu forty-one.
Fazy księżyca
Aby uruchomić ten program, należy wydać polecenie pom (ang. Phase Of the Moon). Wyświetla on informacje o aktualnej fazie księżyca. Strona man, dostępna po wydaniu polecenia man pom, podaje, że informacje te mogą być przydatne do przewidywana własnych zachowań oraz zachowań innych osób.
Rain
Aby uruchomić ten program, należy wydać polecenie rain. Program ten wyświetla na ekranie terminala zmarszczki podobne do powstających w czasie burzy na powierzch-ni kałuż. Na większości terminali działa on jednak o wiele za szybko, nie przypominając oryginału nawet w przybliżeniu.
Worms
Aby uruchomić ten program, należy wydać polecenie worms (nie pomyl go z opisanym wcześniej programem worm). Ekran zostanie zapełniony przez wijące się robaki. Po-dobnie jak program rain, ten program również działa na konsolach linuxowych o wie-le za szybko. Stronę man można obejrzeć po wydaniu polecenia man worms.

Adabas-D i inne bazy danych
Omówimy niektóre z popularniejszych programów obsługi baz danych przeznaczo-nych dla systemu Linux. Skupimy się głównie na takich aplikacjach, jak Adabas-D, FlagShip i dbMan V. Omówimy również skrótowo program LYNCKS, który jest dar-mowym, obiektowym systemem zarządzania bazami danych (DBMS, DataBase Ma-nagement System) działającym w systemie Linux.
Bazy danych kompatybilne z dBASE
Około dziesięć lat temu w powszechnym użyciu był tylko jeden system baz danych, dBASE firmy AshtonTate. Zanim pojawił się system Windows, praktycznie każda ba-za danych dla systemu DOS tworzona była w dBASE, a w miarę migracji systemów UNIX-owych na mniejsze komputery zaczęły pojawiać się również wersje dBASE przeznaczone dla tych systemów. Choć właściciel pakietu dBASE zmieniał się kilka-krotnie, wersja dla Windows nie pojawiła się na rynku dość szybko (ani nie pozostała na nim zbyt długo), co spowodowało znaczny spadek jego popularności. Wkrótce za-miast dBASE zaczęto używać innych baz danych. W związku z opracowaniem szybszych i lepszych wersji systemu dBASE, kilka firm wprowadziło kompatybilne z nim produkty, rozszerzające możliwości tego języka. Produkty były ogólnie nazywane xBase, aby podkreślić ich powiązania z systemem dBASE. Kilka z nich zyskało dość dużą popularność wśród programistów - w szcze-gólności Clipper, kompatybilny z dBASE kompilator, który w ogromnym stopniu przy-spieszał działanie tworzonych programów. Choć wielu programistów uważa system dBASE za przestarzały, napisano tysiące (jeśli nie miliony) aplikacji działających w tym relacyjnym systemie baz danych. Wiele z nich działa po dziś dzień, bądź w niezmienionej formie, bądź też po przeniesieniu do systemów xBase i nowszych systemów operacyjnych. Ponieważ mało prawdopodobne jest, że języki rodziny xBase kiedykolwiek odejdą w zapomnienie, nie powinino być żadną niespodzianką to, że opracowano ich wersje dla systemu Linux. Firma oferująca system FlagShip, który jest systemem baz danych kompatybilnym za-równo z dBASE, jak i Clipper, proponuje jego wersje dla różnych systemów operacyj-nych, w większości UNIX-owych. Wersja dla Linuxa jest produktem komercyjnym, kosztującym w Stanach Zjednoczonych około 200$. Dostępnych jest również kilka wersji demonstracyjnych, których używać można tylko przez 30 dni, dzięki czemu można przekonać się, czy aplikacje stworzone w systemie dBASE czy Clipper będą działać pod kontrolą Linuxa. Jeśli działają prawidłowo i chcesz przenieść je na tę plat-formę, możesz zakupić pełną wersję systemu FlagShip.
Co to jest xBase?
xBase to dość ogólny termin, obejmujący języki programowania oparte na języku dBASE. Dla systemu DOS są to głównie programy FoxPro (którego właścicielem jest obecnie Microsoft), dBASE V (własność firmy Borland) i Clipper (własność firmy Computer Associates). W języku xBase można znaleźć instrukcje występujące w większości innych języków programowania, takie jak IF, ELSE, ENDIF czy WHILE. Struktura tego języka nie jest jednak zaprojektowana do zastosowań ogólnych, ale tak, by uprościć dostęp do in-formacji przechowywanych w bazach danych. Dla przykładu, instrukcja GOTO w języ-ku xBase nie służy do przejścia do określonego punktu w programie, ale do rekordu w bazie danych. xBase zawiera również różne inne polecenia o bardzo dużych możliwo-ściach, służące do przetwarzania plików oraz pobierania danych z formularzy. Również ustalanie zależności pomiędzy plikami jest w systemie xBase bardzo proste. Nazwy wszystkich pól zapisanych w pliku są przechowywane w jego nagłówku. Nowe pola mogą być dodawane bez modyfikowania operujących na nich programów. Takie rozwiązanie pozwala programom na korzystanie z tej samej bazy danych na różne sposoby, przy wykorzystaniu informacji zapisanych w nagłówku. Trzej główni producenci baz danych xBase zignorowali system Linux jako platformę dla swoich produktów. Dostępny jest jednak system FlagShip oraz dbMan (firmy Vera-soft Corporation). Oba te produkty działają pod kontrolą różnych wersji systemu UNIX. Nie ma większego sensu porównywanie tych dwóch systemów. FlagShip jest oparty na języku Clipper w wersji 5, natomiast pakiet dbMan przypomina dBASE III+ czy FoxPlus. FlagShip, podobnie jak Clipper, jest kompilatorem, natomiast dbMan działa głównie jako interpreter, choć możliwe jest "skompilowanie" programu dbMan. FlagS-hip jest poza tym językiem obiektowym, co sprawia, że jego filozofia jest zupełnie in-na, niż filozofia języka dbMan, FoxPro czy dBASE. Języki Clipper i FlagShip posiada-ją kilka cech upodabniających je do języka C. Podobieństwo to jest zaletą dla użyt-kowników systemu Linux. Również rynki, dla jakich przeznaczone są te dwa produkty, są różne. dbMan jest przeznaczony głównie dla użytkowników indywidualnych. Jeśli chcesz napisać pro-gram, którego będziesz mógł używać do śledzenia czasu poświęcanego klientom czy do przechowywania listy telefonów lub danych o sprzedaży, dbMan jest aplikacją dla Ciebie. Program FlagShip nie nadaje się do tworzenia aplikacji wykonujących tylko proste operacje na bazach danych, takie jak utrzymywanie listy adresów itp., czyli progra-mów tworzonych przez zwykłych użytkowników. Nie chodzi bynajmniej o to, że nie radzi sobie on z takimi zadaniami, ale aby wykorzystać jego możliwości, trzeba naj-pierw zapoznać się z samym językiem. FlagShip jest kierowany raczej do osób, które chcą tworzyć własne pakiety oprogramowania. Zgodnie z tradycją, bazy danych sys-temu dBASE składają się z pliku danych o rozszerzeniu .DBF i plików z indeksami. Format plików danych jest w zasadzie taki sam we wszystkich wersjach języków xBa-se. Trudno jednak znaleźć dwa produkty używające tego samego formatu plików in-deksowych - mimo to zarówno w systemie FlagShip, jak i dbMan można używać tych samych plików z rozszerzeniem .DBF.
Co to jest FlagShip?
FlagShip jest kompilatorem, co oznacza, że tworzy on kod nadający się do bezpośred-niego uruchomienia, bez udziału pośredniego pseudo kodu. Nie istnieje żadna interpre-towana wersja języka FlagShip, więc do opracowywania złożonych aplikacji możesz potrzebować takiego interpretera, jak FoxPro czy dBASE. FlagShip został zaprojekto-wany tak, by umożliwić istniejącym programom xBase działanie bez żadnych mody-fikacji (albo przy minimalnych modyfikacjach, dotyczących tylko problemów z na-zwami plików) w systemie Linux i innych wersjach UNIX-a. Nie są pobierane żadne opłaty za stworzone aplikacje, więc po opracowaniu i skompilowaniu programu moż-na bez przeszkód rozprowadzać go za darmo. FlagShip jest całkowicie kompatybilny z dBASE i Clipperem, podobnie jak z większo-ścią innych systemów xBase, takich jak Fox, FoxPlus, FoxPro, dbMan, QuickSilver i innymi. Udostępnia wszystkie przydatne funkcje spotykane w systemach xBase, na przykład:
- obsługa makropoleceń,
- tabele, obiekty i bloki kodu,
- funkcje i polecenia definiowane przez użytkownika
- indeksy i sortowanie tablic
- kompatybilność z większością formatów xBase, takich jak .dbf, .dbt, .mem, .lbl, .frm i .fmt
- interfejs pozwalający na łączenie programów w języku C i FlagShip w obrębie jednej aplikacji.
FlagShip nie posiada odpowiednika wiersza poleceń systemu dBASE, nie umożliwia również pracy interaktywnej, jak czyni to większość systemów xBase. Dostępny jest jednak program dbu, rozprowadzany na licencji public domain, który pozwala w spo-sób interaktywny definiować funkcje, indeksy, dodawać, usuwać i wyszukiwać rekor-dy, oraz przeglądać pliki. Interfejs użytkownika systemu FlagShip oparty jest na bibliotece curses. Podczas je-go instalacji tworzony jest zestaw plików terminfo specjalnie dla systemu FlagShip. Uruchamiając program FlagShip w oknie terminalu systemu X, możesz zamiast ramek otrzymać dziwne symbole. W takim przypadku może nie pomóc nawet zmiana warto-ści parametru acsc wpisu fslinxterm w pliku terminfo. Spróbuj wówczas zastoso-wać czcionki vga, które są rozprowadzane z programem DOSemu. FlagShip nie zawiera funkcji przeznaczonych specjalnie do obsługi rozwijanych menu. Programiści radzą sobie z tym używając do tworzenia poziomych menu polecenia @PROMPT/MENU, natomiast do tworzenia menu pionowych - funkcji ACHOICE(). Kla-wisze skrótu można definiować za pomocą polecenia SET KEY id_klawisza TO. Zwykle polecenia są wywołaniami funkcji. Wewnątrz tych funkcji można wywołać funkcję READVAR(), która poinformuje, w którym z pól znajdował się kursor w czasie, gdy wciśnięty został klawisz. Pole wprowadzania danych może zostać uaktywnione przez dodanie polecenia VALID do instrukcji @SAY/GET. Również w tym przypadku po-lecenie jest wywołaniem funkcji, wewnątrz której można na przykład poszukać wpro-wadzonego przez użytkownika ciągu znaków w bazie danych. W języku FlagShip dostępne są funkcje zarządzające okienkami, które działają w bardzo wygodny sposób, ale nie wchodzą one w skład pakietu podstawowego - aby uzyskać do nich dostęp, trzeba zakupić bibliotekę FStools. Jak sugeruje sama nazwa, jest to klon biblioteki Clipper Tools. Funkcje obsługi okien wchodzą również w skład biblioteki NanForum (zawierającej poza tym funkcje matematyczne i statystyczne), która jest rozprowadzana zgodnie z warunkami licencji public domain. Programy w języku FlagShip mogą być łączone ze stronami WWW, co daje użytkow-nikom WWW dostęp do baz danych, wraz z możliwością ich uaktualniania. Ta cecha, w połączeniu z możliwością wiązania kodu z programami napisanymi w języku C i C++, powoduje że program FlagShip jest systemem zarządzania bazami danych o bardzo dużych możliwościach. Do programu FlagShip dołączany jest program fsman, dzięki któremu można w każdej chwili uzyskać dostęp do potrzebnej dokumentacji (w sumie jest jej ponad 1000 stron), co oznacza, że nie trzeba posiadać ogromnego podręcznika rozłożonego na stałe na biurku. Przykładowe fragmenty kodu pochodzące z dokumentacji mogą być zapisy-wane jako pliki tekstowe, co pozwala w łatwy sposób włączać je do swych programów. Można oczywiście również używać myszy, kopiując fragmenty tekstu pomiędzy ok-nem programu FlagShip i fsman. FlagShip nie jest tylko kompilatorem przeniesionym z platformy DOS-owej. Został on zaprojektowany tak, by można było skorzystać ze wszystkich możliwości udostępnia-nych przez systemy UNIX-owe. Kod źródłowy działa w systemie Linux szybciej, niż analogiczny w systemie DOS (skompilowany na przykład kompilatorem Clipper), po-nieważ system Linux jest po prostu lepiej zaprojektowany. System FlagShip nie posia-da również niektórych ograniczeń systemów xBase dla DOS i Windows. Jeśli chcesz przenieść aplikacje w języku Clipper na platformę linuxową albo szukasz prostego systemu obsługi relacyjnych baz danych, program FlagShip spełni Twoje oczekiwania.
Instalowanie programu FlagShip
Program FlagShip jest dostępny głównie na płytach CD-ROM, w węzłach WWW i ar-chiwach FTP. W większości przypadków rozprowadzane są dwie wersje tego programu, a wybór jednej z nich zależy od wykorzystywanej wersji Linuxa. Zwykle pliki są spa-kowane do jednego archiwum o nazwie fsdemo.tar (dla wersji demonstracyjnej). Jedna z wersji przeznaczona jest dla nowszych wersji Linuxa, ponieważ wykorzystuje format plików wykonywalnych o nazwie ELF. Druga wersja, oznaczana zwykle nazwą aout (pochodzącą od formatu plików wykonywalnych a.out), działa w każdym sys-temie linuxowym. Choć wersja ELF jest o wiele bardziej elastyczna i ma większe moż-liwości, w skład pakietu demonstracyjnego wchodzi często tylko wersja aout. Po umieszczeniu pliku fsdemo.tar w odpowiednim katalogu (najlepiej pustym i no-wo utworzonym) należy rozpakować go, wydając polecenie
tar xvf fsdemo.tar
Spowoduje ono utworzenie pewnej liczby plików, a pomiędzy nimi plików FSin-stall.set i FSinstall. W pliku FSinstall.set znajdują się definicje zmiennych środowiskowych wykorzystywanych podczas instalacji - należy go uruchomić, wpisu-jąc po prostu jego nazwę. Na ekranie nie zostaną wyświetlone żadne komunikaty. Po uruchomieniu pliku .set należy wykonać polecenie FSinstall, które spowoduje roz-poczęcie właściwego procesu instalacji. Jeśli program instalacyjny zostanie poprawnie załadowany, wyświetlone zostanie py-tanie dotyczące ilości wolnego miejsca w systemie plików .Następnie będzie można wybrać docelowy katalog instalacji - w większości przypad-ków powinieneś zaakceptować wartość podpowiadaną przez program instalacyjny. Je-śli chcesz zmienić którąś z wartości domyślnych, możesz to zrobić po prostu wpisując nową wartość w odpowiedzi na monit programu. Po zakończeniu programu instalacyj-nego można już zacząć używać systemu FlagShip.
Używanie programu FlagShip
Jeśli używałeś wcześniej programu Clipper lub innego kompilatora xBase, znasz już większość poleceń wykorzystywanych w języku FlagShip. Wprowadzone modyfikacje wynikają głównie z dostosowania tego języka do wymagań i możliwości systemów UNIX-owych, ale poza tym używanie języka FlagShip jest bardzo proste. Trzeba pa-miętać o tym, że FlagShip nie jest programem do interaktywnego projektowania apli-kacji; nie pomaga on w żaden sposób w tworzeniu kodu programu. Jest to po prostu kompilator. Możesz używać go do tworzenia aplikacji tylko pod warunkiem, że znasz język dBASE - nie jest on bowiem przeznaczony do nauki tego języka. Jeśli przygotowałeś już pliki źródłowe .prg, możesz uruchomić kompilator FlagShip. Składnia odpowiedniego polecenia jest następująca:
FlagShip nazwa_prog.prg -onazwa_prog_wynikowego -Mstart
nazwa_prog to nazwa pliku, zawierającego główną część kodu źródłowego programu (wywołującą pozostałe części), natomiast nazwa_prog_wynikowego to nazwa, jaka zostanie nadana skompilowanej, gotowej do uruchomienia wersji programu (kompila-tor języka C domyślnie przyjmuje nazwę a.out). Jeśli program główny nie wywołuje wszystkich plików programów niezbędnych do prawidłowego działania całej aplikacji, trzeba skompilować odpowiednie pliki oddzielnie, a następnie powiązać je ze sobą. Po skompilowaniu aplikacja może zostać uruchomiona podobnie jak w systemie DOS czy innym systemie operacyjnym. Jedyną modyfikacją kodu źródłowego, którą trzeba było wprowadzić, było dostosowanie ścieżek dostępu do plików do wymagań systemu Linux. Jak widać, nawet grafika tworzona za pomocą znaków ASCII została zacho-wana prawidłowo, dzięki czemu program może być bez problemu uruchamiany z do-wolnego terminalu obsługiwanego przez system Linux.
Przenoszenie istniejących aplikacji
O co więc trzeba zadbać przy przenoszeniu na platformę linuxową istniejących aplika-cji w języku dBASE czy Clipper? Na początek potrzebny będzie oczywiście kod pro-gramu, zapisany w plikach z rozszerzeniem .prg. Przenieś te pliki do systemu linuxo-wego w dowolny sposób - czy to za pomocą dyskietki, połączenia sieciowego, czy też inną drogą. Program FlagShip jest na tyle sprytny, że potrafi ignorować wielkość liter - może to brzmiećbanalnie, ale w rzeczywistości jest to poważny problem, ponieważ większość programistów pracujących w systemie DOS tworzy programy używając zarówno wiel-kich, jak i małych liter - nie ma to dla nich większego znaczenia, natomiast w systemie UNIX wielkość liter jest bardzo istotna, co może powodować wiele kłopotów. Do programu FlagShip dołączona jest dokumentacja dotycząca modyfikowania kodu źródłowego tak, by działał prawidłowo (jest ona również dostępna na stronie WWW), ale w zasadzie prawie wszystkie aplikacje powinny działać bez żadnych problemów. FlagShip zamienia kod źródłowy w języku dBASE na odpowiadający mu kod w języ-ku C, który następnie jest kompilowany. Z tego względu potrzebny jest również kompi-lator języka C, który na szczęście jest częścią prawie każdego systemu UNIX-owego i linuxowego. Jeśli chcesz używać programu FlagShip, a nie zainstalowałeś jeszcze pa-kietu służącego do programowania w języku C, musisz to najpierw zrobić, w przeciw-nym razie program FlagShip nie będzie działał poprawnie, generując komunikaty o błędach. Nie jest potrzebny kompilator języka C++ - w zupełności wystarczy kompila-tor języka C, dostępny na każdej płycie CD-ROM zawierającej dystrybucję Linuxa (nie wyłączając płyty rozprowadzanej z tą książką). Proces uruchamiania aplikacji przez program FlagShip jest dość prosty:
1. wstępne przetworzenie kodu źródłowego, dzięki czemu wykrywane są błędy składniowe i inne często popełniane błędy; jeśli jakieś błędy zostaną wykryte, są one zgłaszane i program kończy działanie;
2. tłumaczenie kodu na język C;
3. kompilacja za pomocą kompilatora języka C, co prowadzi do powstania pli-ku pośredniego .obj;
4. konsolidacja skompilowanego pliku wraz z bibliotekami programu FlagShip do postaci wykonywalnej.
Utworzony plik wykonywalny może zostać uruchomiony z wiersza poleceń systemu Linux.
Jeszcze krótka uwaga dla doświadczonych użytkowników systemów dBASE i Clipper: nie trzeba martwić się o nakładki, ponieważ w systemach UNIX-owych nie są one po-trzebne. Dzięki temu, że system używa pamięci wirtualnej, możliwe jest ładowanie do pamięci aplikacji o prawie dowolnym rozmiarze (choć istnieją pewne ograniczenia, mogą one zostać zmienione). Z tego powodu nie trzeba martwić się nakładkowaniem, tak jak to miało miejsce w systemach dBASE i Clipper - zamiast tego można śmiało połączyć cały kod w jeden duży plik wykonywalny, pozwalając systemowi Linux za-jąć się jego ładowaniem.
dbMan
Program dbMan jest interpreterem. Po jego uruchomieniu na ekranie wyświetlany jest wiersz poleceń ze znakiem zachęty, który ma formę CMD:. W tym wierszu należy wpi-sywać wszystkie polecenia. Rozwiązanie to jest zbliżone do używanego w systemie dBASE - tam znakiem zachęty była kropka. Początkujący użytkownicy mogą sko-rzystać z polecenia ASSIST, które przywoła na ekran interfejs obsługiwany za pomocą menu, podobny do tych dostępnych w systemach FoxPro czy dBASE. Interfejs oparty na systemie menu nie jest szczególnie rozbudowany. Pozwala na pracę tylko z jednym plikiem w tym samym czasie, co oznacza, że nie można ustalać żad-nych powiązań pomiędzy plikami. Z poziomu tego menu można również uruchomić prosty generator programów, ale tu również nałożone jest ograniczenie umożliwiające pracę tylko z jednym plikiem. Programy w systemie dbMan można kompilować, ale proces ten nie powoduje po-wstania pliku wykonywalnego. Zamiast tego, tworzony jest plik z rozszerzeniem .run, do uruchomienia którego niezbędny jest program dbMan. W wierszu poleceń programu dbMan można także wydać polecenie CREATE REPORT lub MODIFY REPORT, które powoduje uruchomienie modułu do tworzenia raportów. Pozwala on na wyświetlanie danych z użyciem operatorów relacyjnych. Funkcja PMENU() pozwala tworzyć rozwi-jane menu. Niestety, nie jest ona wyposażona w żadne mechanizmy pozwalające na tymczasowe wyłączenie którejś z jego menu. Obsługa okien w systemie dbMan odbiega od tej znanej z innych systemów xBase. Przed zdefiniowaniem nowego okna trzeba wywołać procedurę PUSHWIND(), która od-łoży na stos dane o oknie bieżącym. Kiedy program jest w stanie początkowym, cała zawartość ekranu traktowana jest jako okno. Procedura WINDOW() służy do tworzenia nowego okna. Po zakończeniu pracy z oknem należy wywołać procedurę POPWIND(), która spowoduje zdjęcie ze stosu i uaktywnienie poprzedniego okna. W systemie dbMan można zdefiniować tylko jeden klawisz skrótu, wywołując funkcję ONKEY(). Nie będzie ona miała żadnego efektu, dopóki nie zostanie wywołane nastę-pujące po niej polecenie - zwykle jest to instrukcja DO, obsługująca naciśnięcie danego klawisza. Polecenie BROWSE może zostać wywołane z wieloma różnymi opcjami. Używając go, można przeglądać jedynie wyszczególnione pola, można również określać szerokość poszczególnych pól, oraz to, czy mogą one być edytowane. Lista pól może zawierać pola zapisane w innych plikach, co pozwala w łatwy sposób wiązać ze sobą dane po-chodzące z różnych baz. dbMan nie używa informacji zapisanych w pliku termcap czy terminfo. Zamiast te-go zawiera on plik o nazwie dbmterm.dbm. Zawartość tego pliku jest zbliżona do za-wartości pliku termcap. Nie ma w nim wpisów dotyczących terminalu X czy konsoli, więc trzeba stworzyć własne wpisy w oparciu o już istniejące. dbMan nie zawiera interfejsu pozwalającego na wykonywanie funkcji napisanych w języku C czy asemblerze, można więc używać tylko funkcji oferowanych przez ten system. W wersji, którą testowałem (o numerze 5.32), było kilka dość poważnych błę-dów. Najważniejszym z nich był chyba fakt, że pliki procedur po prostu nie działały, jeśli były to pliki z roz-szerzeniem .prg. Po skompilowaniu ich do postaci plików z rozszerzeniem .run wszystko działało poprawnie.
Adabas-D
Adabas-D to baza danych możliwościami dorównująca aplikacjom komercyjnym dla systemów UNIX-owych, kosztującym tysiące dolarów. Obsługuje język SQL, pozwala również na pracę z wieloma popularnymi formatami baz danych - warto więc rozwa-żyć jej zainstalowanie, jeśli potrzebujesz większych możliwości, niż oferowane przez wspomniane wcześniej programy xBase.
Instalowanie programu Adabas-D
System Adabas-D jest zwykle rozprowadzany na płytach CD-ROM, ale udostępniają go również niektóre węzły FTP. Choć wersja rozprowadzana przez firmę Caldera re-klamowana jest jako przeznaczona do pracy z systemem Caldera OpenLinux, działa ona znakomicie ze wszystkimi implementacjami Linuxa. Instalacja pakietu jest pro-sta. Podana poniżej procedura działa we wszystkich wersjach systemu RedHat, Slac-kware i OpenLinux, które udało nam się przetestować. Założymy tu, że oprogramowa-nie Adabas-D znajduje się na płycie CD-ROM. Jeśli załadowałeś odpowiedni plik z sie-ci, powinieneś umieścić go w osobnym katalogu i pominąć kroki dotyczące montowa-nia systemu plików. Zaloguj się jako root, proces instalacji wymaga bowiem uprawnień administratora. Pierwszym krokiem jest zamontowanie systemu plików zapisanego na płycie CD-ROM. Można to zrobić wydając polecenie
mount /dev/cdrom
W tej wersji polecenia mount pominęliśmy argumenty dotyczące urządzenia oraz punktu zamontowania, które omówiliśmy w poprzednich rozdziałach. System plików zostanie zamontowany w katalogu /mnt/cdrom - jeśli chcesz, możesz oczywiście wymusić zamontowanie go w innym katalogu. W dalszej części tego rozdziału przyj-miemy, że punktem zamontowania jest właśnie katalog /mnt/cdrom. Po zamontowaniu płyty CD-ROM przejdź do katalogu zawierającego pliki instalacyj-ne, na przykład wydając polecenie
cd /mnt/cdrom
Wyświetlenie informacji o zawartości katalogu powinno pokazać pliki systemu Ada-bas-D. Większość z nich znajduje się w podkatalogach katalogu głównego. Dla uproszczenia życia użytkownika, ta wersja systemu Adabas-D zawiera skrypt in-stalacyjny, który bierze na siebie wszystkie czynności, jakie normalnie należałoby wy-konać ręcznie. Aby uruchomić ten skrypt, wystarczy wydać polecenie
./install

Kropka i ukośnik poprzedzające nazwę skryptu oznaczają, że jest on umieszczony w katalogu bieżącym. Jeśli zostałyby one pominięte, przed sprawdzeniem zawartości bie-żącego katalogu Linux szukałby pliku o nazwie install w innych lokalizacjach, co zwykle prowadzi do uruchomienia innego programu instalacyjnego. Jeśli w Twojej wer-sji pakietu Adabas-D nie ma skryptu instalacyjnego, w którymś z plików powinien znajdować się dokładny opis czynności, które należy wykonać, aby go zainstalować. Jeśli używasz skryptu instalacyjnego, będziesz miał możliwość zainstalowania kilku pakietów oprogramowania oraz zdecydowania, w którym katalogu mają się one zna-leźć. Dla uzyskania pełnego i kompletnego systemu Adabas-D należy zainstalować wszystkie dostępne pakiety; jedynym wyjątkiem są pakiety obsługujące języki, któ-rych nie potrzebujesz (Adabas-D zwykle rozprowadzany jest wraz z angielską i nie-miecką dokumentacją oraz zestawem poleceń). W skład pakietu w wersji Personal Edi-tion wchodzą cztery składniki.
- adabas-6.1PE. Jądro programu oraz wszystkie pliki wykonywalne i konfigu-racyjne (ok. 46 MB).
- adabas-mydb. Przykładowa baza danych zawierająca dane o niemieckich li-niach kolejowych (ok. 74 MB).
- adabas-docEN. Dokumentacja w języku angielskim (105 MB).
- adabas-dokDE. Dokumentacja w języku niemieckim (79 MB).
Przed uruchomieniem programu Adabas-D należy ustawić odpowiednie wartości dwóch zmiennych środowiskowych dla każdego użytkownika, który będzie korzystał z baz danych. Zmienne te mają następujące znaczenie:
- DBROOT - katalog programu (na przykład /opt/adabas-d),
- PATH - do istniejącej wartości ścieżki przeszukiwania należy dodać podkatalog bin katalogu DBROOT (co zwykle uzyskuje się przez wpisanie $DBROOT/bin:$PATH).
Pakiet adabas-mydb pozwala na łatwe opanowanie obsługi systemu Adabas-D na podstawie przykładowej bazy danych dotyczącej kolei w Niemczech (która jest rów-nież sama w sobie warta obejrzenia, jeśli interesujesz się koleją). Można uruchomić ten przykład w oknie terminalu X Window, aby przekonać się, jakie możliwości ma system Adabas-D. Aby uruchomić program demonstracyjny, uruchom system X Window (po ustawieniu odpowiednich wartości zmiennych środowiskowych) i wydaj polecenie
panel
Nazwa użytkownika, którą należy podać, to control, również hasło ma postać con-trol. Nazwa bazy danych to MYDB. Kliknij na przycisku Connect i poczekaj, aż kon-trolka przypominająca światła na skrzyżowaniu zmieni kolor na zielony. Baza danych zawiera również zdjęcia niektórych niemieckich pociągów. Jeśli chcesz obejrzeć dołą-czone obrazki, w oknie terminalu wydaj polecenie fotos, następnie podaj nazwę użytkownika demo i hasło demo oraz tę samą co poprzednio nazwę bazy danych (MYDB). System Adabas-D powinien już działać poprawnie. Jeśli występują jakieś problemy, upewnij się, że wartości wspomnianych wcześniej zmiennych środowiskowych są pra-widłowe oraz że podczas instalacji nie wystąpił żaden błąd. Dokumentacja systemu Adabas-D znajduje się w podkatalogu doc katalogu głównego systemu Adabas-D (na przykład /opt/adabas-d/doc).
LINCKS
LINCKS to obiektowy system zarządzania bazami danych. Znakomicie nadaje się on do użytku w sieci oraz w sytuacjach, gdy pliki mają być współużytkowane za pomocą zdalnych wywołań procedur. Aby móc w pełni wykorzystać możliwości oferowane przez ten program, trzeba mieć nieco doświadczenia w pracy z siecią i posiadać działa-jącą sieć. Pakiet nie jest raczej przeznaczony dla systemu jednostanowiskowego, po-nieważ po prostu mnóstwo jego możliwości pozostałoby niewykorzystanych. LINCKS oparty jest na obiektowej strukturze pozwalającej jedynie na dołączanie nowych składników. Nowe obiekty definiowane są na podstawie innych obiektów. Po-między obiektami można tworzyć powiązania, obrazujące związki pomiędzy danymi. Dla obiektu można również zdefiniować widok (lub nawet kilka widoków), który pozwala określić, w jaki sposób dane będą prezentowane użytkownikowi. Widoki mogą być dziedziczone. Głównym interfejsem tego pakietu jest program xlincks. Z jego pomocą, używając poleceń zbliżonych do tych wykorzystywanych w edytorze emacs, można w sposób in-teraktywny przeglądać bazy danych. Interfejs nieco przypomina w działaniu funkcje hipertekstowe dostępne na stronach WWW. Po kliknięciu na wyróżnionym elemencie program wyświetla dodatkowe informacje na zadany temat. Pomoc dostępna jest w dwóch postaciach: jako pomoc kontekstowa oraz jako baza danych, którą można swobodnie przeglądać. Dostęp do pliku pomocy można uzyskać w każdej chwili, wciskając klawisz Help. Zawartość tego pliku jest zorganizowana w bardzo przejrzysty sposób, dzięki czemu może on zostać wykorzystany również do nauki systemu LINCKS od podstaw. W archiwach systemu sunsite dostępny jest również podręcznik w wersji postscriptowej. W pakiecie LINCKS znajduje się kilka programów. Program dbroot służy do tworze-nia nowych baz danych. Aby uwolnić bazę danych od obiektów, które nie są już uży-wane, należy wydać polecenie cutoff. Serwerem całej aplikacji jest program net-serv, który uruchamia procesy dbs obsługujące każdego łączącego się z nim klienta.
Inne bazy danych
Oczywiście narzędzia xBase, które omówiliśmy w tym rozdziale, nie są jedynymi sys-temami obsługi baz danych dla platformy linuxowej. Istnieje również mnóstwo pro-gramów niekompatybilnych z systemem dBASE. Przyjrzyjmy się jeszcze króciutko niektórym z nich (większość jest -dostępna za darmo i może zostać załadowana z In-ternetu).
- mbase v5.0 to system obsługi relacyjnych baz danych stworzony pierwotnie dla komputerów Amiga, a następnie przeniesiony na inne platformy. Do ob-sługi baz danych używany jest język przypominający język C. Kompilacja programu mbase wymaga biblioteki ncurses oraz sporej ilości czasu. Zdarza-ją się również problemy z plikiem Makefile, który może wymagać ręcznej modyfikacji. Jeśli potrzebujesz taniego systemu dostępu do baz danych, zbli-żonego do języka C, możesz rozpatrzyć używanie tego systemu. Jednak pro-gramy FlagShip lub dbMan są bardziej stabilne i mają większe możliwości.
- onyx to program do tworzenia baz danych za pomocą języka zbliżonego do języka C. Polecenie make config powoduje uruchomienie procesu instala-cyjnego, podczas którego należy odpowiedzieć na szereg pytań, dzięki którym możliwe będzie prawidłowe skonfigurowanie bazy danych dla systemu Linux.
- DBF to zestaw programów służących do manipulowania bazami zgodnymi z xBase (z rozszerzeniem .dbf). Niektóre z tych programów potrafią na przy-kład dodawać do pliku nowe rekordy lub warstwy informacji (dbfadd), inne potrafią wyświetlać zapisane w bazie danych informacje (dbflist). Program dbft pozwala na wyświetlenie informacji o strukturze bazy danych i poszczególnych jej elementów.
- typhoon to jeszcze jeden system obsługi relacyjnych baz danych. Wyróżnia go fakt, że składnia języka używanego do obsługi baz danych praktycznie ni-czym nie różni się od języka C. Zanim jednak będzie można używać go do poważniejszych zastosowań, program musi jeszcze zostać dopracowany

StarOffice
StarOffice 5.0 to przeznaczony dla środowiska X Window pakiet programów biuro-wych działających w systemie Linux. Jest on rozprowadzany wraz z niektórymi wer-sjami Linuxa (na przykład Caldera OpenLinux), można go również załadować w nie-których węzłach FTP i na stronach WWW. Wersja StarOffice 5.0, która jest wersją najnowszą, zawiera trzy aplikacje: StarWriter, który jest edytorem tekstów, arkusz kal-kulacyjny StarCalc oraz program do tworzenia prezentacji o nazwie StarImpress, po-trafiący również generować dokumenty w języku HTML. Choć możliwości tego pakietu nie są aż tak ogromne, jak możliwości pakietu Office firmy Microsoft czy WordPerfect Suite firmy Corel, to i tak najprawdopodobniej bę-dziesz zaskoczony jego możliwościami i przydatnością. Narzędzia wchodzące w skład pakietu są najczęściej wykorzystywanymi w codziennej pracy programami, potrafią-cymi w dodatku współpracować z bazami danych (więcej informacji o bazach danych możesz znaleźć w rozdziale 62.), co powoduje, że stanowią one pełną platformę biu-rową dla systemów linuxowych. Znakomicie nadają się również do wykorzystania w domu. Program StarOffice działa ze wszystkimi dostępnymi obecnie wersjami Linuxa, pod warunkiem, że pracuje w nich również serwer X Window.
Instalacja pakietu StarOffice
Pakiet StarOffice nie jest instalowany za pomocą standardowych programów instalu-jących, ale za pomocą specjalnego skryptu. Aby zainstalować ten pakiet, musisz być zalogowany jako root. StarOffice jest aplikacją systemu X, więc przed rozpoczęciem instalacji należy uruchomić ten system, a poszczególne polecenia wpisywać w oknie terminalu. Aby zainstalować pakiet StarOffice, który zwykle dostarczany jest na płytach CD-ROM, należy najpierw zamontować odpowiednią płytę w punkcie, którego zwykle używasz, na przykład wydając polecenie:
mount /dev/cdrom /usr/cdrom
Następnie należy przejść do katalogu, w którym dostępne są pliki zapisane na płycie CD-ROM. Dalej należy przejść do katalogu o nazwie StarOffice 5.0 (pozostałe katalogi zawierają pliki pomocnicze i informacje o prawach autorskich), podkatalogu bin, i w końcu uruchomić skrypt instalacyjny, wydając polecenie
./setup
Kropka i ukośnik przed właściwą nazwą pliku oznaczają, że jest to plik zapisany w ka-talogu bieżącym, dzięki czemu na pewno wykonany zostanie ten program, o który chodzi. Po uruchomieniu i wyświetleniu informacji o prawach autorskich zostanie wy-świetlone okno przedstawione na rysunku 63.1. W większości przypadków najlepiej w tym momencie zdecydować się na instalację standardową, chyba że chcesz zainstalo-wać tylko niektóre ze składników pakietu. Jeśli masz mało miejsca na dysku, również powinieneś pomyśleć o zrezygnowaniu z instalacji plików, które nie są niezbędne. Skrypt instalacyjny automatycznie kopiuje wszystkie potrzebne pliki, wyświetlając procentowy wskaźnik zaawansowania tej operacji. Po zakończeniu instalacji skrypt kończy działanie.
Uruchamianie StarOffice
Domyślnie program StarOffice instalowany jest w katalogu /root/Office50. Jeśli wybrałeś instalację ręczną, mogłeś zmienić tę ścieżkę, ale nie jest to konieczne w więk-szości wersji Linuxa. Katalog ten oraz jego podkatalog bin należy dodać do ścieżki przeszukiwania, dzięki czemu będzie można łatwo uruchamiać pakiet z dowolnego miejsca w systemie plików. Aby uruchomić pakiet StarOffice, otwórz okno terminalu (jeśli żadne nie jest jeszcze otwarte), przejdź za pomocą polecenia cd do katalogu /root/Office50/bin (jeśli nie dołączyłeś go do ścieżki przeszukiwania) i wydaj polecenie:
soffice &
Jeśli w skład ścieżki przeszukiwania nie wchodzi ani katalog programu StarOffice, ani katalog bieżący (.), należy poinformować interpreter poleceń, że pliku wykonywalnego ma szukać w katalogu bieżącym, wydając polecenie
./soffice &
Ampersand na końcu polecenia spowoduje, że zostanie ono wykonane w tle, dzięki czemu nie będzie blokowało dostępu do terminalu X. Polecenie soffice jest najprost-szym sposobem uruchamiania tego pakietu, choć możliwe jest również uruchamianie poszczególnych aplikacji. Po uruchomieniu programu StarOffice wyświetlane jest okno główne. Jest ono podzie-lone na część zawierającą przeglądarkę plików oraz drugą, w której wyświetlany jest zestaw ikon pozwalających na uruchomienie poszczególnych aplikacji.
StarWriter
StarWriter to edytor tekstów wchodzący w skład pakietu StarOffice. Aby uruchomić ten program z nowym dokumentem, kliknij dwukrotnie na ikonę New Document w ok-nie głównym programu StarOffice. Spowoduje to uruchomienie programu StarWriter. Lewa część okna nadal zawiera przeglądarkę plików, natomiast w części prawej wy-świetlone jest okno edytora tekstów, wraz z ikonami pozwalającymi na szybki dostęp do niektórych funkcji oraz oknem zawierającym listę dostępnych stylów. Edytor StarWriter zachowuje się podobnie jak system Windows, zarówno pod wzglę-dem dostępnych poleceń, jak i skrótów klawiaturowych oraz ikonek dostępnych w górnej części ekranu. Dzięki temu jego obsługa jest bardzo łatwa (szczególnie dla użyt-kowników, którzy pracowali wcześniej z takimi edytorami, jak Word czy WordPad). StarWriter zawiera również mnóstwo drobnych udogodnień, które na pewno spodobają się użytkownikom Linuxa. Można o nich poczytać używając systemu pomocy pakietu StarOffice. Dla przykładu, jeśli wysyłasz dużą liczbą wiadomości pocztą elektroniczną czy też intensywnie korzystasz z grup dyskusyjnych, jesteś na pewno przyzwyczajony do akcentowania fragmentów tekstu w sposób zgodny ze standardem ASCII. Na przy-kład, aby pogrubić dany fragment tekstu, zwykle otacza się go gwiazdkami, na przy-kład pisząc *A teraz coś bardzo ważnego*. Podkreślenie uzyskuje się przez umieszcze-nie symbolu podkreślenia przed i po wyróżnionym fragmencie, czyli _w taki sposób_. StarWriter potrafi zorientować się, o co Ci chodzi, i zastosować odpowiedni krój czcionki. Dzięki temu używając tego edytora nie musisz zmieniać swoich przyzwycza-jeń.
StarCalc
StarCalc, jest arkuszem kalkulacyjnym. Podobnie jak StarWriter, StarCalc zachowuje się prawie tak samo jak program Excel wchodzący w skład pakietu Microsoft Office. Jeśli więc potrafisz obsługiwać program Excel, nie bę-dziesz miał żadnych problemów z programem StarCalc. Jedną z cech programu StarCalc, której brakuje w wielu innych programach tego typu (nie wyłączając programów dla Windows 95), jest to, że do opisu równań można uży-wać języka naturalnego. Można również na przykład pojedyńczym poleceniem utwo-rzyć tabelę, w której pierwszy rząd i pierwsza kolumna będą pełniły funkcję nagłówka.
StarImpress
Program StarImpress może znaleźć wiele zastosowań - można go na przykład wyko-rzystać do tworzenia prezentacji graficznych. .StarImpress bardzo przypomina pro-gram PowerPoint - obsługuje się go również w podobny sposób. StarImpress zawiera kilka bardziej zaawansowanych możliwości, na przykład potrafi bardzo szyb-ko tworzyć efekty trójwymiarowe. Dzięki temu może konkurować z innymi progra-mami dla platform UNIX-owych przeznaczonymi do tego celu, na przykład pakietem CorelDraw! dla UNIX-a, które są o wiele droższe. Bez żadnych problemów można również używać programu StarImpress wraz z innymi aplikacjami pakietu, osadzając w nich utworzone grafiki. Do importowania dokumen-tów używa się techniki zbliżonej do OLE, dzięki czemu w dokumencie programu StarWriter czy StarCalc można umieścić dowolną liczbę grafik pochodzących z pro-gramu StarImpress. Program StarImage jest programem pomocniczym, pozwalającym na szybką konwer-sję plików graficznych do różnych formatów oraz na manipulację ich zawartością. Sta-rImage potrafi obsługiwać pliki w formatach .BMP, .JPEG, .GIF, .TIFF i .XBM. Więk-szość jego funkcji pokrywa się z udostępnianymi przez inne programy graficzne, na przykład xv, ale scalenie go z pakietem StarOffice ułatwia pracę z różnymi narzę-dziami wchodzącymi w jego skład.
Importowanie i eksportowanie plików
Jak mogłeś się przekonać, pakiet StarOffice bardzo przypomina analogiczny pakiet firmy Microsoft. Rozciąga się to również na możliwości importowania i eksportowania plików innych formatów. Choć własny format, w którym StarOffice zapisuje doku-menty, arkusze kalkulacyjne i grafiki, nie jest kompatybilny z programami Microsoft Word, Excel i PowerPoint, dostępna jest opcja pozwalająca na zapisanie dokumentów w innych formatach. Jednym z tych formatów jest właśnie format używany przez pa-kiet Microsoft Office, co znakomicie ułatwia przenoszenie dokumentów pomiędzy ty-mi pakietami. Oprócz formatów zgodnych z pakietem Office, StarOffice umożliwia również użycie formatów tekstowych, takich jak ASCII, RTF i HTML. Ostatni z nich jest oczywiście bardzo przydatny do tworzenia stron WWW. Po przeniesieniu plików pochodzących z aplikacji firmy Microsoft do systemu linuxo-wego możliwe jest importowanie ich do pakietu StarOffice. Można następnie zapisać je w tym samym formacie bądź też w formacie używanym przez pakiet StarOffice. Moż-liwość wymiany plików pomiędzy pakietem StarOffice i programami dla systemu Win-dows bardzo ułatwia pracę.

Program Lone-Tar firmy Lone Star Software
Tworzenie kopii zapasowych systemu plików może być zajęciem złożonym i irytują-cym, szczególnie jeśli nie dysponujesz napędem taśmowym albo innym nośnikiem o odpowiedniej pojemności. Jeśli musisz korzystać z dyskietek, Twoja sytuacja jest dość nieciekawa, ponieważ wykonanie pełnej kopii systemu plików zajmie kilkadziesiąt, je-śli nie kilkaset dyskietek. Dlatego większość użytkowników nie posiadających nośni-ków o większej pojemności po prostu rezygnuje z wykonywania pełnych kopii zapa-sowych. Wielu użytkowników uważa, że program tar, przeznaczony do wykonywania kopii zapasowych jest trudny i nieprzyjemny w obsłudze. Na domiar złego zdarza się, że zgłasza on błędy powodowane przez najróżniejsze przyczyny, zmuszając Cię do wy-konania kopii zapasowej od początku. W wielu większych systemach UNIX-owych program tar został zastąpiony specjalnie zaprojektowanym programem, opartym na interfejsie graficznym; niestety, w systemie Linux program taki nie jest jeszcze dostęp-ny. Mimo tego istnieje kilka programów mogących zastąpić program tar; najlepszym z nich jest chyba program Lone-Tar firmy Lone Star Software.
Co to jest Lone-Tar?
O programie Lone-Tar można myśleć jak o poprawionej wersji programu tar. Posiada on wszystkie możliwości, które oferuje tar, rozbudowano go ponadto o kilka nowych, których w tym programie zdecydowanie brakowało. Program Lone-Tar nie używa standardowego programu tar, choć jego zachowanie jest dość podobne. Lone-Tar jest dostępny w wersjach dla wielu platform UNIX-owych i innych i jest kompatybilny po-między wszystkimi tymi platformami. Można na przykład wykonać kopię zapasową plików w systemie DOS i przywrócić zapisane w niej pliki pod kontrolą systemu Linux. Podobnie jak program tar, Lone-Tar może tworzyć kopie zapasowe plików i przywra-cać pliki z kopii zapisanych na dyskietkach, taśmach, dyskach twardych i innych no-śnikach. Lone-Tar potrafi również zapisywać informacje o wszystkich plikach specjal-nych, dowiązaniach (symbolicznych i stałych), plikach wirtualnych i partycjach - możliwości takich nie posiada program tar. Program Lone-Tar umożliwia wykonywanie kopii zapasowych na dwóch nośnikach o różnych pojemnościach, co nie jest łatwe do osiągnięcia za pomocą programu tar. Poza tym program Lone-Tar zawiera doskonale działające procedury wykrywania i korekcji błędów, co pozwala na przywrócenie zapisanego systemu plików nawet w sy-tuacji, gdy zapisane dane zostały w pewnym stopniu uszkodzone. Program tar w ta-kiej sytuacji po prostu kończy działanie, pozbawiając kopię zapasową jakiejkolwiek wartości.
Interfejs programu Lone-Tar
Program Lone-Tar posiada dwa interfejsy. Może być obsługiwany za pomocą systemu menu lub też z wiersza poleceń. Dla zapewnienia kompatybilności, interfejs oparty na wierszu poleceń jest bardzo podobny do interfejsu programu tar. Dzięki temu użyt-kownik programu tar, który zdecydował się używać programu Lone-Tar ze względu na jego większe możliwości, nie musi od nowa przyswajać sobie całego zestawu poleceń. Jak jednak miałeś już okazję się przekonać, zestaw poleceń programu tar jest dość dziw-ny, niewygodny i trudny do opanowania. Aby przyzwyczaić się do składni programu tar, potrzeba dość sporo czasu, więc pro-gram Lone-Tar oferuje również o wiele wygodniejszy interfejs obsługiwany za pomocą menu. Wszystkie funkcje programu Lone-Tar dostępne są zarówno z wiersza poleceń, jak i z menu - działają one dokładnie tak samo. Jeśli jednak nie masz doświadczenia w używaniu programu tar, o wiele łatwiej będzie Ci posługiwać się systemem menu. Różnicę pomiędzy obydwoma interfejsami niech zobrazuje składnia polecenia lone-tar (bardzo zbliżona zresztą do składni polecenia tar):
lone-tar [MIcCrtTUxPZ] [bdefhklmnpvFEADVR] [tapefile] [block size] [compression limit] [0-9] [floppy/tape size] files ... Jeśli pomylisz się przy podawaniu któregoś z parametrów, zarówno tar jak i Lone-Tar wygenerują komunikaty o dostępnych opcjach i kodach błędów, przedstawione na ry-sunku 64.1. Można również wyświetlić te informacje wydając polecenie
lone-tar
Natomiast interfejs obsługiwany za pomocą menu, przedstawiony na rysunku 64.2, jest o wiele bardziej przyjazny i łatwiejszy w obsłudze. Każda z pozycji menu główne-go, dostępna po wciśnięciu odpowiedniego klawisza, prowadzi do menu podrzędnego. Wybór interfejsu zależy oczywiście tylko od Ciebie, ale jeśli nie jesteś przyzwyczajony do składni programu tar, powinieneś raczej zdecydować się na użycie systemu menu. Weterani systemów UNIX-owych mogą chcieć pozostać przy używaniu wiersza pole-ceń, ale system menu jest o wiele łatwiejszy w użyciu i pozwala uniknąć błędów typo-graficznych, dlatego w dalszej części tego rozdziału skupimy się głównie na interfejsie opartym na systemie menu.
Instalacja programu Lone-Tar
Proces instalowania programu Lone-Tar jest bardzo prosty. Należy zalogować się jako użytkownik root i przejść do katalogu /tmp. Następnie należy rozpakować wszystkie pliki z płyty CD-ROM lub dyskietki (jeśli posiadasz wersję programu Lone-Tar na dys-kietce) poleceniem tar. Jeśli na przykład pliki programu Lone-Tar znajdują się na dyskietce w pierwszej stacji dysków, należy wydać polecenia:
cd /tmp
tar xvf /dev/rfd0
Polecenie to spowoduje odtworzenie wszystkich plików zapisanych na dyskietce w pierwszej stacji dysków (/dev/rfd0) i zapisanie ich w katalogu bieżącym. W niektórych systemach pierwsza stacja dysków nie nazywa się /dev/ rfd0, ale /dev/fd0. Jeśli przy wydawaniu powyższego polecenia system wygeneruje komunikat Device unknown (nieznane urządzenie), należy zamiast wartości /dev/rfd0 podać /dev/fd0 i spróbować jeszcze raz. Jeśli instalujesz pliki z płyty CD-ROM, możesz skopiować odpowiednie pliki używając po prostu polecenia cp. Jeśli na przykład pliki programu Lone-Tar są zapisane w kata-logu /lone-tar, a płyta CD-ROM jest zamontowana w katalogu /cdrom, powinieneś wydać polecenia:
cd /tmp
cp /cdrom/lone-tar/ * .
Dokładna postać tego polecenia zależy od położenia plików programu Lone-Tar i punktu zamontowania płyty CD-ROM. Po skopiowaniu plików do katalogu /tmp, można rozpocząć właściwą instalację, wydając polecenie
./init.ltar
Program init.ltar, stworzony przez Lone Star Software, potrafi automatycznie za-instalować wszystkie składniki programu Lone-Tar. Podczas instalacji należy odpo-wiedzieć na zestaw pytań dotyczących nośnika, na którym zapisywane będą dane i je-go pojemności; będzie również możliwość wydrukowania instrukcji obsługi. Instrukcję można wydrukować w każdej chwili wybierając odpowiednie polecenie z menu pro-gramu Lone-Tar. Aby uruchomić menu programu Lone-Tar, należy wydać polecenie
ltmenu
Na ekranie wyświetlony zostanie komunikat, przedstawiony na rysunku 64.3. Wciśnię-cie klawisza Enter prowadzi do wyświetlenia menu przedstawionego na rysunku 64.2. Aby uruchomić program Lone-Tar w trybie obsługi z wiersza poleceń, należy wydać polecenie
lone-tar które spowoduje wyświetlenie informacji pomocniczych lub też podać po nim wszystkie wymagane opcje.
Tworzenie kopii zapasowych za pomocą programu Lone-Tar
Tworzenie kopii zapasowych jest integralną częścią pracy z systemem linuxowym, zarówno w przypadku, gdy jest on używany do poważnej pracy, jak i do zabawy. Powód jest prosty: ponowna instalacja i konfiguracja systemu i wszystkich programów tak, aby przywrócić pierwotny stan rzeczy, jest procesem bardzo długotrwałym i może w niektórych przypadkach prowadzić do błędów. Przywrócenie systemu plików z taśmy lub innego nośnika trwa natomiast tylko kilka minut - choć wymaga systematycznego wykonywania kopii. Jeśli w systemie zapisane są jakieś ważne informacje, regularne kopie zapasowe należy wykonywać również dlatego, że odtworzenie utraconych danych może często okazać się niemożliwe. Jeśli jesteś zmuszony do używania dyskietek jako nośnika kopii zapaso-wych, powinieneś z menu programu Lone-Tar wybrać opcję Floppy. Pro-wadzi ona do menu umożliwiającego tworzenie kopii na dyskietkach, za-miast na taśmach czy dyskach twardych. Program Lone-Tar pozwala na wykonywanie dwóch rodzajów kopii zapasowych: pełnych oraz przyrostowych. Kopia pełna zawiera dane o całym systemie plików - zapi-sany jest w niej każdy plik przechowywany w systemie. Kopie przyrostowe tworzy się pomiędzy kolejnymi wykonaniami kopii pełnych i zawierają one dane tylko o tych plikach, które zostały zmienione od czasu wykonania ostatniej kopii. Tworzenie kopii przyrostowej jest szybsze i nie wymaga tak dużo miejsca jak kopia pełna. System Linux orientuje się, które z plików zostały zmodyfikowane, na podstawie atrybutów pli-ku - dzięki temu tylko te pliki, które zostały utworzone lub zmodyfikowane od czasu utworzenia ostatniej kopii zapasowej, są włączane do kopii przyrostowej. W przypad-ku wystąpienia awarii należy najpierw przywrócić dane z kopii pełnej, a następnie ze wszystkich kolejnych kopii zapasowych wykonanych od czasu jej utworzenia. Jeśli na-tomiast potrzebne jest przywrócenie tylko kilku plików, często wystarczy wykorzysta-nie samej kopii przyrostowej. Częstość wykonywania kopii pełnych i przyrostowych zależy od wykorzystania sys-temu, ilości zmienianych codziennie danych i ich ważności. Dla przykładu, dla regular-nie wykorzystywanego systemu można co tydzień wykonywać kopię pełną na taśmie o dużej pojemności, natomiast kopie przyrostowe mogą być wykonywane każdej no-cy. Jeśli system nie jest wykorzystywany zbyt intensywnie, można na przykład tworzyć kopie pełne co miesiąc, a przyrostowe co tydzień, choć takie rozwiązanie nie jest raczej zalecane. W bardziej obciążonych systemach można zrezygnować z kopii przyrosto-wych i co noc wykonywać pełną kopię systemu plików. Jak się za chwilę przekonasz, jedną z zalet programu Lone-Tar jest możliwość automatyzacji tworzenia kopii zapasowych. Aby uruchomić tworzenie pełnej kopii zapasowej (nazywanej w programie Lone-Tar master backup), w menu głównym wciśnij klawisz M. Zostaniesz zapytany o to, czy nie chcesz pominąć któregoś z systemów plików (jak na rysunku 64.4). Domyślnie pro-gram Lone-Tar stworzy kopię zapasową wszystkich plików w systemie, ale możesz zdecydować, że któreś z katalogów nie powinny być kopiowane, na przykład katalog, w którym zamontowana jest płyta CD-ROM. Jeśli jest ona zamontowana w katalogu /cdrom, powinieneś poinformować program Lone-Tar o tym, że nie powinien wyko-nywać kopii tego katalogu (zresztą tworzenie kopii zapasowej płyty CD-ROM nie ma większego sensu). Można również nie wykonywać kopii zamontowanych dysków sie-ciowych. Następnie pojawi się monit o włożenie odpowiedniego nośnika, na przykład taśmy, po czym rozpoczyna się tworzenie kopii zapasowej. Mogą również zostać wyświetlone komunikaty o konieczności wymiany nośnika. Program Lone-Tar sprawdza, czy na-pęd taśmowy (lub inny) jest gotowy do pracy. Program Lone-Tar spodziewa się, że każdy nośnik, na którym wykonywana jest kopia zapasowa, będzie oznaczony za pomocą pliku zawierającego informacje, że jest to nośnik przeznaczony do pracy z programem Lone-Tar. Nie trzeba oznaczać kopii w ten sposób, ale dzięki temu program Lone-Tar ma ułatwione zadanie podczas odzyskiwania zapisanych plików. Komunikat o błędzie mówi, że program Lone-Tar stwierdził, że w napędzie nie ma taśmy lub też włożona została taśma, która nie została wcześniej oznaczona. Oznacze-nie taśmy nie jest konieczne - wciśnięcie klawisza Enter spowoduje rozpoczęcie pro-cesu kopiowania mimo jego braku. Jeśli jeden egzemplarz nośnika nie wystarcza dla wykonania kopii, program Lone-Tar poprosi o wymianę nośnika. Przed ponownym przystąpieniem do tworzenia kopii pro-gram czeka na wciśnięcie klawisza Enter. Po zakończeniu całego procesu ponownie wyświetlane jest menu główne. Podczas tworzenia kopii można również kompresować zapisywane pliki, dzięki czemu na jednym egzemplarzu nośnika można zapisać większą ilość danych. Musisz sam zdecydować, czy chcesz używać kompresji - odpowiednie dane można podać podczas instalacji. Zalet tego rozwiązana nie trzeba chyba nikomu tłumaczyć: większa ilość danych zajmuje mniej miejsca. Ma ono niestety również wady: wykonanie kopii zapa-sowej trwa dłużej, a skompresowane pliki mogą być odtworzone tylko za pomocą pro-gramu Lone-Tar. Nieskompresowana kopia zapasowa może natomiast być odczytana zarówno przez program Lone-Tar, jak i program tar, co jest bardzo ważne przy prze-noszeniu kopii zapasowych pomiędzy różnymi systemami. Czas potrzebny do utworzenia kopii zapasowej zależy od wielu czynników, głównie od wielkości systemu plików, prędkości urządzenia, do którego wysyłane są dane, oraz obciążenia systemu. Jeśli posiadasz szybki komputer oraz urządzenie pozwalające na zapis dużej ilości danych, program Lone-Tar potrafi wykonać kopię w o wiele krót-szym czasie, niż program tar. Prędkość jest ograniczana głównie przez prędkość sa-mych urządzeń, na których wykonywane są kopie. Dla przykładu napęd DAT oparty na interfejsie SCSI jest o wiele szybszy niż napęd QIC, wykorzystujący kasety z taśmą. Po wykonaniu kilku kopii przyzwyczaisz się do czasu, jakiego wymaga ten proces. Jeśli potrzeba na to naprawdę długiego czasu, warto uruchamiać tworzenie kopii zapaso-wych w nocy, w czasie gdy śpisz, czy też wtedy, gdy nie używasz systemu. Weź pod uwagę fakt, że wykonanie pełnej kopii systemu trwa zwykle od godziny do kilku go-dzin, zależnie od prędkości napędu. Upewnij się, że odpowiednio opisałeś nośnik, umieszczając na nim przy-najmniej informacje o dacie wykonania kopii i jej rodzaju. Informacje te powinny być jasne i czytelne, ponieważ nigdy nie wiadomo, kiedy będą musiały zostać odczytane. Proces wykonywania kopii przyrostowych przebiega prawie tak samo, jak tworzenie kopii pełnych. Ponieważ jednak kopie przyrostowe zwykle są o wiele mniejsze niż ko-pie pełne, ich wykonywanie trwa również o wiele krócej. Powinieneś przyzwyczaić się do tego, że kopie przyrostowe tworzy się codziennie i dodatkowo wtedy, gdy zapisujesz dane, na których utratę nie możesz sobie pozwolić. Lepiej spędzić 10 minut na wykonywaniu kopii zapasowej niż potem stracić kilka godzin na odtwarzanie ostatniego rozdziału swojej najnowszej książki. Wykonanie częściowej kopii systemu (ang. selective backup) jest możliwe po wciśnię-ciu w menu głównym klawisza S. Taka kopia zawiera tylko wybrane fragmenty syste-mu plików. Po wybraniu plików, które mają wchodzić w jej skład, proces tworzenia kopii przebiega w zwykły sposób.
Weryfikowanie plików
Opcja weryfikacji utworzonej kopii pozwala na dodatkowe podniesienie poziomu bez-pieczeństwa danych. Pozwala ona na odczytanie każdego zapisanego pliku i porów-nanie jego zawartości z plikiem oryginalnym. Dzięki temu można wychwycić wszystkie problemy z nośnikiem zanim jeszcze będzie za późno. Dobrym zwyczajem jest weryfikacja plików po wykonaniu każdej kopii zapasowej. Jest to szczególnie ważne po utworzeniu pełnej kopii systemu plików. Pamiętaj o tym, że niektóre pliki mogą zostać zmodyfikowane w czasie pomiędzy utworzeniem ich kopii a rozpoczęciem weryfikacji, w zależności od tego, czy system jest w tym czasie używany, czy nie. Również niektóre programy działające przez cały czas, na przykład obsługujące pocztę czy rejestrowanie informacji mogą zmieniać za-wartość niektórych plików w czasie wykonywania kopii i po zakończeniu tego procesu. Program Lone-Tar podczas weryfikacji stwierdza, że pliki te nie są takie same, jak za-pisane i zgłasza błędy. Powinieneś uważnie przejrzeć wygenerowany raport, dzięki czemu będziesz mógł zorientować się, które komunikaty są istotne, a które pojawiły się ze względu na nieprzerwane działanie systemu.
Przywracanie wcześniejszych wersji plików
Kiedy musisz przywrócić wcześniejszą wersję pliku, katalogu czy całego systemu pli-ków, musisz najpierw odszukać właściwą kopię zapasową. Jeśli stosowałeś zarówno kopie pełne, jak i przyrostowe, musisz odnaleźć ostatnią kopię pełną i wszystkie kopie przyrostowe wykonane od czasu jej utworzenia. Jeśli szukasz tylko wersji kilku usunię-tych przez przypadek plików, musisz wiedzieć, na której z taśm możesz je znaleźć. Aby uruchomić proces przywracania wcześniejszych wersji plików, z menu głównego programu Lone-Tar wybierz opcję R (ang. restore). Spowoduje to wyświetlenie menu, które zostało przedstawione na rysunku 64.7. Nazwy poszczególnych opcji nie pozo-stawiają wątpliwości co do ich znaczenia. Aby na przykład przywrócić wszystkie pliki zapisane na taśmie, należy wybrać opcję
Restore entire tape to hard disk.
Pozostałe opcje menu Restore pozwalają na przywrócenie wybranych katalogów i pli-ków, w oparciu o podane nazwy (możliwe jest również używanie symboli wieloznacznych). Można również utworzyć listę katalogów i przywrócić je wszystkie za jednym zamachem. Inną możliwością jest wybranie katalogów, których zawartości nie należy odtwarzać; wówczas przywrócona zostanie poprzednia wersja wszystkich pozostałych katalogów. Po określeniu, które pliki i katalogi mają zostać odtworzone, program Lone-Tar prosi o włożenie odpowiedniego nośnika do napędu, po czym rozpoczyna odtwarzanie. Po-dobnie jak podczas wykonywania kopii, również teraz na ekranie wyświetlane są in-formacje o poszczególnych odtwarzanych plikach. Podczas odtwarzania nawet pojedynczych plików czy katalogów, program Lone-Tar musi przeszukać całą taśmę, by je znaleźć, co może zabrać dłuższą chwilę, zależnie od prędkości urządzenia. Nie przejmuj się więc tym, że przez kilka minut nic się nie dzieje. Diody kontrolne urządzenia, w którym znajduje się nośnik, powinny sygnalizować, że jest ono używane. Jeśli do odtworzenia plików potrzeba więcej niż jednego egzemplarza nośnika, program Lone-Tar poprosi o jego wymianę - cykl taki będzie powtarzany aż do zakończenia odtwarzania. Jeśli chcesz przywrócić pliki zarówno z kopii pełnej, jak i późniejszych kopii przyrosto-wych, powinieneś powtórzyć cały proces dla każdej z kopii. Jeśli na przykład usunąłeś przez przypadek cały katalog, możesz przywrócić jego zawartość z ostatniej kopii peł-nej, a następnie odtworzyć wszystkie wprowadzone później modyfikacje powtarzając cały proces dla każdej z kopii przyrostowych. Poszczególne uaktualnienia trzeba prze-prowadzać ręcznie, za każdym razem korzystając z opcji dostępnych w menu Restore. Po zakończeniu odtwarzania plików, ponownie wyświetlana jest zawartość menu głównego. Należy sprawdzić, czy pliki trafiły na swoje miejsce i czy wszystko wygląda prawidłowo. Moduł Tape-Tell programu Lone-Tar potrafi dostarczyć kilku informacji o czasie ostatniego użycia taśmy. Działa on w oparciu o plik programu Lone-Tar, który może zostać zapisany na początku nośnika. Problem ten przedstawiliśmy w podrozdziale do-tyczącym wykonywania kopii zapasowych. Programy użytkowe i środowisko: dostosowywanie programu Lone-Tar do własnych potrzeb Menu Utilities (programy użytkowe) programu Lone-Tar, zawiera pewną liczbę przydatnych poleceń i funkcji. Większość opcji tego menu posiada nazwy nie pozostawiające wątpliwości co do ich przeznaczenia, ale dla zwykłych użytkowników przydat-nych jest tylko kilka z nich. Warto na przykład co jakiś czas sprawdzać datę wykona-nia ostatniej pełnej kopii zapasowej, co może przypomnieć o tym, że najwyższa pora wykonać nową kopię. Jeśli kopie zapasowe mają być wykonywane automatycznie, warto skorzystać z moż-liwości współpracy z programem cron. Program ten został przedstawiony w jednym z wcześniejszych rozdziałów - pozwala on na wykonywanie poleceń o określonych po-rach, bez konieczności fizycznego przebywania przy komputerze. Dzięki takiemu roz-wiązaniu można z łatwością zlecić wykonywanie kopii zapasowych na przykład każ-dej nocy, dwa razy w tygodniu czy w dowolnych innych porach. Nie trzeba przy tym znać szczegółów obsługi programu cron - program Lone-Tar sam zajmie się wprowa-dzeniem odpowiednich informacji do plików konfiguracyjnych. Menu Utilities pozwala również zmienić urządzenie, na którym zapisywane będą kopie zapasowe, oraz szczegóły konfiguracji, więc jeśli posiadasz więcej niż jedno urządzenie przeznaczone do tworzenia kopii zapasowych, możesz z łatwością przełączać się po-między nimi. Takie rozwiązanie jest szczególnie przydatne, jeśli do wykonywania peł-nych kopii systemu chcesz wykorzystywać inne urządzenie, niż do tworzenia kopii przyrostowych. Menu Environment (środowisko), przedstawione na rysunku 64.9, zawiera listę wszyst-kich ustawień konfigurujących działanie programu Lone-Tar. Wiele z tych wartości zo-stało ustalonych podczas instalacji tego programu, ale również tu można je w razie po-trzeby zmodyfikować.

Statystyka generowana przez Reggi-Stat - www.reggi.pl