PLD Linux Distribution

Transkrypt

PLD Linux Distribution
Podrecznik
˛
użytkownika, administratora i twórcy
PLD Linux Distribution: Podrecznik
˛
użytkownika, administratora i twórcy
Podr˛ecznik użytkownika, administratora systemu i twórcy PLD Linux Distribution Wydanie
Historia zmian
Zmiana $Rev: 9157 $
prawie beta
Spis treści
I. Informacje podstawowe...................................................................................................1
1. Wprowadzenie..........................................................................................................1
Streszczenie .........................................................................................................1
Konwencje użyte w tej ksia˛żce .........................................................................1
O tym podr˛eczniku.............................................................................................1
Krótka historia PLD............................................................................................2
Informacje o PLD ................................................................................................2
Oficjalne wersje PLD ..........................................................................................5
Model rozwoju PLD Linux Distribution .........................................................5
Projekty zwiazane
˛
z PLD...................................................................................7
2. Zasoby sieciowe PLD...............................................................................................9
Ważne adresy ......................................................................................................9
Źródła obrazów ISO ...........................................................................................9
Serwery z pakietami...........................................................................................9
3. Historia powstania naszego logo.........................................................................13
Wst˛ep..................................................................................................................13
Loga duże ..........................................................................................................13
Ikony do umieszczania na stronach WWW..................................................15
Ikony stworzone przez użytkowników ........................................................16
Galeria rysunków Karola Kreńskiego ...........................................................17
II. Instalacja..........................................................................................................................19
4. Instalacja systemu ..................................................................................................19
Wymagania........................................................................................................19
Przygotowanie ..................................................................................................19
Instalacja.............................................................................................................20
Po instalacji ........................................................................................................32
5. Instalacja przy użyciu chroota..............................................................................35
Wst˛ep..................................................................................................................35
Przygotowanie ..................................................................................................35
Instalacja.............................................................................................................37
Konta użytkowników ......................................................................................39
Operacje końcowe ............................................................................................40
6. Aktualizacje.............................................................................................................41
Aktualizacja z Ra do Ac...................................................................................41
III. Podr˛ecznik użytkownika............................................................................................43
7. Podstawy .................................................................................................................43
Wst˛ep..................................................................................................................43
Właczanie
˛
i wyłaczanie
˛
systemu ....................................................................43
Podstawowe operacje na plikach i katalogach.............................................43
Poruszanie si˛e w drzewie katalogów ............................................................44
Data i czas ..........................................................................................................45
Edycja plików konfiguracyjnych....................................................................46
Podstawowe narz˛edzia kontroli sieci TCP/IP .............................................46
Proxy...................................................................................................................48
8. Zasoby systemu ......................................................................................................49
Ilość miejsca na dysku......................................................................................49
Procesy i zasoby ................................................................................................49
Jak sprawdzić kto jest zalogowany oprócz nas? ..........................................51
IV. Podr˛ecznik administratora .........................................................................................53
9. Zarzadzanie
˛
pakietami..........................................................................................53
Informacje podstawowe ..................................................................................53
Cechy pakietów w PLD ...................................................................................54
Architektury pakietów.....................................................................................58
Źródła pakietów................................................................................................60
Budowanie pakietów .......................................................................................61
Poldek.................................................................................................................62
iii
RPM ....................................................................................................................66
Bezpieczeństwo.................................................................................................68
Zaawansowane operacje..................................................................................69
10. Bootloader .............................................................................................................73
Wst˛ep..................................................................................................................73
LILO....................................................................................................................75
GRUB..................................................................................................................77
rc-boot.................................................................................................................80
11. Kernel i urzadzenia..............................................................................................83
˛
Jadro
˛
systemu....................................................................................................83
Parametry jadra.................................................................................................85
˛
Moduły jadra
˛
.....................................................................................................85
Statyczne zarzadzanie
˛
modułami ..................................................................87
Udev - dynamiczna obsługa sprz˛etu .............................................................89
Initrd ...................................................................................................................91
Urzadzenia.........................................................................................................94
˛
12. Konfiguracja systemu ..........................................................................................97
Podstawowe ustawienia ..................................................................................97
Ustawienia konsoli ...........................................................................................98
Internacjonalizacja ............................................................................................99
Myszka pod konsola˛ ......................................................................................100
Strefa czasowa .................................................................................................102
Zegar.................................................................................................................103
Zmienne środowiskowe ................................................................................103
PLDconf - Narz˛edzie do konfiguracji systemu ..........................................104
Kluczowe pliki ................................................................................................105
13. Pami˛eci masowe .................................................................................................109
Wst˛ep................................................................................................................109
Nazewnictwo urzadze
˛
ń masowych.............................................................109
Podział na partycje .........................................................................................110
Systemy plików...............................................................................................112
Formatowanie .................................................................................................114
RAID programowy.........................................................................................114
LVM ..................................................................................................................120
Naprawa ..........................................................................................................122
14. Administracja......................................................................................................125
Ratowanie systemu ........................................................................................125
Zarzadzanie
˛
podsystemami i usługami ......................................................127
Zmiana poziomu pracy systemu..................................................................131
Konta użytkowników ....................................................................................132
Grupy ...............................................................................................................134
Zarzadzanie
˛
uprawnieniami.........................................................................135
Bezpieczeństwo...............................................................................................137
15. Interfejsy sieciowe ..............................................................................................139
Wst˛ep................................................................................................................139
Podstawowa konfiguracja sieci ....................................................................139
Ethernet ............................................................................................................141
WiFi...................................................................................................................142
Neostrada+ z modemem USB firmy Sagem ...............................................146
Neostrada+ z modemem USB firmy Alcatel - Thompson........................148
xDSL z interfejsem Ethernet..........................................................................151
Zaawansowane opcje interfejsów ................................................................152
16. Zastosowania sieciowe ......................................................................................155
Routing statyczny ...........................................................................................155
NAT...................................................................................................................156
Podział łacza
˛
w zależności od serwisów.....................................................157
PPP over SSH - Tunel IPv4 ............................................................................160
VTun - Tunel IPv4 ...........................................................................................163
Narz˛edzia sieciowe.........................................................................................167
17. Usługi dost˛epne w PLD ....................................................................................173
iv
Usługi - wst˛ep .................................................................................................173
ALSA - Dźwi˛ek w Linuksie...........................................................................173
Apache - Serwer stron internetowych .........................................................178
BIND - Serwer Nazw .....................................................................................186
CRON - Cykliczne wykonywanie zadań ....................................................193
CUPS - Popularny system druku dla Uniksa .............................................196
DHCPD - Dynamic Host Configuration Protocol Daemon......................201
Exim - Transport poczty elektronicznej (MTA) ..........................................203
Heimdal - Implementacja protokołu Kerberos...........................................216
Jabber 2 - Serwer typu Instant Messaging ..................................................221
MySQL - System Zarzadzania
˛
Relacyjnymi Bazami Danych (ang.
RDBMS) ..................................................................................................225
NFS - Network File System ...........................................................................230
PDNS (Power DNS) - Serwer Nazw ............................................................233
Postfix - Transport poczty elektronicznej (MTA) .......................................237
PostgreSQL - Baza danych SQL....................................................................244
ProFTPD - serwer FTP ...................................................................................247
Samba - współpraca z Windows ..................................................................250
Snort - Sieciowy System Wykrywania Włamań.........................................255
Syslog-ng..........................................................................................................265
18. X-Window ...........................................................................................................271
Wst˛ep................................................................................................................271
X-Server............................................................................................................271
Zaawansowane ...............................................................................................273
Środowisko GNOME .....................................................................................277
Środowisko KDE.............................................................................................279
Blackbox - Szybki i lekki zarzadca
˛
okien ....................................................280
Fluxbox - Nast˛epca BlackBoxa......................................................................281
Uruchamianie środowiska graficznego.......................................................282
Karty firmy nVidia..........................................................................................284
Karty firmy ATI...............................................................................................285
V. Tworzenie PLD - Praktyczny poradnik ...................................................................287
19. Możliwa droga do zostania szeregowym developerem PLD......................287
Co jest potrzebne ............................................................................................287
Źródła wiedzy .................................................................................................287
Przykład budowania ......................................................................................288
Pierwszy spec ..................................................................................................290
20. W krainie CVS - czyli wielki kocioł .................................................................299
Wst˛ep................................................................................................................299
Dodawanie plików do CVS PLD..................................................................301
Aktualizacja plików........................................................................................301
Zatwierdzanie zmian i Distfiles....................................................................301
Odnogi (Branche) i Etykiety (Tag)................................................................302
Zlecenia dla builderów ..................................................................................304
Zakończenie.....................................................................................................304
VI. O podr˛eczniku ..............................................................................................................??
21. O podr˛eczniku ....................................................................................................305
Autorzy dokumentacji PLD ..........................................................................305
22. Licencja i prawa autorskie ................................................................................307
Tłumaczenie Licencji GNU Wolnej Dokumentacji ....................................307
v
vi
Rozdział 1. Wprowadzenie
Streszczenie
Dzi˛ekujemy za zainteresowanie si˛e PLD Linux Distribution!
W tym rozdziale przedstawione zostana˛ różne aspekty dotyczace
˛ projektu PLD, takie
jak jego historia, cele, model rozwoju, itp.
Konwencje użyte w tej ksiażce
˛
Aby jak najlepiej zrozumieć i przyswoić informacje zawarte w tym podr˛eczniku, warto zapoznać si˛e wpierw z użytymi konwencjami.
$ komenda
W ten sposób opisywane sa˛ komendy, które wykonać możemy z uprawnieniami
użytkownika.
# komenda
Tutaj natomiast przedstawiona została komenda, która˛ należy wykonać z poziomu
użytkownika root, czyli administratora.
Zbyt długie linie zrzutów ekranowych, które nie mieszcza˛ si˛e w jednej linii, podzielone sa˛ przy pomocy znaku \. Czyli:
# komenda z_bardzo_\
długim_parametrem
należy zinterpretować jako:
# komenda z_bardzo_długim_parametrem
W dokumentacji dosyć cz˛esto korzysta si˛e z nast˛epujacej
˛ konstrukcji:
{$zmienna}
Tak oznaczane sa˛ miejsca, w których użytkownik może lub musi samodzielnie dokonać wyboru i wstawić w miejsce ciagu
˛ znaków {$zmienna} odpowiednia˛ wartość.
Niejdnokrotnie w nazwach plików pojawia si˛e znak "gwiazdki", który należy odczytywać podobnie jak robi to powłoka (shell), a wi˛ec zast˛epuje dowolny ciag
˛ znaków,
przykładowo:
/katalog/plik.*
oznacza wszytskie pliki zaczynjace
˛ si˛e od plik. w katalogu /katalog.
O tym podreczniku
˛
Celem tego podr˛ecznika jest pomoc w zainstalowaniu PLD Linux Distribution na
Twojej maszynie. Nie jest to i nigdy nie b˛edzie zamiennik dokumentacji systemowej.
1
Jeśli b˛edzie to Twoja pierwsza instalacja Linuksa, goraco
˛ zach˛ecamy Ci˛e do przeczytania wpierw tego podr˛ecznika. Nawet jeśli jesteś doświadczonym użytkownikiem,
warto przestudiować instrukcje dotyczace
˛ instalacji, aby upewnić si˛e, że wszystko
pójdzie gładko.
Oprócz niniejszej dokumentacji możemy szukać pomocy w wielu innych miejscach.
Pr˛eżnie działaja˛ listy dyskusyjne oraz oficjalne kanały IRC (#PLD i #PLDhelp). Na
cz˛esto zadawane pytania (FAQ) odpowiedzi można znaleźć na głównej stronie
WWW.
Jeśli uważasz, że dokumentacja jest niepełna, znalazłeś bł˛edy, lub chciałbyś
do nas dołaczyć
˛
prosimy o wysłanie informacji na list˛e dyskusyjna˛
<[email protected]> lub o kontakt z jednym z autorów dokumentacji,
których list˛e zamieszczono w sekcja Autorzy dokumentacji PLD w Rozdział 21
Krótka historia PLD
Wraz ze wzrostem zainteresowania Linuksem w Polsce, rosły naciski na stworzenie
polskiej dystrybucji tego systemu. Niemal wszyscy jej chcieli, a niektórzy nawet mówili, że już takowa˛ robia.˛ Nic jednak z tego nie wynikało. Wreszcie, w lipcu 1998,
zawiazał
˛
si˛e projekt majacy
˛ na celu stworzenie polskiej dystrybucji Linuxa. Projekt
PLD, czyli Polish(ed) Linux Distribution, był na tyle dobrze zorganizowany, by przetrwać trudne poczatki.
˛
Nie obeszło si˛e oczywiście bez burzliwych dyskusji na temat
kształtu dystrybucji, doboru oprogramowania jak również wersji jadra,
˛
na której projekt ma być rozwijany. W efekcie zdecydowano si˛e prowadzić równolegle dwa projekty. Pierwszy został nazwany PLD-devel i był forpoczta˛ dla obecnego PLD-stable.
Prace nad 1.1 PLD (devel) koordynowali przede wszystkim Wojtek Ślusarczyk, Marcin Korzonek i Arek Miśkiewicz. Miała to być pierwsza dystrybucja Linuxa zgodna z
nowym, promowanym przez OpenGroup, standardem - Unix98. Równolegle druga
grupa, na czele z Tomkiem Kłoczko i Arturem Frysiakiem, pracowała nad podwalinami właściwej PLD-stable.
Nieco później, przede wszystkim z braku wolnego czasu z prac nad projektem wycofali si˛e Wojtek Ślusarczyk, Andrzej Nakonieczny oraz Marcin Korzonek. Tomasz
Kłoczko postanowił kontynuować prace nad PLD, gromadzac
˛ wokół siebie coraz to
wi˛eksza˛ liczb˛e developerów. Pojawiła si˛e domena pld.org.pl, a wraz z nia˛ liczne adresy "funkcjonalne", takie jak ftp.pld.org.pl, www.pld.org.pl czy cvs.pld.org.pl. Ruch
na listach mailingowych stawał si˛e coraz wi˛ekszy, widać było, iż projekt zyskiwał na
popularności.
22 listopada 2002 roku światło dzienne ujrzała pierwsza stabilna wersja dystrybucji
PLD Linux Distribution 1.0 (Ra). Jeszcze w czasie jej stabilizacji rozpocz˛eły si˛e prace
nad kolejna˛ wersja.˛
Twórcy projektu zakładali uniwersalność PLD, która pozwalałaby na korzystanie z
dystrybucji przez użytkowników z całego świata, jednak pojawiły si˛e obawy, że nazwa Polish(ed) Linux Distribution odstraszy potencjalnych odbiorców z innych krajów. Postanowiono, że zmieniona zostanie nazwa projektu. Pozostawiono charakterystyczny skrót "PLD" w niezmienionej postaci, zmieniono zaś jego rozwini˛ecie nazwa "PLD" stała si˛e rekurencyjnym skrótem od PLD Linux Distribution.
Pierwszego kwietnia 2007 roku wydana została wersja Ac, długi okres rozwoju przyzwyczaił użytkowników do nieustajacych
˛
aktualizacji oprogramowania. Taki model
rozwoju dystrybucji okazał si˛e na tyle wygodny, że postanowiono by kolejne wydanie miały być rozwijane bez końca. Oznacza to, że na razie nie sa˛ planowane żadne
kolejne wydania, a do stabilnej gał˛ezi pakietów nieprzerwanie trafiaja˛ aktualizacje.
2
Informacje o PLD
Podstawowe informacje
PLD-Linux jest dystrybucja˛ rozwijana˛ głównie w Polsce. Jest to produkt grupy entuzjastów Linuksa chcacej
˛ stworzyć system operacyjny dopasowany do własnych
potrzeb. Aktualnie rozwojem dystrybucji interesuje si˛e około 200 osób, z pośród nich
najbardziej aktywna jest grupa 50 deweloperów.
PLD jest jednym z najaktywniejszych projektów Open Source na świecie. Dzi˛eki temu powstała jedna z najwi˛ekszych dystrybucji Linuksa, w trakcie prac nad druga˛
wersja˛ systemu (Ac) ilość dost˛epnych pakietów zbliżyła si˛e do trzynastu tysi˛ecy.
Założenia PLD
Jedna˛ z najwi˛ekszych bolaczek
˛
administratorów jest chroniczny brak czasu, dlatego
bardzo istotne jest zminimalizowanie nakładu pracy przy codziennych zaj˛eciach administracyjnych. Majac
˛ to na uwadze, stworzono dystrybucj˛e, która zapewnia wysokie bezpieczeństwo i łatwość administracji. PLD jest tak projektowane by w możliwie
najkrótszym czasie uruchomić bezpieczny, wydajny i łatwy w zarzadzaniu
˛
system
produkcyjny. Założono, że administrator nie może tracić czasu na kompilacj˛e jadra,
˛
programów czy też pisania rc-skryptów.
PLD jest uniwersalna˛ i elastyczna˛ dystrybucja,˛ dzi˛eki czemu sprawdzi si˛e w różnorodnych zastosowaniach. Przy jej tworzeniu, główny nacisk jest jednak kładziony na
niezawodne działanie usług. Utarło si˛e nawet powiedzenie, że PLD jest dystrybucja˛
tworzona˛ przez administratorów dla administratorów, mamy wi˛ec do czynienia z systemem dobrze przygotowanym do pracy w roli serwera.
Nie oznacza to bynajmniej, że PLD nie nadaje si˛e na system dla stacji roboczej, doskonale sprawdza si˛e również w tym zastosowaniu. Zwykły użytkownik nie znajdzie tu
wielu ułatwiajacych
˛
życie poczatkuj
˛
acym
˛
narz˛edzi, aby używać PLD konieczna jest
solidna porcja wiedzy. Mamy nadziej˛e, że niniejszy podr˛ecznik b˛edzie pomocny w
jej zdobyciu.
Poniżej przedstawiono zestawienie najciekawszych cech systemu.
System
•
w systemie dost˛epne sa˛ silnie zmodularyzowane jadra,
˛
dzi˛eki czemu w ogromnej wi˛ekszości wypadków nie trzeba go kompilować na nowo; wystarczy wybrać
właściwy kernel i załadować potrzebne moduły
•
w PLD zastosowano skrypty startowe (rc-skrypty) typu System-V, Pozwoliło to na
maksymalne zautomatyzowanie procesu instalacji usług systemowych.
•
podobna˛ koncepcja˛ do rc-inetd kierowano si˛e w tworzeniu pakietu rc-boot, pozwala on na łatwe zarzadzania
˛
bootloaderami
•
używanie FHS 2.x jako specyfikacji struktury katalogów
•
całkowite odejście od termcap i libtermcap (w PLD nie ma pakietu z libtermcap i
samego termcapa; ani jeden pakiet nie jest zwiazany
˛
z termcapem)
•
uporzadkowane
˛
rozmieszczenia plików w gał˛ezi /usr - żaden pakiet dystrybucyjny nie umieszcza plików w katalogach wewnatrz
˛ /usr/local
3
Bezpieczeństwo
•
domyślne jadro
˛
zawiera grsecurity
•
restrykcyjne uprawnienia dla użytkowników
•
przystosowanie do łatwego przejścia systemu na alternatywne metody autoryzacji (i -- w zależności od potrzeb -- szyfrowania) komunikacji po sieci, jak PAM, czy
GSAPI, TSL/SSL... Jest bardzo prawdopodobne, że już w niedługiej perspektywie
duża˛ rol˛e zacznie tu odgrywać SASL. W praktyce owo łatwe dostosowywanie do
np. kerberyzacji systemu jest realizowane także z użyciem rc-inetd, która to platforma ułatwia znakomicie podmian˛e różnych serwisów na wersje skerberyzowane czy też wykorzystujace
˛ inne mechanizmy jak np. socks5 (tutaj jeszcze jest mało
zrobione, ale furtka jest szeroko i jednoznacznie otwarta)
•
mechanizm sys-chroot ułatwiajacy
˛ zarzadzanie
˛
środowiskami typu chroot oraz
dobre wsparcie dla środowisk Linux VServer
Sieć
•
PLD posiada najlepsza˛ obsług˛e przyszłościowego protokołu IPv6 z pośród innych
dystrybucji Linuksa.
•
używanie iproute2 jako podstawowego narz˛edzia do operowania na interfejsach
sieciowych, dzi˛eki czemu np. skrypty startowe z PLD sa˛ prostsze i krótsze mimo
wi˛ekszej funkcjonalności w stosunku do swoich odpowiedników z RH; inna˛ zaleta˛ jest wsteczna kompatybilność z opisem interfejsów sieciowych z tym, co jest
stosowane w initscripts z RH; kolejna˛ cecha˛ skryptów startowych jest to, że -- w
zależności od preferencji użytkownika -- moga˛ one wyświetlać wszystkie komunikaty po polsku
•
PLD zawiera rc-inetd - interfejs do zarzadzania
˛
usługami typu inetd. Pozwala zarzadzać
˛
takimi usługami (np.: telnetd, cvs-pserver) bez znaczenia jakiego typu demon inetd jest używany
Pakiety
4
•
PLD zawiera ogromne ilości gotowych, binarnych pakietów; pozwala to uniknać
˛
instalacji oprogramowania spoza dystrybucji
•
w dystrybucji używane sa˛ pakiety typu RPM, do zarzadzania
˛
nimi stworzono program o swojsko brzmiacej
˛ nazwie Poldek, można też używać klasycznego programu RPM
•
możliwość samodzielnego budowania pakietów RPM pozwoli na łatwe skompilowanie pakietu z nietypowa˛ funkcjonalnościa˛
•
znaczna liczba programów podzielona jest na mniejsze pakiety, pozwalajace
˛ instalować tylko te elementy systemu, które sa˛ akurat potrzebne
•
pakiety cz˛esto sa˛ wst˛epnie skonfigurowane i gotowe do działania, ponadto nakładane sa˛ na nie istotne łaty
•
w PLD nie sa˛ faworyzowane żadne z usług czy programów. To czego używamy
zależy tylko od nas
•
pełne przygotowanie pakietów do automatycznego uaktualnienia. Pakiety z RH
kompletnie nie sa˛ na to przygotowane. Przygotowanie to wia˛że si˛e z restartowaniem serwisów przy ich uaktualnieniu, odpowiednim przygotowywaniem procedur uaktualnienia w taki sposób, by umożliwić automatyczna˛ aktualizacj˛e nawet
przy zmianie plików konfiguracyjnych
•
kompresowanie wszystkich plików dokumentacji z użyciem gzip (bzip2 nic w
praktyce tu nie wnosi, a dostarcza tylko nowych kłopotów, czego doświadczaja˛
od czasu do czasu użytkownicy Mandrake)
•
separacja bibliotek statycznych w osobne podpakiety {$nazwa}-static (nie każdy tego potrzebuje), a nagłówków do {$nazwa}-devel
•
uzupełnianie opisów pakietów i dokumentacji w różnych j˛ezykach. W dużej cz˛eści robi si˛e to niejako przy okazji. Użytkownik może sobie skonfigurować i zainstalować wybrane oprogramowanie ze wsparciem dla preferowanego zestawu
j˛ezyków, np.: angielski i niemiecki czy też angielski i polski (zasoby dla innych j˛ezyków zostana˛ pomini˛ete). Tak unikalna˛ możliwość konfiguracji osiagamy
˛
dzi˛eki
konsekwentnemu oznaczaniu zasobów narodowych makrem %lang() w poszczególnych pakietach
Cechy użytkowe
•
PLD jest systemem przyjaznym dla programisty. Dost˛epne sa˛ narz˛edzia do tworzenia aplikacji w wielu j˛ezykach programowania. Dotyczy wielu "standardowych"
j˛ezyków programowania takich jak C, C++, Perl czy Python. Dost˛epne sa˛ też kompilatory do nieco mniej znanych j˛ezyków takich jak SML, Prolog, OCaml jak też
eksperymentalne kompilatory: Cyclone, Ksi. Dodatkowo mamy wybór wielu narz˛edzi programistycznych i bibliotek.
•
maksymalna automatyzacja różnych powtarzalnych czynności (dotyczy to zarówno metodologii bieżacej
˛ pracy jak i zawartości pakietów)
•
dystrybucja jest przystosowana do obsługi wielu j˛ezyków narodowych, a w tym
j˛ezyka polskiego. Jest to najlepiej przygotowana dystrybucja na potrzeby polskich
użytkowników
•
brak nałożonych z góry ograniczeń co do zestawu pakietów, jakie moga˛ być w
dystrybucji. W praktyce oznacza to, że użytkownik ma do dyspozycji wszystko,
co udało si˛e nam zebrać, Jeżeli coś zostanie opracowane i przystosowane do tego,
żeby mogło współgrać z reszta˛ pakietów, to znaczy, że komuś było potrzebne, wi˛ec
może komuś przydać si˛e w przyszłości
Oficjalne wersje PLD
W PLD wersjom dystrybucji1 nadawane numery oraz dwuliterowe oznaczenia kodowe, które pochodza˛ od skrótowych oznaczeń pierwiastków. Pierwszej wersji PLD
nadano oznaczenie Ra (Rad), zaś kolejne odpowiadaja˛ nazwom pierwiastków poukładanych zgodnie z kolejnościa˛ określona˛ przez ich liczb˛e atomowa.˛ Aktualnie
mmy trzy oficjalne wydania: Ra, Ac, Th, jest też nieoficjalny fork Titanium2 prowadzony przez jednego z deweloperów.
5
Model rozwoju PLD Linux Distribution
Rozwój PLD Linux Distribution przebiega w sposób otwarty i elastyczny. Efekt końcowy to wynik nakładu wielu osób, nie tylko developerów posiadajacych
˛
prawo zapisu do repozytorium CVS (o którym poniżej), ale także użytkowników zgłaszaja˛
cych informacje o bł˛edach lub nadsyłajacych
˛
poprawki lub propozycje zmian. Z ch˛ecia˛ przyjmiemy nowych developerów, a osoby chcace
˛ być bardziej zwiazane
˛
z projektem powinny zapisać si˛e na list˛e dyskusyjna˛ developerów [email protected].
Informacje o PLD i sposobie jego rozwoju:
•
Repozytorium CVS
Źródła PLD Linux Distribution trzymane sa˛ w repozytorium CVS (Concurrent Versions System, http://www.cyclic.com/CVS/index.html), wolnodost˛epnym systemie kontroli wersji dostarczanym wraz z nasza˛ dystrybucja.˛ Serwer CVS PLD Linux Distribution (http://cvs.pld-linux.org/) jest dost˛epny dla wszystkich w trybie
tylko dla odczytu (Read Only), oraz dodatkowo w trybie do odczytu/zapisu (Read/Write) dla developerów. Repozytorium zostało podzielone na kilka modułów
w celu ułatwienia pracy osobom doń commitujacym
˛
(określenie commit pochodzi
z podr˛ecznika systemowego cvs).
•
Serwer DistFiles
W zamierzchłych czasach wszystkie pliki (a wi˛ec kody źródłowe, łatki (patche),
poprawki, itp) potrzebne do zbudowania pakietów trzymane były w repozytorium. Niestety CVS nie został zaprojektowany do przechowywania plików binarnych (a archiwum tar.gz takim jest) i próba zmuszenia go do przechowywania takowych dostarczała różnych problemów. A to osoba posiadajace
˛ stosunkowo wolne łacze
˛
zacz˛eła wrzucać kilkudziesi˛ecio megabajtowy plik, skutecznie blokujac
˛
możliwość pracy innym developerom na kilka godzin. Ucia˛żliwe były też pozostajace
˛ tzw. ’locki’, czyli blokady na modułach repozytorium (przede wszystkim
SOURCES/). Rozwiazaniem
˛
tych problemów było wprowadzenie w maju 2003 roku serwera DistFiles, do którego przeniesiono wi˛ekszość plików binarnych z CVS.
•
Core Developers Group
Gdyby PLD Linux Distribution było firma,˛ Core Developers Group najtrafniej
można by określić jako Rad˛e Nadzorcza.˛ Jej celem jest podejmowanie w sposób
demokratyczny krytycznych dla dystrybucji decyzji oraz rozwiazywanie
˛
konfliktów, których nie dało si˛e zażegnać w inny sposób. W skład Grupy
wchodza˛ developerzy aktywnie udzielajacy
˛ si˛e w projekcie.
•
Lista dyskusyjna [email protected]
Na liście tej prowadzone sa˛ dyskusje na temat bieżacych
˛
prac nad dystrybucja,˛
jak również ustalane sa˛ plany na przyszłość. Jeśli nie posiadasz prawa zapisu do
repozytorium, a chciałbyś podzielić si˛e efektami swych prac z innymi, lista ta jest
najlepszym miejscem na poinformowanie o tym fakcie.
•
Buildery
Mianem builderów określane sa˛ specjalnie przygotowane środowiska (cz˛esto na
dedykowanych maszynach), na których budowane sa˛ pakiety, które później zostana˛ umieszczone na serwerach FTP projektu. Każda z linii dystrybucji ma swoje
oddzielne buildery, stworzone z pakietów dla niej przeznaczonych.
6
Nie wszyscy developerzy maja˛ prawo do puszczania zleceń na buildery, czyli rozkazów zbudowania poszczególnych pakietów - przywiliej ten ma ledwie garstka
osób, zaznajomionych z automatyka˛ oraz znajacych
˛
potrzeby danej dystrybucji.
Rzadko kiedy zachodzi potrzeba bezpośredniego grzebania w strukturze danego
środowiska - codzienna praca opiera si˛e na wysyłaniu odpowiednio przygotowanych maili, podpisanych kluczem PGP osoby uprawnionej.
Projekty zwiazane
˛
z PLD
•
Rescue CD
Jest to niewielka dystrybucja startujaca
˛ z płyty CD, bez konieczności instalacji
na twardym dysku. Zawiera zestaw wyspecjalizowanych narz˛edzi pomocnych w
przypadku usuwania awarii systemu. Rescue CD oparto o jadro
˛
PLD i wyposażono w zestaw najbardziej niezb˛ednych programów, dzi˛eki czemu udało si˛e uzyskać
niewielkie rozmiary dystrybucji. Pozwala to załadowanie całości do pami˛eci operacyjnej, a nast˛epnie a wyj˛ecie płyty CD z czytnika. Lista dost˛epnych programów
jest umieszczona na domowej stronie WWW projektu.
•
PLD Live CD http://livecd.pl/3
Pierwszy, oparty o PLD Ac projekt, majacy
˛ na celu stworzenie kompletnej dystrybucji Linuksa startujacej
˛ z płyty CD, zawiera znaczna˛ ilość narz˛edzi i programów
użytkowych. PLD Live jest przygotowane dla zwykłych użytkowników chcacych
˛
bliżej poznać PLD, zawiera system X Window i liczne programy użytkowe. Z założenia w PLD Live dokonywano jak najmniej zmian w stosunku do bazowej dystrybucji.
•
PLD Live.th http://livecd.pld-linux.org
Wersja Live zbudowana na bazie Th i środowiska GNOME
•
PLD-Linux LiveCD http://kde4.livecd.pld-linux.org/index.php
Wersja Live zbudowana na bazie Titanium i środowiska KDE
Przypisy
1. http://pld-linux.org/About
2. http://pld-linux.org/Titanium
3. http://livecd.pl
4. http://livecd.pld-linux.org
5. http://kde4.livecd.pld-linux.org/index.php
7
8
Rozdział 2. Zasoby sieciowe PLD
Ważne adresy
•
Strona główna - http://pld-linux.org1
•
Dokumentacja - http://pl.docs.pld-linux.org
•
Listy dyskusyjne - http://lists.pld-linux.org3
•
Cz˛eściowe archiwa list dyskusyjnych - mail-archive.com4, Gmane5
•
Serwer IRC (freenode) http://irc.freenode.net
Serwer IRC (IRCnet) http://ircnet.org
Serwer PLDNet: irc.pld-linux.org
Istniejace
˛ kanały:
•
#pld - kanał przeznaczony dla Developerów.
•
#pldhelp - kanał użytkowników PLD
•
#pldlivecd - kanał użytkowników LiveCD
Kanały w powyższych sieciach sa˛ połaczone
˛
za pomoca˛ specjalnego bota. Przydatny w takich przypadkach może być skrypt do programu irssi znajdujacy
˛ si˛e
na stronie http://vorlon.icpnet.pl/~agaran/forwardfix.pl lub w zasobach poldka (poldek -i irssi-script-forwardfix), który ma zadanie przekazywać wiadomości
mi˛edzy sieciami.
•
System zgłaszania bł˛edów - http://bugs.pld-linux.org9
•
Rescue CD - http://rescuecd.pld-linux.org10
•
PLD Live CD - http://livecd.pld-linux.org11
Źródła obrazów ISO
Obrazy ISO sa˛ katalogowane wg. schematu {$serwer}/{$wersja}/{$arch} np.:
ftp.iso.pld-linux.org/2.0/i586. Wersje systemu szerzej opisano w sekcja Oficjalne wersje PLD w Rozdział 1, zaś architektury w sekcja Architektury pakietów w Rozdział 9.
Dla każdego z obrazów ISO dost˛epna jest suma MD5, umieszczona w pliku o rozszerzeniu md5. Dzi˛eki niej b˛edziemy mogli sprawdzić przed nagraniem czy pobrany
obraz nie zawiera żadnych zmian. Do obliczenia skrótów MD5 w pod systemami
uniksowymi posłużymy si˛e programem md5sum, zaś w systemach Microsoftu użyjemy dost˛epnego na serwerze programu md5sum.exe.
Serwery FTP z obrazami ISO:
•
TASK, Gdańsk, Polska - ftp://ftp.iso.pld-linux.org
9
Serwery z pakietami
Pakiety sa˛ katalogowane wg. schematu {$serwer}/dists/{$wersja}/{$źródło}/{$arch}
np.: ftp.pld-linux.org/dists/2.0/PLD/i586/. Wersje systemu szerzej opisano
w sekcja Oficjalne wersje PLD w Rozdział 1, źródła w sekcja Źródła pakietów w
Rozdział 9, zaś architektury w sekcja Architektury pakietów w Rozdział 9.
PLD możemy zainstalować z sieci za pomoca˛ protokołu FTP, HTTP lub RSYNC. Pakiety możemy pobierać z głównego serwera PLD lub z jednego z wielu lustrzanych.
FTP - serwer podstawowy
•
FUH KERNEL, VNET.sk, Bratysława, Słowacja - ftp://ftp.pld-linux.org/ ,
ftp://ftp.sk.pld-linux.org/ ,
FTP - serwery lustrzane
•
Gdańsk, Polska - ftp://ftp2.pld-linux.org/
•
Uniwersytet Kardynała Stefana Wyszyńskiego, Polska - ftp://ftp3.pld-linux.org/
, ftp://ftp.csi.pld-linux.org/17
•
ATM
S.A.,
Warszawa,
ftp://ftp.atm.pld-linux.org/
•
Uniwersytet Warszawski, Wydział Prawa i Administracji, Polska - ftp://ftp5.pldlinux.org/ , ftp://ftp.wpia.pld-linux.org/
•
TASK, Gdańsk, Polska - ftp://ftp6.pld-linux.org/ , ftp://ftp.task.pld-linux.org/
•
Politechnika Wrocławska, Polska - ftp://ftp.pwr.wroc.pl/pld/
•
ICM, Polska - ftp://ftp.icm.edu.pl/pub/linux/distributions/pld-linux/
•
Bratysława, Słowacja - ftp://spirit.bentel.sk/mirrors/PLD
Polska
-
ftp://ftp4.pld-linux.org/
,
HTTP - serwer podstawowy
•
FUH KERNEL, VNET.sk, Bratysława, Słowacja - http://ftp.pld-linux.org/
HTTP - serwery lustrzane
•
Gdańsk, Polska - http://ftp2.pld-linux.org/
•
ATM S.A., Warszawa, Polska - http://ftp4.pld-linux.org/
•
TASK, Gdańsk, Polska - http://ftp.task.pld-linux.org/
•
Bratysława, Słowacja - http://spirit.bentel.sk/PLD/
RSYNC
Osoby zainteresowane udost˛epnianiem serwera lustrzanego przy pomocy protokołu
RSYNC proszone sa˛ o kontakt z nami w celu uzyskania szczegółowych informacji:
<[email protected]>
10
Przypisy
1. http://pld-linux.org/
2. http://pl.docs.pld-linux.org
3. http://lists.pld-linux.org/
4. http://www.mail-archive.com/?hunt=pld
5. http://dir.gmane.org/search.php?match=pld
6. http://irc.freenode.net
7. http://ircnet.org
8. http://vorlon.icpnet.pl/~agaran/forwardfix.pl
9. http://bugs.pld-linux.org/
10. http://rescuecd.pld-linux.org/
11. http://livecd.pld-linux.org/
12. ftp://ftp.iso.pld-linux.org
13. ftp://ftp.pld-linux.org/
14. ftp://ftp.sk.pld-linux.org/
15. ftp://ftp2.pld-linux.org/
17. ftp://ftp.csi.pld-linux.org/
19. ftp://ftp.atm.pld-linux.org/
21. ftp://ftp.wpia.pld-linux.org/
23. ftp://ftp.task.pld-linux.org/
24. ftp://ftp.pwr.wroc.pl/pld/
25. ftp://ftp.icm.edu.pl/pub/linux/distributions/pld-linux/
26. ftp://spirit.bentel.sk/mirrors/PLD
27. http://ftp.pld-linux.org/
28. http://ftp2.pld-linux.org/
29. http://ftp4.pld-linux.org/
30. http://ftp.task.pld-linux.org/
31. http://spirit.bentel.sk/PLD/
11
12
Rozdział 3. Historia powstania naszego logo
Wstep
˛
Pomysł na nasze logo zrodził si˛e w głowie Agnieszki Sloty. Projekt graficzny został
stworzony przez Marcina Mierzejewskiego (Kevin) i Maćka Zielińskiego.
Loga duże
• Może być używane tylko wtedy, gdy:
—produkt z logiem jest używany zgodnie z udokumentowanymi na www.pldlinux.org1 zasadami (na przykład oficjalne płyty CD)
—uzyskaja˛ aprobat˛e PLD Linuksa do używania loga w określonych celach
• Cz˛eść całkowitego produktu uznana jest oficjalnie za należac
˛ a˛ do PLD (tak jak jest
to opisane w punkcie pierwszym) i jeśli posiada wyraźnie zaznaczone informacje,
że tylko ta cześć została zatwierdzona
• Zastrzegamy sobie prawo do unieważnienia i modyfikacji licencji dla danego produktu
Pozwolenie na używanie oficjalnego loga zostało przyznane dla wszelkiego typu
odzieży (t-shirty, czapki, itd) ale pod warunkiem, że sa˛ one wykonywane przez developerów PLD i nie sa˛ sprzedawane dla zysku.
Wyjaśnienie: Licencja "zapożyczona" z Debiana.
13
Rysunek 3-1. Logo główne
14
Rysunek 3-2. Logo główne z cieniowaniem
Ikony do umieszczania na stronach WWW
Powered by PLD Linux
To logo i jego zmodyfikowane wersje moga˛ być zamieszczane dla podkreślenia poparcia dla projektu, lecz nie oznacza ono, że dany produkt jest cz˛eścia˛ projektu.
Przypomnienie: docenimy jeśli dodasz do obrazka link wskazujacy
˛ na www.pldlinux.org2 i umieścisz go na swojej stronie.
Rysunek 3-3. Ikona na www 1
15
Ikony stworzone przez użytkowników
To logo i jego zmodyfikowane wersje moga˛ być zamieszczane dla podkreślenia poparcia dla projektu, lecz nie oznacza ono, że dany produkt jest cz˛eścia˛ projektu.
Przypomnienie: docenimy jeśli dodasz do obrazka
www.pld-linux.org3 i umieścisz go na swojej stronie.
Rysunek 3-9. Ikona stworzona przez "muche"
16
link
wskazujacy
˛
na
Rysunek 3-10. Ikona stworzona przez Łukasza "Baseciq" Mozera
Galeria rysunków Karola Kreńskiego
Pod tym adresem http://www.inf.sgsp.edu.pl/pub/MALUNKI/PLD/4 Karol
Kreński "Mimooh" umieścił spora˛ galeri˛e obrazków zwiazanych
˛
z PLD Linux
Distribution
Przypisy
1. http://www.pld-linux.org
4. http://www.inf.sgsp.edu.pl/pub/MALUNKI/PLD/
17
18
Rozdział 4. Instalacja systemu
Ten rozdział prezentuje instalacj˛e systemu.
Wymagania
Minimalne wymagania w przypadku architektury x86:
•
procesor minimum klasy 386
•
16 MB pami˛eci RAM (ze swapem przynajmniej 32MB)
•
50MB wolnego miejsca na dysku twardym
•
nap˛ed CD-ROM lub stacja dyskietek 3,5 cala
Przygotowanie
Instalator
Nośniki na których umieszczany jest instalator:
•
Główna płyta CD (base iso)
Jest to pierwsza z pełnych płyt CD, wystarcza do zainstalowania najważniejszych
pakietów, aby zainstalować całość dystrybucji musisz zaopatrzyć si˛e w pozostałe płyty. Lista serwerów z których pobierzemy obrazy ISO znajduje si˛e w sekcja
Źródła obrazów ISO w Rozdział 2.
•
Płyta MINI-ISO
Miniaturowa wersja dystrybucji przystosowana do nagrania płyty typu MINI-CD
(płyty o średnicy 8cm). Zawiera najbardziej podstawowe pakiety. Lista serwerów
z których pobierzemy obraz MINI-ISO znajduje si˛e w sekcja Źródła obrazów ISO w
Rozdział 2.
•
Dyskietki
Mamy do dyspozycji kilka dyskietek zawierajacych
˛
instalator lub dodatkowe moduły jadra.
˛
Oprócz nich konieczne b˛edzie jeszcze jakieś źródło pakietów (sieć/CDROM/dysk twardy).
Główne
obrazy
dyskietek
(bootdisk_cd.img,
bootdisk_net.img,
bootdisk_pcmcia.img) obsługuja˛ jedynie najpowszechniej używany sprz˛et, jeśli
nasz nie jest obsługiwany, to instalator poprosi o jedna˛ z dodatkowych dyskietek
z modułami jadra.
˛
Z tego wzgl˛edu na wszelki wypadek można pobrać pliki o
nazwie addons{$numer}.img
Obraz dyskietki i reszt˛e pakietów możemy pobrać z głównego serwera
lub jednego z serwerów lustrzanych, list˛e adresów znajdziemy w
sekcja Serwery z pakietami w Rozdział 2. Przykładowo użyjemy adresu:
ftp.pld-linux.org/dists/{$wersja_PLD}/PLD/{$arch}/PLD/images/ ({$wersja_PLD} to
interesujaca
˛ nas wersja PLD zaś {$arch} oznacza architektur˛e procesora). Dost˛epne
sa˛ obrazy dyskietek dla nast˛epujacych
˛
architektur: i386, i586, i686 oraz athlon.
19
Instalacja z sieci
Jeżeli masz wystarczajaco
˛ szybkie łacze
˛
możesz zainstalować system z sieci. W tym
procesie mamy do wyboru instalacj˛e pakietów przy pomocy protokołów: FTP, HTTP
lub NFS.
Możemy użyć MINI-ISO, pierwszej płyty instalacyjnej lub dyskietki. W przypadku dyskietki musimy użyć obrazu bootdisk_net.img lub bootdisk_pcmcia.img
(urzadzenia
˛
sieciowe PCMCIA).
Możemy też zainstalować rdzeń systemu z MINI-ISO lub pierwszej płyty instalacyjnej, a nast˛epnie kontynuować proces instalacji za pośrednictwem sieci z działajacego
˛
już systemu.
Instalacja z płyty CD-ROM
Używamy w tym celu pierwszej z pełnych płyt CD (base) lub wszystkich dost˛epnych
obrazów.
Jeśli BIOS naszej maszyny nie potrafi uruchamiać systemu operacyjnego z płyty CD,
musimy wspomóc si˛e dyskietka˛ i obrazem bootdisk_cd.img. Po uruchomieniu instalatora z dyskietki jako źródło pakietów wybieramy CD-ROM.
Instalacja z dysku twardego
Istnieje możliwość instalacji z lokalnego dysku twardego, użyjemy do tego obrazu
dyskietki bootdisk_cd.img. Musimy jeszcze przegrać zawartość obrazu płyty CD
do katalogu na jednej z partycji dyskowych.
Dodatkowe informacje
Pobrane z internetu obrazy dyskietki nagrywamy poleceniem
# dd if=bootdisk.img of=/dev/fd0
lub
przy
pomocy
programu
rawrite.exe
pod
systemem
Windows/DOS.
Program
rawrite.exe
możemy
pobrac
przykładowo
z
ftp.pld-linux.org/dists/{$wersja_PLD}/PLD/{$arch}/PLD/dosutils/.
PLD jest przygotowane dla wielu architektur sprz˛etowych, zanim wi˛ec przystapisz
˛
do instalacji upewnij si˛e że wybierzesz właściwa˛ wersj˛e. Wi˛ecej na ten temat można
znaleźć w sekcja Architektury pakietów w Rozdział 9
Instalacja
Wstep
˛
Jeżeli pierwszy raz instalujesz Linuksa, lub jesteś bardzo poczatkuj
˛
acym
˛
użytkownikiem warto abyś wiedział kilka rzeczy. Na poczatek
˛
zapoznaj si˛e ze sposobem
oznaczania dysków i partycji opisanych dokładniej w sekcja Nazewnictwo urzadze
˛ ń
masowych w Rozdział 13
Kiedy już zaopatrzymy si˛e we właściwy nośnik, uruchamiamy komputer i czekamy
na pojawienie si˛e ekranu instalatora. Zaczniemy od poznania sposobu poruszania si˛e
po instalatorze, do przesuwania/przewijania tekstu badź
˛ opcji używasz "strzałek" na
klawiaturze, wybór akceptujesz klawiszem ENTER. Klawiszem TAB poruszasz si˛e
pomi˛edzy opcjami instalatora.
20
Zaczynamy
Widzac
˛ standardowy ekran zgłoszeniowy naciskamy ENTER i czekamy aż uruchomi si˛e instalator. Wybieramy j˛ezyk - w naszym przypadku polski. Przeczytawszy
krótkie wprowadzenie jesteśmy w instalatorze.
Rysunek 4-1. Jesteśmy w instalatorze
Teraz pojawiło nam si˛e menu, w którym mamy do wyboru sposoby instalacji. Jeżeli
posiadasz wi˛eksza˛ niż podstawowa˛ wiedz˛e nt. linuksa możesz wybrać "Standartowe
UI", gdzie wi˛ekszość opcji umieszczona jest na jednym przejrzystym ekranie. Także kolejne opcje pozwola˛ ustawić partycje, wybrać pakiety, prekonfigurować system
oraz ustawić bootmanagera. Do edycji partycji mamy do wyboru program fdisk lub
parted.
My wybieramy jednak opcj˛e "Automagiczny Instalator", który sam przeprowadzi
nas gładko przez proces instalacji.
Źródło
Instalacja z sieci
Doszliśmy do momentu gdzie musimy ustawić parametry źródła, skad
˛ b˛edzie instalował si˛e system. Jeżeli korzystamy z bootkietek musimy dobrać odpowiednia˛ w
stosunku do źródła z którego b˛edziemy pobierali pakiety.
21
Rysunek 4-2. Wybór źródła
Powyżej widzimy ekran wyboru źródła ,ja wybrałem instalacj˛e z sieci, jednak instalacja z płyty cd, dysku twardego czy nfs-u nie b˛edzie znaczaco
˛ si˛e różniła.
Rysunek 4-3. Instalujemy z ftp
Nast˛epnie wybieram serwer ftp/http z którego chc˛e instalować system, oraz ścieżk˛e
do źródeł. Jeżeli masz w pobliżu jakiś mirror pld możesz skorzystać z niego, zamiast
oficjalnego serwera.
Kolejne dwa ekrany to konfiguracja karty oraz połaczenia
˛
sieciowego. Wybrane parametry zależa˛ od posiadanego sprz˛etu i topologii sieci, wiec nie ma co nad tym si˛e
rozwodzić.
Instalacja z cdromu
Jeżeli instalujesz system z płytek musisz zaopatrzyć si˛e albo w miniiso, albo przynajmniej w pierwsza˛ (base) płytk˛e.
22
Rysunek 4-4. Źródło - cdrom
W menu wyboru źródła wybieramy cdrom. Nie jest ważne czy instalujemy cały system z płytek, czy tylko miniiso.
Rysunek 4-5. Wybór urzadzenia
˛
Teraz możemy wybrać urzadzenie,
˛
które służy w naszym systemie jako cdrom. System powinien znaleźć i zaznaczyć istniejacy
˛ w systemie nap˛ed, jednak jeżeli mamy
wi˛ecej niż jeden to tutaj należy zaznaczyć w którym znajduje si˛e płytka instalacyjna.
Możesz także ustawić katalog w którym znajduja˛ si˛e pakiety, jednak jeżeli używasz
oficjalnych płytek nie należy nic tutaj zmieniać.
Możesz teraz przejść do kolejnego kroku, czyli ustawień partycji.
Partycje
Nadszedł czas na konfigurowanie partycji. Możemy wybrać proponowane przez instalator ustawienia albo skorzystać z bardzo przyjemnego narz˛edzia o nazwie par23
ted. Jako, że na dysku możemy mieć inny system (Windows) lepiej dla bezpieczeństwa ustawić partycje r˛ecznie.
Rysunek 4-6. Ustawianie partycji
Wybierajac
˛ opcj˛e "ustaw partycje r˛ecznie" przechodzimy do parted
Rysunek 4-7. Parted - interfejs
Interfejs jak widać jest bardzo prosty i intuicyjny. Jeżeli mamy jakieś wolne miejsce
możemy utworzyć nowa˛ partycje, stworzyć macierz RAID, albo przeedytować istniejac
˛ a˛ już partycj˛e. UWAGA! Jeżeli posiadasz nowy sprz˛et, możesz mieć problemy
z instalacja˛ systemu na raidzie. Problem ten wynika z tego, iż system, który właśnie
instalujesz może nie obsługiwać Twojego raida.
Wchodzac
˛ w menu "Akcje" przechodzimy do menu edycji partycji.
24
Rysunek 4-8. Parted - tworzenie partycji
Możemy zmienić punkt montowania, system plików, rozmiar albo usunać
˛ partycj˛e.
Po dokonaniu edycji tablicy partycji, oraz ustawieniu punktów montowań możemy
opuścić parted i przejść do dalszej cz˛eści instalacji.
Wybór pakietów
Przechodzimy teraz do kolejnej cz˛eści instalacji, czyli wyboru pakietów.
Rysunek 4-9. Wybór pakietów
Mamy do wyboru nast˛epujace
˛ gotowe zestawy pakietów. Przy każdym zestawie jest
jego krótka charakterystyka, wi˛ec nie ma sensu si˛e rozpisywać. Wybieramy taki zestaw jaki nam najbardziej pasuje, jednak nie warto przesadzać z pakietami, np stacja
robocza z gnome nie b˛edzie bardzo nadawała si˛e na router. Po zainstalowaniu systemu b˛edziesz zmuszony usunać
˛ mas˛e niepotrzebnych pakietów, przez co stracisz
mnóstwo czasu.
25
Dalej mamy możliwość szczegółowej selekcji pakietów, jeżeli ufamy instalatorowi
możemy pominać
˛ ten krok, jeżeli natomiast znamy si˛e troch˛e na linuksie wybieramy
powyższa˛ opcj˛e i wchodzimy do menu.
Rysunek 4-10. Grupy pakietów
Na ekranie widzimy zaznaczone grupy pakietów, możemy zaznaczać dodatkowe,
albo zrezygnować z dotychczas wybranych. Możemy także rezygnować z pojedynczych pakietów z grup wchodzac
˛ w opcj˛e standartowe pakiety. Pod linkiem "Wybierz opcjonalne pakiety" widzimy menu dzi˛eki któremu mamy możliwość bardziej
spersonalizowanego wyboru interesujacych
˛
nas pakietów.
Kolejnym krokiem jest pytanie czy chcemy zainstalować dokumentacj˛e, na które lepiej odpowiedzieć twierdzaco.
˛
Mamy także możliwość wyboru wersji j˛ezykowych
dokumentacji. Jeżeli nie jesteśmy pewni, możemy zostawić domyślne ustawienia,
czyli "ALL", jednak gdy chcemy mieć dokumentacj˛e tylko po polsku i angielsku wpisujemy "pl:pl_PL:en:en_US". Należy pami˛etać, że może zdarzyć si˛e sytuacja iż pakiet
nie ma jeszcze polskiej dokumentacji, wi˛ec zawsze warto zaznaczyć j˛ezyk angielski.
Nast˛epne kroki to prekonfiguracja instalowanego systemu.
Prekonfiguracja systemu
Dotarliśmy do punktu gdzie musimy ustawić podstawowe parametry instalowanego systemu.
26
Rysunek 4-11. Partametry sieci
Pierwszym krokiem b˛edzie ustawienie parametrów sieci (jeżeli mamy do niej dost˛ep). Jeżeli wcześniej wybraliśmy instalacj˛e przez sieć, możemy zastosować te same
preferencje także w naszym systemie, jeżeli jednak instalujemy z jakiegoś nośnika
(cdrom, dysk) należy r˛ecznie wpisać ustawienia, lub pobrać je z serwera dhcp.
Rysunek 4-12. Hasło administratora
Kolejny krok to ustawienie hasła użytkownika root. Ten punkt chyba nie wymaga
komentarza. Należy ustawić w miar˛e bezpieczne hasło, bo jak wiadomo serwer jest
tak bezpieczny jak jego najsłabsze ogniwo :) Możemy również zlecić wygenerowanie
hasła instalatorowi.
Nast˛epna˛ czynnościa˛ jest ustawienie kont(a) użytkowników, możemy zrobić to teraz,
albo po instalacji używajac
˛ polecenia useradd.
27
Rysunek 4-13. Strefa czasowa
Pozostał jeszcze wybór strefy czasowej i synchronizacja (lub nie) zegara systemowego z UTC, i na tym kończymy prekonfiguracj˛e systemu.
Bootmanager
Przyszła kolej na ustawienie bootmanagera. Jeżeli pld to nasz jedyny system na dysku możemy pominać
˛ ten krok, w przeciwnym przypadku musimy dodać wpisy innych systemów, aby była możliwość uruchomienia ich przy starcie komputera. Oczywiście jeżeli nie chcemy teraz konfigurować bootmanagera można zawsze to zrobić
po ukończeniu instalacji, edytujac
˛ plik /etc/lilo.conf.
Rysunek 4-14. Możliwość wyboru konfiguracji bootloadera
Wybieramy wi˛ec opcj˛e "konfiguruj bootloader", która uruchamia skrypt konfigurujacy.
˛
28
Rysunek 4-15. Bootloader - wpisy
Jak widać nie mamy jeszcze żadnych wpisów, wybieramy "Stwórz nowa˛ pozycj˛e"
aby dodać jakiś system operacyjny. Należy tutaj pami˛etać iż wpisujemy istniejace
˛
systemy na lokalnych dyskach, oprócz tego, który właśnie instalujemy.
Rysunek 4-16. Wybór systemu
Pierwszym krokiem jest wybór systemu który chcemy ładować. Wybieramy
np. DOS, nast˛epnie podajemy lokalizacje partycji na jakiej znajduje si˛e system i
przechodzimy do konfiguracji wpisu.
29
Rysunek 4-17. Konfiguracja wpisu
Jak widać na powyższym przykładzie, musimy wpisać etykiet˛e - czyli nazw˛e jaka
b˛edzie nam si˛e wyświetlała przy starcie komputera. Nazwa jest dowolna, jednak nie
należy przesadzać z długościa˛ i lepiej nie używać polskich znaków. Dwa kolejne pola, czyli "system" i "katalog /" mamy już wypełnione automatycznie. Jeżeli dodajemy
innego linuksa należy podać lokalizacj˛e jadra
˛
systemu (kernela) oraz initrd jeśli mamy. W systemie DOS/Windows te pola sa˛ zb˛edne.
Rysunek 4-18. Gotowy wpis
Po ustawieniu etykiety i zatwierdzeniu zmian możemy obejrzeć nasz(e) wpis(y). Jeżeli mamy wi˛ecej systemów dodajemy je po kolei, po skończeniu opuszczamy konfigurator przechodzac
˛ do kolejnej opcji.
30
Rysunek 4-19. Lokalizacja bootloadera
Ostatnia˛ rzecza˛ jaka˛ musimy zrobić aby zakończyć proces konfiguracji bootloadera
to wybór urzadzenia
˛
na jakim ma być on zainstalowany. Najlepszym rozwiazaniem
˛
jest instalacja go w MBR (Master Boot Record) dysku z którego jest ładowany system.
Jeżeli jednak nie jesteśmy pewni co do tego (lub nie wiemy co to jest MBR) najlepiej
zostawić opcj˛e auto, dzi˛eki której instalator sam wybierze najlepsze urzadzenie.
˛
Kończenie instalacji
Pozostała nam ostatnia rzecz, czyli instalacja pakietów. W tej cz˛eści nie b˛edziemy
musieli nic robić, oprócz czekania. Wi˛ec jeżeli wybraliśmy instalacj˛e z sieci i jakiś
wi˛ekszy zestaw pakietów możemy zaopatrzyć si˛e w jakaś
˛ ksia˛żk˛e i poczytać, bo proces instalacji troch˛e potrwa :)
Słowo komentarza na temat tego, co si˛e dzieje na ekranie:
Rysunek 4-20. Instalator tworzy partycje
31
Tutaj widzimy jak system tworzy partycje, oraz system plików na nich. W zależności
od wielkości partycji i szybkości dysku może to troch˛e potrwać.
Rysunek 4-21. Instalacja pakietów
Dalej po pobraniu indeksów system przechodzi do instalacji pakietów (wi˛ecej o tym
co to sa˛ indeksy w rozdziale poświ˛econym poldkowi). To jest najdłuższa cz˛eść instalacji.
Rysunek 4-22. Instalacja zakończona :)
Jeżeli nie wystapiły
˛
żadne bł˛edy zobaczysz taki ekran. Teraz wystarczy tylko zrestartować system, wyciagn
˛ ać
˛ płytk˛e/dyskietk˛e z nap˛edu, badź
˛ ustawić bootowanie
z dysku na którym zainstalował si˛e bootmanager (najcz˛eściej /dev/hda) i mamy gotowy system :)
32
Po instalacji
Po instalacji system uruchamiany jest w trzecim "poziomie pracy". Jeśli dana maszyna b˛edzie korzystała z X-Window to zapewne zechcemy aby korzystała z piatego
˛
poziomu, o zarzadzaniu
˛
poziomami pracy przeczytamy w sekcja Zmiana poziomu pracy
systemu w Rozdział 14.
Instalator pozostawił w systemie pliki zawierajace
˛ szczegóły instalacji, oto ich lista:
• /var/log/installer
- szczegółowy dziennik instalacji
• /etc/installer.conf
- lista ustawień instalatora
• /etc/installer.pkgs
- lista wybranych pakietów
• /etc/installer.sysconf
- wst˛epna konfiguracja systemu
Ostatni z wymienionych plików zawiera hasła administratora i dodanych użytkowników. Sa˛ one zapisane czytelnym tekstem, wi˛ec jeśli upewnimy si˛e, że nie sa˛ już
nam potrzebne to powinniśmy te dane usunać.
˛ Dost˛ep do tych plików ma tylko administrator, jednak w sprawach bezpieczeństwa należy kierować si˛e dalece posuni˛eta˛
ostrożnościa.˛
Jeśli wybraliśmy jedna˛ z minimalnych wersji systemu, to teraz powinna nastapić
˛
właściwa cz˛eść instalacji pakietów. W tym celu należy użyć programu Poldek, jego
opis odnajdziemy w sekcja Poldek w Rozdział 9
33
34
Rozdział 5. Instalacja przy użyciu chroota
Instalacja systemu przy użyciu chroot
Wstep
˛
Mamy możliwość zainstalowania PLD przy pomocy innego systemu operacyjnego,
sposób ten ma t˛e zalet˛e, że daje nam okazj˛e dobrego poznania PLD już na etapie instalacji, a ponadto umożliwia wykonanie bardziej wyrafinowanych operacji, które sa˛
niedost˛epne z poziomu instalatora. Ta metoda instalacji pozwala zainstalować bardzo mała˛ wersj˛e systemu, (ok. 120MB), która wystarcza do uruchomienia systemu,
skonfigurowania sieci, Poldka i pobrania kolejnych pakietów.
Do instalacji możemy użyć działajacej
˛ dystrybucji, jednak najwygodniejsze b˛edzie
użycie dystrybucji typu live: RescueCD lub PLD-Live. Użycie systemu z płyty CD ma
ta˛ zalet˛e, że instalacja może być wykonywana na docelowej maszynie, co ułatwi nam
stworzenie prawidłowego obrazu initrd. Do instalacji Th należy użyć RescueCD
2.90 lub nowszej (kiedy si˛e pojawia),
˛ zaś do instalacji Ac - jednej ze starszych wersji
np. 2.01.
Osoby ciekawe jak wyglada
˛ przebieg instalacji "na żywo", moga˛ obejrzeć nagranie
przykładowej instalacji1.
Uwaga! W niniejszym rozdziale nie zawarto wielu zbyt szczegółowych opisów, dlatego w przypadku drukowania na papierze może być konieczne dodrukowanie innych rozdziałów dokumentacji.
Przygotowanie
Uruchomienie
W przypadku instalacji z działajacego
˛
systemu musimy podłaczyć
˛
dysk twardy do
komputera i uruchomić go. W przypadku płyty CD typu live - w BIOS-ie maszyny
docelowej właczamy
˛
opcj˛e startu systemu z płyty, a nast˛epnie umieszczamy nośnik
w nap˛edzie i czekamy na start systemu.
Współczesne dystrybucje typu live same wykrywaja˛ sprz˛et i ładuja˛ odpowiednie
moduły kernela, jeśli jednak to si˛e nie powiedzie to musimy wtedy wykonać t˛e operacj˛e samodzielnie, wi˛ecej na ten temat w sekcja Statyczne zarzadzanie
˛
modułami w
Rozdział 11. Interesuja˛ nas jedynie moduły kontrolera ATA/SATA/SCSI oraz interfejsu sieciowego.
Partycje/woluminy
System możemy zainstalować na klasycznych partycjach dyskowych, woluminach
LVM lub programowych macierzach, instalacja z chroot-a daje w tej kwestii duża˛
swobod˛e. Opis tworzenia woluminów LVM przedstawiliśmy w sekcja LVM w Rozdział 13 zaś macierzy w sekcja RAID programowy w Rozdział 13. Dla ułatwienia jednak dalsze przykłady b˛eda˛ dotyczyły zwykłych partycji.
Potrzebujemy co najmniej dwóch partycji: jednej na główny system plików i drugiej
na obszar wymiany. Obszar wymiany, nie jest wymagany do instalacji, jednak dla porzadku
˛
utworzymy go już na tym etapie. Przykłady b˛eda˛ dotyczyły dysku /dev/hda.
Nazewnictwo urzadze
˛
ń masowych wyczerpujaco
˛ przedstawiono w sekcja Nazewnictwo urzadze
˛ ń masowych w Rozdział 13.
Na uprzywilejowanej pozycja˛ b˛eda˛ tym razem użytkownicy kompletnych systemów,
które umożliwiaja˛ użycie programu GParted lub QTParted, w przeciwnym wypadku
użyjemy programu fdisk lub cfdisk np.:
35
# cfdisk /dev/hda
Podział dysku na partycje szerzej opisano w sekcja Podział na partycje w Rozdział 13.
Zakładamy, że na pierwszej partycji dysku IDE umieścimy obszar wymiany, zaś na
drugiej główny system plików.
Systemy plików
Inicjujemy obszar wymiany:
# mkswap /dev/hda1
Tworzymy system plików (np. ext2):
# mkfs.ext2 /dev/hda2
Powyższe operacje omówiliśmy dokładnie w sekcja Systemy plików w Rozdział 13.
Zapami˛etujemy układ partycji i systemów plików, gdyż b˛edzie on nam potrzebny do
prawidłowego skonfigurowania pliku /etc/fstab. Teraz przyszedł czas na utworzenie punktu montowania i podmontowania partycji np.:
# mkdir /pldroot
# mount /dev/hda2 /pldroot
Jeśli system ma używać wi˛ekszej ilości partycji (np. dla /boot) to montujemy je
wszystkie.
Konfiguracja sieci
Założyliśmy, że b˛edziemy instalować pakiety z sieci, dlatego musimy skonfigurować
połaczenie.
˛
W opisach przyj˛eliśmy, że maszyna jest podłaczona
˛
do sieci Ethernet.
W przypadku RescueCD system domyślnie próbuje pobrać konfiguracj˛e z DHCP,
dlatego od razu po uruchomieniu powinniśmy mieć działajac
˛ a˛ sieć. Jeśli w sieci nie
ma takiego serwera to musimy statycznie przydzielić parametry połaczenia.
˛
Zakładajac,
˛ że chcemy ustawić adres 192.168.0.2 z maska˛ /24 parametry pliku konfiguracji
interfejsu (np.: /etc/sysconfig/interfaces/ifcfg-eth0) powinny mieć nast˛epujace
˛ wartości:
DEVICE=eth0
IPADDR=192.168.0.2/24
ONBOOT=yes
BOOTPROTO=none
W pliku /etc/sysconfig/static-routes dodajemy tras˛e routingu do bramy (np.:
10.0.0.254):
eth0 default via 10.0.0.254
W pliku /etc/resolv.conf podajemy przynajmniej jeden adres serwera DNS:
nameserver 193.192.160.243
Na koniec przeładowujemy podsystem sieci:
# service network restart
Konfiguracj˛e sieci szerzej opisano w sekcja Wst˛ep w Rozdział 15.
36
Proxy
Jeśli potrzebujemy skorzystać z proxy ustawiamy odpowiednia˛ zmienna˛ środowiskowa˛ np.:
# export ftp_proxy=w3cache.dialog.net.pl:8080
Szczegóły konfiguracji proxy odnajdziemy w sekcja Proxy w Rozdział 7.
Konfiguracja Poldka
Zaczynamy od ustawienia najlepiej dopasowanej architektury instalowanych pakietów, za pomoca˛ opcji _pld_arch w pliku /etc/poldek/pld-source.conf. Wi˛ecej
o architekturach pakietów w sekcja Architektury pakietów w Rozdział 9. Dobrym pomysłem jest ustawienie opcji, umożliwiajacej
˛ precyzyjne wybieranie alternatywnych
pakietów (dla nieco bardziej zaawansowanych):
choose equivalents manually = yes
w pliku /etc/poldek/poldek.conf.
Teraz tworzymy katalog na indeksy Poldka np.:
# mkdir -p /pldroot/var/cache/poldek-cache
Nast˛epnie w konfiguracji Poldka musimy wskazać ten katalog, odszukujemy w pliku
/etc/poldek/poldek.conf opcj˛e cachedir, w której definiujemy ścieżk˛e do katalogu:
cachedir = /pldroot/var/cache/poldek-cache
Instalacja
Instalacja pakietów
Zanim zaczniemy instalować pakiety musimy mieć świadomość, że zachodzi mi˛edzy
nimi wiele zależności. Zostana˛ zainstalowane wszystkie wymagane dodatkowo pakiety, jednak nie mamy wpływu na kolejność instalacji. Zdarza si˛e, że pakiet wymaga
pliku lub programu, którego jeszcze nie ma w instalowanym systemie, przez co nie
moga˛ być wykonane pewne operacje poinstalacyjne. Pojawia˛ si˛e nam wtedy na ekranie komunikaty bł˛edów, nie należy si˛e tym martwić, gdyż naprawimy ten problem
reinstalujac
˛ pakiet. Musimy jedynie wywołać instalacj˛e z opcja˛ --reinstall
Instalacj˛e rozpoczynamy od inicjacji bazy danych pakietów:
# rpm --root /pldroot --initdb
W tej cz˛eści instalacji zainstalujemy kolejno pakiety: setup, FHS, dev, pwdutils,
chkconfig, dhcpcd, poldek, vim (lub inny edytor), geninitrd, modutils, cpio,
bootloader lilo lub grub. Możemy dodatkowo zainstalować wiele innych
pakietów, jednak możemy spokojnie to wykonać z działajacego
˛
już systemu.
Mamy możliwość użycia trybu interaktywnego Poldka:
# poldek --root /pldroot
37
poldek> install setup FHS dev pwdutils chkconfig dhcpcd poldek vim geninitrd \
modutils cpio lilo mount login mingetty
lub wsadowego
# poldek --root /pldroot -i setup FHS dev pwdutils chkconfig \
dhcpcd poldek vim geninitrd modutils cpio lilo mount login mingetty
Jeśli zdecydowaliśmy sie macierze dyskowe, to powinniśmy zainstalować dodatkowo pakiety: mdadm i mdadm-initrd (jeśli jest na głównym systemie plików). Jeśli używamy woluminów logicznych (LVM) to potrzebujemy pakiety odpowiednio lvm2 i
lvm2-initrd.
Przygotowanie do instalacji kernela
Przed instalacja˛ jadra
˛
musimy wykonać operacje konieczne do prawidłowego wygenerowania initrd:
•
Montujemy pseudo-system plików /proc:
# mount /proc /pldroot/proc -o bind
•
Konfigurujemy plik /etc/fstab, tak by wpisy odpowiadały wybranemu przez
nas układowi partycji i systemów plików. Dla przykładów z poczatku
˛
rozdziału
wpisy b˛eda˛ wygladały
˛
nast˛epujaco.:
˛
/dev/hda1 swap swap defaults 0 0
/dev/hda2 /
ext2 defaults 0 0
Wi˛ecej w sekcja Kluczowe pliki w Rozdział 12.
•
Dokonać odpowiednich koniecznych operacji konfiguracyjnych w przypadku
korzystania z macierzy RAID (plik /etc/mdadm.conf) lub woluminów LVM
(/etc/lvm/lvm.conf).
Instalacja kernela
Musimy wybrać, który kernel zainstalujemy, na poczatek
˛
powinniśmy si˛e zainteresować pakietami: kernel, kernel-grsecurity i ew. ich odmiany z SMP. W wyborze
może pomóc nam opis kerneli w sekcja Jadro
˛
systemu w Rozdział 11. Kiedy już wybraliśmy, instalujemy wybrany pakiet:
# poldek --root /pldroot -i kernel
Jeśli nie pomin˛eliśmy żadnego kroku, to powinien nam si˛e wygenerować prawidłowy obraz initrd, w przeciwnym wypadku musimy to wykonać samodzielnie wg.
opisu zamieszczonego w sekcja Initrd w Rozdział 11.
Bootloader
Jeśli wybraliśmy LILO jako bootloader to powinniśmy odpowiednio zmodyfikować
plik konfiguracji (/etc/lilo.conf), w przypadku użytej w przykładach konfiguracji
b˛edzie wygladał
˛
nast˛epujaco:
˛
boot=/dev/hda
read-only
lba32
38
prompt
timeout=100
image=/boot/vmlinuz
label=pld
root=/dev/hda2
initrd=/boot/initrd
Kiedy konfiguracja jest skończona wydajemy polecenie:
# chroot /pldroot /sbin/lilo
W przypadku GRUB-a plik konfiguracji (/boot/grub/menu.lst) powinien tak wygladać:
˛
timeout 10
title pld
root (hd0,1)
kernel /boot/vmlinuz boot=/dev/hda
initrd /boot/initrd
Teraz instalujemy bootloader:
# chroot /pldroot /sbin/grub
Kiedy zgłosi si˛e nam powłoka GRUB-a kolejno wydamy nast˛epujace
˛ polecenia:
grub> root (hd0,1)
grub> setup (hd0)
grub> quit
Konfiguracj˛e bootloadera wyczerpujaco
˛ przedstawiono w sekcja Wst˛ep w Rozdział
10. Jeśli gałaź
˛ /boot ma być na macierzy to powinniśmy umieścić bootloader na
wszystkich wchodzacych
˛
w skład tej macierzy dyskach, szczegóły tej operacji przedstawiliśmy w sekcja RAID programowy w Rozdział 13.
UDEV
Jeśli chcemy używać systemu urzadze
˛
ń udev, to jest doskonała okazja żeby go zainstalować. Podstawowe pakiety wymagaja˛ urzadze
˛
ń z pakietu dev, dlatego możemy
go zainstalować dopiero teraz:
# poldek --root /pldroot -i udev
# poldek --root /pldroot -e dev
˛
w Rozdział 11.
Urzadzenia,
˛
dev oraz udev zostały opisane w sekcja Urzadzenia
Konta użytkowników
Aby móc si˛e zalogować do nowego systemu musimy nadać hasło dla root-a:
# chroot /pldroot /usr/bin/passwd
39
Nic nie stoi na przeszkodzie, żeby utworzyć konta użytkowników i skonfigurować
uprawnienia. W tym celu posłużymy si˛e narz˛edziami z pakietu shadow lub pwdutils, zanim to jednak zrobimy musimy ustalić z jakiej powłoki b˛eda˛ korzystać użytkownicy. Domyślnie oba pakiety ustawiaja˛ użytkownikom powłok˛e /bin/bash, dlatego przy tworzeniu kont musimy ustawić ja˛ na /bin/sh, lub zainstalować Basha.
Zakładajac,
˛ że mamy zainstalowanego Basha dodajemy konto użytkownika nast˛epujaco:
˛
# chroot /pldroot /usr/sbin/useradd -m jkowalski
# chroot /pldroot /usr/bin/passwd jkowalski
Szczegółowy opis narz˛edzi z pakietu pwdutils znajdziemy w sekcja Konta użytkowników w Rozdział 14.
Operacje końcowe
Przed restartem musimy odmontować systemy plików:
# umount /pldroot/proc
# umount /pldroot
Na koniec wpisujemy polecenie reboot, wyjmujemy płyt˛e z nap˛edu i czekamy aż
uruchomi si˛e nowy system.
Przypisy
1. http://dlugosz.eu/2009/03/05/pld-th-i686-base-video-install/
40
Rozdział 6. Aktualizacje
Aktualizacja systemu PLD z RA do AC
Aktualizacja z Ra do Ac
Gdy mamy zainstalowane już na dysku PLD 1.x, aby przejść do 2.0 (AC) nie musimy
od nowa instalować całego systemu. Możemy posłużyć si˛e skryptem ra2ac. Pakiety
z tego skryptu standardowo pobierane sa˛ z ftp. Czynnościa˛ która˛ musimy wykonać
zanim posłużymy si˛e skryptem to aktualizacja kernela do wersji 2.4.x. Gotowe pakiety możemy pobrać z dwóch źródeł w zależności od architektury.
•
Dla architektur: i686 oraz ppc: ftp://ftp.pld-linux.org/dists/ra/updates/2.4/
•
Dla architektur: i386, i586, i686: ftp://atos.wmid.amu.edu.pl/pub/pld/ra-24/
Cała aktualizacja systemu sprowadzi si˛e do uruchomienia skryptu i r˛ecznej rekonfiguracji nowych wersji usług.
Należy pami˛etać, że AC jest na kernelu 2.6, lub 2.4 do wyboru, w tych kernelach
nie ma ipchains-ów, zamiast tego jest narz˛edzie nazywajace
˛ si˛e iptables. Pomimo
iż służy do tego samego, regułki maja˛ inna˛ składnie. W kernelach 2.4 i 2.6 niektóre
moduły urzadze
˛
ń inaczej si˛e nazywaja,˛ wi˛ec na to też należy być przygotowanym.
Skrypt jest przeznaczony dla ludzi, którzy wiedza˛ co robia˛ i maja˛ ogólne poj˛ecie o
linuksie, jeżeli jesteś poczatkuj
˛
acym
˛
użytkownikiem PLD, to lepsza˛ decyzja˛ b˛edzie
od nowa zainstalowanie systemu.
Pierwszym krokiem powinno być zrobienie kopii zapasowej plików konfiguracyjnych - najlepiej przekopiować gdzieś cały katalog /etc, jeżeli masz np. postgresa, to
ważne jest abyś zrzucił gdzieś bazy. O innych ważnych usługach i zmianach w konfiguracjach powinniśmy poczytać wcześniej. Wiele nowszych pakietów, stare pliki
konfiguracyjne przekopiuje do plików z rozszerzeniem *.old
Zainstalowanego na komputerze kde lub gnome najlepiej jest usunać
˛ (łacznie
˛
z katalogami i plikami zaczynajacymi
˛
si˛e od .kde i .gnome w katalogach domowych użytkowników) - gdyż zmiany sa˛ bardzo duże i praca ze starymi ustawieniami powoduje
cz˛esto wadliwa˛ prace. Generalnie ważne jest aby aktualizować jak najmniejsza˛ liczb˛e
pakietów, wtedy wszystko powinno pójść w miar˛e gładko. Reszt˛e pakietów można
później r˛ecznie doinstalować po aktualizacji.
Teraz pobieramy z cvsu skrypt ra2ac poleceniem:
# cvs -d :pserver:[email protected]:/cvsroot get raac-converter
cvs server: Updating raac-converter
U raac-converter/ChangeLog
U raac-converter/TODO
U raac-converter/ra2ac
Lub korzystamy z adresu www3
Nast˛epnie uruchamiamy ra2ac:
# sh raac-converter/ra2ac
Czekamy aż skończy si˛e instalowanie pakietów, na przewijajace
˛ si˛e niespełnione zależności i bł˛edy nie zważamy :)
I na samym końcu najbardziej nieprzyjemna cz˛eść aktualizacji - konfiguracja. Należy
teraz wi˛ekszość usług jeszcze raz przekonfigurować, cz˛eść usług b˛edzie potrzebowała tylko przekopiowania konfigu z Ra, jednak inne (np. exim, postfix) wymagaja˛
od administratora edycji nowych plików konfiguracyjnych. Ważne jest żeby poczytać w dokumentacji o zmianach w plikach konfiguracyjnych mi˛edzy wersjami które
mieliśmy w RA, a wersjami wyst˛epujacymi
˛
teraz po skończeniu działania skryptu.
41
Rozdział 6. Aktualizacje
Przypisy
1. ftp://ftp.pld-linux.org/dists/ra/updates/2.4/
2. ftp://atos.wmid.amu.edu.pl/pub/pld/ra-24/
3. http://cvs.pld-linux.org/cgi-bin/cvsweb/raac-converter/ra2ac
42
Rozdział 7. Podstawy
W tym rozdziale znajdziesz podstawowe komendy i czynności, które powinieneś
znać.
Wstep
˛
Dokument, który aktualnie czytasz zawiera minimalny zestaw instrukcji i porad koniecnych do instalacji i zarzadzania
˛
dystrybucja˛ PLD Linux. Wi˛ekszość opisywanych
mechanizmów i narz˛edzi ma o wiele wi˛eksze możliwości, aby je poznać powinniśmy
używać podr˛eczników systemowych info i man (przestarzały). Aby z nich korzystać
musisz je zainstalować (o ile nie sa˛ już zainstalowane) poleceniami:
poldek -U man
poldek -U info
W skrócie z podr˛ecznika korzystamy nast˛epujaco:
˛
info {$hasło}
{$hasło} może być nazwa˛ programu, biblioteki, pliku konfiguracyjnego. Dodatkowa˛ dokumentacj˛e odnajdziemy w katalogu /usr/share/doc, tam też możemy odna-
leźć przykładowe pliki konfiguracji, histori˛e zmian programu, licencje i wiele innych
informacji.
Jeśli szukasz prostego narz˛edzia o konkretnych możliwościach możemy przejrzeć
dokumentacj˛e systemowa˛ zestawu coreutils:
info coreutils
Możesz również szukać pomocy na listach dyskusyjnych, IRC-u, czy forum. List˛e
tych jak i wielu innych użytecznych adresów odnajdziesz w sekcja Ważne adresy w
Rozdział 2.
Właczanie
˛
i wyłaczanie
˛
systemu
Tradycyjna˛ metoda˛ wyłaczania
˛
komputera jest komenda shutdown, np.:
# shutdown -h now
Lub poweroff dajaca
˛ ten sam efekt.
Użycie komendy halt jest też właściwe.
# halt
Aby zresetować system wpisujemy reboot albo korzystamy z kombinacji klawiszy
CTRL+ALT+DEL.
W trakcie pracy możemy dowolnie przełaczać
˛
si˛e pomi˛edzy trybami pracy. Służy do
tego polecenie init {$nr} ({$nr} to liczba oznaczajaca
˛ tryb pracy) np.
# init 5
Zmian˛e poziomu pracy szerzej opisano tutaj: sekcja Zmiana poziomu pracy systemu w
Rozdział 14
43
Podstawowe operacje na plikach i katalogach
Zawartość plików wyświetlamy poleceniem cat.
$ cat archiwum
Jeśli chcemy przyjrzeć si˛e plikowi, który nie mieści si˛e na ekranie po wykonania cat
możemy uzyskać poleceniem less. Możemy wtedy przegladać
˛
plik używajac
˛ "strzałek", a kiedy skończymy - naciskamy q.
$ less plik
Komenda˛ touch możemy modyfikować znaczniki czasu pliku, cz˛eściej jednak używa
si˛e jej do tworzenia pustych plików.
$ touch pusty_plik
Polecenie mkdir tworzy katalog.
$ mkdir archiwum
Za pomoca˛ polecenia rmdir usuwamy puste katalogi.
$ rmdir archiwum
Plik możemy przenieść, albo zmienić jego nazw˛e, za pomoca˛ polecenia mv.
$ mv listing listing.old
$ mv /home/listing.old /usr/src/
W podobny sposób operujemy na katalogach.
$ mv archiwum smietnik
$ mvdir smietnik /usr/src/smietnik/
Do kopiowania służy polecenie cp.
$ cp listing podkatalog/
Kasujemy poleceniem rm.
$
$
$
$
$
$
rm
rm
rm
rm
rm
rm
plik
*
* -i
* -f
-r
-rf /home/
//
//
//
//
//
//
Kasuje
Kasuje
Kasuje
Kasuje
Kasuje
Kasuje
plik.
wszystkie
wszystkie
wszystkie
wszystkie
wszystkie
pliki w danym katalogu.
pliki w danym katalogu z potwierdzeniem.
pliki w danym katalogu bez pytania.
pliki, także te w podkatalogach
pliki i katalogi w katalogu /home/
Poruszanie sie˛ w drzewie katalogów
Do poruszania si˛e w drzewie katalogów w trybie tekstowym można używać programu Midnight Commander uruchamianego poleceniem mc, jednak nie każdy go
instaluje, wi˛ec warto zapoznać si˛e z kilkoma poleceniami przedstawionymi w tym
rozdziale.
Do poruszania si˛e w drzewie katalogów używamy polecenia cd ścieżka np.:
$ cd /home/users/zenek/
Ten sam efekt uzyskamy poleceniem
$ cd users/zenek/
44
wykonanym w katalogu /home
Kilka innych przykładów przedstawiamy poniżej.
W systemach uniksowych wyróżniamy kilka rodzajów specjalnych katalogów. Najważniejszym w całym drzewie jest katalog główny -korzeń (ang. root) oznaczany
przez ukośnik: "/"
$ cd /
Cz˛esto po lewej stronie ścieżki podaje si˛e korzeń aby wskazać położenie katalogu lub
pliku bez wzgl˛edu na miejsce z którego wydajemy polecenie np.:
$cd /etc/sysconfig
Polecenie ls powoduje wyświetlenie zawartości katalogu. Należy po nim podać nazw˛e katalogu, który chcemy zobaczyć, w przeciwnym wypadku wyświetlona zostanie zawartość katalogu bieżacego.
˛
$ls /
bin
dev home
boot etc initrd
$cd /home
$ls
services users
lib
media
mnt
opt
proc
root
sbin
selinux
srv
sys
tmp
usr
var
Parametr -a powoduje, że funkcja pokazuje również pliki ukryte (zaczynajace
˛ si˛e od
kropki). -R powoduje wylistowanie również podfolderów.
Polecenie pwd powoduje wyświetlenie ścieżki bieżacego
˛
katalogu.
$cd users/bart
$pwd
/home/users/bart/
Ważnym katalogiem jest katalog domowy użytkownika - oznaczany znakiem tyldy
(~). Każdy użytkownik może używać w ścieżce tego znaku i zawsze b˛edzie oznaczał
jego własny katalog domowy np.:
$ ls ~/dokumenty
Kolejnym takim katalogiem jest katalog nadrz˛edny oznaczany za pomoca˛ dwóch
kropek. B˛edac
˛ w katalogu: /home/users/zenek możemy przejść o jeden poziom do
góry używajac
˛ polecenia
cd ..
Dzi˛eki temu znajdziemy si˛e w katalogu /home/users.
Data i czas
By wyświetlić aktualny czas i dat˛e systemowa˛ posługujemy si˛e komenda˛ date:
$ date sob kwi 26 23:48:33 CEST 2003
Oprócz możliwości wyświetlania daty i czasu w niemal dowolnym formacie, pozwoli nam na ustawianie czasu systemowego. Szczegółowy opis programu znajdziemy
w podr˛eczniku man.
Czas działania komputera sprawdzamy komenda˛ uptime.
$ uptime
45
5:27pm
up
6:51,
4 users,
load average: 0.32, 0.08, 0.02
W sytuacji gdy chcemy z zmierzyć czas potrzeby
operacji/czynności/procesu to posługujemy si˛e komenda˛ time.
na
wykonanie
$ time find /home/users/rennis/ HELLO
real 0m13.297s
user 0m0.060s
sys 0m0.230s
Przykład ten poszukuje pliku HELLO w moim katalogu domowym, co zajmuje systemowi ~13s.
Edycja plików konfiguracyjnych
W systemach z rodziny UNIXa konfiguracja systemu jest przechowywana w plikach
tekstowych. Zaleta˛ tego rozwiazania
˛
jest możliwość konfigurowania systemu przy
pomocy bardzo prostych narz˛edzi, wada˛ zaś to że można łatwo popełnić bład.
˛ Dlatego jeśli chcemy tylko przegladać
˛
plik powinniśmy użyć programu less np.:
# less /etc/poldek/poldek.conf
Jeśli jesteśmy pewni że chcemy dokonać zmian, powinniśmy wcześniej wykonać kopi˛e zapasowa˛ pliku (pliki kopii zapasowej kończy si˛e tylda).
˛
# cp /etc/poldek/poldek.conf /etc/poldek/poldek.conf~
Teraz możemy zaczać
˛ modyfikować plik, domyślnie instalowanym edytorem plików
jest vim, dlatego dobrze jest umieć si˛e nim posługiwać choćby w podstawowym zakresie. Bardzo użyteczna˛ cecha˛ Vima jest kolorowanie składni podstawowych plików
konfiguracji (o ile nasz terminal jest kolorowy), dzi˛eki czemu łatwo możemy zauważyć ewentualne bł˛edy.
Aby otworzyć nim plik do edycji wydajemy polecenie
# vim /etc/poldek/poldek.conf
Po otworzeniu pliku jesteśmy w trybie wydawania poleceń, aby przejść do trybu
edycji naciskamy klawisz i. Teraz możemy wprowadzać zmiany. Po wykonaniu
zmian naciskamy klawisz Esc aby powrócić do trybu wydawania poleceń. Teraz
należy opuścić program jednym z poniższych poleceń: :q - wyjście z programu jeśli
nie dokonaliśmy żadnych zmian; :wq - wyjście z zapisaniem zmian do pliku; :q! wyjście z programu bez zapisywania dokonanych zmian.
Poczatkuj
˛
acym
˛
można zaproponować edytor mcedit b˛edacy
˛ cz˛eścia˛ programu mc
(Midnight Commander), inne nieco mniej popularne edytory to: emacs, pico, joe
Należy pami˛etać o tym, że prawo zapisu plików w katalogu konfiguracji systemu
(/etc) ma tylko superużytkownik (root) i z takimi uprawnieniami należy uruchamiać
edytor. Pliki konfiguracyjne w linuksie musza˛ kończyć si˛e znakiem nowej linii, dlatego przed zapisem należy pami˛etać o sprawdzeniu czy jest wstawiony. Po raz kolejny
swoja˛ przewag˛e nad innymi edytorami pokazuje Vim, który automatycznie wstawia
znak nowej linii.
Podstawowe narzedzia
˛
kontroli sieci TCP/IP
Aby używać przedstawionych tu programów, należy mieć uprawnienia superużytkownika lub być zapisanym do odpowiedniej grupy. List˛e grup i odpowiadajacych
˛
im uprawnień zamieszczono w sekcja Zarzadzanie
˛
uprawnieniami w Rozdział 14. Bar46
dziej zaawansowane narz˛edzia sieciowe opisano w sekcja Narz˛edzia sieciowe w Rozdział 16.
Ping
Najcz˛eściej używanym narz˛edziem diagnostycznym jest program ping - pozwala on
zbadać istnienie połaczenia
˛
mi˛edzy dwoma komputerami, drog˛e pomi˛edzy nimi,
czas potrzebny na przejście pakietu oraz sprawdza czy drugi komputer pracuje w
danym momencie w sieci. Przy okazji ping dokonuje tłumaczenia adresu domenowego na numer IP. Program ten jest przydatny do określania stanu sieci i określonych
hostów, śledzenia i usuwania problemów sprz˛etowych, testowania, mierzenia i zarzadzania
˛
siecia,˛ oraz do badania sieci. Polecenie ping {$nazwa/$numer_IP} wysyła
specjalne pakiety ICMP do wskazanego komputera i czeka na odpowiedź. Możemy
podawać jako cel adres domenowy lub numer IP. Przy okazji program ten dokonuje
tłumaczenia adresu domenowego na numer IP.
$ ping pld-linux.org
PING pld-linux.org (81.0.225.27) 56(84) bytes of data.
64 bytes from 81.0.225.27: icmp_seq=1 ttl=44 time=135 ms
64 bytes from 81.0.225.27: icmp_seq=2 ttl=44 time=99.8 ms
64 bytes from 81.0.225.27: icmp_seq=3 ttl=44 time=149 ms
--- pld-linux.org ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 99.840/128.084/149.144/20.761 ms
prac˛e programu przerywamy skrótem ctrl+c
Na powyższym wydruku przedstawiono 3 odpowiedzi na wysłane pakiety. Jeden
wiersz oznacza odpowiedź na jeden pakiet, dla każdego z nich podawane sa˛ parametry trasy pomi˛edzy komputerami. Najistotniejszym parametrem jest czas odpowiedzi (time). W przypadku problemów z siecia˛ cz˛eść pakietów może zostać zagubiona,
b˛edzie wskazywane przez specjalny licznik (icmp_seq) oraz przez końcowe statystyki. Brak jakiejkolwiek odpowiedzi można interpretować jako brak połaczenia
˛
sieciowego z interesujacym
˛
nas komputerem, blokad˛e tego typu pakietów na komputerze
zdalnym lub zwyczajne wyłaczenie
˛
maszyny. Na końcu wyświetlane sa˛ dodatkowo
szczegółowe statystyki. Przy prawidłowym połaczeniu
˛
czas odpowiedzi dla sieci lokalnej zazwyczaj nie przekracza 1 ms zaś w internecie może si˛egnać
˛ nawet kilkuset
ms.
Komenda może dać również efekt podobny do poniższego:
[root@g82 ~]# ping google.pl
PING google.pl (216.239.57.99) 56(84) bytes of data.
From 192.168.6.1 icmp_seq=1 Packet filtered
From 192.168.6.1 icmp_seq=2 Packet filtered
--- google.pl ping statistics --2 packets transmitted, 0 received, +2 errors, 100% packet loss, time
1000ms
Może to oznaczać, że w naszej sieci zabronione jest wysyłanie pingów poza LAN.
Traceroute
Nieco bardziej zaawansowanym programem jest traceroute. Pokazuje on tras˛e jaka˛ przechodza˛ pakiety mi˛edzy naszym komputerem, a sprawdzanym przez nas hostem. Wskazuje on czasy przesłania pakietów pomi˛edzy sasiaduj
˛
acymi
˛
ze soba˛ routerami (tzw. czasy przeskoków), znajdujacymi
˛
si˛e na trasie połaczenia
˛
dwóch maszyn.
47
Pozwala śledzić tras˛e pakietów oraz wykrywać różnego rodzaje problemy w sieciach
np.: bładzenie
˛
pakietów w sieci, "waskie
˛
gardła" sieci, oraz awarie połacze
˛ ń.
$ traceroute pld-linux.org
traceroute to pld-linux.org (81.0.225.27), 30 hops max, 38 byte packets
1 192.168.1.1 (192.168.1.1) 0.295 ms 0.608 ms 0.484 ms
2 217.153.188.173 (217.153.188.173) 1.012 ms 0.648 ms 0.495 ms
3 217.8.190.153 (217.8.190.153) 30.894 ms 28.983 ms 29.719 ms
Jak widać, polecenie to wypisuje linie zawierajace
˛ TTL, adres bramki oraz czas przebycia każdej z próbek z różnych gatewayów. Jeśli nie było odpowiedzi w ciagu
˛ trzech
sekund to dla próbki drukowane jest ’*’
MTR
Godnym uwagi programem jest MTR, jest narz˛edziem łacz
˛ acym
˛
funkcje opisanych
wcześniej programów. Program ten śledzi tras˛e połaczenia
˛
mi˛edzy dwoma punktami
podobnie jak traceroute i odświeża wyniki w regularnych odst˛epach czasu.
$ mtr pld-linux.org
Proxy
Zdarza si˛e, że chcemy lub musimy korzystać z serwera pośredniczacego
˛
(proxy),
w tym celu trzeba wskazać programowi jego adres i port. Konfiguracja proxy w
GNU/Linuksie zależy od programu klienckiego i może być wykonana na jeden z
trzech sposobów, oto ich lista:
•
zmienne środowiskowe - z nich korzystaja˛ głównie programy działajace
˛ w trybie znakowym np.: lynx, wget, poldek. Definiujemy je nast˛epujaco:
˛ {$protokół}_proxy
np. serwer proxy dla FTP wskazujemy za pomoca˛ zmiennej ftp_proxy zaś dla
HTTP za pomoca˛ http_proxy np.:
export ftp_proxy=w3cache.dialog.net.pl:8080
Sa˛ programy, które akceptuja˛ nazwy tych zmiennych napisanych wyłacznie
˛
wielkimi literami, tak wi˛ec dla wygody i pewności możemy zdefiniować obie wersje.
Wi˛ecej o zmiennych środowiskowych znajdziemy w sekcja Zmienne środowiskowe
w Rozdział 12.
48
•
opcje programu - wiele bardziej rozbudowanych aplikacji używa własnej konfiguracji proxy. Sa˛ to przeważnie programy dla środowiska X-Window np.: gFTP, Firefox,
Opera.
•
konfiguracja środowiska - programy ściśle zwiazane
˛
ze środowiskami graficznymi
Gnome lub KDE używaja˛ ustawień tychże środowisk. Do tego typu programów
należa˛ np.: Epiphany, Konqueror.
Rozdział 8. Zasoby systemu
Tutaj opisano sposób badania zasobów systemu operacyjnego.
Ilość miejsca na dysku
Wiele poleceń zwracajacych
˛
wielkości zajmowanej pami˛eci obsługuje parametr -h
przedstawiajacy
˛ wielkości w jednostkach bardziej wygodnych dla człowieka.
Komenda df służy do pokazania ilości miejsca na zamontowanych partycjach.
$ df -h
System plików
/dev/hdc1
rozm. użyte dost. %uż. zamont. na
36G 5.6G
29G 16% /
Natomiast komenda˛ du można sprawdzać obj˛etość plików oraz całych katalogów.
Uruchomienie du -h wyświetli list˛e plików, katalogów i ich obj˛etości (z bieżacego
˛
katalogu)
$ du -h
4.1kB ./archiv/httpd
4.1kB ./archiv/mysql
4.1kB ./archiv/exim
17kB ./archiv
4.1kB ./httpd
4.1kB ./mysql
111kB ./exim
107kB ./ircd
4.1kB ./mail
2.1MB .
Za pomoca˛ opcji -s uzyskamy sum˛e obj˛etości wszystkich plików
$ du -sh /bin
3,4M
/bin
Procesy i zasoby
List˛e wszystkich uruchomionych procesów oraz dotyczace
˛ ich dane otrzymamy
dzi˛eki poleceniu ps
$ ps aux
USER
root
zenek
root
PID %CPU %MEM
VSZ RSS
1350 0.0 0.1 1788 868
2252 0.0 1.2 11316 6668
2301 0.0 0.3 2748 1556
TTY
?
?
tty2
STAT
Ss
Ss
Ss
START
May27
May27
May27
TIME
0:00
0:01
0:00
COMMAND
syslog-ng
xfce4-session
-bash
Oraz w formie drzewa procesów rodziców i procesów potomnych
$ ps xf
PID
2459
2460
2461
2465
2816
TTY
?
?
?
?
?
STAT
S
S
S
S
S
TIME COMMAND
0:32 xmms
0:00 \_ xmms
0:00
\_ xmms
0:00
\_ xmms
0:00
\_ xmms
49
W przypadku potrzeby ciagłego
˛
śledzenia zmian w systemie możemy użyć programu top. Program ten pokazuje najbardziej zasobożerne procesy. Dodatkowo na bieżaco
˛ wyświetla całkowite zużycie procesora (CPU), pami˛eci operacyjnej(Mem) oraz
zaj˛etość przestrzeni wymiany (Swap).
$ top
top - 01:38:54 up 3:28, 4 users, load average: 0.10, 0.08, 0.08
Tasks: 63 total,
2 running, 61 sleeping,
0 stopped,
0 zombie
Cpu(s): 2.3% us, 1.3% sy, 0.0% ni, 96.1% id, 0.0% wa, 0.3% hi, 0.0% si
Mem:
516244k total,
440344k used,
75900k free,
11840k buffers
Swap: 1076312k total,
0k used, 1076312k free,
328012k cached
PID
2240
2892
2695
1
USER
root
zenek
zenek
root
PR
15
16
16
16
NI VIRT RES SHR
0 62644 24m 45m
0 1880 928 1672
0 6532 3824 5056
0 1532 584 1372
S %CPU %MEM
S 1.6 4.9
R 0.6 0.2
R 0.3 0.7
S 0.0 0.1
TIME+
7:37.40
0:00.05
0:01.63
0:00.82
COMMAND
X
top
xterm
init
Informacje o samej pami˛eci i przestrzeni wymiany uzyskamy dzi˛eki komendzie free
$ free
total
Mem:
516244
-/+ buffers/cache:
Swap:
1076312
used
445536
100928
0
free
70708
415316
1076312
shared
0
buffers
11880
cached
332728
Całkowita ilość zużytej pami˛eci (razem z buforami dyskowymi) mieści si˛e w pierwszym wierszu w kolumnie USED. Zaś ilość pami˛eci zużytej jedynie przez programy
mieści si˛e w drugim wierszu w tej samej kolumnie.
Do śledzenia zmian zużycia zasobów systemu w funkcji czasu warto polecić program vmstat z liczba˛ sekund w parametrze. Podany czas jest odst˛epem pomi˛edzy
pomiarami, program pokazuje zmiany w wykorzystaniu pami˛eci, obszaru wymiany,
czasu procesora, przerwań czy wielkości transferu do i z urzadze
˛
ń masowych:
# vmstat 2
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---r b
swpd
free
buff cache
si
so
bi
bo
in
cs us sy id wa
0 0
0 276896
980 89812
0
0
377
6 482
818 6 2 90 1
0 0
0 276780
980 89816
0
0
0
0 456
770 0 0 100 0
0 0
0 276772
980 89816
0
0
0
28 461
846 0 0 100 0
Szczegółowy opis oznaczeń kolumn odnajdziemy w podr˛eczniku systemowym
man/info.
Do procesów których jesteśmy właścicielami możemy wysyłać sygnały (root może
wysłać sygnał do każdego procesu). Aby zakończyć jakiś proces należy do procesu
wysłać sygnał TERM. Dokonuje si˛e tego poleceniem kill lub killall. Pierwsze zabija
proces o podanym numerze PID (unikalnym identyfikatorze procesu) np.:
$ kill 2901
Drugie z poleceń zabija wszystkie procesy, które maja˛ podana˛ nazw˛e np.:
$ killall xmms
Sygnał TERM może być nieskuteczny w niektórych wypadkach, wtedy należy użyć
bardziej brutalnej metody - sygnału KILL. Możemy go wysłać programem kill lub
killall z odpowiednim parametrem: "-9" lub "-KILL":
kill -9 2901
50
W systemach uniksowych można ustawiać priorytety uruchamianym programom
badź
˛ też modyfikować bieżacy
˛ priorytet działajacego
˛
procesu. Priorytet jest nazywany jest "liczba˛ nice". Mówi ona jak mili jesteśmy dla systemu i innych użytkowników.
Priorytet możemy ustawiać od -20 do +19, przy czym domyślna wartość zazwyczaj
wynosi 0. Ujemne wartości oznaczaja˛ wyższy priorytet, zaś dodatnie niższy. Ujemna˛
wartość może nadać tylko superużytkownik.
Aby uruchomić proces z priorytetem innym niż domyślny należy użyć programu
nice np.:
$ nice -n +5 mc
Działajacym
˛
procesom można zmieniać priorytet. Aby to zrobić używamy polecenia
renice:
$ renice +5 mc
Jak sprawdzić kto jest zalogowany oprócz nas?
Pierwsza˛ komenda˛ jest who. Podaje ona nam nazw˛e użytkownika, terminal na którym jest zalogowany oraz czas rozpocz˛ecia pracy.
$ who
gozda
gozda
gozda
gozda
gozda
gozda
gozda
tty1
pts/1
pts/4
pts/6
pts/8
pts/9
pts/10
Apr
Apr
Apr
Apr
Apr
Apr
Apr
18
18
18
18
18
18
18
10:52
16:21
11:06
14:46
16:25
18:25
18:29
Kolejna komenda w pokazuje nam kto jest zalogowany i co robi na poszczególnych
sesjach.
$ w
6:56pm
USER
gozda
gozda
gozda
gozda
gozda
gozda
up 8:05,
TTY
tty1
pts/1
pts/4
pts/6
pts/9
pts/10
7 users, load average: 1.94, 1.75, 1.61
FROM LOGIN@
IDLE
JCPU
PCPU WHAT
10:52am 8:03m 16.67s 0.02s sh /usr/X11R6/bin/startx
4:21pm 6:45
5.37s 5.32s irssi
11:06am 37:46
3.22s 3.17s ekg
2:46pm 10:17 12.66s 1.08s mp3blaster
6:25pm 0.00s 0.12s 0.03s w
6:29pm 22:07
3:58
0.02s ./mozilla-bin
Komenda users. Pokazuje ona pseudonimy użytkowników zalogowanych w systemie.
$ users
gozda gozda gozda gozda gozda gozda gozda
Poleceniem whoami dowiadujemy si˛e, jak nazywa si˛e użytkownik, na którym pracujemy.
$ whoami
gozda
51
52
Rozdział 9. Zarzadzanie
˛
pakietami
Ten rozdział opisuje metody zarzadzania
˛
pakietami w systemie PLD.
Informacje podstawowe
Wstep
˛
Instalowanie, deinstalowanie oraz aktualizowanie składników systemu operacyjnego to jedne z najważniejszych zadań administratora. Zautomatyzowanie tych procesów pozwala na znaczne przyspieszenie i ułatwienie zarzadzania
˛
systemem.
W świecie Otwartego Oprogramowania pomi˛edzy programami istnieja˛ liczne powiazania,
˛
które w efekcie wymuszaja˛ konieczność instalacji dodatkowych programów i/lub bibliotek. Pomini˛ecie tych zależności spowoduje problemy z działaniem
programu lub całkowity jego brak. Śledzenie tych zależności może przyprawić o ból
głowy wi˛ekszość administratorów. Na szcz˛eście istnieja˛ mechanizmy i narz˛edzia,
które pomagaja˛ znacznie zautomatyzować ten proces.
Pakiety w PLD
Elementy systemu operacyjnego dost˛epne sa˛ w tzw. pakietach (pot. "paczkach"). W
PLD zastosowano system pakietów RPM (RPM Packet Manager), który został stworzony przez twórców dystrybucji Red Hat Linux. Istnieje możliwość instalacji pakietów RPM przygotowanych dla innych dystrybucji, jednak nie skorzystamy wtedy z
dobrodziejstwa zależności dotyczacych
˛
danego pakietu. Wymagane dodatkowe pakiety należy wtedy zainstalować samodzielnie.
Menadżery pakietów
Do zarzadzania
˛
pakietami (instalacja, deinstalacja, uzyskiwanie informacji) używa
si˛e specjalnych programów zwanych menadżerami pakietów:
•
Poldek
Poldek to domyślny menadżer pakietów dla PLD. Jest nakładka˛ na RPM-a
o ogromnych możliwościach, pozwalajacym
˛
na znaczna˛ automatyzacj˛e
procesu zarzadzania
˛
dużymi ilościami pakietów. Jest "wołem roboczym"
odcia˛żajacym
˛
administratora w jego żmudnym zaj˛eciu. Konfiguracj˛e i opis Poldka
przedstawiono w sekcja Poldek.
•
PackageKit
Prosty zarzadca
˛
pakietów, dla środowiska X-Window. Został stworzony pierwotnie dla Gnome, ma także wersj˛e dla Qt. Jest to wygodne narz˛edzie, dobrze sprawujace
˛ si˛e przy zrzadzaniu
˛
niewielkimi ilościami pakietów. PackageKit wyświetla
na tacce systemowej dost˛epność aktualizacji. PackageKit jest świetnym wyborem
dla zupełnie niezaawansowanych użytkowników.
•
RPM
Niskopoziomowy zarzdca pakietów, używany zwykle w nietypowych i awaryjnych sytuacjach. Opis posługiwania si˛e tym programem zamieszczono w sekcja
RPM.
53
˛
pakietami
Pobieranie pakietów
Jedna˛ z najcz˛eściej używanych form instalacji jest instalacja z sieci, dlatego jeśli nie
zostanie podane inaczej to właśnie taka instalacja jest traktowana jako domyślna.
Używamy tej metody nawet jeśli system był instalowany z lokalnego źródła (np. z
dysku), choćby w celu aktualizacji systemu.
Menadżery pakietów sa˛ wst˛epnie skonfigurowane, Aby jednak instalować niestandardowe pakiety lub użyć innego źródła, musimy podać odpowiednie parametry.
Konfiguracja w tym zakresie jest opisana w sekcja Serwery z pakietami w Rozdział 2.
Cechy pakietów w PLD
Zależności miedzy
˛
pakietami
Istotna˛ cecha˛ pakietów RPM jest mechanizm tzw. zależności, dzi˛eki nim w trakcie
instalacji pakietu instalowane sa˛ automatycznie dodatkowe wymagane pakiety. Niekiedy w ramach zależności wymagana jest funkcjonalność dostarczana przez wi˛ecej
niż jeden pakiet. W takim wypadku zostaniemy zapytani o to który pakiet ma być
zainstalowany. Wynika to z filozofii PLD, która dopuszcza bogaty wybór oprogramowania spełniajacego
˛
ta˛ sama˛ rol˛e.
Istnieja˛ zależności wymagajace
˛ wzajemnego wykluczania si˛e pakietów, tak aby w
systemie była zainstalowany był tylko jeden program z pośród kilku dost˛epnych.
Jako przykład można wskazać serwery usług tego samego rodzaju lub pakiety zawierajace
˛ w nazwie słowa "inetd" oraz "standalone".
Dodatkowo system pakietów pilnuje, aby nie można było mieć zainstalowanych
dwóch wersji tego samego pakietu. Próba instalacji pakietu starszego niż ten, który mamy w systemie zakończy si˛e niepowodzeniem, zaś przy instalacji nowszego
nastapi
˛ jego aktualizacja.
Menadżery pakietów pozwalaja˛ na ignorowanie powyższych zależności, jest to jednak operacja nie zalecana, gdyż powoduje później trudny do ogarni˛ecia bałagan. Wyjatki
˛ od tej zasady powinny być robione jedynie w razie uzasadnionej konieczności,
takim przypadkiem jest np. aktualizacja kernela, operacja ta została opisana w sekcja
Jadro
˛ systemu w Rozdział 11.
Dawniej zależności były budowane na podstawie nazw pakietów, w tej chwili stopniowo wprowadzane sa˛ zależności na podstawie plików (programów, bibliotek itd.).
Zyskujemy w ten sposób elastyczność kosztem wygody w niektórych, rzadko spotykanych sytuacjach. W przypadku codziennej pracy z pakietami, nie odczujemy wi˛ekszych różnic i nie musimy si˛e tym martwić.
Wymagania (requires) i własności (provides)
Ważnymi elementami mechanizmu zależności sa˛ tzw. wymagania i własności. Pierwsza z cech wskazuje list˛e wymaganych dodatkowo elementów (pakietów, plików) do
działania instalowanej aplikacji, druga zaś informuje, które z elementów sa˛ dostarczane wraz z pakietem. Aby poznać wymagania pakietu posłużymy si˛e Poldkiem w
trybie interaktywnym:
poldek:/all-avail> desc -r logrotate
Package:
logrotate-3.7-2
PreReqs:
/bin/sh, fileutils
Requires:
/bin/mail, /bin/sh, config(logrotate) = 3.7-2, crondaemon,
glibc, libc.so.6, libc.so.6(GLIBC_2.0), libc.so.6(GLIBC_2.1),
libc.so.6(GLIBC_2.2), libc.so.6(GLIBC_2.3), libpopt.so.0, libselinux,
libselinux.so.1, popt
54
˛
pakietami
RPMReqs:
rpmlib(CompressedFileNames) <= 3.0.4-1,
rpmlib(PayloadFilesHavePrefix) <= 4.0-1,
rpmlib(PayloadIsBzip2) <= 3.0.5-1
Powyższe polecenie ma zadanie czysto informacyjne, gdyż jak już wspomniano zależnościami zajmie sie menedżer pakietów.
Sprawa nieco komplikuje si˛e w przypadku własności, ponieważ w PLD nierzadko
mamy dost˛epnych wiele pakietów spełniajacych
˛
podobne wymagania. Aby sprawdzić dostarczana˛ funkcjonalność ponownie użyjemy Poldka:
poldek:/all-avail> desc -p vixie-cron
Package:
vixie-cron-4.1-7
Provides:
config(vixie-cron) = 4.1-7, crondaemon, crontabs >= 1.7,
group(crontab)
Analizujac
˛ powyższe przykłady można dopatrzyć si˛e informacji o dostarczaniu własności crondaemon przez vixie-cron, która z kolei jest wymagana przez logrotate.
Własność crondaemon jest dostarczana przez wi˛eksza˛ ilość pakietów, możemy samodzielnie wybierać, który z pakietów ma być instalowany lub ustawić automatyczny
wybór. O tym decyduje ustawienie opcji choose equivalents manually w konfiguracji Poldka. Jeśli ustawimy opcj˛e na yes (zalecane) to instalacja programu może
wygladać
˛
nast˛epujaco:
˛
poldek:/all-avail> install logrotate
Przetwarzanie zależności...
Wi˛
ecej niż jeden pakiet udost˛
epnia właściwość "crondaemon":
a) anacron-2.3-22
b) fcron-3.0.0-3
c) hc-cron-0.14-22
d) vixie-cron-4.1-7
Which one do you want to install (’Q’ to abort)? [b]
Na powyższym przykładzie widać list˛e pakietów mogacych
˛
pełnić funkcj˛e demona zegarowego (crondaemon), dodatkowo podana jest domyślna wartość wyboru,
nie zawsze jest to najlepszy wybór dla konkretnej instalacji, dlatego powinniśmy si˛e
upewnić, że wybieramy najwłaściwszy pakiet. Wi˛ecej informacji o obsłudze i konfiguracji Poldka odnajdziemy w sekcja Poldek.
Zawartość pakietów
Pakiety moga˛ zawierać wiele małych programów i/lub bibliotek albo jeden duży
program może być podzielony na kilka pakietów. W PLD najcz˛eściej stosowane jest
to drugie rozwiazanie:
˛
osobno przechowywane sa˛ pliki uruchomieniowe, osobno biblioteki, a jeszcze osobno moduły, wtyczki i dodatki. Ponadto jeśli tylko można to sa˛
umieszczane w pojedynczych pakietach, dzi˛eki temu unikamy dużych, zbiorczych
paczek. Pozwala to instalować tylko to co jest nam potrzebne. Przykładowo jeśli program ABC wymaga bibliotek programu XYZ to instalujemy tylko pakiet z bibliotekami tego drugiego. Skraca to czas instalacji (zwłaszcza przy pobieraniu plików z
Internetu) i pozwala oszcz˛edzać miejsce na dysku.
Nierzadko do osobnych pakietów trafiaja˛ elementy aplikacji, które zostały przewidziane przez jej twórców jako kompletna instalacja. Nie należy si˛e tego obawiać,
gdyż mechanizm zależności wymusi instalacj˛e wszystkich wymaganych dodatkowo
pakietów.
Tak silne rozdrobnienie powoduje czasami, że do przy instalacji mechanizm zależności zaznacza spora˛ ilość dodatkowych pakietów. Potrafi to wprowadzić w konsternacj˛e, jednak nie należy si˛e tego obawiać, gdyż sa˛ to zazwyczaj małe pakiety i po
zainstalowaniu zajmuja˛ tyle samo lub mniej niż domyślna instalacja.
55
˛
pakietami
Aby ułatwić poruszanie si˛e w tym gaszczu,
˛
możemy posłużyć si˛e opisami pakietów:
poldek:/all-avail> desc proftpd-inetd
lub listami plików dostarczanych przez pakiet:
poldek:/all-avail> desc -f proftpd-inetd
Zdarza si˛e, że znamy nazw˛e pliku, ale nie wiemy w jakim pakiecie si˛e znajduje. Do
odnalezienia pakietu posłużymy si˛e poleceniem:
poldek:/all-avail> search -f */sendmail
Dodatkowo możemy korzystać z zamieszczonej dalej tabeli.
Konwencja nazw pakietów w PLD
Nazwy pakietów maja˛ nast˛epujac
˛ a˛ budow˛e: {$nazwa}-{$wersja}.{$arch}.rpm
np.: 0verkill-0.16-3.i686.rpm. Tak wygladaj
˛ a˛ nazwy pakietów w systemie
plików lub na serwerze FTP. W menedżerach pakietów posługujemy si˛e jedynie
nazwa˛ lub nazwa˛ i wersja˛ (nie liczac
˛ instalacji za pomoca˛ rpm-a).
Tabela 9-1. Opis zawartości pakietów w zależności od ich nazwy
Nazwa pakietu
Zawartość
program, program-core
główny pakiet programu, zawiera pliki
wykonywalne, dokumentacj˛e, skrypty
startowe w przypadku usług, niekiedy
biblioteki
program-common
podstawowe, wspólne pliki; zwykle
samodzielny taki pakiet jest
bezużyteczny i wymaga zainstalowania
dodatkowych pakietów
program-libs
zestaw bibliotek stworzonych na
potrzeby danego programu, sa˛ niekiedy
wymagane przez inne programy
program-tools, program-utils,
dodatkowe narz˛edzia, zwykle nie sa˛
program-progs
konieczne do podstawowej pracy
programu
program-extras
dodatkowe, rzadziej używane elementy
program-mod, program-plugin, różnej maści moduły, "wtyczki", applety
program-applets, program-addon
i dodatki przeważnie nie sa˛ konieczne
do podstawowej pracy programu
56
program-skin(s), program-theme(s)
"skórki" i "tematy" modyfikujace
˛ wyglad
˛
programu
program-driver
sterowniki
program-backend
specjalne interfejsy służace
˛ do
rozszerzania możliwości programu,
łaczenia
˛
z innymi programami,
sprz˛etem itp.
program-i18n
dodatkowe wersje j˛ezykowe
program-doc
dokumentacja programu
˛
pakietami
Nazwa pakietu
Zawartość
program-devel
pakiety potrzebne dla programistów i
osób które zajmuja˛ si˛e własnor˛eczna˛
kompilacja˛ programów, badź
˛
budowaniem pakietów.
program-static
program skompilowany statycznie - nie
wymaga bibliotek
program-debuginfo
informacje dla debuggera - pliki
użyteczne tylko dla osób badajacych
˛
problemy z działaniem programu
lib_nazwa_biblioteki
zestaw uniwersalnych bibliotek, nie
zwiazanych
˛
z żadnym konkretnym
programem.
usługa-inetd, usługa-standalone
alternatywne pakiety służace
˛ do wyboru
trybu pracy niektórych usług. Należy
wybrać jeden z nich: uruchamianie
przez Inetd lub praca w tle (standalone).
Pakiety te wzajemnie si˛e wykluczaja˛ na
poziomie mechanizmu zależności.
usługa-init
skrypty startowe programu
metapackage-program
metapakiet
program-legacy
starsze wersje programów lub
sterowniki do starszych urzadze
˛
ń
kernel
pakiety okołokernelowe, zostały
omówione w sekcja Jadro
˛ systemu w
Rozdział 11
Metapakiety
Wada˛ silnego rozdrobnienia pakietów jest pracochłonne zarzadzanie,
˛
aby temu zaradzić stworzono tzw. metapakiety, zwane również pakietami wirtualnymi. Sa˛ to pakiety zawierajacy
˛ jedynie wymagania (requires), nie zawieraja˛ żadnych plików, ani
własności (provides). Ich zadaniem jest zautomatyzowana instalacja wi˛ekszych grup
pakietów oraz utrzymanie wstecznej zgodności w nazwach.
Cz˛eść metapakietów łatwo odnajdziemy dzi˛eki nazwie, która zawiera słowo
metapackage, np. metapackage-gnome. Aby poznać list˛e wymagań takiego pakietu,
użyjemy opisanego nieco wcześniej polecenia desc -r trybu interaktywnego
Poldka.
Komunikaty
Prace przy zarzadzaniu
˛
pakietami niekiedy kończa˛ si˛e komunikatami skierowanymi
do administratora, sa˛ to dość ważne informacje, dlatego powinniśmy je uważnie czytać. Zazwyczaj dotycza˛ plików konfiguracji, zarzadzania
˛
użytkownikami/grupami,
modyfikacji systemu rc-skryptów oraz zalecenia dalszego post˛epowania po instalacji
pakietu. Dla przykładu poniżej przedstawiono komunikaty wyświetlane po instalacji Exim-a:
Adding group exim GID=79.
Adding user exim UID=79.
Run "/etc/rc.d/init.d/exim start" to start exim daemon.
57
˛
pakietami
Wpływ pakietów na prace˛ systemu
Pakiety, oprócz plików programu, zawieraja˛ dokumentacj˛e, przykładowe pliki konfiguracji, strony podr˛ecznika systemowego (man, info) oraz automatyk˛e. Owa automatyka jest uruchamiana w trakcie instalowania badź
˛ odinstalowania pakietu i
wykonuje konieczne prace w systemie, dzi˛eki czemu zmniejsza si˛e nakład pracy administratora do absolutnego minimum. Jest tak skonstruowana, aby nie zaskakiwać
administratora w najmniej oczekiwanych momentach oraz zapewnić nieprzerwanie
działanie systemu, poniżej przedstawiono kilka przykładów jej działania.
Jeśli instalujemy w systemie jakaś
˛ usług˛e to zostanie zapisana odpowiednia informacja do skryptów startowych i nowe oprogramowanie uruchomi si˛e przy najbliższej
zmianie trybu pracy lub restarcie systemu. Jeżeli jakaś usługa jest wyłaczona
˛
z działania i nastapi
˛ jej aktualizacja, to w dalszym ciagu
˛ nie b˛edzie uruchamiana.
Jeśli działa usługa, a my ja˛ zaktualizujemy lub doinstalujemy dodatkowy moduł, to
zostanie ona automatycznie zrestartowana lub taka operacja zostanie zasugerowana przez pakiet. B˛edzie to zależało od ustawienia opcji RPM_SKIP_AUTO_RESTART w
konfiguracji rc-skryptu lub globalnie w /etc/sysconfig/rpm - opcja przyjmuje wartość yes/no. Konfiguracj˛e rc-skryptów dokładniej omówiono w sekcja Zarzadzanie
˛
podsystemami i usługami w Rozdział 14.
Wpływ pakietów na pliki konfiguracji
Po aktualizacji pakietu nie sa˛ naruszanie istniejace
˛ pliki konfiguracji, nowe wersje
tych plików sa˛ zapisywane z rozszerzeniem ".rpmnew". Przykładowo po zaktualizowaniu pakietu sudo obok pliku /etc/sudoers pojawi si˛e nowy plik o nazwie
/etc/sudoers.rpmnew, tak wi˛ec zaktualizowany program b˛edzie używał starego
pliku konfiguracji. W wi˛ekszości wypadków nie b˛edzie to stanowić problemu, jednak dla pewności należy skonfigurować plik dostarczony z nowszym pakietem na
wzór poprzedniej konfiguracji i zmienić mu nazw˛e poprzez usuni˛ecie omawianego
rozszerzenia. Jest to pierwsza rzecz, która˛ należy sprawdzić w razie problemów z
działaniem programu po aktualizacji.
Kiedy odnajdziemy plik *rpmnew to możemy łatwo sprawdzić czym różni si˛e jego
zawartość w stosunku do obecnie używanego pliku konfiguracji. Posłużymy si˛e w
tym celu programem diff z pakietu diffutils np.:
# diff jakis_plik.conf jakis_plik.conf.rpmnew
W przypadku niektórych programów, po odinstalowaniu pakietu, pozostawiane sa˛
jego pliki konfiguracji, posiadaja˛ one rozszerzenie ".rpmsave", możemy je zachować
lub skasować jeśli uznamy że sa˛ nam zb˛edne.
Osoby chcace
˛ trzymać porzadek
˛
w systemie powinny zajmować si˛e plikami .rpmnew
i .rpmsave od razu po pracy z menadżerem pakietów. Pliki łatwo odnajdziemy, gdyż
wyst˛epuja˛ zwykle w katalogu /etc, odszukamy je nast˛epujaco:
˛
$ find /etc -name "*rpmnew"
$ find /etc -name "*rpmsave"
Architektury pakietów
W PLD programy sa˛ kompilowane dla wielu architektur sprz˛etowych, pozwala to
na używanie systemu na bardziej różnorodnym sprz˛ecie oraz na lepsze dopasowanie do używanego procesora. Architektur˛e pakietu rozpoznamy po nazwie, jest to
58
˛
pakietami
kilkuznakowe oznaczenie znajdujace
˛ si˛e tuż przed rozszerzeniem pliku. W przypadku pakietu 0verkill-0.16-3.i686.rpm jego architektura to i686.
Aby sprawdzić architektur˛e komputera, używamy polecenia arch lub uname -m.
Wybór architektury
Pakiety zbudowane dla poszczególnych architektur sa˛ umieszczane w odpowiednich katalogach na serwerze. Ścieżka katalogów na serwerze wyglada
˛ nast˛epujaco:
˛
/dists/{$wersjaPLD}/PLD/{$architektura}
Przykładowo adres ftp://ftp.pld-linux.org/dists/2.0/PLD/i686/ dotyczy systemu w wersji 2.0 (Ac) z wybrana˛ architektura˛ "i686". Poldek instaluje pakiety z tej architektury,
do której należał pakiet z Poldkiem, co w zasadzie jest jednoznaczne z architektura,˛
która została wybrana przy instalacji. Konfiguracja źródeł pakietów w Poldku została opisana w sekcja Poldek.
Procesory
Tabela 9-2. Lista nazw kodowych architektur i odpowiadajacych
˛
im rodzin procesorów:
Nazwa architektury
Obsługiwana platforma
Dostepna
˛
wersja PLD
alpha
DEC/Compaq/HP Alpha
AXP
Ra, Ac
amd64 / x86_64
AMD K8: Opteron, Athlon
64, Sempron (socket: 754,
939), Intel EM64T
Ac, Th
athlon
AMD K7: Athlon, Duron,
Sempron (socket A)
Ac
i386
wszystkie procesory
zgodne z i386 firmy Intel
Ra, Ac
i486
Intel 486, AMD K5 (socket
3) i nowsze
Th
i586
Intel 586 Pentium, Cyrix
5x86, Cyrix 6x86, AMD K5
(socket 7), AMD K6 i
nowsze
Ra, Ac
i686
Intel Pentrium II, Pentium
PRO, AMD K7 i nowsze
Ra, Ac, Th
ppc
PowerPC
Ra, Ac
sparc
Sun SPARC 32bit
Ra, Ac
sparc64
Sun SPARC 64bit
Ac
noarch
dowolna
-
Należy pami˛etać by instalować pakiety wyłacznie
˛
przeznaczone dla używanej architektury. Wyjatkiem
˛
sa˛ pakiety z oznaczeniem noarch oraz pakiety przeznaczone dla
procesorów Intel x86 i zgodnych: i386, i486, itd.
Architektury z rodziny x86 sa˛ bardziej lub mniej wyspecjalizowanymi grupami, najbardziej ogólna jest 386, zaś każda nast˛epna w kolejności jest bardziej wyspecjalizo59
˛
pakietami
wana. Im w˛eższa specjalizacja grupy tym mniej modeli procesorów obsługuje. Przykładowo na maszynie z procesorem Pentium III (i686) możemy zainstalować system
w wersji i386, ale na procesorze 386 wersja i686 nie b˛edzie działać. Jeśli mamy nowszy procesor, to b˛edziemy mogli użyć bardziej wyspecjalizowanej architektury, a co
za tym idzie lepiej wykorzystać jego potencjał.
Źródła pakietów
W PLD jest kilka grup pakietów (źródeł) w ramach tej samej wersji dystrybucji, różnia˛ si˛e one wersjami pakietów i zastosowaniem. Ich list˛e uzyskamy za pomoca˛ Poldka:
$ poldek -l
W wi˛ekszości wypadków, b˛edziemy korzystać z głównego źródła (main), jednak od
czasu do czasu potrzeba zaktualizować system lub pobrać niestandardowe wersje
pakietów, właśnie wtedy z nich skorzystamy. Źródła sa˛ oznaczane za pomoca˛ etykiet:
•
main (np. th): główne źródło pakietów (domyślne), zawiera stabilne wersje, od
chwili wydania danej wersji dystrybucji, nie sa˛ tu dokonywane żadne zmiany
•
obsolete (np. th-obsolete): stare pakiety, usuni˛ete z main w wyniku aktualizacji.
Dzi˛eki temu źródłu, możemy wrócić do starszej wersji pakietu, jeśli zajdzie taka
konieczność. Źródło wprowadzone w Th.
•
test (np. th-test): trafiaja˛ tu pakiety prostu z builderów, bez sprawdzenia czy w
ogóle działaja˛ i czy sa˛ spełnione zależności. Używanie pakietów z tego źródła jest
dosyć ryzykownym krokiem, dlatego należy go wykonywać wyłacznie
˛
w ostateczności
•
ready (np. th-ready): nast˛epny krok w życiu pakietu, jeśli pakiety działaja˛ bez
zarzutu, to sa˛ przenoszone razem z zależnościami do main. Pakiety te sa˛ już wst˛epnie przetestowane, nadal jednak powinniśmy zachować ostrożność instalujac
˛ pakiety z tego katalogu
•
debuginfo (np. th-debuginfo, th-ready-debuginfo): pakiety zawierajace
˛
wyłacznie
˛
symbole potrzebne przy debugowaniu. Pakiety te sa˛ pomocne dla
programistów i deweloperów.
•
home: źródło lokalne, pozwala łatwo instalować pakiety z katalogu ~/rpm/RPMS miejsca domyślnego umieszczania własnor˛ecznie zbudowanych pakietów.
Multilib
W środowisku x86_64 możemy używać także aplikacji 32 bitowych, aby
wygodnie instalować pakiety zostały przygotowane źródła multilib
/etc/poldek/repos.d/pld-multilib.conf. Domyślnie sa˛ przygotowane dla i686.
Źródła używane w starszych wersjach PLD:
•
updates (np. ac-updates) - aktualizacje, zaleca si˛e regularne sprawdzanie
czy nie pojawiaja˛ si˛e tu nowe pakiety, źródło stało si˛e zb˛edne w Th i nie jest
używane. W Th w roli updates używa si˛e źródła ready. W Ra istniały dwa
niezależne źródła pakietów z aktualizacjami: {$wersja}-updates-security i
{$wersja}-updates-general. W Ac nastapiło
˛
ich połaczenie
˛
i od tej pory źródło
nazywa si˛e {$wersja}-updates.
•
supported (np. ac-updates) - nietypowe pakiety, które nie powinny być trzymane
w głównym źródle. Sa˛ tu umieszczane pakiety rzadko używane lub starsze wersje,
podobnie jak updates przestało mieć racj˛e bytu w Th.
Aby wybrać źródło inne niż domyślne należy użyć parametru -n np.:
60
˛
pakietami
$ poldek -n th -n th-ready
Należy pami˛etać, że użycie każdego źródła b˛edzie możliwe dopiero po pobraniu
aktualnych indeksów:
$ poldek -n debuginfo --up
Ścieżki do podstawowych źródeł w konfiguracji Poldka
Poldek
jest
dostarczany
sa˛
one
zdefiniowane
z
właściwie
skonfigurowanymi
etykietami,
w
plikach
/etc/poldek/source.conf
i
/etc/poldek/repos.d/pld.conf. Adresy oficjalnych serwerów i mirrorów
znajdziemy w sekcja Serwery z pakietami w Rozdział 2. Etykieta źródła rozpoczyna
si˛e od przedrostka określajacego
˛
wersj˛e dystrybucji, zapisana˛ małymi literami,
poniżej przedstawiono ja˛ jako ciag
˛ {$wersja}, który może mieć wartość np. ra, ac
lub th. Ciag
˛ {$arch} to architektura pakietów.
•
main: dists/{$wersja}/PLD/{$arch}/PLD/RPMS
•
obsolete: dists/{$wersja}/obsolete/{$arch}/RPMS
•
test: dists/{$wersja}/test/${arch}/
•
ready: dists/{$wersja}/ready/${arch}/
•
home: katalog lokalny: ~/rpm/RPMS
Cykl życia pakietu
Zbudowany pakiet trafia do test gdzie oczekuje na zbudowanie zależności, nast˛epnie jest przenoszony przez RM-a do ready. kiedy wszytko jest w porzadku
˛
trafia w
końcu do main/updates. W przypadku bardziej krytycznych pakietów kiedy pojawia
si˛e aktualizacja to starsza wersja trafia do obsolete. Proces ten został szerzej opisany
w podr˛eczniku dewelopera1.
Budowanie pakietów
Wstep
˛
W wi˛ekszości wypadków b˛edziemy korzystali z gotowych pakietów, zdarza si˛e jednak, że nie ma dost˛epnego jakiegoś pakietu lub nie odpowiadaja˛ nam opcje z jakimi
został skompilowany. Co wi˛ecej może si˛e zdarzyć, że b˛edziemy potrzebować starszej, niedost˛epnej już wersji programu.
W takim wypadku nie powinniśmy pod żadnym pozorem kompilować samodzielnie
programów, jeśli nie upewnimy si˛e, że nie można go zbudować.
Budowanie
Budowanie jest operacja˛ tworzenia pakietów na podstawie plików spec, do tego nie
potrzeba umiej˛etności tworzenia speców ani wiedzy dewelopera. Wystarczy odpowiednio przygotować środowisko, zainstalować kilka pakietów i użyć odpowiedniego narz˛edzia. Tak utworzymy nasz własny, prywatny builder, który może nam
wielokrotnie służyć.
61
˛
pakietami
Opis budowania pakietów odnajdziemy w przewodniku dla deweloperów
PLD,
wszystkie
potrzebne
informacje
odnajdziemy
pod
adresem
pld-linux.org/DevelopingPLD2 oraz w sekcja Co jest potrzebne w Rozdział 19.
Zarzadzanie
˛
Jeśli utworzymy środowisko wg. podanych wskazówek pakiety b˛eda˛ umieszczane
w katalogu ~/rpm/RPMS. Ułatwi to ich instalacj˛e, gdyż Poldek ma ustawione lokalne
źródło dla tego katalogu. Zbudowany pakiet b˛edziemy mogli instalować dowolna˛
ilość razy, warto wi˛ec przechowywać je uznamy że moga˛ nam si˛e jeszcze przydać.
Jeśli wymagamy od programu nietypowej funkcjonalności i budujemy pakiet z niestandardowymi opcjami to może si˛e zdarzyć, że przy aktualizacji zastapimy
˛
nasza˛
wersj˛e programu ta˛ z pakietu dystrybucyjnego. Dlatego musimy być czujni przy operacji aktualizacji lub dopisać nazw˛e tego pakietu do opcji hold w pliku konfiguracji
Poldka.
Poldek
Wstep
˛
Poldek jest nakładka˛ na program rpm, zapewniajac
˛ a˛ wygodny interfejs obsługi oraz
kilka dodatkowych funkcji. Poldek jest pośrednikiem w pobieraniu pakietów, indeksuje ich listy oraz ułatwia zarzadzanie
˛
wieloma źródłami, może pobierać pakiety lokalnie (dyski twarde, nap˛edy optyczne) lub z sieci (FTP, HTTP, HTTPS, SMB,
RSYNC). Obsługuje ponadto zależności miedzy pakietami, wykrywa konflikty itp.
Poldek nie obsługuje jednak wszystkich operacji możliwych na pakietach RPM, dlatego nie może całkowicie zastapić
˛
programu rpm.
Poldek do wielu operacji (pobieranie pakietów i indeksów, wyszukiwanie informacji
itp.) nie wymaga praw administratora, wymagane sa˛ jednak do operacji zapisu w
systemie, np. instalowanie, odinstalowanie, itp. Poldek w tym celu automatycznie
używa programu sudo, z tego wzgl˛edu konieczne jest posiadanie skonfigurowanego
sudo, w przeciwnym razie pozostaje nam uruchamianie programu z konta roota.
Konfiguracja Poldka jest dość złożona i wyjaśnienie wszystkich szczegółów zaj˛eło by
zbyt wiele miejsca, dlatego zajmiemy si˛e jedynie najcz˛eściej używanymi opcjami. Nie
powinniśmy si˛e jednak tym przejmować, program jest gotowy do działania od razu
po zainstalowaniu i w wi˛ekszości wypadków nie ma potrzeby nic modyfikować.
Musimy jednak si˛e upewnić, że mamy dobrze skonfigurowane adresy serwerów i
architektur˛e pakietów, co zostało omówione w dalszej cz˛eści rozdziału.
Wi˛ecej informacji o poldku i jego konfiguracji odnajdziemy w podr˛eczniku systemowym (man,info) oraz na witrynie projektu pod adresem http://poldek.pld-linux.org.
Pliki konfiguracji
Konfiguracja Poldka jest przechowywana w kilku plikach wewnatrz
˛
katalogu
/etc/poldek, to czy dany plik konfiguracji jest używany określa opcja %include,
umieszczona w głównym pliku konfiguracji.
- główny plik konfiguracji, jeśli nie zostało zaznaczone inaczej to
właśnie ten plik ma na myśli autor
• poldek.conf
• aliases.conf
62
- zawiera zdefiniowane aliasy poleceń dla trybu interaktywnego
˛
pakietami
- zawiera konfiguracj˛e alternatywnych programów do pobierania pakietów, domyślnie konfiguracja z tego pliku nie jest wczytywana.
• fetch.conf
• repos.d/pld.conf
• source.conf
• .poldekrc
- ustawienia źródeł pakietów dla PLD
- plik przeznaczony dla lokalnych źródeł pakietów
- plik konfiguracji użytkownika, który umieszczamy w katalogu do-
mowym.
Konfiguracja pobierania pakietów
W pliku repos.d/pld.conf mamy dwie ważne opcje wskazujace
˛ skad
˛ maja˛ być pobierane pakiety. Opcja _pld_arch wskazuje architektur˛e sprz˛etowa˛ pakietów, zaś
_pld_prefix mówi skad
˛ maja˛ być pobierane pakiety i dla jakiej wersji dystrybucji.
Wi˛ecej o architekturach pakietów znajdziemy w sekcja Architektury pakietów, adresy
serwerów i oficjalnych mirrorów zawarto w sekcja Serwery z pakietami w Rozdział 2.
Poldek zacznie korzystać z proxy po ustawieniu właściwych zmiennych środowiskowych - zarówno w przypadku wbudowanego klienta jak i klientów zewn˛etrznych
(np. wget). Możemy też użyć opcji proxy. Konfiguracj˛e proxy dla Linuksa szerzej
opisano w sekcja Proxy w Rozdział 7.
Inne opcje
Poldek przechowuje indeksy pakietów w katalogu zdefiniowanym w opcji
cachedir, domyślnie jest to $HOME/.poldek-cache. Jest to dobre rozwiazanie
˛
jeśli z
Poldka korzysta jeden użytkownik, jeśli ma używać go wi˛ecej osób to lepiej
ustawić wspólny katalog np. /var/cache/poldek-cache, w ten sposób unikniemy
wielokrotnego pobierania indeksów.
use sudo - użycie sudo przy uruchomieniu z konta zwykłego użytkownika.
hold - blokuje aktualizacj˛e pakietów które znalazły si˛e na jej liście.
ignore - opcja ukrywajaca
˛ podane pakiety na liście dost˛epnych.
choose equivalents manually - pozwala wybierać użytkownikowi jeden z kilku
pakietów oferujacych
˛
ta˛ sama˛ funkcjonalność, domyślnie wyłaczona
˛
przez co wybór
nast˛epuje automatycznie. Pozwala bardzo precyzyjnie wybierać pakiety do zainstalowania.
Tryby pracy
Kolejna˛ ważna˛ jego cecha˛ jest możliwość pracy zarówno w trybie wsadowym jak i interaktywnym. Pierwszy z nich nadaje do wszelkiej maści skryptów i automatyki, zaś
drugi jest wygodniejszy do bezpośredniej obsługi przez użytkownika. Komfort pracy w trybie interaktywnym sprawia, że użytkownicy na co dzień korzystaja˛ niemal
zawsze z niego. Stad
˛ jeśli nie zostało to inaczej napisane to właśnie ten tryb autor ma
na myśli.
Tryb interaktywny
Praca w trybie interaktywnym przypomina do złudzenia używanie powłoki systemowej (shella). Dost˛epne sa:˛ historia poleceń, pomoc, dopełnianie komend i nazw
pakietów, aliasy, potoki itp. Na potrzeby tego rozdziału w przykładach taki tryb b˛edziemy sygnalizować nast˛epujacym
˛
znakiem zach˛ety:
poldek>
63
˛
pakietami
Jedna˛ z najwi˛ekszych zalet trybu interaktywnego jest dopełnianie nazw pakietów i
poleceń za pomoca˛ tabulatora. Przykładowo naciśni˛ecie klawisza tab po poleceniu:
poldek> upgrade
spowoduje wyświetlenie listy pakietów, dla których sa˛ dost˛epne aktualizacje.
W przypadku nazw pakietów możemy używać "gwiazdki" jako znaku zast˛epczego
(wildcard), który zast˛epuje dowolny ciag
˛ znaków. Przedstawiono to na poniższym
przykładzie, który spowoduje zainstalowanie wszystkich pakietów o nazwach zaczynajacych
˛
si˛e od "gnome-theme"
poldek> install gnome-theme*
Zazwyczaj nie ma potrzeby podawania wersji programu, jednak w pewnych przypadkach możemy mieć dost˛epnych kilka wersji tego samego pakietu (np. przy używaniu wielu źródeł na raz). Wtedy musimy podać jednoznacznie wersj˛e pakietu.
Mamy do dyspozycji potoki:
poldek> ls perl* | grep curses
Możemy również wywoływać polecenia zewn˛etrzne:
poldek> ls perl* | !wc -l
W obsłudze źródeł i pakietów wyst˛epuje wiele podobieństw do systemu plików. Źródła sa˛ traktowane jak katalogi zaś pakiety jak pliki, do poruszania si˛e w tym środowisku używamy poleceń takich jak pwd, ls oraz cd.
Tryb wsadowy
Opis wszystkich parametrów trybu wsadowego uzyskamy dzi˛eki poleceniu
$ poldek --help
Jest tam całe bogactwo opcji, dzi˛eki którym b˛edziemy mogli ułatwić sobie prac˛e. Na
szczególna˛ uwag˛e zasługuje parametr --shcmd pozwalajacy
˛ wydawać polecenia w
trybie wsadowym jak w trybie powłoki np.:
$ poldek --shcmd="desc apache"
Możemy w tym celu użyć również polecenia ipoldek, np.:
$ ipoldek desc apache
Pierwsze kroki z Poldkiem
Poldek uruchomiony po raz pierwszy (bez podawania parametrów) sprawdza czy
istnieja˛ indeksy dla źródeł, które ma automatycznie obsługiwać. Jeśli ich nie ma, to
zostana˛ automatycznie pobrane i zapisane w miejscu wskazanym przez omówiona˛
powyżej opcj˛e cachedir. Po tej operacji zostanie uruchomiony Poldek trybie interaktywnym i b˛edzie gotowy do pracy. Przed każda˛ kolejna˛ praca˛ z programem musimy
64
˛
pakietami
uaktualnić indeksy pakietów, na wypadek gdyby w źródłach nastapiły
˛
zmiany, w
przeciwnym razie możemy otrzymywać komunikaty o braku pakietów. Aby uaktualnić indeksy domyślnych źródeł wywołujemy nast˛epujaco
˛ program z powłoki systemowej:
$ poldek --up
Aby pobrać na nowo indeksy wywołujemy Poldka z parametrem --upa, dla pozostałych źródeł musimy podać ich nazw˛e po parametrze -n, źródła pakietów zostały
omówione w dalszej cz˛eści rozdziału.
Po uruchomieniu programu mamy od razu możliwość zarzadzania
˛
pakietami, aby
zobaczyć list˛e dost˛epnych poleceń wpisujemy help i naciskamy klawisz Enter. Wi˛ekszość poleceń ma składni˛e:
poldek> {$polecenie} {$pakiet} {$opcje}
Opis dodatkowych parametrów znajdziemy w pomocy danego polecenia, po napisaniu:
poldek> {$polecenie} -?
Aby opuścić program wpisujemy polecenie quit lub wciskamy ctrl+d
Zarzadzanie
˛
pakietami
Mamy dost˛epne nast˛epujace
˛ polecenia zarzadzania
˛
pakietami: operacje instalacji
(install), aktualizacji pakietów (upgrade), usuwania pakietów (uninstall),
pobierania pakietów bez instalacji (get). Ponadto mamy polecenia do zbierania
danych o pakietach: wyświetlanie listy dost˛epnych (ls), wyświetlenia informacji
(desc) oraz przeszukiwania bazy (search). W wielu przypadkach pomocna b˛edzie
opcja -t, która przeprowadzi symulacj˛e całej operacji, dzi˛eki której dowiemy si˛e jak
duże i jak istotne zmiany zostana˛ dokonane w systemie po operacji. Najcz˛eściej jest
używana przy aktualizacji i usuwaniu pakietów.
Poniżej zamieszczono kilka przykładów zarzadzania
˛
pakietami, na poczatek
˛
przykład wyświetlenia listy pakietów (wszystkich zaczynajacych
˛
si˛e od zsh):
poldek> ls zsh*
wyświetlenie informacji o pakiecie:
poldek> desc zsh
instalacja pakietu:
poldek> install zsh
deinstalacja:
poldek> uninstall zsh
To jedynie podstawowe polecenia, wi˛ecej informacji znajdziemy w pomocy Poldka.
65
˛
pakietami
Źródła
Poldek ma kilka zdefiniowanych źródeł pakietów w plikach source.conf i
repos.d/pld.conf, pierwszy z plików jest głównym plikiem konfiguracji
źródeł, drugi zaś zawiera wpisy dla oficjalnych źródeł PLD. Aby wyświetlić list˛e
skonfigurowanych źródeł, wraz użytymi opcjami użyjemy polecenia:
$ poldek -l
ac
ftp://ftp.ac.pld-linux.org/dists/ac/PLD/athlon/PLD/RPMS/ (type=pndir)
ac-ready
ftp://ftp.ac.pld-linux.org/dists/ac/ready/athlon/ (noauto,type=pndir)
ac-supported ftp://ftp.ac.pld-linux.org/dists/ac/supported/athlon/ (noauto,type=pndir)
ac-test
ftp://ftp.ac.pld-linux.org/dists/ac/test/athlon/ (noauto,type=pndir)
ac-updates-general ftp://ftp.ac.pld-linux.org/dists/ac/updates/general/athlon/ (noauto
ac-updates-security ftp://ftp.ac.pld-linux.org/dists/ac/updates/security/athlon/ (type
home
/home/users/qwiat/rpm/RPMS/ (noauto,noautoup,type=dir)
Nie wszystkie źródła sa˛ obsługiwane automatycznie, zależy to od ustawienia opcji
noauto w konfiguracji danego źródła (zauważymy ja˛ też na powyższym zrzucie
ekranu). Aby tymczasowo użyć innego zestawu źródeł przy uruchomieniu musimy
podać ich list˛e poprzedzonych parametrem -n np.:
$ poldek -n ac -n ac-ready
Teraz lista dost˛epnych pakietów b˛edzie si˛e składała z zawartości źródeł ac i
ac-ready, jeśli chcemy, aby zawsze korzystał z niestandardowego zestawu źródeł
wygodniej b˛edzie zmodyfikować ustawienie opcji noauto. Oficjalne źródła PLD
zostały wyczerpujaco
˛ omówione w sekcja Źródła pakietów.
Istnieje możliwość instalacji pakietów Poldkiem z lokalnych źródeł, zamiast posługiwania si˛e programem rpm. W pliku source.conf zdefiniowane jest źródło home,
które służy do wygodnego instalowania pakietów z katalogu $HOME/rpm/RPMS, używanego powszechnie do umieszczania samodzielnie budowanych pakietów. Nie ma
jednak potrzeby każdorazowego umieszczania tam pakietów jeśli to uznamy za konieczne. Możemy utworzyć tymczasowe źródło lokalne na podstawie zawartości katalogu za pomoca˛ opcji -s:
poldek -s /jakis/katalog
Poldek po uruchomieniu tworzy dla wygody dodatkowe źródła wirtualne:
all-avail i installed. Pierwsze zawiera sum˛e pakietów ze wszystkich
wskazanych źródeł, drugie to lista zainstalowanych pakietów.
Przy pracy z samodzielnie podawanymi źródłami należy wskazywać też główne źródło pakietów (main), tak aby mogły zostać pobrane pakiety wymagane w ramach zależności. W przeciwnym razie możemy otrzymać bł˛edy o nieistniejacych
˛
pakietach.
Porady
Przy pracy z wieloma pakietami możemy utracić możliwość przewini˛ecia ekranu w
celu odczytania najstarszych komunikatów. Aby temu zaradzić użyjemy opcji --log,
dzi˛eki której, wskażemy plik do którego trafia˛ wszystkie komunikaty.
66
˛
pakietami
RPM
Instalowanie pakietów
Używajac
˛ programu rpm posługujemy si˛e nast˛epujacym
˛
schematem: rpm [opcje]
pakiet.rpm
Instalacja pakietu jest dosyć prosta. Załóżmy że pobraliśmy z sieci plik
docbook-dtd31-sgml-1.0-12.noarch.rpm, teraz jedyna˛ rzecza˛ jaka˛ musimy
wykonać jest wydanie polecenia rpm z opcja˛ -i. Używajac
˛ kombinacji -ivh dla
procesu instalacji, -Uvh uzyskamy pasek post˛epu instalacji dla poszczególnych
instalowanych pakietów.
# rpm -i docbook-dtd31-sgml-1.0-12.noarch.rpm
Brak ostrzeżeń lub bł˛edów oznacza prawidłowa˛ instalacj˛e, teraz nieco skomplikujemy sytuacj˛e:
# rpm -i libghttp-devel-1.0.9-4.i686.rpm
error: failed dependencies:
libghttp = 1.0.9 is needed by libghttp-devel-1.0.9-4
Tym razem instalacja si˛e nie powiodła, ponieważ pakiet libghttp-devel wymaga
zainstalowanego pakietu libghttp. Aby instalacja pakietu si˛e powiodła wykonujemy nast˛epujace
˛ polecenie:
# rpm -i libghttp-devel-1.0.9-4.i686.rpm libghttp-1.0.9-4.i686.rpm
Teraz wszystko jest w porzadku,
˛
oba pakiety sa˛ zainstalowane. Możliwe jest instalowanie pakietu z opcja˛ ignorowania zależności: --nodeps, opcj˛e ta˛ stosujemy jednak
w ostateczności.
Aktualizowanie pakietów
Aktualizacja przebiega podobnie jak instalacja, tyle że używamy przełacznika
˛
-U np.:
# rpm -U docbook-dtd31-sgml-1.0-13.noarch.rpm
Należy pami˛etać o tym, że aktualizacja nastapi
˛ tylko wtedy gdy w systemie jest zainstalowana starsza wersja, w przeciwnym wypadku zostaniemy poinformowani, że
pakiet jest już zainstalowany. Aby dokonać reinstalacji pakietu wykonujemy polecenie
# rpm -i docbook-dtd31-sgml-1.0-13.noarch.rpm --force
Odinstalowywanie pakietów
Zainstalowaliśmy kilka pakietów, teraz możemy spróbować je odinstalować - wykonujemy to przy użyciu opcji -e.
# rpm -e libghttp-devel-1.0.9-4.i686.rpm libghttp-1.0.9-4.i686.rpm
error: package libghttp-devel-1.0.9-4.i686.rpm is not installed
error: package libghttp-1.0.9-4.i686.rpm is not installed
Cóż tu si˛e stało? Podano nieprawidłowa˛ nazw˛e pakietu, należy pami˛etać o tym, że
przy odinstalowaniu pakietu nie podaje si˛e rozszerzenia pakietu. Poprawne polecenie przedstawiono poniżej:
67
˛
pakietami
# rpm -e libghttp-devel libghttp
lub:
# rpm -e libghttp-devel-1.0.9-4 libghttp-1.0.9-4
Uwaga: pierwszy przykład stosuje si˛e w przypadku zainstalowania jednej wersji pakietu, drugi zaś używa si˛e w przypadku kilku różnych (np. dwie różne wersje jadra).
˛
Uwagi
Program rpm posiada o wiele bogatsze opcje, przedstawiono tu zaledwie kilka najważniejszych, wi˛ecej można znaleźć w podr˛eczniku systemowym (man/info).
Bezpieczeństwo
Uruchamianie Poldka
Dobrym zwyczajem jest używanie Poldka z poziomu zwykłego użytkownika z wła˛
czona˛ obsługa˛ sudo:
use sudo = yes
Jest to domyślne zachowanie Poldka, dzi˛eki temu dla operacji wymagajacych
˛
uprawnień superużytkownika używany jest program sudo. Oczywiście w systemie musi
być zainstalowany pakiet sudo, a dany użytkownik musi być uprawniony do jego
używania.
Podpisy pakietów
W PLD mamy możliwość kontrolowania podpisów pakietów, dzi˛eki czemu zyskujemy pewność, że instalujemy pakiety z zaufanego źródła. Importujac
˛ klucz klucz
publiczny GPG unikamy również zasypywania nast˛epujacymi
˛
komunikatami:
Nagłówek V3 sygnatura DSA: NOKEY, key ID 1bbd5459
Zaczynamy od zaimportowania klucza publicznego (dla Ac) z serwera FTP:
rpm --import ftp://ftp.pld-linux.org/dists/2.0/PLD-2.0-Ac-GPG-key.asc
Od tej pory nie zobaczymy żadnych komunikatów z ostrzeżeniami, warto dodatkowo zabezpieczyć si˛e przed przypadkowym zainstalowaniem niepodpisanych pakietów. Wystarczy, że do każdego z podpisanych źródeł zdefiniowanych w pliku
/etc/poldek/pld-source.conf dodajemy wiersz:
signed = yes
przykładowe źródło b˛edzie wygladało
˛
nast˛epujaco:
˛
[source]
type = %{_ac_idxtype}
name = ac
path = %{_pld_prefix}/PLD/%{_pld_arch}/PLD/RPMS/
signed = yes
68
˛
pakietami
Teraz Poldek b˛edzie ostrzegał przy instalacji niepodpisanego pakietu:
uwaga: rhythmbox-0.9.8-2.athlon.rpm: gpg/pgp nie znaleziono podpisu
bład:
˛
rhythmbox-0.9.8-2: signature verification failed
Wystapiły
˛
bł˛
edy weryfikacji podpisu. Kontynuować? [y/N]
Wi˛ecej informacji w dokumentacji programu rpm i Poldka.
Zaawansowane operacje
Lista ostatnio instalowanych pakietów
Jeśli chcemy utworzyć list˛e zainstalowanych pakietów w kolejności wg. daty instalacji to posłużymy si˛e poleceniem
# rpm -qa --last
Odinstalowanie "opornych" pakietów
Bywa, że pakiet w wyniku bł˛edów w skryptach nie pozwala si˛e odinstalować,
możemy go jednak łatwo usunać
˛ wydajac
˛ polecenie deinstalacji z parametrem
--noscripts np.:
# rpm -e lockdev-1.0.2-1 --noscripts
Repackage - bezpieczna aktualizacja
Jeśli obawiamy si˛e aktualizacji jakichś pakietów, możemy posłużyć si˛e operacja˛
repackage - ponownego umieszczenia plików w pakiecie rpm. Jeśli program po
aktualizacji odmawia posłuszeństwa, wystarczy ponownie zainstalować pakiet w
starszej wersji. Aby właczyć
˛
repakietacj˛e wystarczy, że ustawimy niezerowa˛ wartość
dla makra %_repackage_all_erasures w pliku /etc/rpm/macros:
%_repackage_all_erasures
1
Od tej pory każda aktualizacja rozpocznie si˛e od ponownego złożenia pakietu. Dla
pojedynczych pakietów nie ma sensu modyfikować pliku z makrami, lepiej przekazać parametr do rpm-a:
poldek> upgrade geninitrd-10000.18-6.noarch --pmop=--repackage
W przypadku bezpośredniego użycia rpm-a:
# rpm -U --repackage geninitrd-10000.18-6.noarch
Tak zbudowane pakiety trafiaja˛ do katalogu /var/spool/repackage Repakietacja
jest czasochłonna, ponadto dodatkowo zajmowane jest miejsce na dysku, dlatego
najlepiej używać tej funkcji tylko dla wybranych programów.
69
˛
pakietami
Aby cofnać
˛ wersj˛e pakietu wykonujemy nast˛epujac
˛ a˛ operacj˛e:
rpm -U --oldpackage /var/spool/repackage/1189984560/geninitrd-10000.18-6.noarch
Kontrola integralności systemu
Zdarza si˛e, że potrzebujemy sprawdzić czy nie nastapiły
˛
w systemie uszkodzenia
jakichś plików lub ich modyfikacje. Takie zdarzenia moga˛ si˛e pojawić w wypadku
uszkodzenia systemu plików, bł˛edu człowieka lub ataku crackera. W obu przypadkach możemy posłużyć si˛e weryfikacja˛ pakietów RPM. Kontrola przyniesie oczekiwany skutek tylko wtedy, gdy jesteśmy pewni, że sama baza RPM nie została skompromitowana lub uszkodzona.
Aby uzyskać list˛e zmodyfikowanych plików użyjemy programu rpm:
# rpm --verify --all
......G.
/etc/cups
S.5....T
/usr/lib/libsasl2.so.2.0.22
S....... c /etc/xml/catalog
.M...UG. c /etc/samba/smb.conf
szczegółowy opis oznaczeń znajdziemy w manualu programu rpm. Musimy pami˛etać, że wiele plików konfiguracyjnych (oznaczanych literka˛ "c") jest modyfikowanych
po instalacji programu, dlatego ich obecność na liście jest naturalna.
Załóżmy, że poznaliśmy list˛e zmodyfikowanych plików i chcemy na jej podstawie
stworzyć list˛e pakietów do reinstalacji. Zaczynamy od odfiltrowania wszystkiego
prócz nazw plików:
# rpm --verify --all | sed ’s/.*\ //’ > pliki.txt
Taka˛ list˛e możemy teraz sobie obejrzeć i ewentualnie zmodyfikować, kiedy lista już
nam odpowiada sprawdzamy z jakich pakietów pochodza˛ pliki:
# cat pliki.txt | xargs rpm -qf --qf ’%{NAME}\n’ | sort -u
> pakiety.txt
Powyższy ciag
˛ poleceń stworzy list˛e składajac
˛ a˛ si˛e wyłacznie
˛
z nazw pakietów, by
uniknać
˛ problemów w przypadku różnic w wersjach pakietów: tych zainstalowanych z dost˛epnymi do instalacji. Majac
˛ list˛e unikalnych nazw pakietów, możemy
wywołać polecenie ich reinstalacji:
# poldek --reinstall --pset pakiety.txt
Naprawa bazy RPM
System pakietów RPM opiera si˛e na bazie w postaci plików przechowywanych w
katalogu /var/lib/rpm. Nagłe przerwanie pracy programu, który na niej operował
może zaowocować bł˛edami w jej strukturze. Na poczatek
˛
należy si˛e upewnić, że żaden z procesów nie operuje na bazie:
# lsof | grep /var/lib/rpm
jeśli nie wyświetla˛ nam si˛e żadne informacje to możemy usunać
˛ pliki blokad, łatwo
je rozpoznamy, gdyż zaczynaja˛ si˛e od __db
# rm -f /var/lib/rpm/__db*
70
˛
pakietami
Teraz możemy spróbować czy sytuacja si˛e poprawiła, jeśli nie to musimy spróbować
przebudować baz˛e. Zaczynamy od wykonania kopii bezpieczeństwa:
# tar -czf rpm.tar.gz /var/lib/rpm/
nast˛epnie wydajemy polecenia przebudowania:
# rpm --rebuilddb
W wi˛ekszości wypadków ta operacja pomoże nam odzyskać baz˛e, może si˛e jednak
zdarzyć, że odtworzy nam si˛e tylko jej cz˛eść. Do oszacowania strat konieczne b˛edzie
utworzenie listy pakietów w bazie:
# rpm -qa
Kiedy ustalimy list˛e brakujacych
˛
pozycji, najłatwiejszym sposobem dodania brakuja˛
cych wpisów b˛edzie instalacja pakietów z opcja˛ --justdb, powodujac
˛ a˛ jedynie modyfikowanie bazy RPM.
Reinstalacja wszystkich pakietów - zmiana architektury
Zdarza si˛e, że potrzebujemy zainstalować na nowo wszystkie pakiety, np. w wypadku zainstalowania pakietów w niewłaściwej architekturze. Nie jest to pracochłonna
operacja, wystarczy, że z powłoki Poldka wydamy polecenie:
poldek> install -F * --reinstall --nodeps --nofollow
Przypisy
1. http://pld-linux.org/pl/DevelopingPLD
2. http://pld-linux.org/pl/DevelopingPLD
3. http://poldek.pld-linux.org
71
˛
pakietami
72
Rozdział 10. Bootloader
Ten rozdział zawiera dost˛epnych w PLD bootloaderów
Wstep
˛
Podczas startu naszego komputera z naszego dysku uruchamiany jest bootloader. To
właśnie on odpowiada za załadowanie prawidłowego jadra
˛
systemu, czy też przekazywanie do jadra
˛
specjalnych parametrów. Dla architektur x86 mamy do wyboru
jeden z dwóch bootloaderów: LILO oraz Grub (brak wersji 64 bit).
Parametry jadra
Oba bootloadery pozwalaja˛ na przekazywanie do jadra
˛
specjalnych parametrów,
dzi˛eki którym możemy wpływać na start lub prac˛e systemu jeszcze przed jego załadowaniem. Parametry przekazane przed startem systemu b˛eda˛ przesłaniać te użyte
w konfiguracji bootloadera. W poniższej tabeli przedstawiono najcz˛eściej używane
opcje.
Przekazywanie parametrów jadra
˛
wyglada
˛ podobnie w obu wypadkach, po włacze˛
niu specjalnego trybu w bootloaderze otrzymujemy wiersz, na końcu którego dopisujemy potrzebne nam parametry lub modyfikować istniejace.
˛ Poniżej przedstawiamy przykładowe dodanie parametru init w bootloaderze Grub:
grub append> root=/dev/sda2 init=/bin/sh
Tryb modyfikacji parametrów startowych w Grubie aktywujemy przez wciśni˛ecie
klawisza e, w przypadku LILO wpisujemy etykiet˛e obrazu, jeśli to jest graficzne LILO to użyjemy klawisza tab.
Tabela 10-1. Parametry jadra
˛
Parametr
Znaczenie
Przykład
{$nr}/single
Cyfra (1-5) wskazujaca
˛
który poziom
uruchomieniowy (run
level), opcja single to tryb
jednego użytkownika.
Dzi˛eki nim opcjom
można przesłonić
ustawienie opcji
initdefault z pliku
/etc/inittab.
Wi˛ecej o poziomach pracy w sekcja Zmiana poziomu pracy systemu w
Rozdział 14, zaś o pliku
/etc/inittab przeczytamy w sekcja Kluczowe pliki
w Rozdział 12.
single lub 1
73
Parametr
root={$urzadzenie}
˛
Znaczenie
Przykład
Wskazanie urzadzenia
˛
root=/dev/hda1 lub
(partycji) na którym
root=0x301
znajduje si˛e główny
system plików. Wartościa˛
parametru może być
ścieżka do urzadzenia
˛
w
katalogu /dev (np.
/dev/hda1) lub wartość
liczbowa powstała z
połaczenia
˛
szesnastkowej
wartości liczb major i
minor urzadzenia.
˛
Major
podajemy w postaci
jednej cyfry, natomiast
minor powinien być już
rozwini˛ety do dwóch.
Przykładowo urzadzenie
˛
o wartościach major 3 i
minor 1 b˛edzie
przedstawiane jako 301,
0301 lub 0x301 (wartości
3 i 1 sa˛ takie same w
systemie dziesi˛etnym i
szesnastkowym).
Urzadzenia
˛
oraz liczby
major i minor szerzej opisano w sekcja Urzadzenia
˛
w Rozdział 11
init={$program}
Wskazanie programu,
który ma zostać użyty
zamiast domyślnego
programu Init; opcja
używana w krytycznych
sytuacjach, np. gdy
system nie może zostać
uruchomiony nawet w
trybie single.
init=/bin/bash
vga={$tryb}
Wskazanie trybu bufora
ramki, wi˛ecej o buforze
ramki w nast˛epnym
rozdziale.
vga=0x303
Opis
wybranych
parametrów
jadra
˛
zamieszczono
na
stronie
http://www.jtz.org.pl/Html/BootPrompt-HOWTO.pl.html,
zaś pełna˛ ich list˛e odnajdziemy w dokumentacji jadra,
˛
w pliku
/usr/src/linux/Documentation/filesystems/devfs/boot-options
Sa˛ również specjalne parametry, które przekazuje si˛e do jadra
˛
w trakcie pracy systemu, opisaliśmy je w sekcja Parametry jadra
˛ w Rozdział 11.
MBR czy bootsector?
Oba bootloadery maja˛ możliwość instalacji zarówno w obszarze MBR dysku, jak i
bootsectorze partycji. Instalacja w MBR jest dosyć wygodna i o wiele bardziej popularna, dlatego właśnie tam powinniśmy instalować bootloader. Instalacja w bootsec74
torze w wypadku niektórych systemów plików (np. XFS) jest niemożliwa, gdyż ich
superblok jest umieszczany na samym poczatku
˛
partycji - w miejscu które powinno
być zarezerwowane dla bootloadera.
Frame buffer (bufor ramki)
Frame Buffer (bufor ramki) to m.in. mechanizm pozwalajacy
˛ na prac˛e konsoli w wyższych rozdzielczościach. Aby go właczyć
˛
przekazujemy parametr vga przy uruchomieniu bootloadera lub dodajemy go do pliku konfiguracji np.:
vga=0x303
Sposób dodania tej opcji do pliku konfiguracji bootloadera opisano w dotyczacych
˛
ich rozdziałach.
Wartość opcji vga to numer trybu graficznego dla danej rozdzielczości i gł˛ebi koloru, list˛e dost˛epnych trybów przedstawiono w poniższej tabeli. Kodowe oznaczenia
trybów bufora ramki możemy podawać zarówno szesnastkowo jak i dziesi˛etnie, dlatego też w tabeli, obok wartości szesnastkowych umieszczono wartości w systemie
dziesi˛etnym (w nawiasach).
Tabela 10-2. Tryby bufora ramki
Głebia
˛
koloru
640x480
800x600
1024x768
1280x1024
256 (8 bit)
0x301 (769)
0x303 (771)
0x305 (773)
0x307 (775)
32k (15 bit)
0x310 (784)
0x313 (787)
0x316 (790)
0x319 (793)
65k (16 bit)
0x311 (785)
0x314 (788)
0x317 (791)
0x31A (794)
16M (24 bit)
0x312 (786)
0x315 (789)
0x318 (792)
0x31B (795)
Zamiast wskazywać konkretny tryb możemy opcji vga przypisać wartość ask, dzi˛eki
temu jadro
˛
pozwoli wyświetlić list˛e trybów i wybrać jeden z nich. Wi˛ecej o buforze
ramki dowiemy si˛e z dokumentacji kernela, jeśli zainstalowaliśmy pakiet z dokumentacja˛ jadra
˛
to znajdziemy ja˛ w katalogu /usr/src/linux/Documentation/fb.
LILO
LILO (LInux LOader) jest najbardziej popularnym linuksowym bootloaderem. Jego
instalacja polega na utworzeniu pliku konfiguracyjnego (/etc/lilo.conf) a nast˛epnie na wydaniu polecenia lilo w celu instalacji w MBR lub bootsektorze. Każda modyfikacja pliku konfiguracji, wygenerowanie nowego obrazu initrd lub instalacja
nowego jadra
˛
pociaga
˛ za soba˛ konieczność ponownej instalacji obrazu.
O initrd poczytamy w sekcja Initrd w Rozdział 11.
Konfiguracja podstawowa
Poniżej, dla przykładu przedstawiony został bardzo prosty plik konfiguracji, ma on
za zadanie umieścić lilo w MBR dysku twardego, umożliwiajac
˛ w ten sposób uruchomienie naszej dystrybucji.
boot=/dev/hda
read-only
lba32
image=/boot/vmlinuz
label=pld
75
root=/dev/hda1
initrd=/boot/initrd
Plik konfiguracji lilo dzieli si˛e na dwie zasadnicze cz˛eści: blok opcji głównych oraz
opcje obrazu. W powyższym przykładzie opcje główne umieszczone sa˛ na samym
poczatku
˛
(do pustego wiersza). Wartość zmiennej boot mówi gdzie ma zostać zainstalowany bootloader (bootsector/MBR), w tym wypadku jest o MBR dysku. Opcja
read-only wymusza start systemu w trybie tylko do odczytu (później jest przemontowany na tryb do odczytu i zapisu), lba32 włacza
˛
wykorzystanie 32-bitowego adresowania (jest rozwiazaniem
˛
limitu cylindra 1024).
Nast˛epna sekcja (ustawienia obrazu) to konfiguracja dla konkretnego systemu operacyjnego (tutaj Linuksa). Każdy system, który mielibyśmy obsługiwać z poziomu
lilo, musi mieć taka˛ sekcj˛e. Opcja image rozpoczyna sekcj˛e i jednocześnie wskazuje
ściek˛e do jadra,
˛
label to wyświetlana etykieta obrazu, root wskazuje urzadzenie
˛
z
głównym systemem plików, initrd to ścieżka do obrazu initrd (initial ramdisk).
Opcj˛e root szerzej opisano w sekcja Wst˛ep. Z nazewnictwem urzadze
˛
ń masowych
zapoznamy si˛e w sekcja Nazewnictwo urzadze
Dzi˛eki powyższej konfiguracji bootloader bezzwłocznie uruchomi nasze PLD zainstalowane na pierwszej partycji dysku hda bez zadawania jakichkolwiek pytań. W
wielu przypadkach b˛edziemy chcieli przekazać do kernela specjalne parametry lub
mieć możliwość wyboru innego systemu operacyjnego (o ile dodaliśmy do lilo taka˛
możliwość). Wtedy konieczne b˛edzie zdefiniowanie dwóch dodatkowych opcji:
prompt
timeout=100
Pierwsza włacza
˛
tryb interaktywny, druga zaś ustawia czas oczekiwania na nasza˛
reakcj˛e, podawany w dziesiatych
˛
cz˛eściach sekundy. W tej chwili możemy wygenerować lilo i zrestartować maszyn˛e aby sprawdzić czy dokonaliśmy prawidłowej
konfiguracji.
Inne systemy operacyjne
Istnieje możliwość uruchamiania wielu systemów operacyjnych z poziomu lilo, w
tym celu do pliku konfiguracji musimy dodać odpowiednie obrazy i opisane wcześniej opcje prompt i timeout. Poniżej została umieszczona sekcja pozwalajaca
˛ uruchomić system DOS/Windows umieszczony na dysku hda3.
other=/dev/hda3
label=windows
Domyślnym obrazem wybranym przez bootloader jest pierwszy w kolejności z pliku
konfiguracji. Możemy to ustawienie bardzo prosto modyfikować za pomoca˛ opcji
default wskazujacej
˛ etykiet˛e domyślnego obrazu, np.:
default=pld
Opcj˛e default umieszczamy w głównej cz˛eści konfiguracji.
Frame Buffer
Frame Buffer (bufor ramki) to m.in. mechanizm pozwalajacy
˛ na prac˛e konsoli w wyższych rozdzielczościach. Aby go właczyć,
˛
do konfiguracji linuksowego obrazu lub do
sekcji głównej dodajemy parametr jadra
˛
vga np.:
vga=0x303
76
Przykładowa konfiguracja obrazu b˛edzie wygladała
˛
nast˛epujaco:
˛
image=/boot/vmlinuz
label=pld
root=/dev/hda1
initrd=/boot/initrd
vga=0x303
List˛e dost˛epnych trybów zamieszczono w sekcja Wst˛ep.
Graficzne menu
Jeśli zdecydowaliśmy si˛e na wyświetlanie menu poczatkowego
˛
(za pomoca˛ opcji
prompt) to możemy si˛e pokusić o ustawienie graficznego menu. Z pakietem lilo dostajemy odpowiednio przygotowane bitmapy, musimy tylko dodać kilka opcji do
głównej sekcji pliku konfiguracji.
Wskazujemy interesujacy
˛ nas obrazek:
bitmap = /boot/lilo-pldblue8.bmp
Określamy kolory i położenie tekstu na ekranie:
bmp-table = 17,9;1,14,16,4
bmp-colors = 0,213,137;152,24,1
bmp-timer = 2,29;152,52,1
Musimy pami˛etać że powyższe dane sa˛ dobrane dla konkretnego obrazka i dla innego moga˛ nie być dobre.
Zakończenie
Kiedy już skonfigurujemy nasz bootloader wydajemy polecenie lilo:
# lilo
Added pld *
nast˛epnie restartujemy system.
GRUB
GRUB (GRand Unified Bootloader) jest bootloaderem zdobywajacym
˛
spora˛ popularność, ze wzgl˛edu na swoja˛ elastyczność i duże możliwości. Jest tak rozbudowany, że
musi trzymać cz˛eść swoich danych na dysku twardym, z tego też wzgl˛edu obsługuje
kilka systemów plików i może wykonywać proste operacje dyskowe. GRUB normalnie "widzi" pliki na dysku, a wi˛ec widzi własny plik konfiguracji, kernel i obraz
initrd. Dzi˛eki temu nie ma potrzeby robienia czegokolwiek po zmianie konfiguracji,
wygenerowaniu initrd czy aktualizacji kernela. Jest za to czuły niekiedy na aktualizacje "samego siebie" i wymaga niekiedy ponownej instalacji do MBR-u/bootsectora,
nie ma tu jednak żadnej jasnej reguły. GRUB na każdym etapie konfiguracji (w trybie
interaktywnym) wspiera nas wbudowana˛ pomoca˛ oraz dopełnianiem nazw plików,
urzadze
˛
ń i partycji.
Do najwi˛ekszych zalet GRUB-a można zaliczyć możliwość zmiany konfiguracji startowej z poziomu działajacego
˛
bootloadera. Kiedy uruchomiony zostanie bootloader
wybieramy obraz a nast˛epnie wciskamy klawisz e. Wyświetla˛ nam si˛e wiersze konfiguracji, możemy je modyfikować za pomoca˛ wbudowanego prostego edytora tek77
stów. Po skończonej edycji wciskamy klawisz b, aby uruchomić system z wprowadzonymi zmianami.
Kolejna˛ ważna˛ jego cecha˛ jest możliwość używania klawiatury USB, w przeciwieństwie do LILO, jedyna˛ rzecza˛ jaka˛ musimy zrobić w tym wypadku to właczyć
˛
obsług˛e klawiatury USB w BIOS-ie.
O initrd poczytamy w sekcja Initrd w Rozdział 11.
Nazewnictwo urzadze
˛
ń
Nie używamy nazw dysków opierajacych
˛
si˛e na urzadzeniach
˛
widniejacych
˛
w /dev
(np. /dev/hda). GRUB przy pomocy BIOS-u sprawdza istniejace
˛ dyski i numeruje
je poczawszy
˛
od zera. Dla przykładu, jeżeli posiadamy dwa dyski twarde (np. hda
i hdc), pierwszy z nich zostanie oznaczony jako hd0, drugi jako hd1. Sytuacja z partycjami wyglada
˛ podobnie, również numerowane sa˛ od zera, natomiast pierwsza
partycja logiczna b˛edzie oznaczona numerem 4.
Obszar MBR oznaczany jako /dev/hda b˛edzie widziany jako (hd0), partycja
b˛edzie rozpoznawana jako (hd0,0). Podane nawiasy nie sa˛
przypadkowe, jest to cecha składni poleceń GRUB-a.
/dev/hda1
Urzadzenia
˛
masowe opisano szerzej w sekcja Nazewnictwo urzadze
Konfiguracja podstawowa
Konfiguracja
polega
na
odpowiednim
skonfigurowaniu
pliku
/boot/grub/menu.lst i instalacji bootloadera w MBR/bootsektorze dysku. W
poniższych przykładach założyliśmy, że zarówno / (rootfs) jak i /boot leża˛ na tej
samej partycji pierwszego dysku twardego. W przykładowej konfiguracji b˛edzie to
/dev/hda1. Poniżej przedstawiono przykładowa˛ konfiguracj˛e:
timeout 15
title pld
root (hd0,0)
kernel /boot/vmlinuz root=/dev/hda1
initrd /boot/initrd
Konfiguracja GRUB-a podzielona jest na sekcj˛e główna˛ i sekcje obrazów, sekcja główna sa˛ to ustawienia globalne, zaś konfiguracja obrazów to opcje dla każdego z obsługiwanych systemów operacyjnych. Powyżej mamy sekcj˛e główna˛ oraz sekcj˛e obrazu
oddzielona˛ pustym wierszem.
Opcja timeout w sekcji głównej to czas w sekundach oczekiwania na reakcj˛e użytkownika.
Opcja title w sekcji obrazu to jego etykieta, root(hd0,0) to partycja na której
GRUB b˛edzie szukał swoich plików (w PLD GRUB trzyma swoje pliki w
/boot/grub). Parametry kernel i initrd to ścieżki do plików kernela i initrd, w
powyższym przykładzie b˛eda˛ szukane na urzadzeniu
˛
(hd0,0) gdyż podane do
nich ścieżki sa˛ wzgl˛edne. Parametr root= jest parametrem jadra
˛
wskazujacym
˛
położenie głównego systemu plików, opisanym szerzej w sekcja Wst˛ep. Może mieć
zarówno postać liczbowa˛ jak i postać nazwy urzadzenia
˛
z katalogu /dev np.
/dev/hda1.
Kiedy plik konfiguracji jest gotowy możemy przejść do instalacji GRUB-a.
78
Instalacja
Przejdźmy teraz do instalacji GRUB-a w MBR, rozpoczynamy od uruchomienia programu grub, mamy teraz do dyspozycji interaktywna˛ powłok˛e, oferujac
˛ a˛ liczne polecenia, dopełnianie oraz pomoc. Rozpoczynamy od polecenia root z parametrem
wskazujacym
˛
miejsce gdzie znajduja˛ si˛e pliki GRUB-a, konieczne do jego instalacji.
grub> root (hd0,0)
Filesystem type is xfs, partition type 0x83
Teraz uruchamiamy instalacj˛e bootloadera w MBR dysku, wydajemy polecenie setup
z odpowiednim parametrem:
grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/xfs_stage1_5" exists... yes
Running "embed /boot/grub/xfs_stage1_5 (hd0)"... 18 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+18 p (hd0,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done.
Komunikaty wskazuja˛ poprawność operacji, wi˛ec pozostaje nam tylko wyjście z powłoki programu.
grub> quit
W ten oto sposób staliśmy si˛e posiadaczami GRUB-a w naszym systemie, możemy
teraz zrestartować maszyn˛e.
Inne systemy operacyjne
Zakładam, że chcemy dodać system Microsoftu zainstalowany na partycji
/dev/hda2, oto sekcja jaka˛ musimy dopisać do /boot/grub/menu.lst:
title Windows
rootnoverify (hd0,1)
chainloader +1
Domyślnym obrazem wybranym przez bootloader jest ten pierwszy w kolejności w
pliku konfiguracji. Możemy to ustawienie bardzo prosto modyfikować za pomoca˛
opcji default wskazujacej
˛ numer obrazu. Obrazy sa˛ numerowane wg. kolejności
poczawszy
˛
od 0 np.:
default 2
Omawiana˛ opcj˛e wstawiamy do sekcji głównej pliku konfiguracji.
Frame Buffer
Frame Buffer (bufor ramki) to mechanizm pozwalajacy
˛ m.in. na prac˛e konsoli w wyższych rozdzielczościach. Aby go właczyć,
˛
do parametrów jadra
˛
w konfiguracji linuksowego obrazu dodajemy parametr vga np. vga=0x303. Przykładowa konfiguracja
obrazu b˛edzie wygladała
˛
nast˛epujaco:
˛
title pld
root (hd0,0)
kernel /boot/vmlinuz root=0301 vga=0x303
initrd /boot/initrd
79
List˛e dost˛epnych trybów zamieszczono w sekcja Wst˛ep.
Graficzne menu
W pakiecie z GRUB-em dost˛epne sa˛ grafiki, co sugeruje możliwość wyświetlenia ich
w menu, jednak GRUB w PLD domyślnie ich nie obsługuje. Aby właczyć
˛
taka˛ możliwość musimy samemu zbudować pakiet z opcja˛ --with splashimage.
Instalujemy zbudowany pakiet, a nast˛epnie do pliku konfiguracji, do sekcji głównej
dodajemy opcj˛e wskazujac
˛ a˛ bitmap˛e, która ma być wyświetlana np.:
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
Aby napisy pozostały czytelne możemy ustalić ich kolor za pomoca˛ opcji
foreground i background np.:
foreground
background
= ffffff
= 000000
Pierwsza z opcji wskazuje główny kolor liter, druga zaś określa kolor ich cienia,
oba parametry przyjmuja˛ szesnastkowe wartości. Teraz restartujemy komputer, aby
sprawdzić czy wszystko działa poprawnie.
Grafiki możemy tworzyć samemu, GRUB wymaga indeksowanej bitmapy o 14 kolorach i rozdzielczości 640x480, typu .xpm, plik musi być dodatkowo skompresowany
programem Gzip.
Bezpieczeństwo bootloadera
Jak już zostało wspomniane, GRUB trzyma cz˛eść swoich danych w systemie plików,
co przy poważnym uszkodzeniu systemu plików może uniemożliwić start systemu.
Rozwiazaniem
˛
tego problemu, może być umieszczenie gał˛ezi /boot na osobnej partycji, tak jak to było dawniej robione dla omini˛ecia ograniczeń starych wersji LILO.
Wi˛ecej o podziale na partycje odnajdziemy w sekcja Podział na partycje w Rozdział 13.
Dla wi˛ekszego bezpieczeństwa partycj˛e taka˛ można montować w trybie tylko do odczytu, musimy jednak wtedy pami˛etać o konieczności przemontowania jej do trybu
rw, przed każda˛ aktualizacja˛ jadra,
˛
lub bootloadera.
Uwagi
80
•
W
przypadku
nietypowych
konfiguracji
b˛edziemy
zmuszeni
do
podawania ścieżek bezwzgl˛ednych do plików. Podajemy je nast˛epujaco:
˛
(hdX,Y)/katalog/plik np.: (hd0,0)/boot/vmlinuz
•
GRUB wymaga kompletnej listy urzadze
˛
ń w katalogu /dev, stad
˛ moga˛ pojawić
si˛e problemy przy próbie instalacji go z chroota opartego o udev. Należy w tym
wypadku podmontować z głównego system katalog /dev z opcja˛ -bind. Pliki
urzadze
˛
ń zostały dokładniej opisane w sekcja Urzadzenia
˛
w Rozdział 11.
rc-boot
Wstep
˛
Osoby nie przepadajace
˛ za konfiguracja˛ powyższych bootloaderów, moga˛ skorzystać
z narz˛edzia o nazwie rc-boot. Jest to proste i wygodne w użyciu narz˛edzie, stworzone dla potrzeb PLD, które zapewnia uniwersalny interfejs do zarzadzania
˛
bootloaderem. Został stworzony w celu automatycznego aktualizowania bootloadera po
zaktualizowaniu jadra,
˛
jednak nie zdobył szerszej popularności wśród użytkowników. Dzi˛eki rc-boot możemy używać dowolnego bootloadera (np. LiLo, Grub), nie
znajac
˛ zasad ich działania czy składni plików konfiguracji.
W gruncie rzeczy korzystanie z rc-boot ma sens wyłacznie
˛
przy używaniu LiLo. Bootloader GRUB nie wymaga przeładowania po aktualizacji jadra,
˛
dlatego użytkownicy używaja˛ właśnie jego zamiast rc-boot.
Aby utworzyć bootloader omawianym narz˛edziem należy si˛e posłużyć poleceniem
rc-boot, to jaki bootloader zostanie użyty i jakie opcje b˛eda˛ ustawione, definiujemy w
jednym uniwersalnym pliku konfiguracji: /etc/sysconfig/rc-boot/config. Dodatkowo wymagane sa˛ specjalne pliki "obrazów" odpowiadajace
˛ każdemu systemowi operacyjnemu, który chcemy obsługiwać z poziomu bootloadera. Sa˛ to proste pliki konfiguracyjne umieszczane w katalogu /etc/sysconfig/rc-boot/images. Po
zainstalowaniu systemu powinien tam być przynajmniej jeden taki plik.
Podstawowa konfiguracja
Po zainstalowaniu pakietu rc-boot wymagane sa˛ poprawki w konfiguracji pliku
/etc/sysconfig/rc-boot/config. Na poczatek
˛
odblokujemy działanie rc-boot:
DOIT=yes
Kolejno wybieramy bootloader jaki chcemy używać, mamy do wyboru lilo oraz grub:
LOADER=grub
Nast˛epnie ustalamy gdzie ma być zainstalowany bootloader np.: /dev/hda,
/dev/hdb2 lub mbr. Wartość mbr oznacza że rc-boot stara si˛e automatycznie wykryć
gdzie jest twój MBR (Master Boot Record).
BOOT=mbr
Jeśli posiadamy wi˛ecej niż jeden obraz, możemy wskazać domyślny, poprzez podanie nazwy pliku obrazu z katalogu /etc/sysconfig/rc-boot/images. Definiowanie tej opcji nie jest konieczne, gdyż rc-boot próbuje samemu wykryć domyślny
system operacyjny, jednak w naszym przykładzie ustawimy to "na sztywno":
DEFAULT=pld
Tworzenie "obrazów"
Teraz możemy przejść do utworzenia plików obrazów. Maja˛ one bardzo prosta˛ budow˛e - sa˛ to pliki tekstowe składajace
˛ si˛e z kilku wierszy. Poniższa treść pliku jest
wystarczajac
˛ a˛ konfiguracja˛ do uruchomienia Linuksa, plikowi temu nadamy nazw˛e
"pld".
TYPE=Linux
ROOT=/dev/hda3
KERNEL=/boot/vmlinuz
INITRD=/boot/initrd
81
Opcja TYPE określa rodzaj systemu operacyjnego dla danego obrazu, mamy do wyboru nast˛epujace
˛ pozycje: Linux, DOS (DOS/Windows), BSD. Opcja ROOT wskazuje
partycj˛e na której znajduje si˛e system, wartość podana powyżej jest tylko przykładem. Wartości KERNEL i INITRD sa˛ wskazaniami do pliku kernela i pliku initrd - musza˛ odnosić si˛e do właściwych pozycji w katalogu /boot
Dla każdego kolejnego obsługiwanego systemu operacyjnego należy dodać kolejny
plik obrazu. Jeśli chcemy używać systemu firmy Microsoft, należy utworzyć pusty
plik o nazwie np. "windows" i umieścić w nim przykładowa˛ konfiguracj˛e:
TYPE=dos
ROOT=/dev/hda1
Na koniec generujemy bootloader używajac
˛ polecenia rc-boot.
# rc-boot
pld taken as defult image
image: pld * is linux on /dev/hda3
image: windows is dos on /dev/hda1
Uwagi
Program rc-boot nadpisze plik konfiguracji wybranego bootloadera, zanim wi˛ec użyjemy tego narz˛edzia powinniśmy na wszelki wypadek zrobić kopi˛e bezpieczeństwa
właściwego pliku.
Wi˛ecej szczegółów można uzyskać z podr˛ecznika systemowego.
Przypisy
1. http://www.jtz.org.pl/Html/BootPrompt-HOWTO.pl.html
82
Rozdział 11. Kernel i urzadzenia
˛
Jadro
˛
systemu
Jak zapewne wi˛ekszości z was wiadomo jadro
˛
(kernel) jest najważniejszym elementem każdego systemu. W uproszczeniu można powiedzieć, że zajmuje si˛e ono nadzorowaniem komunikacji wszystkich elementów systemu.
Koncepcja jadra
˛
w PLD
Jedna˛ z silniejszych stron PLD sa˛ dobrze przygotowane jadra
˛
systemu, pozwala
to szybko uruchomić system produkcyjny bez zb˛ednych przygotowań. Poniżej
zamieszczono list˛e najistotniejszych cech jader
˛
PLD:
•
funkcjonalność - nakładanych jest wiele łat rozszerzajacych
˛
możliwości domyślnego
kernela.
•
modularność - jadro
˛
jest tak małe, jak to tylko możliwe; jeśli czegoś potrzebujemy
to wystarczy załadować odpowiedni moduł. Konsekwencja˛ takiego rozwiazania
˛
jest konieczność używania obrazu initrd, co zostało drobiazgowo omówione w
sekcja Initrd.
•
elastyczność - mamy wybór kilku jader,
˛
przygotowanych w postaci binarnych pakietów dla kilku najcz˛estszych zastosowań; dzi˛eki temu unikamy czasochłonnej
kompilacji. Dost˛epne jadra
˛
zostały opisane w dalszej cz˛eści rozdziału.
•
bezpieczeństwo - domyślny kernel ma nakładana˛ łat˛e grsecurity
(www.grsecurity.net1), ponadto możemy mieć jadro
˛
z obsługa˛ Linux VServers
(linux-vserver.org2).
Podsumowujac
˛ można stwierdzić, że dla wi˛ekszości zastosowań jadra
˛
dystrybucyjne
spełnia˛ wszystkie stawiane przed nimi wymagania, bez konieczności rekompilacji.
Informacje o używanym jadrze
˛
Używana˛ wersj˛e jadra
˛
sprawdzimy za pomoca˛ programu uname:
# uname -r
2.6.14.7-5
Jeśli interesuje nas konfiguracja danego jadra,
˛
to możemy ja˛ odczytać z pliku
/proc/config.gz (w Th plik jest dost˛epny po uprzednim załadowaniu modułu
configs) np.:
# zcat /proc/config.gz
lub z pliku config-dist dostarczanego z właściwym pakietem kernel-headers np.:
# cat /usr/src/linux-2.6.27.13/config-dist
83
˛
Rodzaje jader
˛
systemowych
Z PLD dostarczanych jest kilka kerneli, przygotowanych do różnych zastosowań,
jedyna˛ rzecza˛ jaka nam pozostaje to wybór właściwego jadra
˛
dla naszej maszyny.
W poniższej tabeli zamieszczono przykładowe zestawienie dost˛epnych kerneli. Nie
wszystkie z wymienionych poniżej pakietów bezpośrednio dost˛epne na liście pakietów, jeśli
tak nie jest to trzeba je zbudować samodzielnie ze speca.
Tabela 11-1. Kernele
Powyższe zestawienie należy traktować orientacyjnie, gdyż kernel ciagle
˛ si˛e zmienia.
Aby poznać szczegóły, najlepiej jest sprawdzić plik spec3 dla konkretnego kernela.
Ułatwieniem w poszukiwaniu właściwej rewizji, moga˛ być tagi zaczynajace
˛ si˛e od
auto-, np.: auto-th-kernel-2_6_27_12-1. Tagi te sa˛ nadawane dla każdej wersji
pakietu trafiajacego
˛
na serwery FTP/HTTP.
W wersjach Ra i Ac istniał podział na kernel jednoprocesorowy (tzw. up) oraz wieloprocesorowy - SMP (symmetric multiprocessing). Dla odróżnienia te z obsługa˛ wielu
procesorów miały w nazwie pakietu przyrostek -smp. W Th i pakietach z ac-updates
zaniechano takiego podziału i wszystkie jadra
˛
obsługuja˛ wiele procesorów i jednocześnie zrezygnowano z przyrostka -smp.
Należy zwrócić uwag˛e, na inne przyrostki po słowie kernel w nazwach pakietów,
nie mówia˛ one o rodzaju kernela ale o pakiecie z dodatkowymi modułami:
kernel-net, kernel-sound, kernel-video, dokumentacja:
˛ kernel-doc i inna˛
zawartościa.˛
Aktualizacja
Kernel jest kluczowa˛ cz˛eścia˛ systemu, dlatego zaleca si˛e inaczej podejść do jego aktualizacji niż do innych pakietów, dobrym zwyczajem jest instalacja nowej wersji,
zamiast aktualizacji np.:
poldek> install -I kernel-2.6.14.7-5
Po tej operacji zostanie na nowo wygenerowany obraz initrd, użytkownicy LiLo
musza˛ dodatkowo wydać polecenie lilo. W ten sposób mamy zainstalowane dwa
jadra,
˛
przy czym po ponownym uruchomieniu użyta zostanie nowa wersja.
Gdyby nowy kernel okazał si˛e niestabilny, to zawsze możemy powrócić do starej
wersji. Aby ułatwić taka˛ operacj˛e symlinki wskazujace
˛ na dotychczasowy kernel
(/boot/vmlinuz) i initrd (/boot/initrd) automatycznie b˛eda˛ teraz dost˛epne pod
nazwami /boot/vmlinuz.old i /boot/initrd.old. Dzi˛eki temu, możemy w konfiguracji bootloadera mieć "obraz" konfiguracji dla starego kernela i użyć go w razie
potrzeby.
Zależności
Istnieje kilka pakietów, bardziej lub mniej zależnych od konkretnej wersji
kernela. Ścisłe zależności b˛eda˛ dotyczyły pakietów z modułami np.
kernel-vanilla-sound-alsa
oraz
pakietów
ściśle
współpracujacych
˛
z kernelem np. moduł kernel-video-nvidia ze sterownikiem X.Org:
xorg-driver-video-nvidia. Nieco mniej oczywisty jest zwiazek
˛
kernela z
pakietami iproute2 czy iptables, w ich przypadku mamy nieco swobody.
W wielu sytuacjach nie b˛edziemy musieli si˛e o to martwić, gdyż ten problem załatwiaja˛ nam zależności. Mimo to, że mamy tu dost˛epna˛ automatyk˛e, przy tego rodzaju
pakietach powinniśmy zachować zdwojona˛ czujność. Dla ważnych maszyn produkcyjnych warto dodać kernel i pakiety okołokernelowe do opcji hold w Poldku, opcj˛e
84
˛
ta˛ omówiliśmy w sekcja Poldek w Rozdział 9. Wi˛ecej o zależnościach pomi˛edzy pakietami w sekcja Cechy pakietów w PLD w Rozdział 9.
Uwagi
Czasami zdarza si˛e, że załamuje si˛e praca systemu sygnalizowana za pomoca˛ komunikatu Kernel Panic, jadro
˛
informuje nas, że nie wie co ma dalej zrobić i przerywa
prac˛e. Warto ustawić system tak, by po takim zdarzeniu automatycznie nast˛epował
restart, konfiguracj˛e takiego zachowania opisaliśmy w sekcja Podstawowe ustawienia
w Rozdział 12.
Parametry jadra
˛
Mamy możliwość wpływania na prac˛e systemu, dzi˛eki modyfikowaniu specjalnych
parametrów jadra,
˛
parametry te można podzielić na dwie grupy: podawane przed
startem kernela oraz podawane po wystartowaniu. Pierwszy rodzaj został opisany w
sekcja Wst˛ep w Rozdział 10, drugi to zestaw specjalnych wpisów do pseudo-systemu
plików /proc/sys.
Czytać wartości możemy za pomoca˛ programu cat np.:
# cat /proc/sys/net/ipv4/ip_forward
Parametry możemy wysłać za pomoca˛ programu echo np.:
# echo "1" > /proc/sys/net/ipv4/ip_forward
Możemy do tego również użyć programu sysctl, który za nazw˛e w˛ezła przyjmuje nazwy katalogów rozdzielone kropkami, z pomini˛eciem "/proc/sys". Poniżej umieszczono przykład odczytania opcji:
# /sbin/sysctl net.ipv4.ip_forward
oraz przypisania:
# /sbin/sysctl net.ipv4.ip_forward=1
Wada˛ powyższego rozwiazania
˛
jest powrót do poprzednich ustawień po restarcie
maszyny. Rozwiazaniem
˛
problemu jest korzystanie z pliku /etc/sysctl.conf, w
nim przypisujemy wartości odpowiednim zmiennym. W celu wprowadzenia ustawień wywołujemy polecenie:
# /sbin/sysctl -p
Niektóre rc-skrypty wywołuja˛ automatycznie program sysctl, przykładowo robi to
skrypt podsystemu sieci, gdyż plik /etc/sysctl.conf zawiera istotne opcje sieciowe.
Moduły jadra
˛
Czym sa?
˛
Sterowniki moga˛ być wkompilowane do wn˛etrza jadra
˛
lub wydzielone jako osobne
obiekty - moduły. Moduły jadra
˛
zostały stworzone po to by kernel zajmował mało
pami˛eci operacyjnej i był zarazem uniwersalny. Ułatwiaja˛ one także prace ludziom
85
˛
zaangażowanym w rozwój jadra
˛
i dodatkowych modułów (nie potrzeba kompilować
całego kernela by sprawdzić zmiany, wystarczy tylko sam moduł) Wyobraź sobie sytuacj˛e, w której masz wkompilowane do niego wszystko, a twój system nie posiada
urzadze
˛
ń, które kernel potrafi obsłużyć. Jest to duże marnotrawstwo, ponieważ w
pami˛eci znajda˛ si˛e nie potrzebne nam funkcje. Dodać należy fakt, ograniczenia wielkości jadra
˛
(można to zmienić odpowiednimi przeróbkami źródeł via Red Hat). Dlatego lubimy moduły. Daja˛ nam one możliwość wyboru mi˛edzy tym co niezb˛edne, a
brakiem wsparcia dla urzadze
˛
ń. Podsumowujac.
˛ Nie potrzebujesz to nie używasz.
By móc używać modułów potrzebujesz dwóch rzeczy. Kernela z wkompilowana˛
opcja˛ Loadable module support oraz sterowników skompilowanych jako moduły. Ponieważ używasz PLD to nie masz co si˛e głowić ponieważ wszystko to masz u
siebie w systemie.
Załadowanie właściwego modułu dla urzadzenia
˛
Istnieja˛ dwie metody załadowania modułów:
•
statyczna - metoda tradycyjna, polega na wskazaniu modułów do załadowania
przez administratora
•
dynamiczna - automatyczne ładowanie modułów, kiedy urzadzenie
˛
zostaje wykryte
Obydwie metody zostana˛ przedstawione w dalszych rozdziałach.
Konfiguracja modułów
Plik /etc/modprobe.conf jest przeznaczony do ustawiania opcji dla ładowanych
modułów. Warto dodać iż we wcześniejszych wersjach kernela ( < 2.6.0) plik nazywał
si˛e /etc/modules.conf. W pliku mamy dost˛epnych wiele opcji, my omówimy tylko
najcz˛eściej używane: alias, option i blacklist.
Aliasy - sa˛ to dodatkowe nazwy dla modułów, pozwalaja˛ na wczytanie go odwołujac
˛
si˛e do aliasu. Z aliasów korzysta wiele programów, które nie moga˛ wiedzieć z jakiego
modułu maja˛ korzystać i używaja˛ ustalonych nazw (aliasów) np.:
alias eth0 8139too
Dzi˛eki tej linijce wszelkie odwołania przy ładowaniu modułów załaduja˛ automatycznie moduł 8139too.
alias parport_lowlevel parport_pc
W tym fragmencie pliku /etc/modprobe.conf widzimy już znany alias z
tym, że w troch˛e innej formie. Ponieważ wyst˛epuje tu nazwa_jednego_modułu
i nazwa_drugiego_modułu. Oznacza to, że jak b˛edzie potrzeby moduł
parport_lowlevel, to zostanie też automatycznie załadowany moduł parport_pc.
Opcje - cz˛esto używa si˛e możliwości przesłania do modułu ustawień. Przedstawi˛e to
na przykładzie drukarki podpi˛etej do portu LPT:
options parport_pc io=0x378, irq=7
Linijka przesyła jako parametr do modułu parport_pc argumenty we/wy i przerwania. Wi˛ecej informacji o dost˛epnych opcjach modułu można uzyskać po wydaniu
polecenia modinfo parport_pc.
Czarna lista - możemy zabronić ładowania jakiegoś modułu za pomoca˛ słowa kluczowego blacklist np.:
86
˛
blacklist rivafb
.
˛
modułami
Określenie modułu dla urzadzenia
˛
W zależności od naszych wymagań oraz zastosowania systemu operacyjnego, b˛edzie si˛e zmieniać liczba wymaganych sterowników, w wi˛ekszości wypadków b˛edzie
to wartość od kilku do kilkunastu modułów. Jeśli tych modułów jest mało to samodzielne ładowanie może być lepszym rozwiazaniem.
˛
Aby wskazać odpowiedni moduł, musimy poznać dane urzadzenia.
˛
Najbardziej interesujacymi
˛
informacjami sa:˛ producent i model urzadzenia
˛
lub użyty chipset. W
wi˛ekszości wypadków te informacje znajduja˛ si˛e w dokumentacji urzadzenia.
˛
Jeśli
tak nie zdob˛edziemy szukanych informacji to możemy spróbować użyć któraś
˛ z poniższych metod:
•
Organoleptycznie - jeśli mamy dost˛ep do sprz˛etu to możemy obejrzeć urzadze˛
nie, opis może być umieszczony na płytce drukowanej lub na chipsecie (zwykle
najwi˛ekszy układ scalony).
•
lshw - zaawansowany program służacy
˛ do wyświetlania szczegółowych danych
o sprz˛ecie, jego zaleta˛ jest duża ilość sprawdzanych podsystemów i wyświetlanie
nazw używanych modułów przez konkretne urzadzenie.
˛
•
lspci - program ten wyświetla list˛e wykrytych urzadze
˛
ń PCI/AGP wraz z dodatkowymi informacjami. Warto użyć tu dodatkowo opcji "-v" - "-vv" w celu zwi˛ekszenia ilości danych. Program ten znajdziemy w pakiecie pciutils.
•
Komunikaty jadra
˛
- sa˛ to dosyć cenne informacje, możemy je odczytać w dzienniku
kernela: /var/log/kernel lub przejrzeć to co zwraca program dmesg:
# dmesg | less
Kiedy uzyskaliśmy informacje o sprz˛ecie, pozostaje nam odnaleźć moduł:
•
pcidev - program z pakietu pci-database - stara si˛e wykryć używany przez nas
sprz˛et oraz podaje nazw˛e sugerowanego modułu. Należy wywołać program z parametrem wskazujacym
˛
o interesujace
˛ nas urzadzenie
˛
np:
# pcidev agp
10de01e0 nvidia-agp nVidia Corporation|nForce2 AGP (different version?)
drugi zwrócony łańcuch jest nazwa˛ szukanego modułu. Aby otrzymać list˛e parametrów jakie przyjmuje program należy uruchomić go bez parametru. Uwaga: w
celu określenia modułu kontrolera dysku nie należy używać parametru ’ide’, tylko ’sata’, gdyż linia sterowników IDE jest przestarzała. Zamiast niej należy używać
tych opartych na libata.
•
Internet - można założyć, że ktoś si˛e już spotkał z podobnym problemem. Mamy
do dyspozycji spora˛ skarbnic˛e wiedzy: WWW, listy i grupy dyskusyjne.
•
Po nazwie modułu: modprobe -l {$słowo_kluczowe} - tak możemy próbować odnaleźć moduł wg. szukanego klucza np:
# modprobe -l *snd*
/lib/modules/2.6.11.6-4/kernel/sound/pcmcia/pdaudiocf/snd-pdaudiocf.ko.gz
/lib/modules/2.6.11.6-4/kernel/sound/pcmcia/vx/snd-vxp440.ko.gz
87
˛
/lib/modules/2.6.11.6-4/kernel/sound/pcmcia/vx/snd-vx-cs.ko.gz
/lib/modules/2.6.11.6-4/kernel/sound/pcmcia/vx/snd-vxpocket.ko.gz
/lib/modules/2.6.11.6-4/kernel/sound/drivers/snd-serial-u16550.ko.gz
/lib/modules/2.6.11.6-4/kernel/sound/drivers/mpu401/snd-mpu401-uart.ko.gz
/lib/modules/2.6.11.6-4/kernel/sound/drivers/mpu401/snd-mpu401.ko.gz
•
modinfo - program ten zwraca informacje o module, którego nazw˛e podajemy
jako parametr. Program jest pomocny jeśli zaw˛eziliśmy list˛e pasujacych
˛
modułów
do kilku pozycji.
Kiedy sadzimy
˛
że odnaleźliśmy właściwy moduł możemy go bez obaw wczytać i
przetestować nasze urzadzenie,
˛
jeśli próba zakończyła si˛e sukcesem to możemy zapisać jego nazw˛e do odpowiedniego pliku aby został załadowany przy każdym starcie
systemu. Opis tego znajduje si˛e w dalszej cz˛eści rozdziału.
Zarzadzanie
˛
modułami
Moduły sa˛ ze soba˛ powiazane
˛
i załadowanie danego modułu załaduje moduły od
niego zależne (jeśli takie sa),
˛ podobnie jest z ich usuwaniem z pami˛eci. Do zarzadza˛
nia modułami zaleca si˛e używanie programu modprobe z odpowiednimi parametrami zamiast programów insmod i rmmod
List˛e załadowanych modułów i zależności mi˛edzy nimi otrzymamy po wydaniu polecenia lsmod np:
# lsmod
Module
lp
parport
ext3
amd74xx
psmouse
ide_core
ide_disk
Size
8644
29896
119304
11676
34840
109560
14336
Used by
0
1 lp
1
0 [permanent]
0
2 ide_disk,amd74xx
9
Wczytanie modułu do pami˛eci:
# modprobe ne2k-pci
Usuwanie modułu z pami˛eci (możliwe tylko jeśli nie jest używany):
# modprobe -r ne2k-pci
Wyświetlenie listy modułów zależnych od podanego:
# modprobe --show-depends ne2k-pci
insmod /lib/modules/2.6.11.6-4/kernel/drivers/net/8390.ko.gz
insmod /lib/modules/2.6.11.6-4/kernel/drivers/net/ne2k-pci.ko.gz
Wyświetlenie listy dost˛epnych modułów:
# modprobe -l
Po "r˛ecznym" załadowaniu modułu do pami˛eci b˛edzie on dost˛epny do czasu
ponownego uruchomienia komputera, aby moduł był automatycznie ładowany
przy starcie systemu musimy użyć opisanych dalej plików: /etc/modules lub
/etc/modprobe.conf.
88
˛
/etc/modules
Plik ten zawiera list˛e modułów, które zostana˛ załadowane podczas startu systemu
(przez rc-skrypty). Znajac
˛ nazw˛e modułu możemy dodać ja˛ do tego pliku np:
echo "via82cxxx_audio" >> /etc/modules
/etc/modprobe.conf
˛
powiedzieliśmy, że plik /etc/modprobe.conf służy do konW sekcja Moduły jadra
figuracji modułów, jednak za pomoca˛ pewnej sztuczki b˛edziemy mogli wskazywać
moduły do załadowania. Polega ona na utworzeniu aliasów o ustalonych nazwach
i które b˛eda˛ ładowane np. przez rc-skrypty. Przykładowo utworzenie aliasu eth0
do odpowiedniego modułu karty sieciowej spowoduje załadowanie danego modułu przy próbie podniesienia interfejsu pierwszego interfejsu Ethernet. Przykładowy
alias:
alias eth0 8139too
spowoduje załadowanie modułu 8139too. Nic nie stoi na przeszkodzie żeby taki moduł został dopisany do /etc/modules, jednak metoda oparta na aliasach jest bardziej
czytelna i elegancka (zwłaszcza przy wi˛ekszej ilości kart sieciowych). Poniżej została
przedstawiona lista takich aliasów:
• eth{$Nr}
- opisany powyżej alias dla karty sieciowej typu Ethernet.
• ide_hostadapter, scsi_hostadapter
- aliasy do modułów kontrolerów pami˛eci
masowych, używane sa˛ m.in. przez skrypt geninitrd.
• char-major-116, snd-card-{$Nr}, char-major-14, sound-*
- aliasy dla modu-
łów kart muzycznych (ALSA).
Przykładowa konfiguracja:
alias
alias
alias
alias
eth0 8139too
scsi_hostadapter sata_sil
char-major-116 snd
snd-card-0 snd-intel8x0
Udev - dynamiczna obsługa sprzetu
˛
˛
modułami kernela i urzadzeniami
˛
w /dev było skomplikowane, ucia˛żliwe i wymagało praw administratora, stad
˛ narodziła si˛e idea systemu,
który zautomatyzuje te czynności. Tak oto powstał udev, współczesne wersje udeva
(nast˛epcy DevFS) maja˛ wbudowana˛ obsług˛e hotpluga i coldpluga. Dzi˛eki temu moga˛ automatycznie ładować potrzebne moduły, ma to sens wyłacznie
˛
w przypadku
modularnego kernela, jaki jest dost˛epny w PLD. Mimo właczenia
˛
hotpluga do udeva w PLD ciagle
˛
dost˛epne sa˛ pakiety z hotplugiem, sa˛ przechowywane jedynie dla
wstecznej zgodności i nie b˛eda˛ nam już potrzebne.
Poza nielicznymi wypadkami nie b˛edzie już konieczne dopisywanie nazw modułów
do pliku /etc/modules, ani ich r˛eczne ładowanie za pomoca˛ programu modprobe.
Wi˛ecej o plikach urzadze
˛
ń znajdziemy w sekcja Urzadzenia.
˛
89
˛
Instalacja
W systemie domyślnie instalowany jest pakiet dev, jeśli zechcemy przejść na udev to
wystarczy, że zainstalujemy pakiet udev a nast˛epnie odinstalujemy dev np.:
# poldek -i udev
# poldek -e dev
Osoby nie ufajace
˛ do końca dynamicznemu tworzeniu urzadze
˛
ń, nie usuwaja˛ z systemu statycznego deva tak jak to zrobiliśmy powyżej. Praktyka pokazuje jednak, że
nie ma powodów do obaw i poza wyjatkowo
˛
ważnymi instalacjami systemu nie ma
takiej potrzeby.
Konfiguracja
Udev w wi˛ekszości wypadków nie wymaga żadnych operacji konfiguracyjnych,
czasami tylko konieczne jest poprawienie lub dodanie regułki do katalogu
/etc/udev/rules.d/. Zanim si˛e tym zajmiemy powinniśmy zapoznać si˛e z
dokumentacja˛4.
W Ac do wyboru sa˛ dwa tryby pracy: udevstart (domyślny) i udevsynthesize.
Ten drugi wykrywa wi˛eksza˛ liczb˛e urzadze
˛
ń, stad
˛ warto si˛e pokusić o wybór
właśnie jego. Aby go używać wystarczy, że ustawimy odpowiednia˛ opcj˛e w pliku
/etc/udev/udev.conf:
UDEV_STARTER="udevsynthesize"
W Th powyższe opcje nie sa˛ już dost˛epne, ich miejsce zajał
˛ mechanizm udevtrigger.
Udev w praktyce
Liczba załadowanych modułów przez udev może przywrócić o zawrót głowy, udev
ładuje moduły znalezionych urzadze
˛
ń bez wzgl˛edu czy w ogóle z niego korzystamy. Jedyna˛ wada˛ takiego działania jest wi˛eksze zużycie pami˛eci przez nieużywane
sterowniki. Nie powinno przekroczyć 2MiB pami˛eci, wi˛ec dla ogromnej wi˛ekszości
współczesnych komputerów nie b˛edzie to stanowić żadnego problemu.
Mamy wpływ na list˛e ładowanych modułów, aby zablokować ładowanie jakiegoś
modułu wystarczy dodać do pliku /etc/modprobe.conf nazw˛e modułu poprzedzona˛ słowem blacklist np.:
blacklist rivafb
blacklist nvidiafb
Powyższa metoda ma sens jedynie jeśli chcemy zablokować pojedyncze moduły, jeśli
mamy komputer o bardzo małej ilości pami˛eci lepszym pomysłem b˛edzie pozostanie
przy statycznej metodzie ładowania modułów.
Uwagi
Jeśli mamy kilka kontrolerów urzadze
˛
ń masowych (IDE/SATA/SCSI) to moga˛ wyst˛epować problemy z wykrywaniem ich na czas, tak by były gotowe do zamontowania systemów plików określonych w /etc/fstab. Jedynym pewnym sposobem
poradzenia sobie z tym kłopotem jest dodanie modułów kontrolerów do initrd.
Wi˛ecej o udev możemy poczytać w FAQ5
90
˛
Udev nie zajmuje si˛e montowaniem przenośnych nośników danych, musimy robić
to r˛ecznie (co wymaga uprawnień administratora), lub użyć HAL-a, D-Busa oraz np.
gnome-volume-manager w przypadku środowiska Gnome.
Initrd
Wstep
˛
W PLD wszystkie możliwe sterowniki sa˛ dost˛epne w postaci tzw. modułów, przez co
nie sa˛ one "widoczne" dla jadra
˛
w trakcie startu systemu. Aby system wystartował
wymaganych jest kilka modułów i innych komponentów koniecznych do zamontowania głównego systemu plików (root filesystem):
•
moduły kontrolera urzadze
˛
ń masowych (IDE/SATA/SCSI) np.: sata_nv,
sata_sil, sd_mod
•
systemu plików na głównej partycji systemowej np.: xfs, reiserfs
•
elementy konieczne do złożenia woluminów opartych o LVM lub programowy
RAID
Jedynym sposobem dostarczenia tych sterowników jest umieszczenie ich w specjalnym "obrazie" zwanym initrd (initial ramdisk). Obraz ten jest plikiem wczytywanym przez bootloader, tak wi˛ec dodatkowo musimy właściwie skonfigurować bootloader - wskazać położenie obrazu. Obraz przechowywany jest w katalogu /boot
i ma nazw˛e initrd-{$wersja_jadra}.gz
˛
, do niego zaś prowadzi łacze
˛
o nazwie
initrd.
Initrd jest tworzony przy każdej instalacji/aktualizacji kernela. Bywa jednak, że nasz
obraz nie jest wygenerowany prawidłowo i jesteśmy zmuszeni do utworzenia go
samodzielnie. Źle utworzony uniemożliwi uruchomienie systemu, ujrzymy wtedy
nast˛epujacy
˛ komunikat:
Kernel panic: VFS: Unable to mount root fs...
Jadro
˛
mówi nam, że nie może zamontować głównego systemu plików, gdyż brakuje
mu jakiegoś komponentu. Może si˛e to zdarzyć, że nasz sprz˛et nie został prawidłowo
wykryty lub próbujemy uruchomić PLD z naszego dysku na innym komputerze (o
innym kontrolerze urzadze
˛
ń masowych).
Systemu nie można uruchomić wi˛ec musimy skorzystać z operacji chroot-a, możemy
w tym celu użyć dowolnej dystrybucji linuksa jednak chyba najwygodniejsze b˛edzie
użycie PLD-Live lub RescueCD.
Przygotowanie
Poniżej przedstawiono trzy metody generowania initrd. W wi˛ekszości wypadków
wystarczy nam pierwszy ze sposobów, pozostałe sa˛ trudniejsze gdyż musimy znać
nasz sprz˛et i system plików partycji "/". Jeśli obraz nie jest tworzony prawidłowo
przez pierwsza˛ metod˛e musimy si˛e zadowolić dwoma pozostałymi. Druga i trzecia
metoda maja˛ jedna˛ zasadnicza˛ przewag˛e nad pierwsza˛ - moga˛ być przeprowadzane
na dowolnej maszynie.
W dwóch pierwszych metodach użyjemy skryptu /sbin/geninitrd z pakietu
geninitrd. Jest to wygodny automat, który stara si˛e wykryć sprz˛et, system plików i
czy główny system plików jest stworzony na LVM/soft RAID. Skrypt geninitrd
91
˛
wymaga prawidłowych wpisów w /etc/fstab i podmontowanego /proc. Tak wi˛ec
jeśli generujemy initrd w systemie typu chroot to wydajemy polecenie (z chroota):
# mount /proc
Opis wykrywania sprz˛etu i dobierania właściwych modułów opisano w sekcja Statyczne zarzadzanie
˛
modułami.
Automatyczne generowanie initrd
W razie potrzeby edytujemy plik /etc/sysconfig/geninitrd i ustawiamy jaki rodzaj urzadzenia
˛
(SCSI, IDE, RAID) ma być automatycznie wykrywany:
## Do install SCSI modules (if / is on SCSI partition)?
PROBESCSI=yes
## Do install IDE modules (if / is on IDE partition)?
PROBEIDE=yes
## Do install RAID modules (if RAID is used)?
PROBERAID=yes
Teraz przyszedł czas na wygenerowanie obrazu wg schematu
geninitrd [opcje] {$initrd} {$wersja_jadra}
˛
np.:
# geninitrd -v -f /boot/initrd-2.6.16.35-1.gz 2.6.16.35-1
Parametr -v odpowiada za "gadatliwość" programu, zaś -f wymusza nadpisanie
istniejacego
˛
obrazu.
Reczne
˛
generowanie initrd
Metoda ta wymaga precyzyjnej znajomości używanego sprz˛etu i systemu plików,
gdyż sami musimy wskazać odpowiednie moduły. Jest jednak konieczna, w przypadku problemów z automatycznym wykryciem wymaganych sterowników lub jeśli
chcemy operacj˛e wykonać na innej maszynie niż docelowa.
Możemy wpisać list˛e koniecznych modułów do odpowiedniej sekcji w pliku
/etc/sysconfig/geninitrd:
## Basic modules to be loaded
BASICMODULES=""
## Modules that should be loaded before anything (i.e. jbd for ext3)
PREMODS=""
lub zmodyfikować wywołanie geninitrd poprzez użycie parametru --with:
geninitrd [opcje] --with={$nazwa_modułu} {$initrd} {$wersja_jadra}
˛
Dużym ułatwieniem zadania jest automatyczne dołaczanie
˛
modułów zależnych od
wskazanego (o ile takie sa).
˛ Poniżej zamieszczono przykładowe wywołanie geninitrd
dla systemu plików ext3 i kontrolera IDE PDC20268 firmy Promise:
# geninitrd -v --with=ext3 --with=pdc202xx_new
92
/boot/initrd-2.6.16.35-1.gz 2.6.16.35-1
˛
Gdy zawiedzie geninitrd
Możemy zmodyfikować zawartość obrazu wygenerowanego przez geninitrd, aby to
zrobić rozpoczynamy od skopiowania initrd w inne miejsce i rozpakowania go:
# gunzip initrd-2.6.16.35-1.gz
rozpakowany plik montujemy jako loop:
mkdir /tmp/initrd-src
# mount -o loop initrd-2.6.16.35-1 /tmp/initrd-src
Tworzenie initrd rozpocznijmy od skopiowania zawartości katalogu w inne miejsce:
# cp -a /tmp/initrd-src initrd-moje
cp: czytanie ‘initrd-src/bin/sh’: Bład
˛ wejścia/wyjścia
Pomimo tego bł˛edu dobrze si˛e skopiowało, warto jednak sprawdzić uprawnienia i
atrybuty pliku (ewentualnie poprawić na takie jak w oryginale)
Aby dodać moduł, musimy go skopiować z naszego systemu do odpowiedniego
katalogu
w
initrd-moje/lib/modules/*/,
nast˛epnie
do
skryptu
initrd-moje/linuxrc dodać wpis "insmod {$moduł}" na wzór już istniejacych
˛
({$moduł} musi zawierać pełna˛ ścieżk˛e do pliku).
Przyszedł czas na wygenerowanie initrd:
# genromfs -d initrd-moje -f initrd-nowy
Kompresujemy nowy initrd:
# gzip -9 initrd-nowy
Teraz już pozostało tylko skopiowanie pliku initrd-nowy.gz do /boot i nadanie
mu odpowiedniej nazwy.
Bootloader
Musimy si˛e upewnić czy łacze
˛
symboliczne /boot/initrd wskazuje na prawidłowy
obraz. Jeśli używamy LiLo wydajemy polecenie:
# lilo
W przypadku Grub-a nic nie musimy robić.
Na koniec restartujemy komputer i system powinien uruchomić si˛e bez problemu.
Konfiguracj˛e bootloaderów szerzej opisano w sekcja Wst˛ep w Rozdział 10.
Uwagi
Cz˛este zmiany używanego obrazu initrd moga˛ być ucia˛żliwe, można to obejść łacz
˛ ac
˛
do jednego obrazu wi˛eksza˛ ilość modułów. Aby to zrobić możemy dopisać nazwy
modułów do przedstawionych poniżej opcji w pliku /etc/sysconfig/geninitrd:
## Basic modules to be loaded
BASICMODULES=""
## Modules that should be loaded before anything (i.e. jbd for ext3)
PREMODS=""
93
˛
możemy też użyć opcji --with programu geninitrd. Warto pami˛etać żeby nie przesadzać z ich ilościa,˛ może to spowodować wolniejszy start systemu i niepotrzebne
zużycie pami˛eci operacyjnej przez nieużywane sterowniki.
Urzadzenia
˛
Podobnie jak w innych systemach uniksowych obowiazuje
˛
tutaj zasada "everything
is a file", czyli wszystko jest plikiem. Dzi˛eki takiemu podejściu uproszczono sposób
komunikacji z urzadzeniami,
˛
poprzez odwoływanie si˛e do specjalnych plików, odpowiadajacych
˛
konkretnym urzadzeniom.
˛
Pliki te sa˛ przechowywane w katalogu /dev,
zwykły użytkownik nie musi si˛e martwić o jego zawartość, wystarczy że b˛edzie znał
powiazania
˛
mi˛edzy fizycznymi urzadzeniami
˛
a nazwami tych plików.
Z nazw urzadze
˛
ń najcz˛eściej korzysta si˛e w przypadku operacji dyskowych, warto
zatem znać zasad˛e ich określania, wi˛ecej szczegółów na ten temat podano w sekcja
Nazewnictwo urzadze
Podstawowe informacje o urzadzeniu
˛
Nazwy urzadze
˛
ń nadawane sa˛ tak, aby ułatwiać życie użytkownikom, dla jadra
˛
sa˛
właściwie oboj˛etne. Jadro
˛
rozróżnia urzadzenia
˛
za pomoca˛ pary liczb: major (głównej) i minor (pobocznej). To jakie sa˛ wartości tych liczb odczytamy nast˛epujaco:
˛
ls -l /dev/hda2
brw-rw---- 1 root disk 3, 2 2005-11-11 15:08 /dev/hda2
Na powyższym przykładzie major jest równa 3, zaś minor jest równa 2. Pierwsza
literka w łańcuchu opisujacego
˛
uprawnienia określa rodzaj pliku, znak "b" (jak na
powyższym przykładzie) oznacza urzadzenie
˛
blokowe, zaś "c" urzadzenie
˛
znakowe.
Jeśli potrzebujemy samodzielnie utworzyć plik urzadzenia,
˛
to użyjemy do tego programu mknod np.:
# /bin/mknod
/dev/zero c 1 5
Numery major i minor oraz inne informacje odnajdziemy w dokumentacji kernela,
jeśli zainstalujemy pakiet kernel-doc to powinniśmy zapoznać si˛e z zawartościa˛ pliku
/usr/src/linux/Documentation/devices.txt
Systemy plików-urzadze
˛
ń
Sa˛ dwa sposoby dostarczania plików urzadze
˛
ń dla systemu: dev - statyczny i udev
- dynamiczny. Każdy z nich ma wsparcie w PLD, jednak domyślnie instalowany
jest pakiet udev. Jeśli chcemy użyć innego mechanizmu, wystarczy że odinstalujemy
udev a zainstalujemy dev w jego miejsce, dla pewności ta˛ operacj˛e lepiej przeprowadzać przy pomocy operacji chroot-a.
Najstarszym z rozwiaza
˛ ń jest pakiet dev, dzi˛eki niemu w katalogu /dev zostanie
utworzona spora ilość w˛ezłów (nawet jeśli nie mamy danego rodzaju urzadzenia),
˛
wystarczajaca
˛ dla wi˛ekszości zastosowań. Jeśli jednak mamy jakieś egzotyczne urza˛
dzenie to b˛edziemy musieli samemu utworzyć wymagane pliki. Pliki urzadze
˛
ń tworzymy za pomoca˛ opisanego wcześniej programu mknod.
W odróżnieniu od statycznej bazy plików urzadze
˛
ń w ostatnim czasie popularność
zdobywaja˛ systemy automatycznego tworzenia w˛ezłów w katalogu /dev. W chwili
podłaczenia
˛
urzadzenia
˛
lub startu systemu automatycznie tworzone sa˛ wymagane
pliki. Jest to ogromne ułatwienie dla użytkowników, gdyż nie wymaga od nich wiedzy na ten temat.
94
˛
UDEV
Udev automatycznie tworzy pliki urzadze
˛
ń, jednak sam potrzebuje kilku z nich, aby
mógł zaczać
˛ działać, sa˛ to: /dev/console, /dev/null, /dev/zero. Pliki te sa˛ dostarczane razem z pakietem, a wi˛ec nie musimy si˛e to martwić.
System udev jest wart uwagi dlatego, że nie tylko tworzy wymagane w˛ezły urzadze
˛
ń
lecz dodatkowo ładuje wymagane moduły jadra
˛
dla danego urzadzenia.
˛
Wi˛ecej informacji o udev znajdziemy w sekcja Udev - dynamiczna obsługa sprz˛etu
Należy pami˛etać o tym, że udev jest wywoływany z rc-skryptów, i nie wystartuje
przy użycia parametru jadra
˛
init lub przy próbie wykonania operacji chroota z innego systemu. Wtedy wymagane pliki nie zostana˛ utworzone, co może spowodować
nieoczekiwane problemy z działaniem programów. W przypadku wykonania operacji chroota problem ten rozwiazujemy
˛
poprzez wcześniejsze podmontowanie katalogu /dev z systemu głównego. W pozostałych przypadkach uruchamiamy skrypt
/etc/rc.d/rc.sysinit, w ostateczności tworzymy wymagane urzadzenia
˛
za pomoca˛ programu mknod lub skadś
˛ je kopiujemy. Operacja chroota została szerzej
opisana w sekcja Ratowanie systemu w Rozdział 14. Parametr jadra
˛
init jak i wiele
innych szerzej opisano w sekcja Wst˛ep w Rozdział 10.
Jaki system wybrać?
Na stacji roboczej bez zastanowienia można polecić udev, gdyż pozwoli na znaczne
podniesienie komfortu pracy. W przypadku serwerów b˛edzie to głównie zależało od
preferencji administratora i wybór nie b˛edzie miał tu wi˛ekszego znaczenia.
Zupełnie inaczej to wyglada
˛ w przypadku systemów zamkni˛etych typu chroot, zarówno plikami urzadze
˛
ń jak i modułami zajmuje si˛e system gospodarz, ponadto
udev może stać si˛e poważnym wyłomem w bezpieczeństwie klatki. W takim wypadku powinniśmy użyć statycznych plików (dev), których lista powinna zostać poważnie ograniczona do kilku niezb˛ednych.
Przypisy
1. http://www.grsecurity.net
2. http://linux-vserver.org
3. http://cvs.pld-linux.org/cgi-bin/cvsweb/SPECS/
4. http://www.reactivated.net/writing_udev_rules.html
5. http://pld-linux.org/pl/UdevFAQ
95
˛
96
Rozdział 12. Konfiguracja systemu
Ten rozdział prezentuje metody konfiguracji parametrów systemu.
Podstawowe ustawienia
Plik /etc/sysconfig/system przechowuje zaawansowana˛ konfiguracj˛e systemu, w
rozdziale tym opisano cz˛eść z zawartych w nim opcji.
Konfiguracja skryptów startowych
Zmienna określa czy skrypty startowe maja˛ używać kolorów:
COLOR_INIT=yes
Numer kolumny wyświetlania wyniku działania skryptu startowego:
INIT_COL=75
Szybsze uruchomienie systemu z pomini˛eciem niektórych skryptów, startowych m.in. skryptu od obsługi j˛ezyków:
FASTRC=no
Zezwolenie na interaktywny start rc-skryptów (pytanie o uruchomienie każdego z
podsystemów) po wciśni˛eciu klawisza I:
RC_PROMPT=yes
Opcje zwiazane
˛
z jadrem
˛
"Gadatliwość" kernela dla komunikatów wysyłanych na konsol˛e tekstowa.˛ Opcja jest
jednoznaczna z wywołaniem polecenia dmesg -n {$nr} (domyślnie 1):
CONSOLE_LOGLEVEL=1
Czas w sekundach, po którym nastapi
˛ restart maszyny jeśli wystapił
˛ krytyczny bład
˛
jadra
˛
(kernel panic). Ważna opcja w przypadku komputerów, do których nie mamy
fizycznego dost˛epu:
PANIC_REBOOT_TIME=60
Opcje uruchamiania systemu
Uruchomienie programu sulogin (pytanie o hasło root-a) zamiast powłoki jeśli wystapi
˛ a˛ problemy w trakcie uruchomienia:
RUN_SULOGIN_ON_ERR=yes
97
Wartość "yes" poniższej zmiennej pozwala na zalogowanie si˛e użytkowników dopiero po zakończeniu procesu ładowania systemu. Dzi˛eki unikniemy potencjalnych
problemów wynikajacych
˛
z przedwczesnym uzyskaniem dost˛epu, z drugiej jednak
strony tracimy możliwość zalogowania si˛e (np. przez SSH) jeśli pojawia˛ si˛e problemy
przed końcem ładowania systemu. Może to być istotne dla systemów obsługiwanych
na odległość.
DELAY_LOGIN=yes
Opcja określa czy w czasie startu ma być usuwana zawartość katalogu /tmp:
CLEAN_TMP=yes
Wskazuje czy ma być zamontowany podsystem devfs:
MOUNT_DEVFS=no
Usługi
Domyślny priorytet (liczba nice) dla usług, którym nie go zdefiniowano w zmiennej SERVICE_RUN_NICE_LEVEL umieszczanej w pliku podstawowej konfiguracji
usługi (/etc/sysconfig/{$usługa}):
DEFAULT_SERVICE_RUN_NICE_LEVEL=0
Lista katalogów przechowujacych
˛
systemy typu chroot, które maja˛ być zarzadzane
˛
przez skrypt /etc/init.d/sys-chroots:
SYSTEM_CHROOTS=/jakis_katalog
Ustawienia konsoli
Dzi˛eki plikowi /etc/sysconfig/console możemy ustawić takie parametry jak
czcionka konsoli, mapa klawiatury, kodowanie fontów oraz zarzadzanie
˛
energia.˛
Aby zmienić czcionk˛e, edytujemy parametr:
CONSOLEFONT=lat2u-16
Do wyboru mamy czcionki zamieszczone w katalogu /usr/share/consolefonts.
Aby zmienić kodowanie znaków, edytujemy parametr:
CONSOLEMAP=8859-2
Aby zmienić mapowanie klawiatury edytujemy parametr:
KEYTABLE=pl2
Aby ustawić numery konsol dla których aplikowane sa˛ parametry, zmieniamy:
98
SET_FONT_TERMINALS="1 2 3 4 5 6 7 8"
Przedstawiony parametr deklaruje zmian˛e ustawień dla konsol tty1-tty8.
Aby zmienić opcje zarzadzania
˛
energia,˛ edytujemy parametry:
POWER_SAVE=on
BLANK_TIME=10
POWERDOWN_TIME=60
Parametr BLANK_TIME określa liczb˛e minut nieaktywności do wygaszenia ekranu,
POWERDOWN_TIME - do wyłaczenia
˛
monitora.
Aby zmienić kolor czcionki lub tła, edytujemy parametr:
FOREGROUND_COLOUR=red
BACKGROUND_COLOUR=green
Do wyboru posiadamy kolory black|red|green|yellow|blue|magenta|cyan|white|default.
Aby zmienić domyślny tryb NUM Locka, edytujemy parametr:
NUM_LOCK=on
Do wyboru posiadamy atrybut "on" lub "off".
Aby uaktywnić zmiany wykonujemy:
/sbin/service console start
Internacjonalizacja
Wstep
˛
Cz˛estym problemem poczatkuj
˛
acego
˛
użytkownika Linuksa jest ustawienie wyświetlania znaków diakrytycznych, walut oraz odpowiedniego j˛ezyka. Ponieważ PLD
jest dystrybucja˛ dla zaawansowanych użytkowników, możemy w niej przystosować
środowisko pracy do naszych indywidualnych potrzeb.
Internacjonalizacja konsoli i programów
Zanim przystapimy
˛
do instalowania poszczególnych paczek, musimy w
pliku /etc/sysconfig/i18n ustawić odpowiednie zmiennie środowiskowe
odpowiadajace
˛
za j˛ezyk czcionk˛e systemowa˛ oraz kodowanie. W naszym
przypadku wpis ten wyglada
˛ nast˛epujaco:
˛
SUPPORTED_LOCALES=pl_PL
LANG=pl_PL
LC_ALL=pl_PL
LINGUAS=pl_PL
SYSFONT=lat2u-16
UNIMAP=lat2u
SYSFONTACM=iso02
Nast˛epnie instalujemy pakiety odpowiedzialne za ustawienia lokalne i klawiatur˛e:
# poldek -i localedb-src kbd
Locale generujemy poleceniem localedb-gen, które domyślne ustawienia pobiera ze
zmiennej SUPPORTED_LOCALES wiec jeśli chcielibyśmy mieć obsług˛e również innego
j˛ezyka, to trzeba to zaznaczyć właśnie przy tej zmiennej.
99
Przykładowy zapis dla kilku j˛ezyków w pliku /etc/sysconfig/i18n może wygla˛
dać tak:
LANG=pl_PL
# list of supported locales
SUPPORTED_LOCALES="pl_PL/ISO-8859-2 de_DE/ISO-8859-2 \
en_GB/ISO-8859-1 en_US/ISO-8859-1"
Można też zainstalować pakiet zawierajacy
˛ baz˛e danych locale dla wszystkich lokalizacji obsługiwanych przez glibc.
# poldek -i glibc-localedb-all
Aby sprawdzić czy wszystko przebiegło pomyślnie wydajemy polecenie:
$ locale
LANG=pl_PL
LC_CTYPE="pl_PL"
LC_NUMERIC="pl_PL"
LC_TIME="pl_PL"
LC_COLLATE="pl_PL"
LC_MONETARY="pl_PL"
LC_MESSAGES="pl_PL"
LC_PAPER="pl_PL"
LC_NAME="pl_PL"
LC_ADDRESS="pl_PL"
LC_TELEPHONE="pl_PL"
LC_MEASUREMENT="pl_PL"
LC_IDENTIFICATION="pl_PL"
LC_ALL=
Sprawdzamy czy wszystkie wpisy si˛e zgadzaja.˛
Jeśli chcemy aby ustawienia dopasowane były do naszych upodobań do dyspozycji
mamy nast˛epujace
˛ zmienne LC_*:
Dost˛
epne zmienne LC_*:
* LC_CTYPE: Konwersja czcionki i wielkości liter.
˛
sortowania.
* LC_COLLATE: Porzadek
* LC_TIME: Format wyświetlania daty i godziny.
˛
z waluta˛
* LC_NUMERIC: Wyświetlanie liczb nie zwiazanych
* LC_MONETARY: Formaty walutowe.
* LC_MESSAGES: Format wiadomości informacyjnych, diagnostycznych \
oraz określajacych
˛
interakcje programu.
* LC_PAPER: Rozmiar papieru.
* LC_NAME: Format nazw.
* LC_ADDRESS: Format wyświetlania adresu i lokalizacji.
* LC_TELEPHONE: Format wyświetlania numeru telefonu.
* LC_MEASUREMENT: Jednostki miary (metryczna lub inna)
* LC_IDENTIFICATION: Metadata o ustawieniach locale.
Przykładowo jako domyślnego j˛ezyka, możemy używać angielskiego jednak ze
wsparciem dla polskich czcionek i polskich walut. Wszelkiego typu zmiany
dokonujemy poprzez dodanie do pliku ~/.bash_profile odpowiednich wpisów:
LANG=en_EN
export LANG
LC_CTYPE=pl_PL
export LC_CTYPE
100
Myszka pod konsola˛
Wstep
˛
Niniejszy rozdział dotyczy uruchomienia obsługi myszy dla terminala znakowego,
konfiguracj˛e myszy dla środowiska graficznego (X-Window) opisano w sekcja XServer w Rozdział 18. Proces konfiguracji rozpoczynamy od instalacji demona gpm:
# poldek -i gpm
Dalsza cz˛eść konfiguracji polega na załadowaniu właściwego modułu jadra
˛
i ustawieniu przynajmniej dwóch parametrów w pliku /etc/sysconfig/mouse: nazwy
urzadzenia
˛
(DEVICE) i typu myszy (MOUSETYPE).
Poniższy opis dotyczy kernela 2.6.x, w tej wersji jako urzadzenia
˛
dla myszy PS2 i
USB stosuje si˛e /dev/input/mouse0, /dev/input/mouse1, ... lub urzadzenie
˛
zbiorcze /dev/input/mice. Jednak dla wstecznej zgodności działa dalej /dev/psaux
Szeregowa
Obsługa portu szeregowego RS-232 jest cz˛eścia˛ jadra
˛
PLD, wi˛ec nie ładujemy żadnego modułu - urzadzenia
˛
działaja˛ od razu po podłaczeniu.
˛
W zależności od tego,
na którym porcie mamy podpi˛eta˛ mysz, ustawiamy odpowiednio parametr DEVICE, pami˛etajac,
˛ że /dev/ttyS0 to COM1, /dev/ttyS1 to COM2 ...
Typ myszy b˛edzie zależał od modelu posiadanego urzadzenia,
˛
w wi˛ekszości wypadków powinna zadziałać dla wartości "ms", "msc", lub "ms3". Szczegółowe informacje
na ten temat znajdziemy w pomocy demona, która˛ wyświetlimy w sposób opisany
na końcu rozdziału.
DEVICE=/dev/ttyS0
MOUSETYPE=ms3
PS/2, TouchPad, TrackPoint
W laptopach urzadzenia
˛
wskazujace
˛ sa˛ zgodne z myszkami typu PS/2, stad
˛ ich konfiguracja przebiega tak samo. Rozpoczynamy od załadowania modułu jadra:
˛
# modprobe psmouse
Podajemy urzadzenie
˛
myszy i jej typ, który dla wi˛ekszości urzadze
˛
ń ustawimy na
"ps2" lub "imps2":
DEVICE=/dev/input/mice
MOUSETYPE=ps2
USB
Ładowanie modułów dla tego rodzaju urzadze
˛
ń może być wykonane automatycznie przez mechanizm udev lub r˛ecznie. W drugim wypadku wydajemy nast˛epujace
˛
polecenia (zakładam że sa˛ już załadowane moduły dla kontrolera USB):
# modprobe usbhid
# modprobe usbmouse
101
Podajemy urzadzenie
˛
myszy i jej typ, który dla wi˛ekszości urzadze
˛
ń ustawimy na
ps2 lub imps2:
DEVICE=/dev/input/mice
MOUSETYPE=ps2
Zakończenie
Teraz wystarczy tylko uruchomić usług˛e gpm:
# /etc/init.d/gpm start
Wcześniej załadowane moduły można jeszcze wpisać do /etc/modules, aby ładowały si˛e przy starcie systemu.
Porady
•
Wi˛ekszość dost˛epnych na rynku myszek powinna zadziałać z przedstawiona˛
powyżej konfiguracja.˛ Możliwe jednak, że nasza mysz używa nietypowego
protokołu i należy ustawić inny typ urzadzenia
˛
(MOUSETYPE). W takim
wypadku pomocna może si˛e okazać lista urzadze
˛
ń i odpowiadajacych
˛
im typów
wyświetlana w wyniku poniższego polecenia:
# gpm -m /dev/input/mice -t help
•
Pożyteczna˛ opcja˛ jest BUTTON_COUNT, która definiuje liczb˛e przycisków myszy.
•
Zamiast wskazania pliku urzadzenia,
˛
możemy użyć łacza
˛
symbolicznego o nazwie
/dev/mouse wskazujacego
˛
na właściwe urzadzenie.
˛
Strefa czasowa
Strefy czasowe to specjalne ustawienia, pozwalajace
˛ systemowi na łatwe przeliczanie
czasu uniwersalnego (UTC) na lokalny i na odwrót. Zaczynamy od instalacji koniecznego pakietu:
$ poldek -i tzdata
Aby wskazać stref˛e czasowa˛ modyfikujemy plik /etc/sysconfig/timezone, jego
ustawienia wskazuja˛ na odpowiednie pliki i katalogi w /usr/share/zoneinfo, które z kolei odpowiadaja˛ strefom czasowym. Nazwy plików odpowiadaja˛ pewnym
punktom geograficznym tak aby łatwiej było określić właściwa˛ stref˛e.
W Ac ustawiamy zmienne ZONE_INFO_AREA i TIME_ZONE. Opcje wskazuja˛ na
katalog i plik opisujacy
˛ stref˛e, jak zapewne czytelnik zauważy, cz˛eść z nich nie jest
przechowywania w podkatalogach, wtedy ta˛ zmienna˛ należy ustawić pusta.˛ Dla Polski wybieramy podajemy nast˛epujace
˛ wartości:
ZONE_INFO_AREA="Europe"
TIME_ZONE="Warsaw"
˛
przez TIMEZONE, tutaj wartości oddzielaW Th powyższe opcje zostały zastapione
my slashem:
TIMEZONE="Europe/Warsaw"
102
Aby zmiany odniosły skutek musimy zrestartować odpowiedni skrypt startowy:
# service timezone restart
Wi˛ecej
informacji
o
www.timeanddate.com1
strefach
czasowych
znajdziemy
na
witrynie
Zegar
Standardowo BIOS powinien używać czasu uniwersalnego (UTC), zegar
systemowy powinien wtedy działać zgodnie z czasem lokalnym, określonym w
pliku /etc/sysconfig/timezone. W ten sposób zmiany czasu letni/zimowy b˛eda˛
nast˛epowały automatycznie, bez modyfikowania ustawień zegara sprz˛etowego.
Wyjatkiem
˛
od tej reguły jest używanie na tym samym komputerze PLD i któregoś z
produktów Microsoftu. Te ostatnie używaja˛ zgodnego czasu dla BIOS-u i systemu, co
spowoduje różnice we wskazaniach zegarów. Jedynym rozwiazaniem
˛
tego problemu
jest zmuszenie naszego PLD, by używał czasu BIOS-u jako czasu lokalnego. W tym
wypadku zmiana˛ czasu letni/zimowy może zajać
˛ si˛e system Microsoftu lub możemy
wykonać to samodzielnie.
Aby skorzystać z pierwszego rozwiazania
˛
synchronizujemy zegar sprz˛etowy z czasem uniwersalnym, a w pliku /etc/sysconfig/clock ustawiamy:
UTC="true"
W przeciwnym wypadku ustawiamy czas lokalny i wybieramy wartość
UTC="false"
Zmienne środowiskowe
Przegladanie
˛
Zmienne środowiskowe to prosty sposób modyfikowania konfiguracji środowiska
użytkownika. List˛e zmiennych i przypisanych im wartości uzyskamy za pomoca˛
polecenia powłoki set, na poniższym przykładzie przedstawiono fragment wyniku
polecenia:
$ set
BASH=/bin/bash
BASH_VERSINFO=([0]="2" [1]="05b" [2]="0" [3]="2" [4]="release" [5]="i686-pld-linux-gnu"
BASH_VERSION=’2.05b.0(2)-release’
COLORTERM=gnome-terminal
COLUMNS=125
Konfiguracja globalna
Administrator może ustawić globalnie wszystkim użytkownikom zmienne środowiskowe. Do tego wykorzystuje si˛e mechanizm env.d. Jest to katalog umieszczony
w /etc, zawierajacy
˛ pliki tekstowe o nazwach takich samych jak nazwy zmiennych,
wewnatrz
˛ każdego z nich podana nazwa zmiennej i jej wartość. Przykładowo zmienna EDITOR zostanie zainicjowana jeśli utworzymy plik /etc/env.d/EDITOR, jego
treść może wygladać
˛
nast˛epujaco:
˛
103
EDITOR=vim
Zmiany w /etc/env.d sa˛ aktualizowane po ponownym zalogowaniu danego użytkownika.
Konfiguracja lokalna
Każdy użytkownik może zarówno tworzyć takie zmienne jak i nadpisywać te ustawione globalnie.
Zmienne możemy powoływać na czas sesji, dokonujemy tego przy pomocy powłoki (shell). W wi˛ekszości z nich (sh, zsh, bash, ksh) istnieje polecenie export które
pozwala ustawić dowolna zmienna˛ np.:
# export EDITOR=mcedit
Tak ustawiona zmienna b˛edzie funkcjonować do czasu wylogowania użytkownika
Aby ustawić na stałe zmienna˛ użyjemy pliku konfiguracyjnego powłoki. Musimy
jedynie wstawić do takiego pliku podane wyżej polecenie export. Każda z powłok
posiada swoje własne pliki startowe, przykładowo powłoka BASH używa pliku
~/.bash_profile i ~/.bashrc, zaś ZSH ~/.zshenv. Wi˛ecej informacji na ten temat
zawarto w manualu każdej z powłok.
Jeśli chcemy ustawić zmienna˛ środowiskowa˛ tylko dla jednego uruchamianego programu, to podajemy jej definicj˛e przed nazwa˛ programu np.:
$ http_proxy=62.87.244.34:8080 wget http://foobar.com/plik.foo
PLDconf - Narzedzie
˛
do konfiguracji systemu
Pldconf jest narz˛edziem tworzonym z myśla˛ o poczatkuj
˛
acych
˛
użytkownikach. Wiele opcji jest konfigurowanych automatycznie. Pldconf ma małe wymagania i jest niewielkim pakietem (ok. 150 kB) Jego instalacja sprowadza si˛e do wydania polecenia:
# poldek -i pldconf
Program zadaje minimalna˛ ilość pytań i w podstawowej wersji (dla PLD RA 1.0)
konfiguruje:
1. Serwer X: karta (auto), rozdzielczość, kolory, itd;
2. Sieć: bramka, DNS, karty sieciowe (auto), otoczenie sieciowe, SDI, NEO (ethernet);
3. Desktop: menedżer okien, kolory, czcionki i wi˛ecej;
4. Menedżer startu: menu z linuksem i windows, dyskietka startowa i wi˛ecej;
5. Dost˛ep do partycji windows;
tyle z podstawowych możliwości - pldconf potrafi wi˛ecej.
Obecnie pldconf rozwijany jest dla nadchodzacego
˛
PLD 2.0 (AC/DC/NEST). W nowej wersji dodano mi˛edzy innymi:
1. Konfiguracje karty dźwi˛ekowej (alsa);
2. Konfiguracje drukarki (cups);
3. Optymalizacje dysku twardego (hdparm);
104
4. Konfiguracje fetchmail;
5. Konfiguracje tunera telewizyjnego
6. Zarzadzanie
˛
kontami użytkowników
Wersja pldconf dla PLD 2.0 nieznacznie różni si˛e od wersji dla PLD 1.0. Różnice
dotycza˛ przede wszystkim zmiany ścieżek (np. /usr/X11R6/bin/mozilla w PLD
2.0 zmieniono na /usr/bin/mozilla) głównie w module do konfiguracji desktopu. W praktyce blisko 100% pldconf w najnowszej wersji (przeznaczonym dla PLD
2.0) działa poprawnie również w systemie PLD 1.0. W szczególności najnowszy pldconf potrafi przeprowadzić sieciowa˛ instalacj˛e PLD 2.0 - moduł instalacji zadziała
poprawnie w systemie PLD 1.0. Innymi słowy, aby zainstalować PLD 2.0 spod uruchomionego PLD 1.0 należy zainstalować najnowsza˛ wersj˛e pldconf.
Uwaga: W przypadku instalacji nowego pldconf w systemie PLD 1.0 wymagana jest
również instalacja pakietu perl-modules.
Strona domowa projektu
• http://www.inf.sgsp.edu.pl/pub/PROGRAMY/PLD/
Kluczowe pliki
W tym rozdziale przedstawione sa˛ informacje o kluczowych plikach systemu operacyjnego. Zostały tu opisane jedynie podstawowe dane na ich temat, wi˛ecej można
znaleźć w podr˛eczniku systemowym man, oraz info
/etc/inittab
Plik /etc/inittab przechowuje konfiguracj˛e programu init, uruchamianego w trakcie startu systemu i działajacego
˛
bez przerwy do chwili jego zamkni˛ecia. Głównym
zadaniem procesu init jest kontrola zachowania systemu w zależności od osiagni˛
˛ etego poziomu pracy systemu oraz w wypadku wystapienia
˛
specjalnych zdarzeń. Poziomy pracy szczegółowo opisano w sekcja Zmiana poziomu pracy systemu w Rozdział
14.
Oto najważniejsze opcje zawarte w pliku /etc/inittab:
•
Domyślny poziom uruchomienia - wskazuje programowi init jaki poziom
uruchomienia ma być wybrany jeśli wywołano go bez parametrów lub w
trakcie startu systemu. Wiersz określajacy
˛
t˛e opcj˛e wyglada
˛
nast˛epujaco:
˛
id:{$poziom}:initdefault: ($poziom to cyfra odpowiadajaca
˛ poprawnemu
poziomowi uruchomienia), ustawienie domyślnie trzeciego poziomu
uruchomienia przedstawiono na poniższym przykładzie:
id:3:initdefault:
•
Instrukcje uruchomienia programu mingetty na pierwszym terminalu wirtualnym
(/dev/tty1), wywołania dla kolejnych b˛eda˛ bardzo podobne:
1:12345:respawn:/sbin/mingetty --noclear tty1
•
Poniższy wiersz uruchomi program agetty, łacz
˛ acy
˛ si˛e z portem szeregowym
/dev/ttyS0, w celu podłaczenia
˛
terminala szeregowego:
0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100
Jeśli nie używamy tego rodzaju urzadze
˛
ń to powyższe wywołania sa˛ dla nas
zbyteczne.
•
Wywołania skryptów startowych - opcje te bardzo rzadko wymagaja˛ ingerencji
użytkownika:
105
si::sysinit:/etc/rc.d/rc.sysinit
l0:0:wait:/etc/rc.d/rc 0
•
Obsługa specjalnych zdarzeń np. wciśni˛ecia kombinacji klawiszy ctrl+alt+del:
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
Mamy spora˛ dowolność w zarzadzaniu
˛
tym zdarzeniem, w powyższym przykładzie po naciśni˛eciu kombinacji ctrl+alt+del nastapi
˛ przeładowanie systemu, aby
nastapiło
˛
zamkniecie powinniśmy użyć polecenia shutdown -h.
/etc/fstab
Plik ten przechowuje szczegółowe informacje o systemach plików, które maja˛ być
montowane do odpowiednich katalogów. Informacje w nim zawarte sa˛ odczytywane w trakcie startu systemu, dzi˛eki temu automatycznie sa˛ montowane wszystkie
woluminy (partycje) nie oznaczone opcja˛ "noauto". Plik ten jest zazwyczaj tworzony
przez instalator, jednak administrator ma możliwość, a nawet obowiazek
˛
dokonywać
w nim zmian. Dla lepszego zrozumienia tematu przyjrzyjmy si˛e przykładowemu plikowi i przeanalizujmy funkcje jakie spełniaja˛ poszczególne wpisy.
#(fs_spec) (fs_file)(fs_vfstype) (fs_mntops) (fs_freq) (fs_passno)
/dev/hda2 / ext3 defaults 0 0
/dev/hda3 swap swap defaults 0 0
proc /proc proc defaults 0 0
pts /dev/pts devpts gid=5,mode=600 0 0
/dev/fd0 /media/floppy vfat noauto
0 0
/dev/cdrom /media/cdrom iso9660 noauto,ro,user,unhide 0 0
Jak widzimy plik jest podzielony na wiersze, z których każdy odpowiada jednemu
obsługiwanemu woluminowi. Poszczególne pola oddzielone sa˛ od siebie spacja˛ lub
tabulatorem. Dane odpowiedniego rekordu wczytywane sa˛ przez skrypty startowe
oraz programy takie jak: fsck, mount czy umount przez co musza˛ one być zapisane
w uporzadkowany
˛
sposób.
Pole (fs_spec) - określa urzadzenie
˛
blokowe lub zasób sieciowy przeznaczony do
zamontowania, na przykład partycj˛e dysku, CDROM czy udział NFS. Opis urza˛
dzeń masowych przedstawiono w sekcja Nazewnictwo urzadze
˛ ń masowych w Rozdział
13, montowanie udziałów NFS przedstawiono w sekcja NFS - Network File System w
Rozdział 17.
Pole (fs_file) - wskazuje na miejsce, w którym ma być zamontowany dany system
plików, na przykład dla partycji wymiany (ang. "swap partition") to pole powinno
zawierać wartość "none", a dla CDROM-u "/media/cdrom".
Pole (fs_vfstype) - określa typ systemu plików jaki znajduje si˛e na danym urza˛
dzeniu. Najbardziej powszechne obecnie i obsługiwane systemy plików to:
106
•
ext2 - podstawowy system plików w Linuksie
•
ext3 - j.w. tyle że z ksi˛egowaniem
•
reiserfs - zaawansowany system plików z ksi˛egowaniem
•
xfs - zaawansowany system plików z ksi˛egowaniem
•
vfat - używany w starszych systemach Microsoftu, znany również jako FAT32
•
ntfs - system plików współczesnych wersji systemów Microsoftu
•
iso9660 - używany na płytach CD-ROM
•
nfs - sieciowe udziały dyskowe NFS
•
swap - obszar wymiany
Pole (fs_mntops) udost˛epnia szereg znaczników systemowych, które moga˛ mieć
kluczowe znaczenie dla bezpieczeństwa i wydajności naszego systemu. Przykładowo nast˛epujace
˛ znaczniki oznaczaja:˛
•
defaults - domyślny zestaw opcji, użyteczny w wi˛ekszości wypadków.
•
nodev - zapobiega rozpoznawaniu przez jadro
˛
dowolnych plików urzadze
˛
ń, znajdujacych
˛
si˛e w systemie plików
•
noexec - zapobiega wykonywaniu plików wykonywalnych w danym systemie plików
•
nosuid - zapobiega uwzgl˛ednianiu bitów set-UID oraz set-GID w przypadku dowolnego pliku wykonywalnego
•
ro - powoduje zamontowanie systemu plików w trybie tylko do odczytu,
powstrzymujac
˛ wszelkie modyfikacje informacji dotyczacych
˛
plików, właczaj
˛
ac
˛ w
to na przykład czas dost˛epu do pliku
Pole (fs_freq) jest używane przez program dump do wykrywania, który system
plików ma mieć wykonywana˛ kopi˛e bezpieczeństwa. Jeżeli nie ma informacji o tym
polu, zwracana jest wartość 0 i dump przyjmuje, że dany system plików nie musi
być mieć robionych kopii danych. Jeśli nie korzystamy z tego programu możemy
wsz˛edzie ustawić wartość 0.
Pole (fs_passno) jest używane przez program fsck aby zadecydować, jaka powinna
być kolejność sprawdzania systemów plików podczas ładowania systemu. Główny
system plików powinien mieć (fs_passno) równa˛ 1, zaś inne systemy plików powinny mieć (fs_passno) równe 2. Jeżeli to pole nie posiada żadnej wartości lub jest
ona równa 0 to wtedy dany system plików nie jest sprawdzany. Sprawdzania nie
wymagaja˛ właściwie systemy plików z ksi˛egowaniem, gdyż sa˛ bardzo odporne na
awarie.
Uwaga! Najważniejszym woluminem w systemie jest ten przypisywany do korzenia
drzewa katalogów (katalog "/"), dlatego należy bardzo ostrożnie dokonywać zmian
jego konfiguracji. Bład
˛ może spowodować problemy z uruchomieniem systemu operacyjnego.
/etc/passwd
Jeden z najważniejszych plików w systemie - przechowuje informacje o kontach
wszystkich użytkowników. Jeden wiersz w tym pliku zawiera informacje o jednym
użytkowniku. Każdy składa si˛e z pól rozdzielonych dwukropkiem:
login:haslo:UID:GID:komentarz:katalog_domowy:powłoka
np.:
marek:x:502:1000:Marek Kowalski:/home/users/marek:/bin/bash
Uwagi: Znak "x" w miejscu hasła oznacza że jest przechowywane w osobnym pliku (/etc/shadow). UID to unikalny identyfikator użytkownika, zaś GID to unikalny numer grupy głównej użytkownika - zdefiniowany w pliku /etc/group. Powłoka (shell) musi być zdefiniowana w pliku /etc/shells. Oznaczenie powłoki jako
/bin/false oznacza że jest to konto użytkownika systemowego. Jest to specjalny
rodzaj kont na które zwykli użytkownicy nie moga˛ si˛e zalogować
Plik ten jak i opisany poniżej /etc/shadow maja˛ kluczowe znaczenie dla systemu,
dlatego nie należy ich edytować r˛ecznie. Narz˛edzia, służce do tego, opisano w sekcja
Konta użytkowników w Rozdział 14.
107
/etc/shadow
Plik zawierajacy
˛ zakodowane hasła i dodatkowe informacje dla systemu uwierzytelniania użytkowników np.:
marek:$1$qb/waABk$F3Y6dKw/6ekZPfcoTpzks/:12575:0:99999:5:::
/etc/group
Plik zawierajacy
˛ nazwy utworzonych grup i przypisanych do nich użytkowników
według schematu:
nazwa_grupy::GID:login1,login2,login3,...
np.:
audio::23:kasia,marek
Uwagi: Pierwsze pole to unikalna nazwa grupy, drugie nie ma we współczesnych
systemach uniksowych już zastosowania, GID to niepowtarzalny identyfikator grupy, trzecie pole zawiera list˛e identyfikatorów użytkowników zapisanych do tej grupy.
Podobnie jak dwa powyższe, ten plik też powinien być modyfikowany przez przeznaczone do tego programy, ich opis zawarto w sekcja Grupy w Rozdział 14
/etc/shells
Zawiera list˛e dost˛epnych dla użytkowników powłok np.:
/bin/ksh
/bin/sh
/bin/bash
Aby użytkownik miał możliwość korzystania z danej powłoki musi być ona zdefiniowana w tym pliku
/etc/motd
Wiadomość dnia (ang. Message of the day) - Powitanie użytkownika: treść tego pliku
wyświetlana po uwierzytelnieniu si˛e w systemie.
/etc/nologin
Plik tworzony przez administratora - blokuje możliwość logowania si˛e użytkowników do systemu. Przy próbie logowania wyświetlana jest jego treść.
Przypisy
1. http://www.timeanddate.com/
2. http://www.inf.sgsp.edu.pl/pub/PROGRAMY/PLD/
108
Rozdział 13. Pamieci
˛ masowe
Ten rozdział opisuje operacje dyskowe takie jak podział na partycje, tworzenie systemów plików i inne zaawansowane zagadnienia
Wstep
˛
Uwaga! Wszelkie operacje dyskowe narażaja˛ nas na nieodwracalna˛ utrat˛e danych,
dlatego zaleca si˛e stworzenie kopii zapasowej danych i zachowanie szczególnej
ostrożności.
Nazewnictwo urzadze
˛
ń masowych
Numerowanie partycji
W Linuksie moga˛ być obsłużone cztery partycje podstawowe lub trzy podstawowe
i jedna rozszerzona. Takie partycje sa˛ numerowane od 1 do 4, zaś dyski logiczne
kolejnymi numerami poczawszy
˛
od 5. Podawanie numeru partycji ma sens wyłacz˛
nie w wypadku dysków twardych, nie podajemy ich dla urzadze
˛
ń takich jak nap˛edy optyczne (CD/DVD), dyskietki czy też woluminy logiczne. Nie podajemy go
również w przypadku odwołania do urzadzenia
˛
fizycznego np. używajac
˛ programu
fdisk lub hdparm.
Aby zorientować si˛e w układzie partycji urzadzenia
˛
możemy użyć programu fdisk
np.:
# fdisk -l /dev/hda
Urzadenia
˛
ATA (IDE)
Urzadzenia
˛
ATA nazywane sa˛ wg. schematu: /dev/hd{$x}{$Nr} np. /dev/hda1.
Parametr {$x} jest mała˛ litera˛ identyfikujac
˛ a˛ fizyczne urzadzenie,
˛
zaś {$Nr} to omówiony powyżej numer partycji dyskowej. W odróżnieniu od urzadze
˛
ń SATA i SCSI
w interfejsie IDE litery te maja˛ swoje specjalne znaczenie - wskazuja˛ sposób podła˛
czenia urzadzenia:
˛
•
"a" -dysk nadrz˛edny (primary) podłaczony
˛
do pierwszego kanału IDE
•
"b" -dysk podrz˛edny (slave) podłaczony
˛
do pierwszego kanału IDE
•
"c" -dysk nadrz˛edny (primary) podłaczony
˛
do drugiego kanału IDE
•
"d" -dysk podrz˛edny (slave) podłaczony
˛
do drugiego kanału IDE
Urzadenia
˛
SCSI/SATA/USB Storage
Dyski twarde i pami˛eci flash maja˛ oznaczenia /dev/sd{$x}{$Nr} np. /dev/sda1.
Symbol {$x} to oznaczenie fizycznego urzadzenia,
˛
którym przypisywane sa˛ kolejne
litery zaczynajac
˛ od "a", zaś {$Nr} to opisany na poczatku
˛
numer partycji. Nap˛edy
optyczne (CD/DVD) sa˛ oznaczane jako /dev/sr{$Nr} np.: /dev/sr0.
109
Rozdział 13. Pami˛eci masowe
Dyskietki elastyczne
Do stacji dyskietek odwołujemy si˛e za pomoca˛ urzadzenia
˛
/dev/fd0 lub /dev/fd1.
LVM
Woluminy logiczne maja˛ dowolne nazwy - nadawane przez administratora w trakcie ich zakładania. Jeśli pliki urzadze
˛
ń nie sa˛ utworzone statycznie, to moga˛ być wykrywane automatycznie (przy starcie systemu) i wtedy nadawane sa˛ im nazwy w
konwencji /dev/mapper/$VG-$LV np. /dev/mapper/sys-home.
RAID programowy
Urzadzenia
˛
maja˛ nazwy wg. schematu: /dev/md{$nr}, np. /dev/md0, które z kolei
jest symlinkiem do /dev/md/0.
Urzadzenia
˛
w GRUB-ie
GRUB ze wzgl˛edu na swoja wieloplatformowość używa własnego schematu nazewnictwa. Dyski fizyczne sa˛ widoczne jako (hd{$NR}), np. (hd1) zaś partycje jako (hd{$NR1},{$NR2}) np. (hd1,2). Urzadzenia
˛
te nie sa˛ bezpośrednio powiazane
˛
z
plikami urzadze
˛
ń w katalogu katalogu /dev i programy poza GRUB-em nie moga˛ z
nich korzystać. Wi˛ecej w opisie bootloadera, w sekcja GRUB w Rozdział 10.
Podział na partycje
Partycje
Na dysku twardym możemy utworzyć do czterech partycji podstawowych (primary partition) lub do trzech partycji podstawowych i jednej rozszerzonej (extended
partition). Partycj˛e rozszerzona˛ możemy podzielić na liczne dyski logiczne (logical
partitions).
Partycje szerzej opisano m.in. w Wikipedii1, zaś sposób ich oznaczania przedstawiono w sekcja Nazewnictwo urzadze
˛ ń masowych. Opis systemu plików-urzadze
˛
ń z katalogu /dev odnajdziemy w sekcja Urzadzenia
˛
w Rozdział 11.
Zanim zaczniemy
Operacje na partycjach moga˛ skończyć si˛e utrata˛ danych, dlatego warto najpierw
zrobić zrzut tablicy partycji do pliku:
# sfdisk -d /dev/hda > hda.out
Jeśli zechcemy powrócić do poprzedniego układu partycji wystarczy, że wydamy
polecenie:
# sfdisk /dev/hda < hda.out
110
Wymagane miejsce na system
Wymagania dyskowe w PLD (nie liczac
˛ danych, logów i obszaru wymiany):
•
instalacja minimalna - poniżej 150MB
•
serwer - dużo zależy od zainstalowanych usług, należy założyć, że zajmie co najmniej 250MB; dla wi˛ekszej elastyczności i stabilności warto przeznaczyć wi˛ekszy
zapas miejsca, niż w przypadku maszyn domowych.
•
stacja robocza z XWindow - należy przeznaczyć przynajmniej 1GB miejsca
Logi i dane moga˛ zajmować bardzo duże ilości miejsca, dlatego musimy podejść do
tego indywidualnie.
Osobnym zagadnieniem jest wielkość obszaru wymiany, stara zasada mówiaca,
˛ aby
swap był dwukrotnie wi˛ekszy niż pami˛eć operacyjna, sprawdza si˛e wi˛ekszości wypadków. Należy jednak podejść do tego elastycznie i dobrać obj˛etość obszaru wymiany odpowiednio do charakterystyki pracy maszyny.
Plan podziału dysku
Dla stacji roboczych zazwyczaj wystarczy podział na dwie partycje, które b˛eda˛ użyte
dla: "/" (głównego drzewa) i obszaru wymiany (swap). W przypadku serwerów dużo b˛edzie zależało od zastosowania maszyny i preferencji administratora, lecz jako
minimum należy dodatkowo przydzielić partycj˛e dla gał˛ezi /var.
W obu zastosowaniach dla wygody i bezpieczeństwa nierzadko tworzy si˛e dodatkowa˛ partycj˛e dla katalogu /home, pozwala to na łatwiejsze zarzadzanie
˛
uprawnieniami i ułatwia wiele operacji. Partycj˛e na katalogi domowe należy traktować jako obowiazkow
˛
a˛ jeśli na maszynie b˛eda˛ dost˛epne konta z dost˛epem do powłoki (shella). Jej
wielkość bezpośrednio zależy od planowanej ilości przechowywanych danych.
Jeśli od maszyny wymagamy zwi˛ekszonej niezawodności można utworzyć mała˛
partycj˛e dla katalogu /boot, w którym sa˛ trzymane ważne pliki systemowe. Dane
w katalogu /boot zaraz po zainstalowaniu nie powinny przekroczyć ok. 7MB, aby
wi˛ec mieć możliwość instalacji kilku kerneli, musimy przeznaczyć na taka˛ partycj˛e co
najmniej 25MB miejsca. Dzi˛eki temu zwi˛ekszymy szanse na uruchomienie systemu z
uszkodzonym głównym systemem plików. Jest to szczególnie zalecane w przypadku użycia bootloadera GRUB, ze wzgl˛edu na jego specyficzna˛ konstrukcj˛e, wi˛ecej na
temat GRUB-a znajdziemy w sekcja GRUB w Rozdział 10.
Programy do zarzadzania
˛
partycjami
fdisk - interaktywny program do zarzadzania
˛
partycjami, wydane polecenia zostana˛
wykonane na samym końcu - po operacji zapisu zmian. Właśnie ten program zostanie użyty w naszych przykładach, wywołujemy go z parametrem określajacym
˛
urzadzenie
˛
z katalogu /dev.
cfdisk - wygodne narz˛edzie, wyposażone w semigraficzny interfejs użytkownika.
Twórcy ułatwili życie poczatkuj
˛
acym,
˛
poprzez ukrywanie partycji rozszerzonych,
tworzeniem i ich usuwaniem zajmuje si˛e program bez naszego udziału. Podobnie
jak fdisk zapisuje zmiany do tablicy partycji na samym końcu. Wywołujemy go z
parametrem określajacym
˛
urzadzenie
˛
z katalogu /dev.
parted - jest pot˛eżnym narz˛edziem, umożliwiajacym
˛
wiele operacji niedost˛epnych
dla obu poprzednich programów. Oprócz podstawowych operacji na partycjach
umożliwia takie operacje jak zmian˛e wielkości partycji, tworzenie obrazów partycji
i inne. Istotna˛ różnica˛ w działaniu w porównaniu dla powyższych narz˛edzi
jest natychmiastowe wprowadzanie zmian, stad
˛ zaleca si˛e zachowanie dużej
ostrożności przy korzystaniu z niego.
111
GParted/QtParted - programy dla X-Window oparte o parted. Maja˛ interfejs wzorowany na programie Partion Magic z systemu MS Windows.
sfdisk - program obsługiwany za pomoca˛ argumentów i danych przesyłanych na
wejście standardowe. Jest dosyć trudny w obsłudze ale za to może być używany w
skryptach.
Podział
Poniższe przykłady b˛eda˛ dotyczyć programu fdisk, cfdisk jest bardzo prosty w obsłudze i nikt nie powinien mieć nim problemów, zaś opis parted wykracza poza ramy
tego rozdziału.
Aby sprawdzić czy na dysku /dev/sda sa˛ jakieś partycje użyjemy nast˛epujacego
˛
polecenia:
# fdisk -l /dev/sda
Założyłem, że na dysku nie ma innych partycji, jeśli w naszym wypadku takie sa˛ to
musimy je najpierw usunać.
˛ Kiedy dysk jest gotowy uruchamiamy program fdisk:
# fdisk /dev/sda
Command (m for help):
wybieramy opcj˛e n (nowa partycja)
Command action
e
extended
p
primary partition (1-4)
Program pyta o rodzaj rodzaj partycji, która˛ ma utworzyć. Tu wybór zależy od nas
ale jeśli dysk ma mieć nie wi˛ecej niż cztery partycje, to śmiało możemy zostać przy
partycjach podstawowych - w naszym przykładzie wybieramy opcj˛e p (podstawowa
partycja). Dalej program zapyta nas o numer partycji, pierwszy i rozmiar partycji.
Rozmiar możemy podać w cylindrach, KiB, MiB lub GiB.
Dla kolejnych partycji powtarzamy cały proces, aż uzyskamy to co zaplanowaliśmy.
Opcja˛ p) wyświetlamy planowany układ partycji. Po zakończeniu podziału przypisujemy typy partycji opcja˛ t) podajac
˛ kolejno: numer partycji, Jeśli wybrany podział
nam odpowiada to zapisujemy zmiany na dysk (do tablicy partycji) przez wybór
opcji w.
Zakończenie
Jeśli żadna z partycji nie była używana w trakcie podziału na partycje (np. zamontowana) to tablica partycji jest ponownie odczytywana i od razu możemy wykonywać dalsze prace. W przeciwnym wypadku musimy jeszcze przeładować system.
Po zakończeniu dzielenia dysku pozostało nam utworzenie systemów plików, które
zostało opisane w sekcja Systemy plików.
Systemy plików
W tym rozdziale omówimy tworzenie jednej z dwóch możliwych struktur na partycji
lub urzadzeniu
˛
- systemu plików lub obszaru wymiany (swap).
112
Wybór systemu plików
Rodzaj użytego systemu plików zależy od planowanego zastosowania. W Linuksie
najbardziej uniwersalnym i popularnym systemem plików jest ext2. Swoja˛ pozycj˛e
uzyskał dzi˛eki temu, że jest prostym i stosunkowo wydajnym systemem plików. Ponadto jako jeden z niewielu systemów plików nadaje si˛e do użytku na dyskietkach i
bardzo małych partycjach.
W pozostałych zastosowaniach możemy śmiało użyć systemów plików z tzw. ksi˛egowaniem (journaling) np.: ext3, ReiserFS, XFS, JFS ze wzgl˛edu na duże bezpieczeństwo przechowywania danych. Dla zastosowań wymagajacych
˛
wysokiej niezawodności najlepszy b˛edzie ext3, pozostałe z wymienionych można polecić w systemach
wymagajacych
˛
dużej wydajności i wsz˛edzie tam gdzie wyst˛epuja˛ duże ilości plików.
Aby z partycji mogły również korzystać systemy Microsoftu musimy utworzyć na
niej system plików vfat. Utracimy jednak wtedy wszystkie zalety uniksowych systemów plików.
Tworzenie systemu plików
Programy do tworzenia konkretnych systemów plików różnia˛ si˛e nazwami, łatwo je
rozpoznamy gdyż ich nazwy zaczynaja˛ si˛e od "mkfs." np.:
/sbin/mkfs.ext2
/sbin/mkfs.ext3
/sbin/mkfs.reiserfs
/sbin/mkfs.msdos
/sbin/mkfs.vfat
/sbin/mkfs.xfs
Aby utworzyć system plików wywołujemy odpowiedni program z nazwa˛ urzadze˛
nia jako parametrem, na poniższym przykładzie przedstawiono tworzenie systemu
plików ext2 na drugiej partycji podstawowej:
# /sbin/mkfs.ext2 /dev/sda2
Wi˛ecej o nazewnictwie urzadze
˛
ń masowych w sekcja Nazewnictwo urzadze
˛ ń masowych.
Powyżej przedstawiono jedynie skrócona˛ list˛e wszystkich dost˛epnych programów,
programy te sa˛ dost˛epne w odpowiednich pakietach, przykładowo narz˛edzia dla
systemu plików xfs odnajdziemy w pakiecie xfsprogs.
Tworzenie obszaru wymiany
Do tworzenia obszaru wymiany używamy programu mkswap np.:
# mkswap /dev/hda5
Podmontowanie partycji / aktywacja swapu
Partycje i obszary wymiany sa˛ montowane/właczane
˛
przez rc-skrypty w trakcie uruchamiania systemu wg. opcji zawartych w pliku /etc/fstab (o ile tam zostały dodane). W pozostałych wypadkach systemy plików montujemy poleceniem mount z
odpowiednimi opcjami np.:
# mount /dev/sda2 /katalog_docelowy
113
System plików zostanie automatycznie wykryty a opcje zostana˛ ustawione na wartość "defaults". Wi˛ecej na ten temat odnajdziemy w podr˛eczniku systemowym.
Obszary wymiany aktywujemy nast˛epujaco:
˛
# /sbin/swapon /dev/hda5
Szczegółowy opis pliku /etc/fstab oraz rc-skryptów przedstawiono w sekcja Kluczowe pliki w Rozdział 12.
Poznanie typu systemu plików
Aby dowiedzieć si˛e jaki typ systemu plików jest na danej partycji, użyjemy programu
file z opcja˛ -s:
# file -s /dev/hda2
/dev/hda1: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)
List˛e urzadze
˛
ń z utworzonymi do tej pory systemami plików uzyskamy za pomoca˛
programu blkid:
# blkid
/dev/md/0: UUID="4f6fc9cc-9a3a-42bd-9e47-50ecfbeb090b" TYPE="xfs"
/dev/hda1: UUID="6d7abd95-9731-4406-b154-78ee66fc6c7f" TYPE="ext2"
/dev/sda: UUID="4f6fc9cc-9a3a-42bd-9e47-50ecfbeb090b" TYPE="xfs"
/dev/sdb: UUID="4f6fc9cc-9a3a-42bd-9e47-50ecfbeb090b" TYPE="xfs"
Aby zobaczyć systemy plików podmontowanych urzadze
˛
ń możemy użyć programu
mount:
/dev/hda1 on /boot type ext2 (rw,sync)
/dev/md/0 on /vservers type xfs (rw,noatime,usrquota)
Formatowanie
Obecnie nie formatuje si˛e dysków twardych, można to robić jedynie z dyskietkami
elastycznymi za pomoca˛ narz˛edzia fdformat. Robi si˛e to wyłacznie
˛
dla uzyskania
jakiejś nietypowej pojemności nośnika, w pozostałych wypadkach operacja ta jest
zb˛edna, gdyż dyskietki podobnie jak dyski twarde sa˛ formatowane fabrycznie. Takie
formatowanie nazywane jest także tzw. formatowaniem niskopoziomowym.
To co obecnie potocznie określa si˛e jako "formatowanie" jest złożeniem dwóch operacji: podziału na partycje a nast˛epnie utworzeniem systemów plików.
RAID programowy
W systemie Linux istnieje możliwość tworzenia na dyskach programowych macierzy RAID poziomów 0, 1, 4, 5, 6, 10, 01. Służy do tego celu usługa mdadm. W przeciwieństwie do macierzy RAID sprz˛etowych które wymagaja˛ specjalnego kontrolera
dysków (dość drogiego), macierze RAID programowe zakłada si˛e na dyskach podłaczonych
˛
do zwykłego kontrolera IDE, SATA lub SCSI i cała˛ obsług˛e przekazuje do
odpowiedniego oprogramowania (np: mdadm).
Macierze możemy zakładać zarówno na całych dyskach, jak i na odpowiednio przygotowanych partycjach, przy czym zakładanie na partycjach daje wi˛ecej możliwości
114
konfiguracji. Zarówno korzystajac
˛ z całych dysków jak i partycji należy pami˛etać
o tym że najmniejsza partycja lub dysk decyduje o wielkości zakładanej macierzy
(miejsce ponad jest tracone), dlatego też należy raczej korzystać z takich samych rozmiarów dysków lub partycji.
Poniżej zamieszczono list˛e i opis dost˛epnych rodzajów macierzy dla mdadm, w nawiasach podano nazwy parametrów programu:
•
RAID 0 (raid0, 0, stripe) - striping czyli połaczenie
˛
dwóch dysków (partycji)
z przeplotem danych, zwi˛eksza si˛e wydajność w porównaniu z pojedynczym
dyskiem, obniża odporność na awarie dysków - awaria jednego dysku to utrata
wszystkich danych.
•
RAID 1 (raid1, 1, mirror) - kopie lustrzane, dyski sa˛ w dwóch jednakowych kopiach, w przypadku awarii jednego drugi przejmuje role pierwszego. Wydajność
tak jak pojedynczy dysk, duże bezpieczeństwo, wada˛ jest duża strata pojemności
(n/2 - n-liczba dysków w macierzy)
•
RAID 4 (raid4, 4) - dane sa˛ rozpraszane na kolejnych dyskach a na ostatnim zapisywane sa˛ dane parzystości, zwi˛ekszone bezpieczeństwo danych przy zachowaniu
dużej pojemności (n-1). Wymaga przynajmniej trzech dysków, wydajność ograniczona przez dysk parzystości
•
RAID 5 (raid5, 5) - rozpraszane sa˛ zarówno dane jak i informacje o parzystości na
wszystkich dyskach, dzi˛eki czemu wydajność jest wyższa niż w RAID 4; pojemność n-1, wymaga przynajmniej trzech dysków.
•
RAID 6 (raid6, 6) - jest to rzadko stosowana, rozbudowana macierz typu 5. Jedyna˛ różnica˛ jest dwukrotne zapisanie sum kontrolnych. Dzi˛eki temu macierz może
bez utraty danych przetrwać awari˛e dwóch dysków. Wymaga minimum czterech
dysków, jej pojemność to n-2.
•
Tryb liniowy (linear) - czyli połaczenie
˛
dwóch dysków w jeden w ten sposób
że koniec pierwszego jest poczatkiem
˛
drugiego, nie zapewnia absolutnie żadnego
bezpieczeństwa a wr˛ecz obniża odporność na awarie dysków.
Najcz˛eściej stosuje si˛e macierze RAID1 i RAID5, do specyficznych zastosowań używa
si˛e RAID0, pozostałe sa˛ rzadziej spotykane.
Instalacja
Instalujemy nast˛epujace
˛ pakiety:
# poldek -i mdadm
A jeśli zaplanowaliśmy umieszczenie głównego systemu plików (/) na macierzy,
musimy dodatkowo zainstalować pakiet mdadm-initrd:
# poldek -i mdadm-initrd
oraz możemy opcjonalnie dla dysków ATA przy korzystaniu z device-mapera zainstalować dodatkowo:
# poldek -i dmraid
Planowanie macierzy
Dosyć popularnym rozwiazaniem
˛
jest utworzenie identycznego zestawu partycji na
każdym z dysków, a nast˛epnie spi˛ecie odpowiednich partycji w macierze. Aby uła115
twić sobie zadanie możemy najpierw podzielić jeden z dysków, a na nast˛epne urza˛
dzenia skopiować układ tablicy partycji np.:
# sfdisk -d /dev/sdc | sfdisk /dev/sdd
jak si˛e łatwo domyśleć w powyższym przykładzie kopiujemy z dysku /dev/sdc na
/dev/sdd.
Garść porad:
•
Kernel może być ładowany wyłacznie
˛
z macierzy RAID 1, jeśli wi˛ec b˛edziemy
chcieli używać np. RAID5 na głównym systemie plików to musimy umieścić gałaź
˛
/boot na osobnej, niewielkiej macierzy RAID1. Opis konfiguracji bootloadera do
obsługi macierzy znajduje si˛e w dalszej cz˛eści artykułu.
•
Należy oprzeć si˛e pokusie umieszczenia obszaru wymiany (swap) na RAID0, gdyż
awaria jednego z dysków może doprowadzić do załamania systemu.
•
Urzadzenia,
˛
z których składamy macierz powinny być równej wielkości, w przeciwnym razie wielkość macierzy b˛edzie wyznaczana przez najmniejsza˛ partycj˛e.
Wi˛ecej informacji o podziale na partycje i planowaniu miejsca na dysku zdob˛edziemy
w sekcja Podział na partycje.
Tworzenie macierzy RAID
Przyst˛epujemy do zakładania macierzy na partycjach za pomoca˛ polecenia mdadm:
mdadm -C {$dev_RAID} --level={$rodzaj} --raid-devices={$ilość_urzadzen} {$urzadzenia}
• -C, --create
- utwórz nowa˛ macierz.
- ustaw poziom RAID np: linear, raid0, 0, stripe, raid1, 1, mirror,
raid4, 4, raid5, 5, raid6, 6; Jak możemy zauważyć niektóre opcje sa˛ synonimami.
Przy opcji Building pierwsze moga˛ być użyte: raid0, raid1, raid4, raid5.
• -l, --level
• -n, --raid-devices
- liczba aktywnych urzadze
˛
ń (dysków) w macierzy
- liczba zapasowych (eXtra) urzadze
˛
ń w tworzonej macierzy. Zapasowe dyski można dodawać i usuwać także później.
• -x, --spare-devices
• -v --verbose
- tryb "gadatliwy"
- automatyczne tworzenie urzadze
˛
ń w /dev/ przez mdadm (stosowane zwykle przy użyciu UDEVa), wi˛ecej w Poradach na końcu rozdziału.
• --auto=yes
Przykłady tworzenia macierzy różnego typu:
•
RAID0 na dwóch partycjach - /dev/sda1 i /dev/sdb1 jako /dev/md0
# mdadm -C -v /dev/md0 --level=0 -n 2 /dev/sda1 /dev/sdb1
•
RAID1 na dwóch partycjach - /dev/sdc1 i /dev/sdd1 jako /dev/md1
# mdadm -C -v /dev/md1 --level=1 -n 2 /dev/sdc1 /dev/sdd1
•
RAID5 na 4 partycjach w tym jedna jako zapasowa (hot spare), jeśli nie podasz ile
ma być zapasowych partycji domyślnie 1 zostanie zarezerwowana na zapasowa˛
# mdadm -C -v /dev/md2 --level=5 -n 4 --spare-devices=1 \
/dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
116
Konfiguracja
Po utworzeniu macierzy post˛epujemy z nia˛ dalej jak z partycja,˛ czyli zakładamy system plików i odwołujemy si˛e do niej np: jako /dev/md0 np.:
# mkfs.xfs /dev/md0
Teraz możemy dokonać odpowiednich wpisów w pliku /etc/fstab.
Aby macierz była automatycznie składana przy starcie systemu musimy dodać odpowiednie wpisy do pliku /etc/mdadm.conf. Na poczatek
˛
dodajemy wiersz, w którym wymieniamy list˛e urzadze
˛
ń z których budowane sa˛ macierze (można używać
wyrażeń regularnych):
DEVICE /dev/sd[abcd][123]
Nast˛epnie dodajemy definicje macierzy, możemy to zrobić automatem:
# mdadm --detail --scan >> /etc/mdadm.conf:
lub samodzielnie, poprzez dodanie nast˛epujacych
˛
wierszy:
ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md1 devices=/dev/sdc1,/dev/sdd1
ARRAY /dev/md2 devices=/dev/sda3,/dev/sdb3,/dev/sdc3,/dev/sdd3
Macierze (inne niż rootfs) sa˛ składane przez rc-skrypt /etc/rc.d/rc.sysinit, na
podstawie powyższych wpisów konfiguracyjnych, zatem po restarcie maszyny b˛edziemy już z nich korzystać. Jeśli mamy macierz z głównym systemem plików, to
musimy jeszcze przygotować initrd i bootloader (poniżej).
Przy r˛ecznym składaniu macierzy przydane może być polecenie skanujace
˛ urzadze˛
nia blokowe w poszukiwaniu istniejacych
˛
macierzy:
# mdadm --examine --scan -v
Initrd
Jeśli główny system plików ma być na macierzy to musimy wygenerować obraz initrd z modułami, które pozwola˛ na złożenie macierzy. Na poczatek
˛
musimy mieć
zainstalowany pakiet mdadm-initrd. Generowanie takiego initrd przebiega dokładnie tak samo jak dla zwykłego urzadzenia
˛
blokowego, musimy si˛e tylko upewnić, że
do obrazu trafiły dodatkowo moduły: md-mod, odpowiednio raid0, raid1... i ewentualnie xor. Generowanie obrazu initrd szczegółowo zostało opisane w sekcja Initrd
w Rozdział 11.
Bootloader
Jeśli na raidzie ma si˛e znaleźć główny system plików (bez /boot), to konfiguracja jest
identyczna jak w przypadku klasycznych urzadze
˛
ń blokowych.
Jeśli gałaź
˛ /boot ma si˛e znaleźć na macierzy (wyłacznie
˛
RAID1) to powinniśmy zainstalować bootloader na każdym z dysków wchodzacych
˛
w skład macierzy, dzi˛eki
czemu b˛edziemy mogli uruchomić system mimo awarii jednego z dysków. RAID0 i
RAID2-5 nie sa˛ obsługiwane przez LILO\GRUB
W LILO w pliku /etc/lilo.conf należy podać odpowiednie urzadzenie
˛
dla opcji
root i boot:
117
boot=/dev/md0
raid-extra-boot="/dev/sda,/dev/sdb"
image=/boot/vmlinuz
label=pld
root=/dev/md0
initrd=/boot/initrd
Opcja w opcji raid-extra-boot wskazuje urzadzenia
˛
na których ma zostać zainstalowany bootloader (urzadzenia
˛
wchodzace
˛ w skład /dev/md0). Po zmodyfikowaniu
konfiguracji musimy zaktualizować bootloader poleceniem lilo.
Jeśli używamy Grub-a wywołujemy z powłoki:
# grub
grub>
nast˛epnie szukamy gdzie znajduja˛ sie pliki bootloadera,
grub>find /boot/grub/stage1
jeśli /boot jest oddzielna˛ partycja˛ to /grub/stage1 i otrzymujemy wynik, np:
(hd0,0)
(hd1,0)
Now you want to make sure that grub gets installed into the master boot
record of your additional raid drives so that if id0 is gone then the next
drive has a mbr loaded with grub ready to go. Systems will automatically go
in drive order for both ide and scsi and use the first mbr and active
partitions it finds so you can have multiple drives that have mbr’s as well
as active partitions and it won’t affect your system booting at all.
So using what was shown with the find above and already knowing that hd0
already has grub in mbr, we then run:
Grub>device (hd0)/dev/sda (/dev/hda for ide)
Grub>root (hd0,0)
Grub>setup (hd0)
i to samo dla dysku drugiego czyli:
Grub>device (hd1) /dev/sdb (/dev/hdb for ide)
Grub>root (hd1,0)
Grub>setup (hd1)
Grub will then spit out all the commands it runs in the background of setup
and will end with a successful embed command and then install command and
end with .. succeeded on both of these commands and then Done returning to
the grub> prompt.
Notice that we made the second drive device 0. Why is that you ask?
Because device 0 is going to be the one with mbr on the drive so passing
these commands to grub temporarily puts the 2nd mirror drive as 0 and will
put a bootable mbr on the drive and when you quit grub you still have the
original mbr on sda and will still boot to it till it is missing from the
system.
You have then just succeeded in installing grub to the mbr of your other
mirrored drive and marked the boot partition on it active as well. This
will insure that if id0 fails that you can still boot to the os with id0
pulled and not have to have an emergency boot floppy.
Bootloadery szczegółowo opisaliśmy w sekcja Wst˛ep w Rozdział 10.
118
Diagnostyka
Skrócone informacje o macierzy:
# mdadm --query /dev/md0
Poniżej podałem przykłady dwóch poleceń, które pozwalaja˛ odczytać dokładne dane
macierzy i jej stan:
# mdadm --detail /dev/md0
# cat /proc/mdstat
Porady
•
Majac
˛ dwie macierze RAID1 np: /dev/md0 i /dev/md1, możemy utworzyć macierz
RAID10 (strip dwóch mirrorów) jako /dev/md2
# mdadm -C -v /dev/md2 --level=1 -n 2 /dev/md0 /dev/md1
analogicznie RAID01 tworzymy majac
˛ dwie macierze RAID0.
•
Aby samemu złożyć macierz (z np: PLD Live CD) wydajemy polecenie, które może
wygladać
˛
nast˛epujaco:
˛
# mdadm -A /dev/md0 /dev/hda /dev/hdb
•
Jeśli macierz jest składana w trakcie startu systemu to automatycznie tworzony
jest plik urzadzenia
˛
/dev/mdX. W trakcie tworzenia macierzy, lub gdy macierz
nie startuje wraz z systemem, możemy skorzystać z gotowych urzadze
˛
ń w /dev
(pakiet dev) lub samemu je utworzyć (pakiet udev). Udev nie tworzy urzadze
˛
ń
/dev/md0, wi˛ec musimy w tym celu użyć parametru --auto=yes w wywołaniach programu mdadm, lub utworzyć je poleceniem mknod. Urzadzeniu
˛
nadajemy major o wartości 9 i kolejny, niepowtarzalny numer minor. Nie musimy si˛e
martwić o moduły, sa˛ on ładowane automatycznie przez mdadm lub initrd. Wi˛ecej
o UDEV w sekcja Udev - dynamiczna obsługa sprz˛etu w Rozdział 11.
•
Wraz z pakietem mdadm dostarczany jest rc-skrypt uruchamiajacy
˛ mdadm w trybie monitorowania (jako demona). Wi˛ecej szczegółów w dokumentacji programu
mdadm.
•
Migracja z pojedynczego dysku na RAID12
Instalacja linuksa na raid13
Naprawa zdegradowanej macierzy4
Dodatki
Literatura:
•
http://www.eioba.com/a70652/konfiguracja_i_objasnienie_raid_oraz_lvm
•
http://lists.us.dell.com/pipermail/linux-poweredge/2003-July/008898.html
•
http://www.linuxsa.org.au/mailing-list/2003-07/1270.html
•
http://gentoo-wiki.com/HOWTO_Gentoo_Install_on_Software_RAID
119
LVM
LVM (Logical Volume Management) to system zaawansowanego zarzadzania
˛
przestrzenia˛ dyskowa,˛ który jest o wiele bardziej elastyczny, niż klasyczne partycje dyskowe. To wia˛że si˛e z bardziej złożona˛ konstrukcja,˛ która składa si˛e z nast˛epujacych
˛
struktur:
(physical volumes) - fizyczne woluminy: sa˛ bezpośrednio zwiazane
˛
z partycjami dyskowymi (np. /dev/hda1, /dev/sdb3).
• PV
• VG (volume groups) - grupy woluminów: składaja˛ si˛e z co najmniej jednego PV, ich
wielkość to suma obj˛etości wszystkich PV należacych
˛
do danej grupy. Uzyskane
miejsce dyskowe może być dowolnie dysponowane pomi˛edzy kolejne LV.
(logical volumes) - woluminy logiczne: sa˛ obszarami użytecznymi dla systemu
(podobnie jak partycje dyskowe). LV sa˛ obszarami wydzielonymi z VG, zatem suma wielkości woluminów nie może zatem przekraczać obj˛etości VG, do którego
należa.˛
• LV
Schemat LVM-u, który zostanie użyty jako przykład w tym rozdziale:
PV1
PV2
\ /
VG
/ | \
LV1 LV2 LV3
Planowanie woluminów
Musimy wyznaczyć urzadzenia
˛
blokowe których chcemy użyć do stworzenia struktur PV. Jeśli główny system plików ma być umieszczony na woluminie logicznym to
musimy przeznaczyć mała˛ partycj˛e dla gał˛ezi /boot, gdyż bootloadery lilo i grub nie
potrafia˛ czytać danych z woluminów. Szczegółowy opis dzielenia dysków na partycje zamieściliśmy w sekcja Podział na partycje.
Załóżmy, że mamy dwa dyski twarde po 250GB (/dev/sda i /dev/sdb), których powierzchni˛e chcemy połaczyć
˛
i rozdysponować pod system operacyjny. Jako, że rootfs
także b˛edzie na woluminie to rozplanowanie miejsca może wygladać
˛
nast˛epujaco:
˛
• /dev/sda1:
mała partycja na /boot o pojemności 50MB
• /dev/sda2:
druga partycja dla woluminów (reszta dysku)
• /dev/sdb:
cały dysk dla woluminów
VG b˛edzie miało rozmiar ~500GB miejsca, z czego 400GB przydzielimy do użytku, a
reszt˛e pozostawimy dla przyszłych, nieokreślonych na razie zastosowań. Miejsce na
VG rozdysponujemy nast˛epujaco:
˛
120
•
swap: 5GB
•
/ (rootFS): 25GB
•
/home: 370GB
Instalacja
Omawiamy implementacj˛e LVM2, zatem instalujemy pakiet lvm2, jeśli LVM ma być
użyty jako główny system plików to potrzebujemy jeszcze pakiet lvm2-initrd do
wygenerowania odpowiedniego obrazu initrd.
Budowanie woluminów
Ładujemy moduł device mappera:
# modprobe dm-mod
Dzielimy dysk /dev/sda na dwie opisane powyżej partycje, a nast˛epnie wskazujemy
urzadzenia
˛
Physical Volumes:
# pvcreate /dev/sda2 /dev/sdb
tworzymy Volume Group o nazwie "vgsys" z wskazanych powyżej PV:
# vgcreate vgsys /dev/sda2 /dev/sdb
W powstałej VG tworzymy woluminy o podanych pojemnościach (-L) i dowolnych
nazwach (-n):
# lvcreate -L 5GB -n swap vgsys
# lvcreate -L 25GB -n rootfs vgsys
# lvcreate -L 370GB -n home vgsys
na naszym VG pozostaje 100GB wolnego miejsca, które możemy rozdysponować
w przyszłości (przykład dalszej cz˛eści rozdziału). Rzucajac
˛ a˛ si˛e w oczy
cecha˛ woluminów logicznych jest możliwość swobodnego nadawania im
nazw, co znacznie ułatwia utrzymanie porzadku.
˛
Do utworzonych powyżej
woluminów odwołujemy si˛e za pomoca˛ utworzonych przed chwila˛ urzadze
˛
ń:
/dev/vgsys/swap, /dev/vgsys/rootfs i /dev/vgsys/home. Woluminy sa˛ już
gotowe do pracy, musimy jeszcze tylko utworzyć na nich systemy plików, co robimy
jak w przypadku tradycyjnych partycji np.:
# mkswap /dev/vgsys/swap
# mkfs.xfs /dev/vgsys/rootfs
# mkfs.xfs /dev/vgsys/home
partycja dla gał˛ezi /boot:
# mkfs.ext2 /dev/sda1
Teraz montujemy woluminy w klasyczny sposób i jeśli wszystko przebiegło bez bł˛edów dokonujemy odpowiednich modyfikacji w /etc/fstab.
Konfiguracja startowa
Woluminy sa˛ automatycznie aktywowane przez rc-skrypt /etc/rc.d/rc.sysinit
lub initrd. Moduł device mappera również jest ładowany automatycznie. Jeśli
chcemy umieścić główny system plików na LV, to musimy jeszcze wygenerować
nowy obraz initrd, z obsługa˛ LVM. Zostało to szczegółowo przedstawione w sekcja
Initrd w Rozdział 11. W konfiguracji bootloadera ustawiamy opcj˛e ’root=’ na
/dev/vgsys/rootfs. Teraz instalujemy system, instalujemy bootloader i możemy
zrestartować maszyn˛e.
121
Gdy zajdzie potrzeba "r˛ecznego" aktywowania woluminów (np. spod RescueCD),
to na poczatek
˛
musimy si˛e upewnić, że jest załadowany moduł dm-mod. Kernel nie
zgłasza komunikatów o odnalezieniu woluminów, tak jak ma to miejsce z partycjami,
należy je odszukać za pomoca˛ odpowiednich narz˛edzi: lvmdiskscan i lvscan. Jeśli
odnaleźliśmy żadane
˛
struktury, to możemy je aktywować:
# vgchange -a y
Narzedzia
˛
diagnostyczne
Skrócone informacje o każdym z rodzaju komponentów (PV/VG/LV) wyświetlimy
za pomoca˛ programów pvs, vgs, lvs. Wi˛ecej informacji uzyskamy za pomoca˛ programów: pvdisplay, vgdisplay, lvdisplay.
Do niektórych operacji z woluminami b˛edziemy musieli je odmontować i deaktywować. Aby deaktywować wszystkie woluminy użyjemy polecenia
# vgchange -a n
aby wszystkie aktywować wywołujemy:
# vgchange -a y
Zarzadzanie:
˛
powiekszanie
˛
woluminu
Teraz przedstawimy pot˛eg˛e LVM-a: pokażemy jak powi˛ekszyć wolumin, gdy dochodzimy do wniosku, że przeznaczonego miejsca jest za mało. Załóżmy, że mamy
woluminy utworzone zgodnie z wcześniejszymi przykładami i chcemy przeznaczyć
cała˛ dost˛epna˛ wolna˛ przestrzeń na naszym VG (100GB) dla /dev/vgsys/homes:
# lvextend
-l 100%VG
/dev/vgsys/home
Teraz, kiedy wolumin jest powi˛ekszony, musimy rozszerzyć system plików, w naszych przykładach jest to XFS, zatem musimy podmontować wolumin, a nast˛epnie:
# xfs_growfs /home
Operacja trwa krótko i nie powoduje utraty danych, jednak jak przypadku każdych
operacji dyskowych, powinniśmy wcześniej wykonać kopi˛e zapasowa.˛ Każdy system plików posiada własne narz˛edzia do zmiany rozmiaru systemu plików, szczegóły w ich dokumentacji.
Porady
Woluminy LVM powoduja˛ zwi˛ekszone ryzyko uszkodzenia danych, gdyż awaria
jednego dysku może spowodować utrat˛e wszystkich danych. Z tego powodu zaleca
si˛e tworzenie woluminów na macierzach RAID.
122
Naprawa
Awarie dysków cz˛esto sa˛ bolesne, a nierzadko dosyć kosztowne. Istnieje wiele narz˛edzi do odzyskiwania danych, jednak nigdy nie gwarantuja˛ sukcesu. Dlatego warto
dokonywać regularnie kopie zapasowe danych.
Uszkodzenia fizyczne
Uszkodzenia fizyczne sprawdzamy programem badblocks z pakietu e2fsprogs, uruchamiamy go poleceniem:
# badblocks -s /dev/sda
Program wypisze list˛e uszkodzonych bloków
Naprawa systemu plików
Nazwy programów, podobnie jak programy do tworzenia systemów plików, sa˛ ujednolicone (poza XFS). Zaczynaja˛ si˛e od "fsck.":
fsck.ext2
fsck.reiserfs
fsck.vfat
fsck.jfs
do naprawy XFS-a użyjemy programu xfs_repair. Programy te różnia˛ si˛e nieco obsługa,˛ dlatego przed użyciem każdego z nich należy zapoznać si˛e z podr˛ecznikiem
systemowym (man/info), tak wyglada
˛ przykładowe wywołanie testu systemu plików XFS:
# xfs_repair /dev/sda2
Programy te nie pozwola˛ na sprawdzanie na systemie plików podmontowanym w
trybie do odczytu i zapisu. Powinniśmy w ogóle nie montować takiego systemu plików, a przynajmniej podmontować w trybie tylko do odczytu.
Nieco bardziej złożone jest sprawdzanie głównego systemu plików jeśli uruchomiliśmy system w trybie jednego użytkownika. Problemem jest konieczność przemontowania systemu plików w tryb ro. Niektóre programy moga˛ sprawdzać w pliku
/etc/mtab czy system plików jest w trybie tylko do odczytu. Może to dać nieprawidłowe wyniki, gdyż zazwyczaj gałaź
˛ /etc leży na głównym systemie plików i w
pliku tym nie nastapi
˛ a˛ żadne zmiany po takim przemontowaniu. Można to obejść
wcześniej modyfikujac
˛ wpis w /etc/mtab, kiedy już to zrobimy wykonujemy polecenie:
# mount / -o ro,remount
Naprawienie systemu plików nie gwarantuje, że nie zostały uszkodzone żadne pliki.
Jeśli na naprawianym systemie plików były jakieś dane systemowe, to powinniśmy
wykonać kontrol˛e ich integralności, opisana˛ dokładnie w sekcja Zaawansowane operacje w Rozdział 9.
Przypisy
1. http://pl.wikipedia.org/wiki/Partycja_(informatyka)
2. http://andrzej.dopierala.name/2007-04-11_Migracja_serwera_na_RAID1
123
3. http://andrzej.dopierala.name/2007-04-09_Instalacja_linuksa_na_raid1
4. http://wolvverine.jogger.pl/2007/02/20/degradedarray-fail-event-on-mddevice-repair/
5. http://www.eioba.com/a70652/konfiguracja_i_objasnienie_raid_oraz_lvm
6. http://lists.us.dell.com/pipermail/linux-poweredge/2003-July/008898.html
7. http://www.linuxsa.org.au/mailing-list/2003-07/1270.html
8. http://gentoo-wiki.com/HOWTO_Gentoo_Install_on_Software_RAID
124
Rozdział 14. Administracja
W tym rozdziale znajdziesz informacje dotyczace
˛ administracji systemem PLD
Ratowanie systemu
Wstep
˛
W tym rozdziale pokażemy co można zrobić w wypadku, jeśli nastapiła
˛
awaria systemu, uniemożliwiajaca
˛ normalne uruchomienie. Musimy uzyskać dost˛ep do urza˛
dzeń lub plików na dysku twardym, możemy w tym celu spróbować uruchomić system na niskim poziomie pracy, a jeśli to si˛e nie powiedzie, to użyć operacji chroota z
innego systemu np. dystrybucji typu live.
Uruchomienie na niskim poziomie pracy
Możemy uruchomić system z pomini˛eciem wielu czynności wykonywanych przez
skrypty startowe. Operacja polega na przekazaniu do kernela odpowiednich parametrów, które wymusza˛ użycie przez proces init specjalnie przygotowanego zestawu
rc-skryptów.
Interesuje nas poziom 1 lub single (tryb jednego użytkownika), tak też nazywaja˛ si˛e
parametry, które musimy przekazać do kernela. Parametry przekazujemy do jadra
˛
za
pośrednictwem bootloadera, w trakcie uruchomienia systemu np.:
grub append> root=/dev/sda2 single
Szczegółowy opis bootloadera i przekazywanie parametrów kernela opisano w sekcja Wst˛ep w Rozdział 10. Poziomy pracy zostały szerzej omówione w sekcja Zmiana
poziomu pracy systemu
Uruchomienie RescueCD
Jako dystrybucj˛e Live najlepiej wybrać RescueCD lub PLD Live. Oba projekty sa˛ dobrze przygotowane do pracy z nasza˛ dystrybucja,˛ gdyż zawieraja˛ program rpm i
poldek.
Na poczatek
˛
musimy zadbać o to, aby system mógł si˛e uruchomić z płyty CD, uzyskamy to modyfikujac
˛ odpowiednia˛ opcj˛e BIOS-u komputera. Teraz uruchamiamy
komputer z RescueCD umieszczonym w nap˛edzie CD-ROM i czekamy aż system si˛e
uruchomi.
Aby dokonać napraw musi zostać załadowany moduł kontrolera masowego. Wi˛ekszość współczesnych dystrybucji typu live sama wykrywa sprz˛et, jeśli jednak to si˛e
nie powiedzie lub używamy starej wersji RescueCD to musimy sami załadować moduł. Jeśli potrzebujemy obsłużyć kontroler typu IDE musimy załadować moduł idedisk
# modprobe ide-disk
Jeżeli naprawiany system jest oparty na macierzach programowych to musimy je
najpierw złożyć np.:
# mdadm -A --auto=yes /dev/md0 /dev/hda /dev/hdb
Wi˛ecej szczegółów dotyczacych
˛
programowych macierzy znajdziemy w sekcja RAID
programowy w Rozdział 13.
125
Teraz kiedy mamy załadowane odpowiednie moduły i dost˛ep do plików urzadze
˛
ń
(w katalogu /dev) możemy wykonać liczne operacje diagnostyczne i naprawcze (opisane dalej).
Naprawa systemu plików
Do naprawy systemu plików konieczny jest tylko dost˛ep do plików urzadze
˛
ń z katalogu /dev. Aby sprawdzić i naprawić system plików XFS wydajemy polecenie:
# xfs_repair /dev/sda2
Naprawy systemów plików została szczegółowo omówiona w sekcja Naprawa w
Rozdział 13.
Naprawa konfiguracji
W przypadku podniesienia systemu w trybie single mamy swobodny dost˛ep do plików konfiguracji, w przeciwnym wypadku musimy najpierw podmontować odpowiednia˛ partycj˛e aby uzyskać dost˛ep do plików. W tym celu tworzymy nowy katalog, a nast˛epnie montujemy do niego właściwe urzadzenie
˛
np.:
# mkdir -p /mnt/rootfs
# mount /dev/hda3 /mnt/rootfs
Jeżeli masz wi˛ecej partycji, na których znajduja˛ si˛e pliki systemowe (np. /boot), także
je podmontuj w odpowiednich katalogach np.:
# mount /dev/hda1 /mnt/rootfs/boot
mamy teraz nieograniczony dost˛ep do plików uszkodzonego systemu.
Operacja chroota
Jeśli uruchomiliśmy system z RescueCD i mamy podmontowane systemy plików
to wielu wypadkach wygodniejsze, a czasami nawet konieczne b˛edzie wykonanie
tzw. chroot-a.. Polega to na podmianie głównego systemu plików używanego przez
dany program na główny system plików ratowanego systemu operacyjnego. B˛edzie
to konieczne przy problemach z jadrem,
˛
bootloaderem czy initrd. Aby wykonać ta˛
operacj˛e należy wykonać komend˛e:
# chroot /mnt/rootfs
To polecenie uruchomi powłok˛e /bin/sh w taki sposób, że wszystkie działania z jej
poziomu b˛eda˛ odbywały si˛e przeźroczyście na podmontowanym systemie plików.
Zanim jednak zabierzemy si˛e do pracy prosz˛e o zapoznanie si˛e z uwagami na końcu
rozdziału. Jeśli używamy powłoki korzystajacej
˛ z chroot-a, wystarczy że zakończymy jej prac˛e wydajac
˛ polecenie exit lub skrótem klawiszowym ctrl+d. Na koniec
odmontowujemy systemy plików jeśli takie sa˛ i restartujemy komputer.
Uwagi
•
Niektóre operacje w środowisku chroot wymagaja˛ (np. tworzenie initrd) podmontowania pseudo systemu plików /proc:
# mount /proc /mnt/rootfs/proc -o bind
126
•
Użytkownicy udeva powinni pami˛etać, że wiele operacji w podmontowanym
środowisku wymagaja˛ istnienia kompletu plików urzadze
˛
ń:
# mount /dev /mnt/rootfs/dev -o bind
Udev dokładniej opisano w sekcja Udev - dynamiczna obsługa sprz˛etu w Rozdział 11.
•
Może si˛e zdarzyć, że poldek si˛e nie uruchamia w chroocie. Sposobem na obejście
tego jest uruchomienie go z flaga˛ -r , np:
# poldek -r /mnt/rootfs
•
Duża˛ zaleta˛ RescueCD jest to, że automatycznie "podnosi" interfejs sieciowy z obsługa˛ DHCP oraz serwer SSH. Pozwala to na zdalna˛ napraw˛e, wystarczy, że ktoś
umieści płyt˛e z dystrybucja˛ w nap˛edzie i uruchomi komputer. My zalogujemy si˛e
na odpowiedni adres za pośrednictwem SSH; login: root, hasło: pld.
Zarzadzanie
˛
podsystemami i usługami
W systemie dost˛epne sa˛ specjalne skrypty, napisane w j˛ezyku powłoki, zwane
"skryptami startowymi" lub "rc-skryptami". W PLD zastosowano skrypty startowe
typu System-V, dzi˛eki temu praca administratora jest znaczaco
˛ zautomatyzowana.
Za pomoca˛ rc-skryptów pomoca˛ możemy uruchamiać lub zatrzymywać podsystemy
i usługi, kontrolować ich działanie oraz wiele innych. Można je podzielić na dwie
zasadnicze grupy:
•
Skrypty podsystemów - specjalnych zadań majacych
˛
za zadanie dokonać konfiguracji systemu operacyjnego. Do tego typu zadań należa:˛ konfigurowanie sieci,
ładowanie modułów, prace porzadkowe
˛
i wiele innych. Te skrypty sa˛ integralna˛
cz˛eścia˛ systemu (pakiet rc-scripts) i zapewne sa˛ już u nas zainstalowane.
•
Skrypty zarzadzania
˛
usługami - zarzadzaj
˛
a˛ programami działajace
˛ w tle (demonami) np.: serwerem WWW, serwerem NFS. Skrypty te sa˛ instalowane automatycznie razem z pakietami usług. Wyjatek
˛
stanowia˛ usługi z wydzielonymi w tym celu
pakietami, rozpoznamy je po nazwie *-init i *-standalone. Wi˛ecej o nazewnictwie pakietów przedstawiono w sekcja Cechy pakietów w PLD w Rozdział 9.
Budowa systemu rc-skryptów
Katalog /etc/rc.d przechowuje konfiguracj˛e uruchamiania usług i podsystemów,
poniżej pokrótce omówiono składniki systemu rc-skryptów:
• /etc/rc.d/init.d
- katalog z skryptami startowymi usług
- katalogi tak oznaczone zawieraja˛ łacza
˛
symboliczne do
skryptów zawartych w katalogu init.d. Wartość {$NR} jest liczba˛ wskazujac
˛ a˛
poziom pracy (run level), dla którego uruchamiana jest zawartość danego katalogu.
• /etc/rc.d/rc{$NR}.d
• /etc/rc.d/rc
- skrypt uruchamiajacy
˛ i zatrzymujacy
˛ usługi
- skrypt ustawiajacy
˛ opcje narodowe (j˛ezyk, waluta) pobiera
konfiguracj˛e z pliku /etc/sysconfig/i18n
• /etc/rc.d/rc.init
- uruchamiany na samym końcu wszystkich skryptów,
użytkownicy moga˛ dodawać tu swoje wpisy jeśli nie chca˛ używać init.d i
• /etc/rc.d/rc.local
rc{$NR}.d
• /etc/rc.d/rc.serial
- konfiguracja portów szeregowych
127
• rc.sysinit - główny skrypt startowy uruchamiany jednokrotnie (w trakcie startu)
• /etc/rc.d/rc.modules
- załadowanie modułów z /etc/modules
• /etc/rc.d/rc.shutdown
- główny skrypt uruchamiany przy zatrzymaniu sys-
temu lub restarcie.
- plik startowy przy pomocy którego sa˛ ustawiane głównie zmienne systemowe
• /etc/profile
Zarzadzanie podsystememi/usługami
Usługami/podsystemami zarzadzamy
˛
r˛ecznie, wykonujemy to za pomoca˛ uruchomienia odpowiedniego skryptu z katalogu /etc/rc.d/init.d/. Dodatkowo podajemy odpowiednim parametr określajacy
˛ akcj˛e, która˛ skrypt ma wykonać. Uruchomienie bez parametru podaje list˛e możliwych dla niego akcji, dla przykładu wyświetlimy list˛e dost˛epnych parametrów podsystemu sieci:
# /etc/rc.d/init.d/network
Usage: /etc/rc.d/init.d/network {start|stop|restart|status}
Poniżej przedstawiono wyłaczenie
˛
obsługi sieci, oraz ponowne jej uruchomienie. W
ten sposób zmusza si˛e usług˛e lub podsystem do ponownego odczytania swojej konfiguracji. W tym wypadku nastapi
˛ skonfigurowanie na nowo interfejsów, zaktualizowanie ustawień, tablic routingu itd...
# /etc/rc.d/init.d/network stop
Shutting down interface eth0.......................................[ DONE ]
Shutting down interface eth1.......................................[ DONE ]
# /etc/rc.d/init.d/network start
Setting network parameters.........................................[ DONE ]
Bringing up interface eth0.........................................[ DONE ]
Bringing up interface eth1.........................................[ DONE ]
Lista dost˛epnych parametrów b˛edzie si˛e zmieniać w zależności od usługi, w poniższej tabeli przedstawiono znacznie tych najcz˛eściej spotykanych:
Tabela 14-1. Popularne akcje skryptów startowych
128
Parametr
Akcja
start
Uruchamia podsystem/usług˛e
stop
Zatrzymuje podsystem/usług˛e
reload, force-reload
Przeładowanie usługi poprzez wysłanie
sygnału (zwykle HUP) do demona,
cz˛esto oba podane parametry maja˛ takie
same działanie. Operacja używana do
ponownego odczytania konfiguracji
demona.
restart
Pełny restart usługi (zazwyczaj jest to
kolejne wywołanie skryptu z
parametrem start i stop). Operacja
używana do ponownego odczytania
konfiguracji demona.
Parametr
Akcja
status
Wyświetla stan podsystemu/usługi,
dzi˛eki temu możemy łatwo określić czy
czy jest uruchomiony. W niektórych
wypadkach podawane sa˛ dodatkowe
informacje.
Niektóre usługi posiadaja˛ inne, użyteczne tylko dla nich parametry. Przykładem może być argument init, który zazwyczaj musi być użyty przed pierwszym uruchomieniem usługi.
Nieco wygodniej zarzadza
˛
si˛e skryptami przy pomocy programu service. Aby wykonać za jego pomoca˛ taki sam efekt jak powyżej musimy go wywołać z dwoma
parametrami, pierwszy to nazwa skryptu, drugi zaś to wybrana akcja:
# service network stop
# service network start
Domyślnie po zainstalowaniu nowego podsystemu lub usługi, dodawane sa˛ potrzebne skrypty startowe. Dzi˛eki temu nowo zainstalowane oprogramowanie uruchamia si˛e automatycznie w trakcie startu systemu lub przy zmianie poziomu pracy.
Aby uruchomić dopiero co zainstalowany podsystem lub usług˛e musimy wykonać
to "r˛ecznie".
•
Zarzadzanie
˛
skryptami startowymi w trakcie instalacji/aktualizacji pakietów
opisano w sekcja Cechy pakietów w PLD w Rozdział 9
•
Jeśli zechcemy utworzyć własny rc-skrypt to z pomoca˛ przyjdzie nam szablon z
pliku /usr/share/doc/rc-scripts{$wersja}/template.init.gz
Konfiguracja rc-skryptów
Skryptów startowych typu System-V nie konfigurujemy bezpośrednio, w PLD
służy ku temu zestaw plików konfiguracyjnych umieszczony w katalogu
/etc/sysconfig. Znajdziemy w nim zarówno pliki konfiguracji systemu jak i
konfiguracji zainstalowanych usług.
Wi˛ekszość tych plików jest bezpośrednio załaczana
˛
do kodu rc-skryptów, zatem
ich składnia musi odpowiadać składni powłoki wskazanej w skrypcie (w PLD
jest to /bin/sh). Dotyczy to także plików konfiguracji interfejsów sieciowych
w katalogu /etc/sysconfig/interfaces. W plikach tych wyst˛epuja˛ jedynie
konstrukcje przypisania zamiennych oraz ewentualne komentarze. Możemy co
prawda umieszczać tam dowolne komendy wiersza poleceń, jednak należy być
przy tym niezwykle ostrożnym i robić to tylko w uzasadnionych przypadkach.
Jest jednak kilka plików konfiguracji, które sa˛ traktowane inaczej - maja˛ własna˛
składni˛e, przykładem tego rozwiazania
˛
sa˛ np. pliki /etc/sysconfig/static-*,
nimi jednak nie b˛edziemy si˛e zajmować w tym rozdziale.
Opcje w plikach konfiguracji można podzielić na dwie grupy: ogólnego stosowania i
specyficzne dla rc-skryptu. Pierwsza z nich to uniwersalne opcje, z którymi możemy
si˛e zetknać
˛ w wielu w innych plikach konfiguracji np.:
• SERVICE_RUN_NICE_LEVEL
- priorytet procesów usługi (liczba nice)
- mówi programowi rpm czy usługa ma być automatycznie restartowana po aktualizacji, wi˛ecej o tej opcji w sekcja Cechy pakietów w
PLD w Rozdział 9
• RPM_SKIP_AUTO_RESTART
Druga grupa to opcje wyst˛epujace
˛ tylko w pliku konfiguracji konkretnego rc-skryptu
- zwykle sa˛ zwiazane
˛
z argumentami pliku wykonywalnego usługi, dlatego należy
129
uważnie czytać komentarze plików konfiguracji i w razie potrzeby podr˛eczniki systemowe usług.
Zależności
Pomi˛edzy niektórymi demonami i podsystemami istnieja˛ ścisłe powiazania,
˛
jako
przykład można wymienić usługi sieciowe i podsystem sieci. Usługa jest zależna od
działania sieci i próba wyłaczenia
˛
najpierw tej drugiej może niekiedy zaowocować
problemami, gdyż PLD nie dba o to za nas. Musimy samemu si˛e zatroszczyć o
wyłaczanie
˛
usług we właściwej kolejności.
Pewna˛ wskazówka˛ b˛eda˛ numery przy nazwach łaczy
˛
symbolicznych w katalogach
/etc/rc.d/rc{$nr}.d (przy literze S). Numery te określaja˛ kolejność ładowania
usług w trakcie startu systemu.
Usługi a poziomy pracy
W PLD zastosowano klasyczny, oparty na rc-skryptach typu System-V system poziomów pracy. Poziomami na których pracuja˛ usługi można zarzadzać
˛
r˛ecznie, jest
to jednak niezalecany sposób, lepszym pomysłem jest użycie programu chkconfig.
Aby wyświetlić list˛e usług uruchamianych przy w danych poziomach pracy wydajemy polecenie:
# chkconfig --list
crond
0:wył.
cups
0:wył.
sshd
0:wył.
gdm
0:wył.
network
0:wył.
sshd
0:nie
1:wył.
1:wył.
1:wył.
1:wył.
1:wył.
1:nie
2:wł.
2:wł.
2:wył.
2:wył.
2:wł.
2:nie
3:wł.
3:wł.
3:wł.
3:wył.
3:wł.
3:nie
4:wł.
4:wł.
4:wł.
4:wył.
4:wł.
4:tak
5:wł.
5:wł.
5:wł.
5:wł.
5:wł.
5:nie
6:wył.
6:wył.
6:wył.
6:wył.
6:wył.
6:nie
W PLD najcz˛eściej korzysta si˛e z trybów 3 i 5 rzadziej z: 1, 2 i 4, nigdy nie ustawiamy trybu 0 (restart) i 6 (wyłaczenie).
˛
Na powyższym przykładzie podsystem network jest uruchamiana dla poziomów: 2,3,4,5, zaś gdm tylko dla trybu 5. Aby wła˛
czyć/wyłaczyć
˛
uruchamianie jakiejś usługi wywołujemy program nast˛epujaco:
˛ chkconfig {$usługa} on/off. Wyłaczenie
˛
usługi sshd (domyślnie jest właczona):
˛
# chkconfig sshd off
Właczenie
˛
analogicznie:
# chkconfig sshd on
Poziomy dla których usługa ma być właczona/wył
˛
aczona
˛
jest wskazywane przez
specjalny wpis w rc-skrypcie, możemy go odczytać nast˛epujaco:
˛
$ grep chkconfig /etc/init.d/sshd
# chkconfig:
345 55 45
pierwszy ciag
˛ cyfr w wierszu to lista poziomów, których dotyczy operacja włacze˛
nia/wyłaczenia
˛
rc-skryptu. W razie potrzeby możemy wymusić operacj˛e dla konkretnego numeru poziomu pracy np:
# chkconfig --level 5 sshd off
Dodawanie lub usuwanie usług w poziomach pracy nie powoduje ich uruchomienia
lub zatrzymywania, aby to zrobić musimy wykonać to r˛ecznie lub zmienić tryb pracy.
Poziomy pracy zostały szerzej omówione w sekcja Zmiana poziomu pracy systemu.
130
Zmiana poziomu pracy systemu
PLD jest systemem uniksowym, a wi˛ec obsługuje tzw. poziomy pracy (ang. run levels). Poziom pracy jest to specjalna konfiguracja systemu, która pozwala zaistnieć
tylko wytypowanym usługom badź
˛ podsystemom. Mamy sporo swobody w wyborze usług pracujacych
˛
badź
˛ wyłaczonych
˛
w danym poziomie pracy, opis jak nimi
zarzadzać
˛
znajdziemy w sekcja Zarzadzanie
˛
podsystemami i usługami.
Tabela 14-2. Dost˛epne poziomy pracy
Poziom
Opis
1
Konfiguracja z minimalna˛ ilościa˛
uruchamianych podsystemów. Nie ma
obsługi sieci i nie zezwala na logowanie
si˛e innym użytkownikom.
2
Rzadko używany tryb wielu
użytkowników. Uruchamiana jest
obsługa sieci i wi˛ekszości usług oprócz
NFS.
3
Popularny tryb prac z dost˛epem wielu
użytkowników i uruchomieniem
wszystkich usług. Jest to typowy tryb
dla maszyn obsługiwanych z konsoli
tekstowej - np.: serwerów.
4
Rzadko używany tryb wielu
użytkowników. - praca w konsoli
tekstowej
5
Typowy tryb z dost˛epem wielu
użytkowników uruchamiajacy
˛ system
X-Window (uruchamia demon GDM lub
KDM). Poziom używany na stacjach
roboczych z GUI. Wi˛ecej o sposobach
uruchamiania X-Window w sekcja
X-Server w Rozdział 18.
single
Tryb jednego użytkownika (ang. Single
user mode) - używany przez
administratorów w sytuacjach
awaryjnych. Uruchamia mniej skryptów
startowych niż pierwszy poziom. Jego
właczanie
˛
ma sens tylko przez
przekazanie do jadra
˛
parametru single
z poziomu bootloadera.
Sa˛ jeszcze dwa tryby: tryb 0 i 6. Pierwszy jest używany w celu zatrzymania wszystkich usług i podsystemów przed zamkni˛eciem systemu, drugi zaś przed ponownym
uruchomieniem systemu. Z pośród wymienionych poziomów pracy najcz˛eściej używa si˛e poziomu 3 lub 5.
Poziomem pracy zarzadza
˛
proces init. W celu określenia domyślnego poziomu pracy, init odczytuje swój plik konfiguracji (/etc/inittab) podczas uruchomienia systemu. Po uruchomieniu administrator może wymusić zmian˛e poziomu za pośrednictwem programu telinit (link symboliczny do programu init). Należy pami˛etać o
tym, że telinit nie dokonuje zmian w pliku /etc/inittab, tak wi˛ec przy ponownym
uruchomieniu systemu wybrany zostanie ustawiony w nim poziom pracy. Wi˛ecej
informacji o pliku /etc/inittab znajdziemy w sekcja Kluczowe pliki w Rozdział 12.
131
Za domyślny poziom pracy odpowiada opcja "initdefault", może ona przyjać
˛ wartość od 1 do 5 np.:
id:3:initdefault:
Powyższy przykład właczy
˛
system na trzecim poziomie pracy, jest domyślna wartość
w PLD.
W wyniku zmiany poziomu zostana˛ zatrzymane wszystkie wszystkie podsystemy
wyłaczone
˛
z pracy na tym poziomie, zaś te które maja˛ działać zostana˛ uruchomione.
Przykładowo jeśli chcemy przejść do trybu 2 użyjemy polecenia:
# telinit 2
Jeśli system do tej pory pracował w trybie 3 to wyłaczona
˛
zostanie usługa NFS.
Możemy również określić poziom uruchomienia przed startem systemu, dokonujemy tego za pomoca˛ parametrów przekazywanych za pośrednictwem bootloadera.
Wi˛ecej szczegółów na ten temat znajdziemy w sekcja Wst˛ep w Rozdział 10.
Konta użytkowników
W PLD zastosowano klasyczny dla systemów uniksowych system kont użytkowników, tak wi˛ec istnieje podział na dwa rodzaje kont: konta systemowe i konta użytkowników. Zarzadzanie
˛
kontami systemowymi nast˛epuje automatycznie w trakcie instalowania bad
˛ ż usuwania programów, które ich wymagaja.˛ Z tego powodu nie musimy
si˛e nimi zajmować, zajmiemy si˛e wi˛ec tylko kontami zwykłych użytkowników.
W PLD domyślnie instalowanym pakietem do zarzadzania
˛
kontami jest pakiet shadow. Możemy do jednak zastapić
˛
zbiorem pwdutils, który zawiera narz˛edzia o wi˛ekszych możliwościach. Dzi˛eki nim nie b˛edzie już konieczności "r˛ecznego" edytowania
plików systemowych, z tego wzgl˛edu opisane zostana˛ wyłaczne
˛
narz˛edzia pwdutils.
Dodanie
Konto użytkownika dodajemy poleceniem useradd -m {$nazwa_użytkownika} np.:
# useradd -m jkowalski
Powyższe polecenie doda konto o identyfikatorze ’jkowalski’ i utworzy katalog domowy (parametr "-m"). Dodatkowo do stworzonego katalogu skopiowana zostaje
zawartość katalogu /etc/skel. Domyślna konfiguracja konta jest tworzona na podstawie opcji z plików: /etc/default/useradd i /etc/login.defs. Najważniejsze
opcje pierwszego z nich to:
•
GROUP - identyfikator grupy głównej - domyślnie: 1000 (users)
•
HOME - miejsce przechowywania katalogów domowych - domyślnie:
/home/users
•
SHELL - powłoka - domyślnie: /bin/bash
Drugi określa bardziej zaawansowane opcje, najważniejsze z nich to:
132
•
PASS_MAX_DAYS - liczba dni do wygaśni˛ecia hasła -domyślnie: 99999
•
PASS_MIN_DAYS - minimalna liczba dni do mi˛edzy zmianami hasła -domyślnie:
0
•
PASS_WARN_AGE - ilość dni przez które b˛edzie pokazywane ostrzeżenie o wygaśni˛eciu hasła - domyślnie: 7
Wiele opcji kont zawartych w tych plikach można łatwo modyfikować, poprzez przekazanie odpowiednich parametrów do programu useradd oraz passwd, wi˛ecej informacji na ten temat uzyskamy w podr˛eczniku systemowym. Jeśli chcemy utworzyć
wi˛eksza ilość kont o zmodyfikowanych parametrach to wygodniejsze b˛edzie ustawienie interesujacych
˛
nas wartości w podanych powyżej plikach.
Jeśli użytkownik ma konto na wielu maszynach dobrym zwyczajem jest nadawanie takiego samego numeru użytkownika (UID) dla każdego z kont. W przypadku
programu useradd należy użyć opcji "-u".
Na koniec administrator musi ustawić hasło dla danego użytkownika.
Usuniecie
˛
Aby usunać
˛ konto użyjemy programu userdel:
# userdel jkowalski
Warto wspomnieć tu o opcjach "-r" i "-f", pierwsza usuwa katalog domowy, druga
wymusza usuni˛ecie również plików z katalogu domowego nawet jeśli do niego nie
należa.˛
Ze wzgl˛edów bezpieczeństwa można polecić blokowanie kont użytkowników w
miejsce ich usuwania, w ten sposób możemy si˛e ochronić przed sytuacja˛ powrotu
do użytku numeru UID usuni˛etego użytkownika.
Modyfikacja
Dane użytkownika modyfikujemy poleceniem usermod, dokładny opis tego programu znajdziemy w manualu.
Hasło
Pierwsze hasło dla użytkownika jest nadawane przez administratora, każda˛ nast˛epna˛ jego modyfikacj˛e użytkownik może wykonywać samodzielnie.
Ustawienie hasła przez administratora: passwd {$nazwa_użytkownika}
# passwd jkowalski
Changing password for jkowalski.
New UNIX password:
Retype new UNIX password:
Zwykły użytkownik zmienia swoje hasło również poleceniem passwd, tyle że bez
podawania parametru. Administrator może zmusić użytkownika do zmiany hasła
tuż po zalogowaniu:
# passwd -e jkowalski
133
Zarzadzanie
˛
kontami
Hasło blokujemy poleceniem: passwd -l {$nazwa_użytkownika} np.:
# passwd -l jkowalski
Aby odblokować użyjemy parametru parametru "-u" np.:
# passwd -u jkowalski
Musimy pami˛etać, że powyższe polecenia nie blokuja˛ dost˛epu opartego o inna˛ metod˛e autoryzacji niż hasło, np. o klucz SSH. W takim wypadku dodatkowo powinniśmy zmienić powłok˛e użytkownikowi na nie figurujac
˛ a˛ w /etc/shells np.:
# usermod -s /bin/false jkowalski
Grupy
W PLD zastosowano klasyczny dla systemów uniksowych system grup, tak wi˛ec istnieje podział na dwa rodzaje grup: grupy systemowe i grupy użytkowników. Grupy te
rozróżniamy na podstawie identyfikatorów grupowych (GID), dla grup użytkowników przeznaczone sa˛ wartości 1000 i wi˛ecej. Ponadto grupy systemowe cz˛esto przyjmuja˛ nazwy podobne jak nazwy usług np: ftp, named, itp.
Zarzadzanie
˛
grupami systemowymi nast˛epuje automatycznie w trakcie instalowania
badź
˛ usuwania pakietów, z tego powodu nie należy w nie ingerować. W naszej dystrybucji zarzadzanie
˛
grupami zazwyczaj sprowadza si˛e do dodawania/usuwania
własnych grup oraz zarzadzania
˛
uczestnictwem w istniejacych
˛
grupach.
W PLD domyślnie instalowanym pakietem do zarzadzania
˛
grupami jest pakiet shadow. Możemy do jednak zastapić
˛
zbiorem pwdutils, który zawiera narz˛edzia o wi˛ekszych możliwościach. Dzi˛eki nim nie b˛edzie już konieczności "r˛ecznego" edytowania
plików systemowych, z tego wzgl˛edu opisane zostana˛ wyłaczne
˛
narz˛edzia pwdutils.
Dodanie grupy
Używamy polecenia groupadd {$nazwa_grupy} np.:
# groupadd kadry
Jeśli tworzymy takie same grupy na wielu maszynach, to dobrym zwyczajem jest
nadawanie takiego samego numeru grupy (GID) dla każdej z grup. Dowolny GID
narzucamy w trakcie tworzenia grupy programem groupadd z użyciem opcji "-g".
Zapisanie do grup
Dzi˛eki poleceniu id {$nazwa_użytkownika} sprawdzimy do jakich grup zapisany
jest użytkownik, jeśli nie podamy nazwy konta to zostanie wyświetlona informacja
o aktualnie używanym koncie np.
$id jkowalski
uid=500(jkowalski) gid=1000(users) grupy=1000(users),10(wheel),19(floppy),23(audio)
Program zwrócił wartości: UID, GID i list˛e grup do których zapisany jest użytkownik
jkowalski: users, wheel, floppy, audio
134
Zapisanie do grupy nast˛epuje po
{$konto_użytkownika} {$grupa} np.
wykonaniu
polecenia
groupmod
-A
groupmod -A jkowalski kadry
Aby wyrejestrować użytkownika z grupy musimy użyć parametru "-R" np.
groupmod -R jkowalski kadry
Usuniecie
˛
grupy
Używamy polecenia groupdel {$nazwa_grupy}:
# groupdel kadry
Uwagi
•
Po każdej modyfikacji uczestnictwa w grupach, użytkownik musi si˛e ponownie
zalogować, aby wprowadzone zmiany zacz˛eły obowiazywać.
˛
•
Zapisanie użytkownika do grupy służy podniesieniu jego uprawnień, list˛e przywilejów jakie uzyska zamieszczono w sekcja Zarzadzanie
˛
uprawnieniami.
Zarzadzanie
˛
uprawnieniami
W PLD zastosowano restrykcyjny poziom bezpieczeństwa, zwykły użytkownik domyślnie ma minimalne możliwe uprawnienia. Aby je zwi˛ekszyć administrator musi
zapisać użytkownika do odpowiednich grup, poniżej została przedstawiona skrócona ich lista i odpowiadajace
˛ im "przywileje" lub funkcje.
Tabela 14-3.
GID
Nazwa
Właściciel/Uprawnienia
0
root
grupa administracyjna wysokie uprawnienia w
całym systemie
3
sys
odczyt niektórych plików
systemowych np.
konfiguracji i logów
systemu druku CUPS
4
adm
możliwość korzystania z
narz˛edzi takich jak:
tarcerouote, ping, arping,
clockdiff
135
136
GID
Nazwa
6
disk
bezpośredni dost˛ep do
urzadze
˛
ń masowych np.
naprawy i tworzenie
systemów plików,
odtwarzanie i nagrywanie
CD
7
lp
dost˛ep do portu drukarki:
równoległego, USB
9
kmem
odczyt z urzadze
˛
ń
/dev/mem, /dev/kmem
10
wheel
możliwość korzystania z
programu su
17
proc
dost˛ep do pseudosystemu
plików /proc (np. wglad
˛
do procesów innych
użytkowników)
19
floppy
możliwość
niskopoziomowego
formatowania dyskietek i
tworzenia na nich
systemu plików
22
utmp
zapis do plików
/var/run/utmpx,
/var/log/wtmp,
/var/log/lastlog
23
audio
dost˛ep do karty
dźwi˛ekowej
27
cdwrite
dost˛ep do narz˛edzi
nagrywania płyt CD
28
fsctrl
grupa której można
używać do nadawania
praw dla plików na
montowanych
urzadzeniach
˛
50
ftp
grupa systemowa serwera
FTP: odczyt plików
konfiguracji
51
http
grupa systemowa serwera
WWW
117
crontab
odczytywanie konfiguracji
demona CRON
123
stats
grupa używana do
potrzeb automatycznie
generowanych statystyk
(mrtg, calamaris, itd.)
124
logs
grupa odczytu niektórych
logów
138
fileshare
możliwość udost˛epniania
zasobów NFS i SMB (zapis
do /etc/exports,
/etc/samba/smb.conf)
GID
Nazwa
1000
users
domyślna grupa główna
dla zwykłych
użytkowników
Dużo wi˛ecej informacji o grupach i użytkownikach znajdziemy w dokumencie
uid_gid.db.txt1 trzymanym w CVS-ie. Zapisywanie do grup opisano w sekcja Grupy.
Bezpieczeństwo
Bezpieczeństwo systemów i danych to rozległy temat dlatego głównie skupimy si˛e
na aspektach dotyczacych
˛
PLD.
Dostepne
˛
narzedzia
˛
PLD jako dystrybucja "robiona przez administratorów dla administratorów" ma duże zasoby programów użytecznych w zakresie bezpieczeństwa, poczynajac
˛ od NetCata (nc), a na wiresharku i nessusie kończac.
˛
Dostep
˛ do konta root
Nasza polityka bezpieczeństwa wymaga, aby użytkownik należał do grupy wheel,
jeśli chce zwi˛ekszyć swoje uprawnienia za pomoca˛ su i sudo. W ten sposób atakujacy
˛
musi zgadnać
˛ trzy parametry zamiast jednego (nazwa użytkownika, hasło i hasło administratora zamiast samego hasła administratora). Nie ma też możliwości zdalnego
zalogowania si˛e bezpośrednio na konto roota (z tych samych powodów). Dodatkowo
root nie może zdalnie używać innych usług (ftp, imap, pop3, smtp) m.in z powodu
niedostatecznie silnego szyfrowania transmisji.
SUID
Domyślnie zwykli użytkownicy nie maja˛ prawa wykonania programów z ustawionym bitem SUID. Aby takie prawo uzyskać musza˛ być zapisani do odpowiedniej
grupy. Przykładowo program ping wymaga zapisania do grupy adm. Pogladowe
˛
zestawienie grup zamieściliśmy w sekcja Zarzadzanie
˛
uprawnieniami.
/proc
Domyślnie użytkownicy nie widza˛ żadnych procesów poza swoimi. Jest to nie tylko krok w stron˛e bezpieczeństwa, ale i w wygody, użytkownik nie głowi si˛e nad
długimi listami procesów generowanych przez program top czy ps. Podobnie jak z
programami z bitem SUID jest to oparte o grupy, aby użytkownik widział wszystkie
procesy należy go zapisać do grupy /proc.
chroot i vserver
PLD oferuje system sys-chroot, wbudowany w rc-skrypty, służacy
˛ do wygodnego
zarzadzania
˛
środowiskami typu chroot. Usługi, które wspieraja˛ natywnie chrooty
(np. Bind) działaja˛ w izolowanym środowisku od razu po instalacji.
PLD wspiera także mechanizm Linux VServers2, zwany potocznie "chrootem na sterydach". Wymaga on zainstalowania odpowiedniej wersji kernela i odpowiedniego
zestawu narz˛edzi.
137
Statyczny VIM
Najważniejszym narz˛edziem administracyjnym jest edytor tekstu, dlatego nie powinniśmy pozostać bez takiego programu, co może mieć miejsce np. przy uszkodzeniu systemu plików. Tu z pomoca˛ przychodzi nam statycznie zlinkowany VIM z
pakietu vim-static. Aby nie kolidował ze "zwykłym" vimem, plik wykonywalny jest
umieszczany w /bin/vim.
Pakiety
Zagadnienia zwiazane
˛
z bezpieczeństwem zostały omówione w sekcja Bezpieczeństwo w Rozdział 9.
Przypisy
1. http://cvs.pld-linux.org/cgi-bin/cvsweb/PLD-doc/uid_gid.db.txt?rev=HEAD
2. http://pld-linux.org/Vserver
138
Rozdział 15. Interfejsy sieciowe
˛ konfiguracji sieci
Wstep
˛
Pierwsza˛ rzecza˛ jaka˛ musimy zrobić to ustalić wszystkie konieczne parametry poła˛
czenia sieciowego. W razie watpliwości
˛
należy skontaktować si˛e z naszym dostawca˛
usług internetowych. Ten rozdział opisuje konfiguracj˛e interfejsów sieciowych, testowanie połaczenia
˛
oraz inne prace diagnostyczne przeprowadzimy za pomoca˛ narz˛edzi opisanych w sekcja Narz˛edzia sieciowe w Rozdział 16.
Zarzadzanie
˛
całym podsystemem sieci (właczanie,
˛
wyłaczanie,
˛
restart) dokonujemy
za pomoca˛ rc-skryptu network, wi˛ecej informacji o zarzadzaniu
˛
rc-skryptami znajdziemy w sekcja Zarzadzanie
˛
podsystemami i usługami w Rozdział 14. Jest on integralna˛
cz˛eścia˛ PLD i startuje automatycznie w trakcie uruchomienia systemu. Aby skonfigurować sieć potrzebujemy jedynie ustawić podstawowe parametry sieci (opisane w
nast˛epnym rozdziale) oraz prawidłowo skonfigurować interfejs(y).
Konfiguracj˛e proxy opisano szczegółowo w sekcja Proxy w Rozdział 7.
Jeśli mamy zamiar modyfikować konfiguracj˛e sieci na zdalnej maszynie (np. przez
ssh), to zalecane jest użycie programu screen, aby mieć pewność, że cała procedura zakończy si˛e poprawnie i nie utracimy kontaktu z hostem. Jeśli mamy program
screen wystarczy że wydamy polecenie:
# screen service network restart
Podstawowa konfiguracja sieci
W wi˛ekszości wypadków konfiguracja sieci (oprócz ustawień interfejsu sieciowego)
b˛edzie si˛e składała ze wskazania domyślnej bramy i serwerów DNS dla resolvera.
Wiele zaawansowanych opcji sieci (np. przekazywanie pakietów) ustawianych jest
w pliku konfiguracji jadra:
˛
/etc/sysctl.conf, parametry te zostały omówione w
sekcja Parametry jadra
˛ w Rozdział 11.
Brama domyślna
Jeśli nie korzystamy z serwera DHCP ustawiamy statyczna˛ tras˛e routingu do domyślnej bramy, w tym celu edytujemy plik /etc/sysconfig/static-routes - wpis
może wygladać
˛
nast˛epujaco:
˛
eth0 default via 192.168.0.1
Odwzorowanie nazw - serwery DNS
Wskazanie serwerów DNS jest obowiazkow
˛
a˛ pozycja˛ konfiguracji resolvera nazw.
Operacja ta nast˛epuje automatycznie, o ile korzystamy z serwera DHCP, w przeciwnym wypadku musimy podać ich adresy samodzielnie. Serwery nazw ustawiamy
edytujac
˛ plik /etc/resolv.conf. Jeśli go nie ma, to możemy go utworzyć za pomoca˛
dowolnego edytora lub poleceniem touch. Podajemy przynajmniej jeden (zazwyczaj
nie wi˛ecej niż dwa) serwer nazw za pomoca˛ słowa kluczowego nameserver np.:
nameserver 192.168.0.12
139
Nazwa hosta
Możemy ustawić nazw˛e, za pomoca˛ której nasza maszyna b˛edzie si˛e
przedstawiała zalogowanym użytkownikom, i niektórym programom. W pliku
/etc/sysconfig/network ustawiamy:
HOSTNAME=pldmachine
Dla porzadku
˛
warto by była zgodna z adresem FQDN (o ile jest nadany). Niekiedy
podana˛ tu nazw˛e należy dopisać do pliku /etc/hosts opisanego w dalszej cz˛eści
rozdziału.
Odwzorowanie nazw - konfiguracja zaawansowana
Plik /etc/host.conf zawiera podstawowe opcje resolvera nazw, w wi˛ekszości wypadków wystarczy domyślna konfiguracja:
order hosts,bind
multi on
Pierwsza pozycja wskazuje kolejność używania metod szukania adresów hostów, w
podanym przykładzie najpierw b˛edzie przeszukiwany plik /etc/hosts, w drugiej
kolejności b˛eda˛ odpytywane serwery DNS. Drugi wiersz zezwala na zwracanie wi˛ecej niż jednego adresu IP z pliku /etc/hosts (o ile przypisano wi˛eksza˛ liczb˛e adresów do nazwy).
W pliku /etc/hosts można dodawać odwzorowania hostów, które sa˛ uzupełnieniem dla usługi DNS, jedyny wymagany wpis to wskazanie adresu IP p˛etli zwrotnej
dla nazwy localhost:
127.0.0.1
localhost
Oprócz nielicznych wyjatków,
˛
inne wpisy nie sa˛ tu konieczne, Dla potrzeb niektórych programów trzeba dopisać do powyższego wiersza nazw˛e hosta ustawionego
za pomoca˛ opisanej powyżej opcji HOSTNAME:
127.0.0.1
localhost styx
przykład wpisu dla programu wymagajacego
˛
przypisania pełnej nazwy domenowej:
213.25.115.88 platinum.elsat.net.pl
Rozwiazanie
˛
to służy do szybszej identyfikacji komputerów w sieci lub prac diagnostycznych. Aby w ogóle z tego skorzystać musimy ustawić odpowiednia˛ kolejność
przeszukiwania w pliku /etc/host.conf
Jeśli cz˛esto odwołujemy si˛e do maszyn w naszej domenie to możemy ułatwić sobie
życie i ustawić domen˛e domyślna˛ w pliku /etc/resolv.conf. Od tej pory podanie samej nazwy hosta (bez cz˛eści domenowej), b˛edzie uważane za podanie pełnego
adresu. Przykładowe ustawienie domyślnej domeny (np. jakasdomena.cos) podano
poniżej:
domain jakasdomena.cos
140
Inne opcje
Edytujemy plik /etc/sysconfig/network, domyślne wartości opcji z tego pliku w
zupełności wystarczaja˛ do typowego korzystania z sieci i nie ma potrzeby nic modyfikować w nim.
NETWORKING=yes
Ustawiamy na "yes" jeżeli w ogóle chcemy komunikować si˛e z siecia.˛
IPV4_NETWORKING=yes
Ustawiamy na "yes" jeżeli b˛edziemy korzystać z protokołu IPv4 (wymagany do korzystania z Internetu).
NISDOMAIN=
Domena NIS, jeśli nie korzystasz z tej usługi sieciowej, lub nie jesteś pewien pozostaw to pole puste.
GATEWAY=192.168.0.254
GATEWAYDEV=eth0
Opcje za pomoca˛ których możemy ustawić tras˛e routingu do domyślnej bramy.
Opcje te zostały uznane za przestarzałe, obecnie należy korzystać z pliku
/etc/sysconfig/static-routes.
Ethernet
Urzadzenie
˛
Wi˛ekszość dost˛epnych na rynku kart sieciowych jest oparta na układach Realteka,
3Com badź
˛ Intela, dzi˛eki temu nie b˛edzie problemów z uruchomieniem urzadzenia.
˛
Karty sieciowe sa˛ automatycznie wykrywane przez jadro
˛
i nadawane sa˛ im nazwy
kolejno: eth0, eth1, eth2, itd. Jedyna˛ rzecza˛ jaka pozostaje to załadowanie odpowiedniego modułu dla danego urzadzenia,
˛
proces ten dokładnie opisano tutaj: sekcja Moduły jadra
˛ w Rozdział 11.
Pliki
konfiguracyjne
interfejsów
sa˛
przechowywane
w
katalogu
/etc/sysconfig/interfaces, nazwy tych plików b˛eda˛ miały kolejno nazwy
ifcfg-eth0, ifcfg-eth1, ifcfg-eth2, itd. W tym rozdziale założono, że konfigurujemy
pierwszy interfejs (eth0). Pliki te modyfikujemy za pomoca˛ dowolnego edytora
tekstu np.
# vim /etc/sysconfig/interfaces/ifcfg-eth0
Statyczna konfiguracja karty sieciowej
Zaczynamy
od
zmodyfikowania
/etc/sysconfig/interfaces/ifcfg-eth0,
lub
utworzenia
pliku
aby karta działała poprawnie
powinieneś mieć tam podobne ustawienia:
DEVICE="eth0"
Powyższa opcja ta określa nazw˛e urzadzenia.
˛
IPADDR="192.168.0.2/24"
141
Ta opcja określa adres karty sieciowej oraz mask˛e podsieci. Mask˛e podsieci podajemy
w notacji CIDR - "/24" odpowiada masce 255.255.255.0.
ONBOOT="yes"
Ustaw na "yes" jeśli chcesz aby interfejs automatycznie podnosił si˛e razem z podsystemem sieci.
BOOTPROTO="none"
Ta opcja pozwala dokonać wyboru, w jaki sposób karta sieciowa ma otrzymywać
konfiguracj˛e. Powyższy wpis sprawia, że system pobiera wszystkie ustawienia z posiadanych plików konfiguracyjnych.
Na końcu aktywujemy sieć.
Dynamiczna konfiguracja karty sieciowej (DHCP)
Na poczatek
˛
wybieramy jeden z programów klienckich: dhcpcd lub pump:
# poldek -i dhcpcd
Nasze
zadanie
ogranicza
si˛e
do
zmiany jednego parametru w
Odszukujemy
w
nim
BOOTPROTO i wskazujemy klienta DHCP, który ma być użyty:
/etc/sysconfig/interfaces/ifcfg-eth0.
pliku
opcj˛e
BOOTPROTO="dhcp"
Na koniec dokonujemy aktywacji interfejsu.
Mała uwaga: przy użyciu DHCP statyczne opcje sieciowe (adres IP, maska podsieci,
brama) umieszczone w plikach konfiguracyjnych b˛eda˛ ignorowane, zaś zawartość
pliku /etc/resolv.conf b˛edzie nadpisywana informacjami przyznanymi przez serwer DHCP.
Aktywacja sieci
Ostatnia˛ czynnościa˛ jest uruchomienie lub restart podsystemu sieci:
Ustawianie parametrów sieci....................[ ZROBIONE ]
Podnoszenie interfejsu eth0....................[ ZROBIONE ]
WiFi
Wstep
˛
W przypadku laptopa dobrym pomysłem jest użycie jakiejś aplikacji X-Window do
konfiguracji WiFi, z możliwościa˛ łatwego przełaczania
˛
pomi˛edzy sieciami oraz automatycznym wykrywanie podłaczenia
˛
kabla do karty Ethernet. Takie możliwości
zapewnia np. NetworkManager (korzysta z aplikacji wpa_supplicant), przeznaczony dla środowiska Gnome. W przypadku stacjonarnych maszyn konfiguracja rcskryptów powinna być wystarczajaca
˛ w wi˛ekszości wypadków.
W naszych przykładach przedstawimy konfiguracj˛e dla sieci bezprzewodowej działajacej
˛ w trybie trybie infrastruktury (managed), o określonym identyfikatorze SSID
142
i zabezpieczonej kluczem WEP oraz WPA2-PSK (WPA2 Personal). WEP zawiera zbyt
dużo słabych punktów i jest podatny na szybkie złamanie, dlatego o ile nie jesteśmy
ograniczeni sprz˛etem to należy używać właśnie WPA2.
Niektóre karty sieciowe WiFi maja˛ dedykowane sterowniki i ich konfiguracja nie
sprawia wi˛ekszych kłopotów, w pozostałych wypadkach posłużymy si˛e sterownikami dla systemu Microsoft Windows, uruchomionymi dzi˛eki aplikacji NdisWrapper. Jest to możliwe dzi˛eki temu, że wi˛ekszość sterowników jest napisana zgodnie ze
standardem NDIS. Po załadowaniu modułów, dalsza konfiguracja interfejsu w obu
przypadkach przebiega niemal identycznie.
Sterowniki dedykowane
Do kernela w wersji 2.6.24 trafiło wiele modułów obsługujacych
˛
sterowniki kart
WLAN, sterowniki rozwijane niezależnie sa˛ dost˛epne w osobnych pakietach
kernel-net-* Przykładowo zainstalujemy moduł dla kart Atheros:
$ poldek -i kernel-net-madwifi-ng
musimy załadować moduł:
# modprobe ath_pci
Jeśli nie UDEV ładuje nam moduł kernela, to musimy dodać jego nazw˛e do pliku
/etc/modules lub /etc/modprobe.conf, co zostało szczegółowo opisano w sekcja
Moduły jadra
˛ w Rozdział 11. Teraz możemy przejść do konfiguracji interfejsu.
Sterowniki z NdisWrapperem
Instalujemy pakiety kernel-net-ndiswrapper oraz ndiswrapper:
$ poldek -i ndiswrapper kernel-net-ndiswrapper
Potrzebne nam b˛eda˛ teraz sterowniki windowsowe naszej karty sieciowej. Konkretnie chodzi o pliki z rozszerzeniami *.inf oraz *.sys. Możesz je skopiować z dostarczonej przez producenta płytki ze sterownikami
#
#
#
#
mkdir /lib/windrivers
cd /lib/windrivers
cp /media/cdrom/sciezka/do/sterownikow/sterownik.inf .
cp /media/cdrom/sciezka/do/sterownikow/sterownik.sys .
Musimy teraz zainstalować te sterowniki przy użyciu NdisWrappera.
# ndiswrapper -i /lib/windrivers/sterownik.inf
Jeśli chcemy aby stworzył si˛e alias w pliku /etc/modprobe.conf wykonujemy polecenie:
# ndiswrapper -m
Sieć WEP
Domyślnie rc-skrypty do obsługi WLAN używaja˛ pakietu wireless-tools:
$ poldek -i wireless-tools
143
Kiedy poradziliśmy sobie ze sterownikiem, musimy utworzyć odpowiedni plik
konfiguracji, który umieścimy w katalogu /etc/sysconfig/interfaces/.
Nazwiemy go ifcfg-wlan0, zaś w przypadku kart z chipsetem Atheros użyjemy
nazwy ifcfg-ath0. Przykładowa˛ treść takiego pliku zamieszczono poniżej:
DEVICE=wlan0
IPADDR=192.168.0.2/24
ONBOOT=yes
BOOTPROTO=dhcp
WLAN_ESSID=nasza_nazwa_sieci
WLAN_KEY=A638FED41027EA086ECD6825B0
Opcje sieci bezprzewodowej rozpoczynaja˛ si˛e si˛e od przedrostka WLAN_, pozostałe
parametry (w tym opcje protokołu IP) sa˛ takie same jak dla zwykłej karty typu Ethernet, której konfiguracj˛e szczegółowo omówiono w sekcja Ethernet.
Jako urzadzenie
˛
w opcji DEVICE wskazujemy nadana˛ przez kernel nazw˛e. Kartom
nadawane sa˛ zwykle nazwy wlan0, wlan1, itd. Wyjatkiem
˛
od tej reguły sa˛ niektóre
sterowniki, rozwijane niezależnie od kernela np. ath{$NR} dla kart z układami Atheros Communications, czy ra{$NR} dla Ralink Technology (w kernelach do 2.6.24). To
jaka nazwa została przydzielona naszemu urzadzeniu
˛
możemy odczytać z komunikatów jadra.
˛
Poniżej przedstawione zostana˛ parametry sieci WLAN:
WLAN_ESSID=moja_siec
Powyższa opcja to identyfikator ESSID naszej sieci
WLAN_KEY=A638FED41027EA086ECD6825B0
Przy pomocy kolejnej zmiennej podajemy klucz WEP, na przykładzie użyto klucza
szesnastkowego, aby podać klucz w postaci ASCII musimy ma jego poczatku
˛
dodać:
"s:"
Dodatkowo możemy ustawić szybkość interfejsu:
WLAN_BITRATE=auto
Ta˛ opcj˛e możemy ustawić również na sztywno, przez podanie obsługiwanej wartości
np.: 11MB, 24MB, 54MB.
Sieć WPA2-PSK
Opisane powyżej wireless-tools nie potrafia˛ używać szyfrowania WPA/WPA2,
dlatego konieczny nam b˛edzie pakiet wpa_supplicant:
$ poldek -i wpa_supplicant
Edytujemy plik /etc/wpa_supplicant.conf, w którym definiujemy opcje sieci
WLAN:
ap_scan=1
network={
ssid="nasza_nazwa_sieci"
key_mgmt=WPA-PSK
proto=RSN
pairwise=CCMP TKIP
group=CCMP TKIP WEP104 WEP40
psk=anejdlf7323e64ekjlkbdsxhjsldjf3fda
144
}
Hasło do naszej sieci w linijce psk może być jawne lub kodowane za pomoca˛ polecenia wpa_passphrase
Testujemy połaczenie
˛
z WiFi:
# ifconfig wlan0 up
# wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf -dd
Opcja -dd włacza
˛
tryb debugowania i jeżeli nie otrzymamy jakichś bł˛edów, to
przerywamy działanie wpa_supplicant skrótem ctr-c Pozostała nam jeszcze edycja
/etc/sysconfig/interfaces/ifcfg-wlan0, w celu wskazania, że chcemy
korzystać z wpa_supplicant:
DEVICE=wlan0
IPADDR=192.168.0.2/24
ONBOOT=yes
BOOTPROTO=dhcp
WLAN_WPA=yes
WLAN_WPA_DRIVER=wext
Restartujemy ponownie nasza˛ sieć:
# /etc/init.d/network restart
i nasza sieć WiFi powinna już działać.
Aktywacja i diagnostyka
Na wszelki wypadek powinniśmy si˛e upewnić, że nasza maszyna jest w zasi˛egu sieci
radiowej:
# iwlist wlan0 scan
Jeśli sieć jest na liście, to próbujemy podnieść interfejs (oczywiście, jeżeli tego nie
zrobiliśmy już wcześniej):
Ustawianie parametrów sieci....................[ ZROBIONE ]
Podnoszenie interfejsu wlan0...................[ ZROBIONE ]
Aby sprawdzić czy wszystko jest OK możemy użyć polecenia iwconfig, które powinno wyświetlić coś w stylu:
# iwconfig
lo
no wireless extensions.
eth0
no wireless extensions.
wlan0
IEEE 802.11g ESSID:"nasza_nazwa_sieci" Nickname:"foo.com"
Mode:Managed Frequency:2.412 GHz Access Point: 8A:1C:F0:6F:43:2D
Bit Rate=300 Mb/s
Sensitivity=-200 dBm
RTS thr=2346 B
Fragment thr=2346 B
Encryption key:ABFA-155B-E90F-1D1C-FC34-66ED Security mode:restricted
Power Management:off
Link Quality:100/100 Signal level:-30 dBm Noise level:-96 dBm
Rx invalid nwid:0 Rx invalid crypt:0
Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
145
w wyświetlonych danych interfejsu odszukujemy wartość jakości połaczenia:
˛
Link
Quality Niezerowa wartość oznacza, że konfiguracja zakończyła si˛e sukcesem.
W przypadku użycia pakietu wpa_supplicant możemy użyć programu wpa_cli:
wpa_cli status
Selected interface ’wlan0’
bssid=00:1e:e5:6d:62:5e
ssid=nasza_nazwa_sieci
id=0
pairwise_cipher=CCMP
group_cipher=TKIP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=192.168.0.2
Wartość COMPLETED parametru wpa_state oznacza prawidłowe połaczenie
˛
z WiFi.
Jeżeli mamy kart˛e obsługujac
˛ a˛ tryb "n" może nam si˛e przydać polecenie iwpriv z pakietu wireless-tools. Możemy przełaczyć
˛
wtedy kart˛e wifi w szybszy tryb, ponieważ
cz˛esto z automatu właczony
˛
jest wolniejszy np. "g". Uruchamiamy wi˛ec:
# iwpriv wlan0 network_type n
i powinniśmy wykorzystywać już nasza˛ kart˛e maksymalnie - co możemy sprawdzić
poleceniem:
# iwlist bitrate
lo no bit-rate information.
eth0 no bit-rate information.
wlan0
8 available bit-rates :
6 Mb/s
9 Mb/s
12 Mb/s
18 Mb/s
24 Mb/s
36 Mb/s
48 Mb/s
54 Mb/s
Current Bit Rate=270 Mb/s
Neostrada+ z modemem USB firmy Sagem
Wprowadzenie
Na samym poczatku
˛
musimy właczyć
˛
w biosie komputera port USB oraz zainstalować takie pakiety jak eagle oraz kernel-usb-eagle. Dodatkowo musimy jeszcze zainstalować pakiet ppp. Jeżeli zainstalowałeś system z płytki MINI-iso, powinieneś je
tam znaleźć. W przypadku, kiedy instalowałeś system z dyskietki, znajdziesz je na
jednej lub kilku dyskietek "addons" czyli dyskietek zawierajacych
˛
dodatkowe pakiety.
146
Instalacja
Przyst˛epujemy do instalacji. Należy przejść do do lokalizacji w której znajduja˛ si˛e
owe pakiety a nast˛epnie wydać nast˛epujace
˛ polecenie.
# rpm -Uvh kernel-usb-eagle* eagle-usb* ppp*
Kiedy już upewniliśmy si˛e, że mamy właczony
˛
port USB w biosie, musimy go zainicjować w systemie. Możemy to zrobić za pomoca˛ pliku /etc/modules.conf w
którym umieszczamy przykładowa˛ linijk˛e
alias usb-controller usb-uhci
Jeżeli posiadasz zainstalowany kernel z serii 2.6.x powinieneś umieścić nast˛epujacy
˛
wpis w pliku /etc/modprobe.conf
alias usb-controller uhci-hcd
Po ponownym uruchomieniu komputera powinniśmy posiadać w systemie obecny
moduł usb-uhci (uhci-hcd dla jadra
˛
2.6.x). W przypadku, kiedy ten moduł po prostu
nie zadziała spróbuj załadować usb-ohci (ohci-hcd dla jadra
˛
2.6.x). Jeżeli podłaczyłeś
˛
modem do portu USB 2.0 powinieneś użyć modułu usb-ehci (ehci-hcd dla jadra
˛
2.6.x).
Możemy teraz podłaczyć
˛
modem do komputera. Nasze urzadzenie
˛
zostanie od razu wykryte i zainicjowane w systemie. Poprawna inicjalizacja powinna zakończyć
si˛e załadowaniem do pami˛eci modułu adiusbadsl. UWAGA! Jeżeli posiadasz kernel
2.6.x powinieneś załadować moduł eagle-usb.
Konfiguracja
Możemy zaczać
˛ od pliku /etc/resolv.conf. Opis znajdziecie w rozdziale
poświ˛econym konfiguracji sieci. Przyst˛epujemy teraz do konfiguracji pliku
/etc/eagle-usb/eagle-usb.conf. Należy w nim zmienić wartość opcji VPI na
taka˛ jaka˛ widzicie poniżej.
VPI=00000000
Skonfigurujemy teraz demona PPP. Utworzonemu w wyniku instalacji plikowi
/etc/ppp/options zmieniamy nazw˛e na options.old. Tworzymy nowy plik
options z zawartościa˛ taka˛ jaka została przedstawiona na poniższym listingu.
Najważniejsza˛ rzecza˛ jest podanie w nim nazwy użytkownika, która jest konieczna
do ustanowienia połaczenia.
˛
Możemy również dopisać opcj˛e debug, jeśli chcemy
być informowani o tym co si˛e dzieje.
# cat /etc/ppp/options
user "[email protected]"
mru 1492
mtu 1492
noipdefault
defaultroute
usepeerdns
noauth
#ipcp-accept-remote
#ipcp-accept-loacal
nobsdcomp
nodeflate
nopcomp
novj
novjccomp
#novaccomp -am
noaccomp -am
#właczam
˛
debug.
debug
147
Musimy
jeszcze
wpisać
hasło.
Aby
tego
dokonać
wyedytujmy
plik
/etc/ppp/chap-secrets. UWAGA! Jeżeli si˛e pomylisz i wpiszesz hasło do
/etc/ppp/pap-secrets, hasło nie zadziała.
# cat /etc/ppp/chap-secrets
[email protected] * haslo *
Na tym zakończymy konfiguracj˛e połaczenia
˛
z Neostrada.˛ Jesteśmy już gotowi aby
wszystko uruchomić.
Uruchomienie i post konfiguracja
Najbardziej wygodnym sposobem b˛edzie wykorzystanie mechanizmu rc-scripts do
uruchamiania usługi. Do tego potrzebny b˛edzie odpowiedni plik konfiguracji, przykładowy taki plik umieszczono w katalogu /usr/share/doc/rc-scipts/ oraz na
poniższym wydruku:
DEVICE=ppp0
ONBOOT=yes
PPPOA_EAGLE=yes
AUTH=no
MTU=1452
PERSIST=yes
DEFROUTE=yes
USEPEERDNS=yes
[email protected]
# put password in /etc/ppp/pap-secrets or install
# ppp-plugin-ifcfg-password and uncommend following lines
# PLUGIN_IFCFG_PASSWORD=yes
# PASSWORD=YYYY
Plik zapisujemy jako /etc/sysconfig/interfaces/ifcfg-ppp0 i wydajemy polecenie:
# ifup ppp0
Dzi˛eki opcji ONBOOT=yes połaczenie
˛
b˛edzie nawiazywane
˛
wraz z uruchamianiem
systemu.
Możemy sprawdzić np. pingiem łaczność
˛
z jakimś zewn˛etrznym serwerem, np. ping
www.pld-linux.org. Jeżeli posiadasz jakaś
˛ sieć LAN, lub kilka komputerów w mieszkaniu, powinieneś przeczytać rozdział poświ˛econy maskaradzie.
Neostrada+ z modemem USB firmy Alcatel - Thompson
Przygotowanie do instalacji
Oto krótka lista tego, co b˛edzie nam potrzebne do uruchomienia modemu.
•
Port USB w komputerze
•
Jadro
˛
z serii 2.4 lub 2.6
•
Programy: modem_run oraz pppoa3
•
Pakiet: ppp-plugin-pppoatm
•
Firmware do modemu.
Firmware
dla
modemu
można
ściagn
˛ ać
˛
http://speedtouch.sourceforge.net/files/firmware.bin1.
148
z
stad:
˛
Jeżeli już upewniłeś si˛e, że masz wszystkie wymagane rzeczy, możemy przystapić
˛
do instalacji.
Konfiguracja
W pierwszej kolejności musimy zainicjować w systemie USB, oraz kilka modułów
do obsługi ppp. Możemy to zrobić wykonujac
˛ nast˛epujace
˛ polecenie
# for i in usbcore uhci acm ppp_generic \
ppp_synctty;do modprobe $i;done
Komentarza wymaga tutaj obsługa USB. W przykładzie został podany moduł uhci.
Jeżeli nie załaduje si˛e poprawnie (zostaniesz o tym poinformowany) powinieneś
wybrać jeden z nast˛epujacych:
˛
usb-uhci, usb-ohci lub dla USB 2.0 usb-ehci. Posiadacze jader
˛
z serii 2.6 maja˛ do wyboru nast˛epujacy
˛ zestaw modułów: uhci-hcd,
ohci-hcd lub ehci-hcd. Ta różnorodność jest uwarunkowana sprz˛etowo, w zależności od rodzaju chipsetu obsługujacego
˛
porty USB. Ważna˛ rol˛e tutaj odgrywa moduł
acm, gdyż bez niego nie b˛edzie możliwe załadowanie firmware do modemu. W kernelach z serii 2.6.x odpowiednikiem acm jest moduł cdc-acm.
Posiadacze kernela z serii 2.6.x moga˛ użyć poniższej p˛etli która załaduje wszystkie
potrzebne moduły. Oczywiście należy zwrócić uwag˛e aby załadować odpowiedni
dla Twojego sprz˛etu moduł obsługujacy
˛ kontroler USB na płycie głównej.
# for i in usbcore uhci-hcd cdc-acm ppp_generic ppp_synctty;do modprobe $i;done
Nast˛epnym krokiem jest podmontowanie systemu plików w proc.
# mount none /proc/bus/usb -t usbfs
W tym momencie możemy sprawdzić, czy SpeedTouch rzeczywiście jest widziany
przez system. Aby tego dokonać wykonaj poniższe polecenie
# cat /proc/bus/usb/devices
[...]
S: Manufacturer=ALCATEL
S: Product=Speed Touch 330
[...]
Musisz teraz zainstalować oprogramowanie do modemu. Robimy to wydajac
˛ nast˛epujace
˛ polecenie:
# poldek -U speedtouch
Podłacz
˛ modem do komputera. B˛edzie on potrzebował do działania specjalnego pliku, tak zwanego firmware. Program modem_run potrafi odczytywać firmware w
formatach przygotowanych dla Linuksa, Windowsa oraz MacOS. Jakie sa˛ możliwości pobrania pliku firmware? Możemy pobrać go z adresu podanego na poczatku
˛
rozdziału. Jest to firmware przygotowany dla systemu MacOS. Linuksowy firmware
możemy pobrać ze strony Alcatela: www.speedtouchdsl.com/dvrreg_lx.htm2. Wymagana jest rejestracja. Możemy również go wziać
˛ z płytki dostarczonej przez TPSA.
Powinien on znajdować si˛e w archiwum Linux/ThomsonST330/pliki.tar.gz. Po
jego rozpakowaniu powinniśmy mieć coś takiego jak: drivers/speedmgmt.tar.gz.
Posiadajac
˛ już plik speedmgmt.tar.gz możemy sobie zbudować pakiet rpm z firmwarem przy użyciu speedtouch-firmware.spec. Musimy tylko skopiować archiwum
do katalogu ~/rpm/SOURCES. Dalsze instrukcje dotyczace
˛ budowania pakietów znajdziesz w tej dokumentacji w rozdziale: Tworzenie PLD. Po zainstalowaniu zbudowanego pakietu z firmwarem, możemy go załadować wydajac
˛ poniższe polecenie:
# modem_run -v 1 -m -f /ścieżka/do/firmware
149
Ładowanie firmware do modemu może troch˛e potrwać. Jeżeli chcesz widzieć co si˛e
dzieje wpisz nast˛epujace
˛ polecenie
# tail -f /var/log/messages
W trakcie ładowania pliku firmware, zaczna˛ migać diody urzadzenia.
˛
B˛edzie to
oznaczać synchronizacj˛e linii. Po kilkunastu sekundach modem si˛e ustabilizuje.
Diody powróca˛ do zielonego koloru.
Jeżeli masz zainstalowany kernel z serii 2.6 lub 2.4.22+ wykonaj poniższe polecenia:
# modprobe speedtch
# modem_run -k -m -v 1 -f /usr/share/speedtouch/mgmt.o
# modprobe pppoatm
Moduł speedtch jest potrzebny do użycia opcji -k (może być ładowany automatycznie przez hotplug. Z kolei pppoatm b˛edzie potrzebny do uruchomienia pppd. Nie
ładuje si˛e on automatycznie, dlatego należy go dopisać np. do /etc/modules.
W porzadku.
˛
Po zakończonej operacji ładowania firmware jesteśmy gotowi aby
skonfigurować nasze ppp do neostrady. Zanim to zrobimy b˛edziemy musieli
zainstalować pakiet ppp-plugin-pppoatm.
# poldek -U ppp-plugin-pppoatm
W zależności od wersji zainstalowanego kernela (2.6 lub 2.4) konfiguracja demona
pppd b˛edzie si˛e różniła kilkoma szczegółami. Poniżej przedstawiam przykłady dla
obu serii jader.
˛
Linux z serii 2.4
# cat /etc/ppp/peers/neostrada
debug
lock
noipdefault
defaultroute
pty "/usr/sbin/pppoa3 -v 1 -e 1 -c -m 1 -vpi 0 -vci 35"
asyncmap 0
lcp-echo-interval 2
lcp-echo-failure
7
sync
user "[email protected]"
noauth
holdoff 3
persist
maxfail 25
mru 1500
mtu 1500
Linux z serii 2.6 lub 2.4.22+
# cat /etc/ppp/peers/neostrada
noauth
usepeerdns
noipdefault
defaultroute
pty "/usr/sbin/pppoa3 -e 1 -v 1 -m 1 -c -vpi 0 -vci 35"
sync
user nasz_login
noaccomp
nopcomp
noccp
holdoff 4
persist
maxfail 25
150
Ważna˛ rol˛e odgrywa tu parametr -e 1, gdyż bez niego nie uzyskamy połaczenia.
˛
Oczywiście musimy jeszcze odpowiednio skonfigurować pap-secrets oraz
chap-secrets
# cat /etc/ppp/chap-secrets
[email protected]
*
haslo
*
Uruchomienie i zakończenie
W celu nawiazania
˛
połaczenia,
˛
które uprzednio skonfigurowaliśmy, wydajemy takie
oto polecenie
pppd call neostrada
Jeżeli nie chcemy, badź
˛ z jakichś powodów nie możemy korzystać z programu hotplug nie musimy tego robić. Nie jest on tak naprawd˛e niezb˛edny. W takim przypadku za każdym razem b˛edziemy musieli ładować firmware modemu programem
modem_run.
xDSL z interfejsem Ethernet
Wprowadzenie
Coraz wi˛ecej dostawców usług internetowych oferuje dzierżaw˛e linii xDSL z portem
LAN typu Ethernet, takie usługi oferuja˛ np. Telekomunikacja Polska (Internet DSL)
oraz Dialog (DIALNET DSL).
Konfiguracja
W celu uruchomienia usługi, wystarczy jedynie skonfigurować interfejs sieciowy
Ethernet w naszym komputerze, zgodnie z informacjami uzyskanymi od dostawcy łacza
˛
(konfiguracja statyczna). Poniżej przedstawiono skrócony opis konfiguracji
tego typu interfejsu, szczegółowy opis znajdziemy tutaj: sekcja Ethernet
Podniesienie interfejsu eth0 możemy osiagn
˛ ać
˛ tworzac
˛ lub edytujac
˛ (jeśli istnieje)
plik /etc/sysconfig/interfaces/ifcfg-eth0 i wpisujac
˛ dane otrzymane od dostawcy:
DEVICE="eth0"
IPADDR="80.55.203.222/30"
ONBOOT="yes"
BOOTPROTO="none"
Istotna˛ kwestia˛ jest przypisanie odpowiedniego prefiksu (maski podsieci) przy podaniu adresu IP zarezerwowanego dla abonenta. Prefiks wykorzystywane w usłudze
InternetDSL, to: /30 Internet DSL 512 oraz Internet DSL 1 (przydzielone 4 adresy IP,
co odpowiada masce podsieci 255.255.255.252), /29 Internet DSL 2 (przydzielone 8
adresów IP, co odpowiada masce podsieci 255.255.255.248). Należy pami˛etać że 3 adresy IP sa˛ zarezerwowane do obsługi połaczenia
˛
(adres sieci,brama,broadcast)
Ostatnia˛ zmiana˛ potrzebna˛ do prawidłowego działania sieci jest wyedytowanie pliku /etc/sysconfig/network. Należy tam podać adres bramy (IP modemu DSL).
GATEWAY="80.55.203.221"
GATEWAYDEV="eth0"
151
Na koniec pozostaje nam uruchomienie podsystemu sieci:
# service network start
Uwagi
Jeśli przy łaczu
˛
Internet DSL 1 zdarzaja˛ si˛e przypadki zerwania połaczenia,
˛
należy
przywiazać
˛
wszystkie 5 adresów IP jako wirtualne interfejsy
IPADDR1="ip1/29"
IPADDR2="ip2/29"
IPADDR3="ip3/29"
IPADDR4="ip4/29"
IPADDR5="ip5/29"
Zaawansowane opcje interfejsów
HotPlug
HotPlug jest mechanizmem pozwalajacym
˛
na automatyczne konfigurwanie
systemu po podłaczeniu
˛
określonego urzadzenia.
˛
W przypadku urzadze
˛
ń
sieciowych PCMCIA i USB możliwe jest automatyczne aktywowanie interfejsu od
razu po podłaczeniu
˛
urzadzenia.
˛
Aby uruchomić ten mechanizm musimy najpierw zainstalować odpowiednie oprogramowanie:
# poldek -i hotplug*
Kolejnym krokiem b˛edzie umieszczenie odpowiedniego wpisu w pliku konfiguracji
interfejsu sieciowego. Dodajemy opcj˛e:
HOTPLUG=yes
Narzedzia
˛
Narz˛edzia do zarzadzania
˛
i diagnostyki interfejsów sieciowych opisano w sekcja Narz˛edzia sieciowe w Rozdział 16.
Inne opcje
Zaawansowane opcje sieciowe interfejsów nie sa˛ umieszczane w plikach
generowanych w trakcie instalacji systemu. Ich opis znajdziemy w pliku
/usr/share/doc/rc-scripts/ifcfg-description.gz.
Wzory konfiguracji
Wiele przykładowych konfiguracji interfejsów sieciowych odnajdziemy w katalogu
z dokumentacja˛ do rc-skryptów: /usr/share/doc/rc-scripts. Sa˛ to pliki tekstowe
zarchiwizowane programem Gzip.
152
Przypisy
1. http://speedtouch.sourceforge.net/files/fi rmware.bin
2. http://www.speedtouchdsl.com/dvrreg_lx.htm
153
154
Rozdział 16. Zastosowania sieciowe
˛ konfiguracji sieci
Routing statyczny
Podstawowe trasy do podsieci sa˛ automatycznie tworzone przy konfiguracji interfejsów sieciowych na podstawie podanego adresu IP i maski podsieci. Trasa domyślna
jest konfigurowana na podstawie ustawień w pliku /etc/sysconfig/network. Operacje te zostały opisane w poprzednim rozdziale, w przypadku bardziej zaawansowanych zastosowań musimy samodzielnie skonfigurować trasy pakietów.
Wstepna
˛
konfiguracja
Konfiguracj˛e routingu obowiazkowo
˛
rozpoczynamy od właczenia
˛
przekazywania
pakietów mi˛edzy interfejsami sieciowymi, opcj˛e ta˛ możemy ustawić tymczasowo
wykonujac
˛ polecenie
# echo "1" > /proc/sys/net/ipv4/ip_forward
Możemy też w pliku /etc/sysctl.conf ustawić nast˛epujaca
˛ opcj˛e:
net.ipv4.ip_forward = 1
Nast˛epnie restartujemy podsystem sieci
# service network restart
Wi˛ecej o parametrach jadra
˛
znajdziemy w sekcja Parametry jadra
˛ w Rozdział 11
Tablica routingu
Aby wyświetlić tablic˛e routingu posłużymy si˛e poleceniem ip route:
# ip route
10.0.0.4/32 dev eth0 proto kernel scope link
10.0.0.0/24 dev eth1 proto kernel scope link
default via 10.0.0.100 dev eth0 onlink
src 10.0.0.4
src 10.0.0.1
Zarzadzanie
˛
trasami
Zarzadzenia
˛
routingiem na kilku przykładach:
Dodanie trasy do hosta
# ip route add 10.0.0.4/32 dev eth0
Dodanie trasy do podsieci
# ip route add 10.0.0.0/24 dev eth1
Wskazanie bramy domyślnej:
155
# ip route add 0/0 via 10.0.0.100 dev eth0
dodatkowe opcje:
•
src {$adres_IP} - adres źródłowy nowo tworzonych pakietów, opcja ma istotne znaczenie m.in. w przypadku przypisania kilku adresów IP do tego samego interfejsu.
•
protocol {$nazwa/$numer} - opcja ważna w przypadku łaczenia
˛
trasowania statycznego z dynamicznym. Najcz˛eściej stykamy si˛e z protokołami: redirect, kernel,
boot, ra. Ich pełna˛ list˛e wraz z odpowiadajacym
˛
im numerom znajdziemy w pliku
/etc/iproute2/rt_protos. Dla samego statycznego routowania nie ma potrzeby
jej definiowania.
Usuwanie regułek jest bardzo podobne do dodawania, musimy użyć opcji "del" zamiast "add".
Zakończenie
•
Dodane przez nas regułki możemy zapisac na stałe, w ten sposób zostana˛ automatycznie wczytanie po "podniesieniu" podsystemu sieci. W tym celu modyfikujemy plik /etc/sysconfig/static-routes np.:
eth0 10.0.0.0/24
eth1 192.168.0.0/24 src 192.168.0.4
•
Jadro
˛
używa specjalnego cache do wydajniejszego trasowania pakietów, ma to
jednak pewna˛ wad˛e: zmiany w nim nie nast˛epuja˛ od razu po zmodyfikowaniu
tablicy routingu. Aby wymusić natychmiastowe wyczyszczenie cache należy
użyć poniższego polecenia:
# ip route flush cache
NAT
NAT (Network Address Translation) w Linuksie można zrobić na dwa sposoby:
•
wykorzystujac
˛ infrastruktur˛e netfilter jadra
˛
2.4 i 2.6.
•
korzystajac
˛ z narz˛edzi do kontrolowania sieci z pakietu iproute2.
Oryginalna dokumentacja Netfilter w j˛ezyku angielskim1
Najlepszym sposobem jest wykorzystanie możliwości netfilter, gdyż wykonuje on
nat przed (PREROUTING) lub po (POSTROUTING) routingu, co daje nam możliwość tak
skonfigurowania firewalla, jak by nie było wykonywane NAT. NAT w iptables tworzymy dodajac
˛ regułki do tabeli "nat". Żeby sprawdzić jakie sa˛ dost˛epne "Chains" w
tabeli nat, należy wykonać takie polecenie:
# iptables -t nat -L
W poniższych przykładach założyliśmy, że 1.2.3.4 jest adresem IP podniesionym na
interfejsie zewn˛etrznym ($if_wan) zaś 192.168.1.0/16 to adresy na interfejsie sieci lokalnej ($if_lan).
156
DNAT
W PREROUTING sa˛ regułki do wykonania DNAT (Destination NAT). Zamienia to
adres hosta docelowego na nasz prywatny, w ten sposób możemy przekierować ruch
na dowolny host w sieci prywatnej:
# iptables -t nat -A PREROUTING -d 1.2.3.4 -j DNAT --to 192.168.1.2
Można określić na jakim interfejsie b˛edzie wykonany NAT poprzez opcj˛e -i $inteface.
Opcja -o w PREROUTING nie jest dost˛epna.
Możemy też dokonać przekierowania ruchu kierowanego na konkretny port, zwanego potocznie przekierowaniem portu:
# iptables -t nat -A PREROUTING -i $if_wan -p TCP -d 1.2.3.4 --dport 8000
SNAT i MASQUERADE
SNAT (Source NAT) zmienia to adres nadawcy np. z puli adresów prywatnych na
adres z puli publicznej, co jest wykorzytywane zwykle do "dzielenia łacza".
˛
# iptables -t nat -A POSTROUTING -s 192.168.1.2 -j SNAT --to 1.2.3.4
Jeśli podamy mask˛e podsieci, zostanie wykorzystana wi˛eksza ilość adresów.
MASQUERADE wykonuje to samo co SNAT z tym, że na adres interfejsu jakim wychodzi pakiet. Używać go należy tylko kiedy nasz adres publiczny zmienia si˛e. (np.
w połaczeniach
˛
ze zmiennym IP publicznym)
Zakończenie.
Po ustawieniu DNAT na adres wewn˛etrzny zauważymy, że jest problem z dost˛epem
do ip 1.2.3.4 z wewnatrz
˛
sieci. Dzieje si˛e tak dlatego, że adres source zostaje bez
zmian, dlatego też pakiet nie wraca do bramy. Musimy wi˛ec zmusić, aby host wysyłał
odpowiedź do bramy. Możemy wykonać to w nast˛epujacy
˛ sposób:
# iptables -t nat -A POSTROUTING -o $if_lan -s 192.168.0.0/16 \
-d 1.2.3.4 -j SNAT --to 192.168.0.1
Gdzie $if_lan to interfejs lokalnej sieci, a 192.168.0.1 to adres na tym interfejsie.
Podział łacza
˛
w zależności od serwisów
Wstep
˛
Administratorzy sieci osiedlowych cz˛esto natrafiaja˛ na problemy z programami p2p.
Potrafia˛ one skutecznie zapychać łacza.
˛
Jednym z możliwych rozwiaza
˛ ń jest zablokowanie takiego ruchu, a drugim opisanym w tym dokumencie, jest przekierowanie
go na jedno z łacz
˛ - odcia˛żajac
˛ tym samym drugie.
Jednym z możliwych problemów może być "zatykanie" modemu, wi˛ec należy si˛e dowiedzieć ile modem może obsłużyć aktywnych połacze
˛ ń i ograniczyć wyjście przez
iptables do tej wartości.
157
-j DNAT --to
Podstawy
Ograniczenie można wykonać w ten sposób:
# iptables -t filter -A FORWARD -s 192.168.3.0/24 -o eth1 -p tcp -m mark \
--mark 0x0 -m connlimit --connlimit-above 300 --connlimit-mask 32 \
-j REJECT --reject-with tcp-reset
Co powoduje ograniczenie użytkownikom do 300 wychodzacych
˛
połacze
˛ ń TCP. Wyeliminuje to problem, kiedy pakiety nie sa˛ w stanie wyjść w świat gdyż za dużo jest
aktywnych połacze
˛ ń i modem si˛e zawiesza.
Drugim sposobem jest ograniczenie pasma wychodzacego
˛
w taki sposób, żeby router
pilnował, aby na modemie nie było zbyt dużego ruchu sieciowego.
# tc qdisc del dev eth1 root
# tc qdisc add dev eth1 root handle 1 cbq bandwidth 256Kbit \
avpkt 1000 cell 8
# tc class change dev eth1 root cbq weight 32bit allot 1514
# tc class add dev eth1 parent 1: classid 1:2 cbq bandwidth 256Kbit \
rate 216Kbit weight 27Kbit prio 1 allot 1514 cell 8 maxburst 20 \
avpkt 1000 bounded
# tc qdisc add dev eth1 parent 1:2 handle 2 tbf rate 216Kbit \
buffer 10Kb/8 limit 15Kb mtu 1500
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 \
match ip src $ip_nat classid 1:2
Gdzie $ip_nat to adres ip serwera
Przekierowanie p2p i połacze
˛
ń podobnych
Trzecim sposobem jest zakupienie drugiego, taniego łacza
˛
i puszczenie nim niechcianego ruchu np tak:
Cały niezidentyfikowany ruch przekierowywany jest na łacze
˛
dodatkowe, a zidentyfikowany na łacze
˛
drugie (szybsze).
Na poczatek
˛
ustawimy w tabeli mangle takie regułki, służac
˛ do oznaczania odpowiednich pakietów:
// przywrócenie wartości mark dla nawiazanych
˛
już połaczeń
˛
# iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
// jeśli si˛
e okaże, że jakieś p2p działa na portach preferowanych to
// zaznaczy je i wtedy nie przepuści
# iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ipp2p \
-j MARK --set-mark 0x1214
# iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ipp2p-data \
// zachowanie dla potomności
# iptables -t mangle -A PREROUTING -p tcp -m mark --mark 0x1214 \
-j CONNMARK --save-mark
// jeśli jakiś pakiet jest już oznaczony to wychodzi
// z tabeli mangle i sprawdza kolejne regułki iptables
# iptables -t mangle -A PREROUTING -m mark ! --mark 0x0 -j RETURN
// znakuje uprzywilejowane servisy
# iptables -t mangle -A PREROUTING -p icmp
# iptables -t mangle -A PREROUTING -p udp
// porty 1:1024
# iptables -t mangle -A PREROUTING -p tcp
158
-s 192.168.0.0/16 \
-s 192.168.0.0/16 \
-s 192.168.0.0/16 \
--dport 1:1024 -j MARK --set-mark 0x1
// mysql
-s
--dport 3306 -j MARK --set-mark 0x1
// gg
-s
// cache
-s
// gra americans army
-s
// irc
-s
// gra enemy terrytory
-s
// gra MU Online
-s
-s
// wszystkie porty dobrze znanych serwerów
// www.wp.pl
-s
-d 212.77.100.101 -j MARK --set-mark 0x1
// czat.wp.pl
-s
-d 212.77.100.113 -j MARK --set-mark 0x1
// www.onet.pl
-s
-d 213.180.130.200 -j MARK --set-mark 0x1
//strona z grami Online www.miniclip.com
-s
-d 69.0.241.20 -j MARK --set-mark 0x1
// www.kurnik.pl
-s
-d 217.17.45.25 -j MARK --set-mark 0x1
192.168.0.0/16 \
192.168.0.0/16 \
192.168.0.0/16 \
192.168.0.0/16 \
192.168.0.0/16
192.168.0.0/16 \
192.168.0.0/16 \
192.168.0.0/16 \
192.168.0.0/16 \
192.168.0.0/16 \
192.168.0.0/16 \
192.168.0.0/16 \
192.168.0.0/16 \
// no i jeszcze zachować dla potomności
# iptables -t mangle -A PREROUTING -p tcp -m mark --mark 0x1 \
-j CONNMARK --save-mark
Jeśli już mamy oznaczone pakiety należy je odpowiednio przekierować. Możemy
skorzystać z dobrodziejstwa iproute2 i dodać nast˛epujace
˛ regułki:
# ip route add from 192.168.0.0/16 fwmark 0x1214 lookup TABLE_SMIECI
# ip route add from 192.168.0.0/16 fwmark 0x1 lookup TABLE_PRIORYTET
// ta regułka kieruje cały nieoznakowany ruch na łacze
˛
śmieci
// potrzebne jeśli domyślne jest inne łacze
˛
# ip route add from 192.168.0.0/18 lookup TABLE_SMIECI
Oczywiście trzeba dodać do tabeli odpowiednie wpisy default i informacje o sieciach
obsługiwanych przez ten router. Należy jeszcze wykonać te polecenia dla interfejsu
z wyjściem w świat:
# echo 0 >
/proc/sys/net/ipv4/conf/eth1/rp_filter
Po takich zabiegach użytkownicy powinni odczuć znaczny wzrost wydajności łacza
˛
PRIORYTET
Niestety łacze
˛
SMIECI jest maksymalnie zapchane, wi˛ec należy przygotować si˛e na
narzekania użytkowników którzy sa˛ przekierowani na to łacze.
˛
159
Przy takim rozwiazaniu
˛
należy mieć stała˛ kontrol˛e nad usługami, które maja˛ działać
na łaczu
˛
PRIORYTET i stale uaktualniać tabel˛e mangle o odpowiednie wpisy.
Nie udało si˛e niestety przekierować samego ruchu p2p gdyż podczas nawiazywania
˛
połaczenia
˛
nie wiemy jeszcze czy jest to pakiet należacy
˛ do p2p. Dzisiejsze programy
p2p potrafia˛ działać na portach poniżej 1024 np 80 (http) wi˛ec rozróżnienie ich po
portach nic nie da
Innym rozwiazaniem
˛
może być wydzielenie portów dla programów p2p i ogłoszenie ich użytkownikom sieci. Należy wtedy zablokować ruch p2p na wszystkie porty
oprócz tych wydzielonych i jeśli ktoś si˛e nie dostosuje to nie b˛edzie miał transferu.
To rozwiazanie
˛
ma jednak wad˛e: b˛edzie generowało dużo połacze
˛ ń nawiazywanych
˛
(pakiety SYN) na obu łaczach,
˛
gdyż iptables nie pozwoli na transfer dopiero po nawiazaniu
˛
połaczenia
˛
i rozpoznaniu połaczania
˛
jako należacego
˛
do p2p.
PPP over SSH - Tunel IPv4
Wstep
˛
Zaleta˛ tego rodzaju tunelu jest to, że jego działanie opiera si˛e na jednych z bardziej
popularnych protokołach PPP oraz SSH. Komunikacja odbywa si˛e na porcie 22. Dzi˛eki temu nie zachodzi potrzeba otwierania dodatkowych portów komunikacyjnych w
konfiguracji zapory ogniowej. Interfejsy tunelu uruchamiane sa˛ przez demona pppd.
Posłuża˛ nam one do zestawienia trasy mi˛edzy dwoma hostami lub sieciami w zależności od potrzeb. Do naszych celów b˛edzie potrzebny demon pppd b˛edacy
˛ implementacja˛ protokołu ppp oraz klient i serwer ssh implementujacy
˛ protokół ssh.
Konfiguracja
Zanim przystapimy
˛
do konfiguracji musimy zdecydować który komputer b˛edzie serwerem a który klientem. Klient b˛edzie inicjował połaczenie
˛
z serwerem uruchamiajac
˛
demona pppd.
Serwer
Zanim przystapimy
˛
do konfiguracji należy sprawdzić czy system wyposażony jest w
demona ppp oraz serwer ssh. Pakiety które to udost˛epniaja˛ to odpowiednio ppp oraz
openssh-server. Przydatnym może si˛e okazać pakiet openssh-clients zawierajacy
˛ jak
sama nazwa wskazuje klienta ssh.
Po zainstalowaniu wyżej wymienionych pakietów przechodzimy do konfiguracji
systemu. W pierwszej kolejności zakładamy konto użytkownika oraz przydzielamy
mu grup˛e.
# groupadd vpn-users
# useradd -m -s /usr/sbin/pppd -g vpn-users vpn
# passwd vpn
New UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Efekt wykonanych poleceń możesz zobaczyć na listingu poniżej
# grep vpn /etc/passwd
vpn:x:506:1005::/home/users/vpn:/usr/sbin/pppd
#grep vpn-users /etc/group
vpn-users:x:1005:
160
Wynik tych poleceń powinien odpowiadać temu co tutaj widać. GID grupy
vpn-users wynosi 1005 czyli odpowiada GID ustawionemu w pliku /etc/passwd.
Poleceniem passwd ustawiamy hasło dla tego konta, które zostało wpisane do
/etc/shadow.
Istotnym dla konfiguracji elementem w katalogu użytkownika vpn jest katalog
~/.ssh. Możemy go stworzyć (o ile wcześniej zainstalowaliśmy) przy pomocy
klienta ssh. Robimy to w dwóch krokach które obrazuje poniższy przykład
# su - vpn -s /bin/bash
$ ssh domena.pl
Warning: Permanently added ’domena.pl,xxx.xxx.xx.x’ \
(RSA) to the list of known hosts.
Password:
^C
Można też r˛ecznie utworzyć z poziomu konta vpn ten katalog poleceniem mkdir.
Aby umożliwić użytkownikowi prawo do wykonania po zalogowaniu polecenia
/usr/sbin/pppd należy nadać temu plikowi suida.
# chmod 4755 /usr/sbin/pppd
Konfiguracj˛e warstwy ssh mamy już za soba.˛ Możemy teraz przystapić
˛
do
konfiguracji demona pppd. Demon nie b˛edzie wymagał autoryzacji, wi˛ec w pliku
/etc/ppp/options wyszukujemy opcj˛e auth i zmieniamy ja˛ na noauth. Musimy
teraz skonfigurować wierzchołek (tzw. peer) końca tunelu. Tworzymy wi˛ec plik
/etc/ppp/peers/tunel określajacy
˛ wszystkie niezb˛edne parametry połaczenia.
˛
Na
listingu poniżej przykładowa konfiguracja wierzchołka.
# cat /etc/ppp/peers/tunel
192.168.1.100:192.168.1.101
noauth
lcp-echo-interval 5
lcp-echo-failure 3
W pierwszej linijce oddzielone sa˛ dwukropkiem adresy IP wierzchołków tunelu. Ten
po lewej stronie zostanie ustawiony na interfejsie serwera, ten po prawej klienta.
Przedstawiona˛ konfiguracj˛e należy potraktować jako przykład i dostosować ja˛ do
rzeczywistej. Oczywiście, jeżeli spełnia ona Twoje wymagania możesz ja˛ zastosować.
• noauth
- wyłaczamy
˛
autoryzacj˛e ppp
• lcp-echo-interval - wartość przy tej opcji określa interwał w sekundach z jakim
wysyłana b˛edzie do peera ramka żadania
˛
o echo LCP. Demon sprawdza w ten
sposób czy połaczenie
˛
nadal jest aktywne.
- wartość podana przy tej opcji określa ile żada
˛ ń o echo LCP
ma zostać wysłanych jeżeli peer nie dał odpowiedzi. Po tylu próbach demon
stwierdzi, że połaczenie
˛
zostało utracone.
• lcp-echo-failure
Klient
Konfiguracja po stronie klienta sprowadza si˛e do wygenerowania kluczy rsa oraz
odpowieniego ustawienia demona pppd. Klucze nam sa˛ potrzebne do autentykacji nie interaktywnej ssh. Inaczej nie uda nam si˛e nawiazać
˛
połaczenia
˛
z serwerem.
Do zestawienia połaczenia
˛
z serwerem po stronie klienta wymagana jest instalacja
pakietów ppp oraz openssh-clients. Jeżeli ich nie posiadasz musisz je niezwłocznie
zainstalować.
Przyst˛epujemy do dalszej konfiguracji usługi po stronie klienta. Zaczniemy od wspomnianego na wst˛epie generowania kluczy.
161
$ ssh-keygen -b 1024 -f ~/.ssh/klucz -t rsa -P ""
Generating public/private rsa key pair.
Your identification has been saved in /home/users/foo/.ssh/klucz.
Your public key has been saved in /home/users/foo/.ssh/klucz.pub.
The key fingerprint is:
c9:d8:17:bd:ba:82:a0:f0:47:7c:32:c2:e8:7e:32:e8 foo@pldmachine
Do generowania kluczy służy znajdujace
˛ si˛e w pakiecie openssh-clients polecenie
ssh-keygen. Użyliśmy go z nast˛epujacymi
˛
parametrami:
• -b - długość klucza w bitach. Wartość podana na listingu jest minimalna˛ długościa˛
klucza która jest akceptowana przez demona sshd.
• -f
- nazwa pliku (można podać ścieżk˛e do niego) zawierajacego
˛
klucz prywatny.
- typ klucza. Na listingu jest to RSA. RSA jest algorytmem służacym
˛
do generowania kluczy.
• -t
- hasło klucza. Na potrzeby tunelu hasło musi pozostać puste. Inaczej tunel nie
zadziała. Demon sshd b˛edzie czekał na potwierdzenie hasłem klucza co nigdy nie
nastapi,
˛ gdyż sesja ssh b˛edzie inicjowana poprzez demona pppd uniemożliwiajac
˛
nam w sposób interaktywny jej przej˛ecie.
• -P
Kolejnym krokiem jest skopiowanie zawartości pliku klucz.pub do pliku
~vpn/.ssh/authorized_keys na serwerze. Możemy tego dokonać w nast˛epujacy
˛
sposób.
$ scp ~/.ssh/klucz.pub [email protected]:~/.ssh/authorized_keys
Polecenie to zadziała tylko wtedy, kiedy na koncie vpn znajdujacym
˛
si˛e na serwerze zmienimy tymczasowo powłok˛e z /usr/sbin/pppd na standardowa˛ /bin/bash.
Na tym etapie kończy si˛e cała konfiguracja dotyczaca
˛ ssh po obu stronach. Możemy
wi˛ec przywrócić na serwerze w pliku /etc/passwd dla użytkownika vpn powłok˛e
na /usr/sbin/pppd. Przyst˛epujemy teraz do skonfigurowania demona pppd, który
b˛edzie wywoływał podczas ustanawiania połaczenia
˛
klienta ssh.
Podobnie jak po stronie serwera w pliku /etc/ppp/options musimy opcj˛e auth
zmienić na noauth. Kiedy już to zrobimy, przystapimy
˛
do konfiguracji wierzchołka (tzw. peera) dla klienta, który b˛edzie inicjował połaczenie.
˛
Nazwa pliku może być
taka sama jak na serwerze. Poniżej na listingu znajduje si˛e przykładowa konfiguracja
wierzchołka dla klienta.
# cat /etc/ppp/peers/tunel
192.168.1.101:192.168.1.100
debug
noauth
pty "ssh -i ~/.ssh/klucz [email protected]"
connect-delay 5000
Pierwsza linijka w pliku to dwa adresy IP oddzielone znakiem dwukropka. Adres
po lewej stronie jest adresem tego końca tunelu, który właśnie konfigurujemy. Pami˛etamy, że adres 192.168.1.100 został już przydzielony jako adres wierzchołka
serwera. Pozostałe opcje zostały objaśnione poniżej.
• debug
- właczamy
˛
raportowanie szczegółów połaczenia
˛
ppp.
• noauth
- wyłaczamy
˛
autoryzacj˛e.
- dzi˛eki tej opcji możemy wykorzystać zewn˛etrzny skrypt jako ośrodek komunikacji zamiast konkretnego urzadzenia
˛
terminalowego. Wykorzystujemy tutaj
ssh.
• pty
- określony w milisekundach czas oczekiwanie na prawidłowy
pakiet PPP od peera. Jeżeli taki w tym czasie nadejdzie pppd rozpocznie negocjacj˛e wysyłajac
˛ pierwszy pakiet LCP.
• connect-delay
162
W
przypadku
problemów
z
połaczeniem
˛
możemy
zwi˛ekszyć
wartość
connect-delay nawet dziesi˛eciokrotnie jeżeli łacza
˛
pomi˛edzy którymi zestawiamy
tunel b˛eda˛ sporo obcia˛żone. Również po stronie klienta musimy nadać bit suid
plikowi /usr/sbin/pppd.
# chmod 4755 /usr/sbin/pppd
Na tym kończymy konfiguracj˛e tunelu. Możemy przejść do fazy jego uruchomienia.
Uruchomienie
Skonfigurowane połaczenie
˛
należy teraz zainicjować wykonujac
˛ polecenie:
$ /usr/sbin/pppd call tunel
Udana próba połaczenia
˛
połaczenia
˛
powinna zaowocować zapisami w logach takimi
jak poniżej na listingu.
Sep
Sep
Sep
Sep
Sep
2 12:35:34
2 12:35:34
2 12:35:34
2 12:35:37
2 12:35:37
address for
Sep 2 12:35:37
Sep 2 12:35:37
pldmachine
pldmachine
pldmachine
pldmachine
pldmachine
proxy ARP
pldmachine
pldmachine
pppd[6623]:
pppd[6623]:
pppd[6623]:
pppd[6623]:
pppd[6623]:
pppd 2.4.2b3 started by foo, uid 501
Using interface ppp0
Connect: ppp0 <--> /dev/pts/0
Deflate (15) compression enabled
Cannot determine ethernet \
pppd[6623]: local IP address 192.168.1.101
pppd[6623]: remote IP address 192.168.1.100
Wykonujac
˛ po obu stronach polecenie ifconfig zauważysz, że utworzone zostały interfejsy ppp służace
˛ do komunikacji. Wykorzystamy je do zestawienia prostej trasy
pomi˛edzy dwoma sieciami.
Zakładajac,
˛ że jedna sieć po stronie serwera ma adresacj˛e 192.168.0.0/24 a po stronie
klienta 192.168.2.0/24 routing b˛edzie wygladał
˛
w sposób nast˛epujacy.
˛
Po stronie serwera:
# route add -net 192.168.2.0/24 gw 192.168.1.100
Po stronie klienta:
# route add -net 192.168.0.0/24 gw 192.168.1.101
W ten sposób oba komputery b˛eda˛ przechowywały w swoich tablicach routingu informacje o sieciach połaczonych
˛
dzi˛eki interfejsom tunelu.
VTun - Tunel IPv4
Wstep
˛
VTun umożliwia tworzenie tuneli poprzez sieci TCP/IP wraz z przydzielaniem pasma, kompresja,˛ szyfrowaniem danych w tunelach. Wspierane typy tuneli to: PPP,
IP, Ethernet i wi˛ekszość pozostałych protokołów szeregowych. VTun jest łatwy i elastyczny w konfiguracji. Może zostać wykorzystany do takich sieciowych zastosowań
jak VPN, Mobil IP, łacza
˛
o określonym paśmie oraz innych. Działa w warstwie user
space.
Opis procesu konfiguracji tunelu podzielony został na cz˛eść klient oraz serwer. Adresacja użyta na listingach może zostać użyta o ile nie b˛edzie si˛e ona kłóciła z bieżac
˛ a˛
163
konfiguracja˛ Twojej sieci. Zaczynamy od instalacji pakietu vtun na obu maszynach
b˛edacych
˛
końcami tunelu. Dodatkowo ładujemy moduł tun do pami˛eci.
# modprobe tun
Na tym kończy si˛e wst˛epne przygotowanie systemu do konfiguracji tunelu.
Konfiguracja
Serwer
Po zainstalowaniu pakietu, opcja VTUND_MODE w pliku /etc/sysconfig/vtun powinna być ustawiona tak jak na listingu poniżej
# grep VTUND_MODE /etc/sysconfig/vtun
VTUND_MODE="server"
Plikiem konfiguracyjnym dla VTuna jest /etc/vtund.conf. Po instalacji pakietu jest
on wypełniony przykładami konfiguracji różnego rodzaju tuneli po obu stronach
(klient - serwer). Warto je sobie zostawić. W tym celu wystarczy jedynie zmienić nazw˛e pliku.
# mv /etc/vtund.conf /etc/vtund.conf.orig
Przy użyciu ulubionego edytora stwórzmy nowy plik /etc/vtund.conf. Możemy
w nim wyodr˛ebnić kilka sekcji: options, default, nazwa, up oraz down. Sekcje up
oraz down sa˛ podsekcjami sekcji nazwa.
options - opcje dotyczace
˛ działania demona oraz wykorzystywanych przez niego
programów.
options {
port
5000;
syslog
daemon;
ppp
/usr/sbin/pppd;
ifconfig
/sbin/ifconfig;
route
/sbin/route;
firewall
/sbin/iptables;
ip
/sbin/ip;
}
• port
- port na którym ma nasłuchiwać demon.
• syslog
- sposób logowania zdarzeń na interfejsie tunelu.
- zmienne, które zawieraja˛ ścieżki do wykorzystywanych przez VTun programów.
• ppp ifconfig route firewall ip
default - domyślne ustawienia transmisji danych.
default {
compress yes;
speed 0;
}
• compress
• speed
164
- kompresja pakietów w trakcie transmisji.
- pr˛edkość transmisji. Wartość 0 oznacza brak ograniczeń.
vpn1 - wymieniona wcześniej nazwa tunelu. W tym miejscu znajduje si˛e właściwa
konfiguracja parametrów połaczenia.
˛
vpn1 {
passwd tajne.haslo;
type tun;
proto tcp;
compress zlib:9;
encrypt yes;
keepalive yes;
up {
...
};
down {
...
};
}
• passwd
• type
- hasło, które posłuży do szyfrowania połaczenia.
˛
- typ tunelu (w przykładzie tunel IP)
• proto
- protokół warstwy transmisyjnej tunelu.
• compress
• encrypt
- metoda oraz stopień kompresji.
- właczenie
˛
szyfrowania transmisji.
• keepalive
- utrzymywanie połaczenia
˛
- co ma si˛e wykonać po nawiazaniu
˛
połaczenia
˛
oraz jego zakończeniu.
Szerzej o tym poniżej.
• up, down
up - akcje wykonywane po nawiazaniu
˛
połaczenia.
˛
up {
ifconfig "%% 192.168.2.10 pointopoint 192.168.2.11 mtu 1450";
route "add -host 192.168.2.11 gw 192.168.2.10";
};
Po nawiazaniu
˛
połaczenia
˛
należy uruchomić odpowiedni interfejs. Jego nazwa zostanie rozwiazana
˛
dzi˛eki zmiennej %%. Określamy oczywiście typ interfejsu oraz jego
MTU. Kolejna˛ czynnościa˛ jest podanie trasy do drugiego końca tunelu. Adres IP po
prawej stronie jest oczywiście adresem naszego (czyli serwera) końca i przez niego
prowadzi droga na druga˛ stron˛e.
down - czynności nast˛epujace
˛ po wyłaczeniu
˛
tunelu.
down {
ifconfig "%% down";
ifconfig "%% delete";
route "delete -host 192.168.2.11"
};
Po zakończeniu działania połaczenia
˛
powinniśmy wyłaczyć
˛
oraz skasować interfejs
który nam do niego służył. Usuwamy również zb˛edna˛ tras˛e do drugiego końca tunelu z tablicy routingu. Zwróć uwag˛e na konstrukcj˛e tych dwóch podsekcji. polecenie
"argument". Polecenie zostało określone w sekcji options, natomiast argumentami
sa˛ odpowiednie parametry danego polecenia.
Na tym kończy si˛e konfiguracja serwera. Możemy przystapić
˛
teraz do konfiguracji
klienta.
165
Klient
Konfiguracj˛e klienta zaczniemy od edycji pliku /etc/sysconfig/vtun. Opcje w nim
zawarte powinieneś ustawić zgodnie z tym co jest przedstawione na listingu.
VTUND_MODE="client"
VTUND_SESSION="vpn1"
VTUND_SERVER_ADDR="123.45.67.89"
VTUND_SERVER_PORT="5000"
• VTUND_MODE
- tryb pracy demona.
• VTUND_SESSION
- nazwa sesji, która˛ ustawimy w pliku konfiguracyjnym
• VTUND_SERVER_ADDR
- publiczny adres IP serwera.
• VTUND_SERVER_PORT
- port na którym nasłuchuje serwer.
Również po stronie klienta musimy wyedytować plik /etc/vtund.conf. Także i tutaj możemy mu zmienić nazw˛e na vtund.conf.orig, aby zachować przykłady konfiguracji. Krok po kroku omówi˛e sekcje vtund.conf po stronie klienta.
options {
type stand;
port 5000;
syslog daemon;
timeout 60;
ppp
/usr/sbin/pppd;
ifconfig
/sbin/ifconfig;
route
/sbin/route;
firewall
/sbin/iptables;
ip
/sbin/ip;
}
• type
- tryb pracy VTuna. Na listingu ustawiony został standalone.
• port
- port na którym nasłuchuje VTun.
• syslog
- logi VTuna zbierane b˛eda˛ przez syslog.
• timeout
- timeout VTuna.
• ppp, ifconfig, route, firewall, ip
-
ścieżki
do
programów
wykorzystywanych w czasie konfiguracji.
Przyst˛epujemy teraz do konfiguracji połaczenia
˛
o nazwie vpn1. Jak pami˛etasz nazwa
została już wst˛epnie określona w pliku /etc/sysconfig/vtun.
vpn1 {
passwd tajne.haslo;
type tun;
proto tcp;
compress zlib:9;
encrypt yes;
keepalive yes;
stat yes;
persist yes;
up {
...
};
down {
...
};
}
166
• passwd
• type
- hasło które posłuży nam do szyfrowania połaczenia.
˛
- typ tunelu, w przykładzie jest to tunel IP.
• proto
- protokół warstwy transmisyjnej tunelu.
- typ oraz stopień kompresji. Na listingu ustawiona została kompresja
przy użyciu zlib dziewiatego
˛
stopnia.
• compress
• encrypt
- właczamy
˛
szyfrowanie połaczenia.
˛
• keepalive
- utrzymywanie połaczenia
˛
w przypadku braku ruchu na interfejsie
tunelu.
- statystyki pracy tunelu, które VTun b˛edzie zapisywał do sysloga co pi˛eć
minut.
• stat
- opcja ustawiona tak jak na listingu sprawi, że w przypadku zerwania
połaczenia
˛
z serwerem klient b˛edzie nawiazywał
˛
połaczenie.
˛
• persist
• up, down - programy wykonywane po nawiazaniu
˛
połaczenia
˛
i po jego zerwaniu.
up {
ifconfig "%% 192.168.2.11 pointopoint 192.168.2.10 mtu 1450";
route "add -host 192.168.2.10 gw 192.168.2.11";
};
Poleceniem ifconfig uruchamiamy interfejs naszego tunelu o parametrach takich jakie zostały podane w przykładzie. Nast˛epnym krokiem jest wyznaczenie trasy do
naszego serwera, czyli drugiego końca tunelu. Jak doskonale widać, ta cz˛eść konfiguracji jest analogiczna do serwera. Należy tylko zwrócić uwag˛e na adresacj˛e. Adres
nast˛epujacy
˛ po parametrze gw określa nasz (czyli klienta) koniec tunelu. Przez niego
wiedzie droga na drugi koniec.
down {
ifconfig "%% down";
ifconfig "%% delete";
route "del -host 192.168.2.10";
};
Polecenia które si˛e wykonaja˛ po zamkni˛eciu połaczenia.
˛
Kolejno, wyłaczamy
˛
oraz
kasujemy interfejs tunelu. Nast˛epnie kasujemy z tablicy routingu tras˛e do serwera.
Na tym kończy si˛e etap konfiguracji VTuna. Możemy przejść do jego uruchomienia.
Uruchomienie
Uruchomienie VTuna sprowadza si˛e do wykonania jednego polecenia na serwerze
oraz kliencie.
# /etc/rc.d/init.d/vtund start
Po jego wykonaniu na komputerach b˛edacych
˛
końcami tunelu za kilka chwil powinny si˛e utworzyć interfejsy tun0. Numeracja zaczyna si˛e od "0". Nazwy kolejnych
interfejsów b˛eda˛ kończyć si˛e nast˛epna˛ w kolejności liczba˛ naturalna.˛
Narzedzia
˛
sieciowe
W PLD głównym pakietem narz˛edzi sieciowych jest iproute2, oferuje on wi˛eksze
możliwości oraz bardziej ujednolicony interfejs obsługi w stosunku do narz˛edzi z
pakietu net-tools (ifconfig, route, arp, ifup, ifdown). Sercem pakietu iproute2 jest
167
program ip zawierajacy
˛ funkcjonalność kilku starszych narz˛edzi w jednym. Z tego
wzgl˛edu b˛edzie naszym podstawowym narz˛edziem sieciowym.
Jako dodatek do niniejszego rozdziału, pragn˛e polecić lektur˛e opisu najprostszych
narz˛edzi sieciowych (ping, traceroute), który można znaleźć w sekcja Podstawowe
narz˛edzia kontroli sieci TCP/IP w Rozdział 7 oraz opis zarzadzania
˛
routingiem statycznym zamieszczony w sekcja Routing statyczny.
Konfiguracja interfejsow
Aby wyświetlić konfiguracj˛e interfejsów użyjemy polecenia ip addr.
# ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:50:8d:e1:e8:83 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global eth0
inet 10.0.0.22/24 brd 10.0.0.255 scope global secondary eth0
inet6 fe80::250:8dff:fee1:e883/64 scope link
valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
Polecenie wyświetliło list˛e dost˛epnych interfejsów, każdy z nich oznaczony jest numerem porzadkowym.
˛
W wi˛ekszości wypadków najbardziej interesujace
˛ sa˛ dla nas
interfejsy fizyczne (eth0 na powyższym przykładzie). Interfejsy lo oraz sit0, sa˛ "wirtualnymi" interfejsami, pierwszy z nich to interfejs p˛etli zwrotnej (loopback), drugi
służy do tunelowania protokołu IPv6 wewnatrz
˛ IPv4.
Tryb pracy urzadzenia
˛
jest wyświetlany wewnatrz
˛ trójkatnych
˛
nawiasów, oto kilka
oznaczeń:
•
UP - urzadzenie
˛
działa
•
LOOPBACK - interfejs p˛etli zwrotnej
•
BROADCAST - urzadzenie
˛
ma możliwość wysyłania komunikatów rozgłoszeniowych
•
MULTICAST - interfejs może być używany do transmisji typu multicast
•
PROMISC - tryb nasłuchiwania, używany przez monitory sieci i sniffery
•
NO-CARRIER - brak nośnej, komunikat spotykany zwykle w wypadku braku fizycznego połaczenia
˛
z siecia˛
Poniżej omawianego wiersza wyświetlone zostały informacje o adresach zwiazanych
˛
z urzadzeniem
˛
(adresy IP i maski podsieci sa˛ przedstawione w notacji CIDR):
168
•
-link/ether - adres fizyczny karty sieciowej (MAC)
•
-inet - dane protokołu IPv4
•
-inet6 - dane protokołu IPv6
Zarzadzanie
˛
interfejsami
Do najcz˛estszych operacji tego typu należy właczanie
˛
i wyłaczanie
˛
interfejsów, w
tym celu użyjemy nast˛epujacego
˛
polecenia:
ip link set {$interfejs} {up/down}
# ip link set eth0 up
# ip link set eth0 down
Dodawanie/usuwanie adresów IP interfejsu:
ip addr {add/del} {$adresIP}/{$maska} dev {$interfejs}
# ip addr add 10.1.1.1/24 dev eth0
# ip addr del 10.1.1.1/24 dev eth0
Adresy sprzetowe
˛
(MAC)
Do odczytania adresu sprz˛etowego lokalnych kart sieciowych możemy użyć opisanego wcześniej polecenia ip addr. Aby odczytać MAC zdalnej maszyny użyjemy
programu arping {$nazwa/$IP} np.:
# arping 10.0.0.100
ARPING 10.0.0.100 from 10.0.0.1 eth0
Unicast reply from 10.0.0.100 [00:04:ED:07:25:F8]
4.250ms
0.976ms
0.929ms
Dowolny adres MAC karty sieciowej ustawimy poleceniem:
ip link set {$interfejs} address {$MAC-adres}
# ip link set eth0 address 01:01:01:01:01:01
Aby adres sprz˛etowy za każdym razem był ustawiany dla interfejsu,
powinniśmy dokonać odpowiedniego wpisu w pliku konfiguracyjnym
interfejsu. W przypadku urzadzenia
˛
eth0 musimy zmodyfikować plik
/etc/sysconfig/interfaces/ifcfg-eth0, i dodać zmienna˛ MACADDR np.:
MACADDR="01:01:01:01:01:01"
ARP
Aby wyświetlić tablic˛e ARP należy użyć polecenia ip neighbour:
# ip neighbour
10.0.0.140
10.0.0.2
10.0.0.100
ether
ether
ether
00:E0:7D:A1:8B:E2
4C:00:10:54:19:50
00:04:ED:07:25:F8
C
C
C
eth0
eth0
eth0
Tablica ARP wypełnia si˛e w miar˛e komunikowania si˛e z innymi hostami, aby wymusić zbadanie działania protokołu ARP wystarczy zainicjować komunikacj˛e. Możemy
użyć do tego programu ping.
169
Możemy stworzyć własna,˛ statyczna˛ tablic˛e ARP, posłuży nam do tego plik
/etc/sysconfig/static-arp w którym umieszczamy wpisy zawierajace
˛ kolejno:
interfejs, adres MAC, adres IP oraz status wpisu.
eth0 00:80:48:12:c2:3c 192.168.10.10 permanent
eth0 00:c0:df:f9:4e:ac 10.0.0.7 permanent
Opcja permanent oznacza, że wpis nigdy nie wygasa.
Serwery nazw (DNS)
Do odpytywania serwerów DNS możemy użyć programu host z pakietu bind-utils.
Pozwala na szybkie sprawdzenie poprawności konfiguracji domeny (strefy).
host {$nazwa/$IP} {$dns_nazwa/$dns_IP}
Pierwszy parametr to nazwa domeny lub IP maszyny, drugi parametr nie jest obowiazkowy
˛
- wskazuje na serwer nazw, który chcemy odpytać. Jeśli nie podamy drugiego parametru użyty zostanie serwer zdefiniowany w pliku /etc/resolv.conf.
Odpytanie serwera DNS o domen˛e, wpisanego do pliku /etc/resolv.conf
$ host pld-linux.org
pld-linux.org has address 217.149.246.8
Odpytanie o adres IP (odwzorowanie odwrotne)
$ host 217.149.246.8
8.246.149.217.in-addr.arpa domain name pointer webmachine.pld-linux.org.
Odpytanie dowolnego serwera DNS
$ host pld-linux.org ns4.pld-linux.org.
Using domain server:
Name: ns4.pld-linux.org.
Address: 217.149.246.7#53
Aliases:
pld-linux.org has address 217.149.246.8
Aby odczytać konkretny rekord domeny użyjemy parametru "-t". Dla przykładu
spróbujemy określić rekord MX dla domeny pld-linux.org:
$ host -t mx pld-linux.org
pld-linux.org mail is handled by 0 a.mx.pld-linux.org.
W celu poznania szczegółów zarejestrowanej domeny (np. obsługujace
˛ ja˛ serwery
nazw) możemy posłużyć si˛e programem whois:
$ whois pld-linux.org
Wydajność sieci
Aby sprawdzić przepustowość sieci pomi˛edzy dwoma hostami możemy użyć programu iperf. Jest to program typu klient-serwer sprawdzajacy
˛ na kilka sposobów
170
przepustowość połaczenia.
˛
Rozpoczynamy od instalacji programu na obu interesujacych
˛
nas maszynach, nast˛epnie na jednej z maszyn uruchamiamy program w trybie
serwera:
$ iperf -s
a na drugiej w trybie klienta - iperf -c {$adres_serwera} np.:
$ iperf -c 192.168.0.5
Po chwili odczytujemy wyniki testu.
Monitorowanie sieci
Nawiazane
˛
połaczenia
˛
i otwarte porty protokołu TCP/IP możemy kontrolować za
pomoca˛ programu netstat np.:
# netstat -tua
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address
Foreign Address
tcp
0
0 *:blackjack
*:*
tcp
0
0 *:ircs
*:*
tcp
0
0 *:netbios-ssn
*:*
tcp
0
0 *:ipp
*:*
tcp
0
0 *:microsoft-ds
*:*
tcp
0
0 gargamel:ircs
192.168.1.3:rapidmq-reg
tcp
0
0 gargamel:imaps
192.168.1.6:ttc-etap-ds
tcp
0
0 gargamel:td-postman
host-92.gadugadu.p:8074
tcp
0
0 gargamel:cma
chrome.pl:5223
tcp
0
0 *:1024
*:*
udp
0
0 gargamel:netbios-ns
*:*
udp
0
0 *:netbios-ns
*:*
udp
0
0 *:ipp
*:*
State
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
LISTEN
Na powyższym przykładzie zostały wyświetlone dane dotyczace
˛ protokołu TCP
(opcja: -t) oraz UDP (-u). Dodatkowo zostały wyświetlone gniazda nasłuchujace
˛
(-a). Warte uwagi sa˛ jeszcze dwa parametry: -n i -p, pierwszy wyświetla porty i
adresy w postaci liczb, drugi zaś wyświetla nazwy programów korzystajacych
˛
z danych gniazd.
Do analizowania wielkości ruchu sieciowego na interfejsie polecam program nload,
jest to proste narz˛edzie rysujace
˛ wykresy pomoca˛ znaków ASCII. Podstawowe statystyki możemy przegladać
˛
dzi˛eki programowi ip np. ip -s link, dokładniejsze dane
otrzymamy dzi˛eki programowi iptraf.
Wygodnym sposobem śledzenia wybranego ruchu sieciowego jest użycie regułek
linuksowego filtra pakietów. Do śledzenia ruchu służy cel "-j LOG" np.:
# iptables -A INPUT -p TCP --dport 80
-s 10.0.0.3 -j LOG
Powyższy wpis doda do łańcucha INPUT regułk˛e rejestrujac
˛ a˛ połaczenia
˛
TCP z hosta
10.0.0.3 na port 80 danej maszyny. Aby te regułki działały z wpisami odrzucajacymi
˛
pakiety (DROP/REJECT) musza˛ być analizowane wcześniej, w przeciwnym wypadku pakiet nigdy nie dotrze do regułki rejestrujacej.
˛
W przypadku dopasowania pakietu do regułki nast˛epuje odnotowanie tego zdarzenia, wpisy te można odczytywać
za pomoca˛ programu dmesg, lub z plików syslog-a - zwykle z /var/log/kernel i
/var/log/messages.
Dużo bardziej szczegółowe informacje o ruchu sieciowym otrzymamy dzi˛eki programowi tcpdump, jest to rozbudowany sniffer i program do analizy pakietów.
171
Zakończenie
W przypadku modyfikacji plików konfiguracji w wi˛ekszości wypadków trzeba dokonać restartu podsystemu sieci.
W tym rozdziale opisano niewielki fragment możliwości dost˛epnych narz˛edzi sieciowych. Poniższa lista przedstawia miejsca gdzie można znaleźć szerszy opis niektórych zagadnień.
•
NET-3-HOWTO z http://www.jtz.org.pl/
•
Zaawansowany routing: http://echelon.pl/pubs/NET4.pdf3
•
Dokumentacja iproute2 http://www.policyrouting.org/iproute2-toc.html4
•
http://linux-ip.net/5
Przypisy
1. http://www.netfilter.org/documentation/HOWTO/pl/packet-filteringHOWTO.html
2. http://www.jtz.org.pl/
3. http://echelon.pl/pubs/NET4.pdf
4. http://www.policyrouting.org/iproute2-toc.html
5. http://linux-ip.net/
172
Rozdział 17. Usługi dostepne
˛
w PLD
W rozdziale tym przedstawimy opis instalacji i konfiguracji ważniejszych usług dost˛epnych w PLD
Usługi - wstep
˛
Usługi w PLD sa˛ przygotowane do natychmiastowego uruchomienia, wystarczy wyedytować pliki konfiguracji i można korzystać z programu. Zanim jednak zaczniemy
pracować z usługami warto zapoznać si˛e z opisem zarzadzania
˛
usługami zawartym
w sekcja Zarzadzanie
˛
podsystemami i usługami w Rozdział 14.
Z wieloma demonami dostarczane sa˛ przykładowe pliki konfiguracji, którymi możemy si˛e sugerować przy konfigurowaniu aplikacji, przykłady te sa˛ umieszczane w
dokumentacji programu, w katalogu /usr/share/doc. Ponadto, zanim uruchomimy usług˛e, powinniśmy przyjrzeć si˛e konfiguracji startowej demona, która umieszczana jest w pliku konfiguracji rc-skryptu - plik ten przychodzi wraz z pakietem i
umieszczany jest w katalogu /etc/sysconfig. Zwykle zamieszczone w nim opcje
odpowiadaja˛ argumentom programu demona, sa˛ też opcje określajace
˛ np. priorytet
programu i inne właściwości.
W trakcie uruchamiania usługi zdarzaja˛ si˛e trudne do odnalezienia problemy. Pierwsza˛ rzecza˛ jaka˛ powinniśmy w takim wypadku zrobić to przeczesać logi programu,
w takich wypadkach niejednokrotnie pomaga właczenie
˛
wi˛ekszej "gadatliwości" demona. Wygodnym sposobem szukania bł˛edów jest uruchomienie demona na pierwszym planie (bez przejścia w tło), w takich wypadkach cz˛esto demony wysyłaja˛ komunikaty na standardowe wyjście. W trudniejszych przypadkach b˛edziemy zmuszeni użycia programu strace w celu śledzenia wywołań systemowych aplikacji. W wypadku demonów powinniśmy użyć opcji -f, aby śledzić również procesy potomne
lub uruchomić demona z wyłaczonym
˛
forkowaniem procesów. Opisane tu czynności sa˛ specyficzne dla każdego z demonów, zatem musimy skorzystać z dokumentacji
właściwej aplikacji.
Aktualizacja niektórych demonów wia˛że si˛e z pewnymi czynnościami przygotowawczymi i poprawkami, problem ten dotyczy szczególnie silników baz danych.
Zanim bezmyślnie zaktualizujemy pakiet, należy dokładnie zapoznać si˛e z dokumentacja˛ produktu, aby uchronić si˛e przed unieruchomieniem usługi na dobre.
W PLD usługi, podobnie jak inne oprogramowanie, kompilowane jest z najcz˛eściej
używanymi opcjami, jeśli program nie obsługuje jakichś funkcji, to powinniśmy
sprawdzić czy uzyskamy je samodzielnie budujac
˛ pakiet, wi˛ecej na ten temat
odnajdziemy w sekcja Budowanie pakietów w Rozdział 9.
ALSA - Dźwiek
˛ w Linuksie
Obecnie w Linuksie do obsługi dźwi˛eku stosuje si˛e system ALSA (ang: Advanced Linux Sound Architecture), b˛edacy
˛ nast˛epca˛ systemu OSS. ALSA to zestaw modułów
jadra
˛
oraz kilku narz˛edzi pomocniczych, moduły możemy ładować za pomoca˛ systemu UDEV lub statycznie, obydwie metody b˛eda˛ opisane w tym rozdziale. Druga
z metod jest bardziej złożona, dlatego poczatkuj
˛
acych
˛
zach˛ecamy do korzystania z
metody opartej o system UDEV.
Instalacja
Zaczynamy od pakietu zawierajacego
˛
moduły kernela:
$ poldek -i kernel-sound-alsa
Potrzebujemy jeszcze kilku narz˛edzi, w tym programu do zarzadzania
˛
mikserem:
173
Rozdział 17. Usługi dost˛epne w PLD
$ poldek -i alsa-utils
W ogóle nie należy instalować pakietu kernel-sound-oss, ALSA potrafi emulować OSS.
Konfiguracja z użyciem systemu UDEV
Niezaawansowanym zalecamy użycie udeva zamiast statycznej konfiguracji (opisanej dalej), ze wzgl˛edu na łatwiejsza˛ konfiguracj˛e. Zakładam, że w systemie mamy
działajacy
˛ UDEV, instalujemy pakiet z rc-skryptem, koniecznym do zapisywania stanu miksera (inicjacja miksera jest wykonywana bezpośrednio przez UDEV):
$ poldek -i alsa-udev
i uruchamiamy go
# /etc/init.d/alsa-udev start
Nie należy sie martwić, że nic si˛e nie wyświetla po jego uruchomieniu, parametr
start nic nie robi. Najprawdopodobniej mamy już załadowane właściwe moduły i
jedyne co pozostaje nam to w mikserze ustawić głośność i wyłaczyć
˛
wyciszenie, co
zostało opisane w dalszej cz˛eści rozdziału. Wi˛ecej o systemie UDEV w sekcja Udev dynamiczna obsługa sprz˛etu w Rozdział 11.
Konfiguracja statyczna
Konfiguracja statyczna jest alternatywna˛ metoda˛ w stosunku do powyższej. Zaczynamy od zainstalowania pakietu alsa-utils-init:
$ poldek -i alsa-utils-init
Teraz
musimy
postarać
si˛e
o
dodanie
koniecznych
aliasów
do
pliku
/etc/modprobe.conf, które posłuża˛ do załadowania koniecznych modułów, przez
zainstalowany przed chwila˛ rc-skrypt. Możemy wykonać to na dwa sposoby:
•
samodzielnie - za pomoca˛ dowolnego edytora tekstu; wpisy możemy skopiować
z opisu Driver & Docs, urzadzenia
˛
odnalezionego na liście obsługiwanego
sprz˛etu1
•
za pomoca˛ programu alsaconf, który wykryje urzadzenie
˛
i dokona koniecznych
wpisów
Pierwsza z metod jest tak oczywista, że zajmiemy si˛e tylko druga˛ z wymienionych.
Na poczatek
˛
musimy si˛e upewnić, że mamy pakiet pciutils i uruchamiamy program:
# /usr/sbin/alsaconf
Po ukazaniu si˛e ekranu z napisem "Searching sound cards" czekamy ok. 10 sekund i
wciskamy ctrl-c (konfigurator szybko znajduje nasza˛ właściwa˛ kart˛e - a ponieważ
szuka również kart starego typu oraz różnych egzotycznych, co zajmuje mu bardzo
dużo czasu dlatego przerywamy wyszukiwanie). Nast˛epne okno pokazuje nam list˛e
znalezionych kart muzycznych (zwykle jedna).
˛ Zatwierdzamy wyświetlona˛ kart˛e i
na pytanie:
Do you want to modify /etc/modprobe.conf?
Odpowiadamy twierdzaco,
˛
spowoduje to dopisanie odpowiednich aliasów modułów do pliku konfigurujacego.
˛
Kiedy progam zakończy działanie, uruchamiamy rcskrypt:
174
# /etc/init.d/alsasound start
Teraz pozostaje nam ustawić głośność w mikserze oraz wyłaczyć
˛
wyciszenie.
Ustawienie miksera i testowanie
Domyślnie wszystkie "suwaki" miksera sa˛ ustawione na zero i dodatkowo właczo˛
ne jest wyciszenie (mute), aby to zmienić musimy uruchomić program alsamixer lub
amixer:
# /usr/bin/alsamixer
Wyłaczmy
˛
mute (klawisz m) i przesuwamy "suwaki" (strzałkami) kanału Master i
PCM. Teraz możemy przetestować ustawienia z poziomu root-a, możemy to zrobić
odsłuchujac
˛ dowolny plik wav (np. z pakietu gnome-audio):
# /usr/bin/aplay test.wav
lub plik mp3 (wymagany pakiet "alsaplayer" oraz "alsaplayer-input-mad"):
# /usr/bin/alsaplayer -o alsa test.mp3
To już praktycznie koniec instalacji. Pami˛etać należy, że do niektórych programów
należy doczytać odpowiednie wtyczki, które umożliwia˛ prace z ALSA-a.˛ Wtyczki te
łatwo rozpoznać po dopisce "alsa" w nazwie pakietu.
Na koniec pozostaje nam nadać uprawnienia wybranym użytkownikom, do obsługi
dźwi˛eku. Musimy zapisać użytkowników do grupy audio np.:
# usermod -A jkowalski audio
Wi˛ecej o uprawnieniach w sekcja Grupy w Rozdział 14.
Zaawansowana obsługa miksera
W wielu przypadkach okazuje si˛e, że posiadamy kart˛e muzyczna,˛ która nie potrafi
miksować dźwi˛eku sprz˛etowo - co powoduje m.in., że jednocześnie może z karty korzystać jeden program lub proces. Zdarza si˛e także, że niektóre programy na sztywno
próbuja˛ połaczyć
˛
si˛e np. z OSS w celu obsługi dźwi˛eku (np. Skype). W takim przypadku możemy skorzystać z wtyczki ALSA-y o nazwie dmix. Wbrew nazwie nie musimy niczego dogrywać - wszystko odbywa si˛e w plikach tekstowych: /etc/asound
(gdy chcemy ustawień globalnych) lub ~/.asoundrc (czyli indywidualnych ustawień dla każdego użytkownika). Przykładowy wpis przedstawimy poniżej - po wi˛ecej szczegółów odsyłamy na strony projektu ALSA (www.alsa-project.org2):
# definiujemy urzadzenie
˛
wirtualne nazwane przez nas demixer
# do którego później b˛
edziemy si˛
e odwoływać:
pcm.demixer
{
type dmix
# typ urzadzenia,
˛
tutaj "dmix"
ipc_key 1024
# numer musi być unikalny
slave {
pcm "hw:0,0"
# you cannot use a "plug" device here, darn.
period_time 0
buffer_time 0
period_size 1024 # must be power of 2 and much smoother
# than 1024/8192!
buffer_size 8196 # must be power of 2 and for Audiophile
# card (ICE1712 chip) or a VIA VT82xx
# (snd-via82xx) must be less 6652
#format "S32_LE"
175
periods 128
rate 44100 # with rate 44100 Hz you *will* hear,
# if demixer is used
}
# bindings are cool. This says, that only the first
# two channels are to be used by dmix, which is enough for
# (most) oss apps and also lets multichannel chios work
# much faster:
#
# Wskazujemy że tylko dwa pierwsze kanały beda˛ używane
# przez demixer (czyli tutaj dmix)
bindings {
0 0 # from 0 => to 0
1 1 # from 1 => to 1
}
} # koniec konfiguracji wirtualnego urzadzenia
˛
demixer
# nast˛
epnie ustawiamy przekierowanie z wybranych
# urzadzeń
˛
do wirtualnego urzadzenia
˛
demixer:
# możemy przekierowywać z nast˛
epujacych
˛
urzadzeń
˛
OSS:
#
/dev/audio
#
/dev/dsp
#
/dev/dspW
#
/dev/midi
#
/dev/mixer
#
/dev/music
#
/dev/sequencer (recording doesn’t work yet)
#
/dev/sequencer2
# dla /dev/dsp0
pcm.dsp0 {
type plug
slave.pcm "demixer"
}
# dla /dev/dsp
pcm.dsp {
type plug
slave.pcm "demixer"
}
#
#
#
#
#
#
Software mixing for all aplications
uses ALSA "default" device
Wszystkie aplikacje korzystajace
˛
z urzadzenia
˛
default ALSA-y przekierowujemy do miksera
czyli wszystko przechodzi przez dmix
pcm.!default {
type plug
slave.pcm "demixer"
}
# OSS device /dev/mixer0 use hardware
# Urzadzenie
˛
OSS /dev/mixer0 bez zmian
# obsługuje pierwsza˛ (0) kart˛
e audio bezpośrednio
ctl.mixer0 {
type hw
card 0
}
Jeśli chcemy jedynie przekierować dźwi˛ek z programów obsługujacych
˛
tylko OSS
do ALSA, bez programowego miksowania (czyli bez używania dmix) wystarczy że
wpiszemy tylko:
176
# from /dev/dsp0 to ALSA
pcm.dsp0 {
type plug
slave.pcm "hw:0"
}
# lub:
# pcm.dsp0 pcm.default
# jeśli "default" nie było redefiniowane
ctl.mixer0 {
type hw
card 0
}
Natomiast najprostsze przekierowanie z /dev/dsp0 do dmix wyglada
˛ tak:
pcm.dsp0 {
type plug
slave.pcm "dmix"
}
Dla chipsetów nvidia nforce(2) (intel8x0) oraz C-media konfiguracja powinna wygla˛
dać na przykład tak:
pcm.nforce-hw {
type hw
card 0
}
pcm.!default {
type plug
slave.pcm "nforce"
}
pcm.nforce {
type dmix
ipc_key 1234
slave {
pcm "hw:0,0"
period_time 0
period_size 1024
buffer_size 4096
#rate 44100
rate 48000
}
}
ctl.nforce-hw {
type hw
card 0
}
Nast˛epnie możemy przetestować nasz "dmix" czyli urzadzenie
˛
demixer
alsaplayer -o alsa -d demixer test.mp3
ponieważ wcześniej zdefiniowaliśmy urzadzenie
˛
"default", ALSA kieruje wszystko
na urzadzenie
˛
"demixer" - co jest równoważne:
alsaplayer -o alsa test.mp3
To tylko podstawowe przykłady działania jakie daje nam ALSA, a
dzi˛eki
olbrzymim
możliwościom
definiowania
dowolnych
urzadze
˛
ń
wirtualnych i przekierowywania dźwi˛eku, możemy uzyskać ciekawe i
różnorodne efekty. Wi˛ecej o konfiguracji urzadze
˛
ń PCM znajdziemy tutaj:
www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html3.
177
Przy pracy z pluginem "dmix" nie należy zapomnieć o wyłaczeniu
˛
demonów ARTs i
ESD gdyż w przeciwnym razie moga˛ pojawić si˛e opóźnienie w odtwarzaniu dźwi˛eków i zakłócenia w niektórych programach, gdyż wiele z nich próbuje najpierw korzystać z w/w demonów dźwi˛eku.
Uwagi
Wi˛ecej o dźwi˛eku pod Linuksem na stronie linux-muzyka.ixion.pl/4.
Apache - Serwer stron internetowych
Wstep
˛
Każdy, nawet poczatkuj
˛
acy
˛ użytkownik sieci internet zetknał
˛ si˛e z apaczem świadomie lub nie. Apache jest oprogramowaniem, które można powiedzieć zdominowało
w pewnym stopniu rynek aplikacji serwerowych. Do działania wykorzystuje on protokół HTTP (RFC26165). Jak sama nazwa wskazuje Apache (a patche server) składa
si˛e z wielu modułów. Można to zauważyć już na pierwszy rzut oka. W tym rozdziale
zostanie opisana autoryzacja, obsługa j˛ezyka PHP, CGI, virtualhosts oraz ogólna jego
konfiguracja. Przedstawiona poniżej oparta została o apache z serii 2.x.
Instalacja
Apache w PLD jest podzielony na wiele małych pakietów, możemy dzi˛eki instalować
tylko potrzebne moduły. Jeśli nie możemy si˛e połapać w tym gaszczu
˛
to możemy
posłużyć si˛e metapakietem apache, który za pośrednictwem mechanizmu zależności
zainstaluje najważniejsze pakiety.
# poldek -i apache
Kiedy b˛edziemy mieli zainstalowane wymagane pakiety, b˛edziemy mogli wst˛epnie
przetestować serwer, zatem uruchomimy usług˛e:
# service httpd start
W katalogu /home/services/httpd umieszczamy jakaś
˛ testowa˛ stron˛e WWW która˛
nazwiemy np. test.html i sprawdzamy za pomoca˛ przegladarki
˛
czy si˛e prawidłowo
wyświetla:
$ elinks localhost/test.html
Jeśli wszystko jest w porzadku,
˛
to możemy przejść do właściwej konfiguracji serwera.
Pliki konfiguracji
Tytułem wst˛epu pragn˛e powiedzieć, że niniejszy dokument nie może być traktowany jako dokumentacja do Apache. Ma on na celu ułatwienie użytkownikowi zapoznania si˛e z usługa˛ oraz kilkoma jej możliwościami. Po bardziej szczegółowe informacje odsyłam do stron podr˛ecznika systemowego (man) oraz dokumentacji on-line6
- w tym katalogu przechowywane sa˛ pliki konfiguracyjne demona. Po instalacji poszczególnych składników Apache, właśnie w tym
miejscu należy szukać plików konfiguracyjnych od nich.
• /etc/httpd/httpd.conf
178
• /home/services/httpd - pliki domyślnej strony Apache, katalog z komunikatami
o bł˛edach oraz katalog przeznaczony dla skryptów cgi.
- moduły potrzebne do działania Apache oraz poszczególnych
jego składników. Warto o tym pami˛etać w przypadku problemów z uruchomieniem usługi.
• /usr/lib/apache
- jest to katalog należacy
˛ stricte do Apache, jednak warto o nim
wspomnieć ze wzgl˛edu na to iż przechowywane sa˛ w nim jego binaria. Aby si˛e
dowiedzieć które należa˛ do niego wydaj nast˛epujace
˛ polecenie
• /usr/sbin
# rpm -ql apache |grep ^\/usr\/sbin
Aby nasz serwer obsługiwał dodatkowe funkcje musimy zainstalować odpowiednie
moduły, wraz z modułami dostarczane, sa˛ pliki konfiguracji z dyrektywami konfiguracyjnymi dla tego modułu.
Apache domyślnie działa z uprawnieniami zwykłego użytkownika (http), dlatego
trzeba zadbać o to by demon miał prawo do odczytu plików ze stronami WWW.
Bardzo pożyteczna˛ cecha˛ Apache jest możliwość tworzenia lokalnych plików konfiguracji, dzi˛eki którym możemy modyfikować niektóre opcje konfiguracji. Pliki te
maja˛ nazw˛e .htaccess i może ich używać każdy, kto ma tylko dost˛ep do katalogu
ze strona˛ WWW. Wygoda w ich używaniu polega na tym, że nie ma potrzeby restartowania demona po każdorazowej ich modyfikacji.
Głównym plikiem konfiguracyjnym jest /etc/httpd/apache.conf. Spośród wielu
opcji w tym pliku zajmiemy si˛e dwiema podstawowymi:
ServerAdmin [email protected]
Powinieneś tutaj wpisać kontaktowy adres e-mail do siebie jako administratora tego
serwera.
Poniżej znajduje si˛e opcja ServerName. Powinna ona wygladać
˛
tak jak w poniższym
przykładzie.
ServerName example.net:80
Dosłownie jest to nazwa tego serwera. A dokładniej nazwa domenowa skonfigurowana na serwerze nazw opiekujacym
˛
si˛e Twoja˛ domena.˛ Jeżeli nie posiadasz zarejestrowanej domeny, powinieneś wpisać tutaj adres IP.
Teraz
zajmiemy
si˛e
opcja˛
DocumentRoot,
która˛
odnajdziemy
w
/etc/httpd/conf.d/10_common.conf Określa ona domyślny katalog w którym
b˛edzie przechowywana strona internetowa. Wpisujac
˛ nazw˛e lub adres IP określony
przez ServerName właśnie z tego katalogu zostana˛ pobrane i wczytane przez
przegladark˛
˛
e pliki strony.
DocumentRoot "/home/services/httpd/html"
Domyślnie wszystkie żadania
˛
sa˛ tutaj skierowane. Ta lokalizacja nie jest obligatoryjna, wi˛ec nie musisz si˛e jej trzymać. Może zostać zmieniona przy użyciu dowiaza
˛ ń
symbolicznych lub aliasów wskazujacych
˛
w inne miejsca.
Zgodnie z obecnym standardem tworzenia stron internetowych, domyślnym
plikiem który jest automatycznie wczytywany po wpisaniu w przegladarce
˛
adresu jest index, który w zależności od konstrukcji strony może mieć różne
rozszerzenia. A wi˛ec skad
˛ Apache wie, co ma zostać wczytane jako pierwsze? Do
tego właśnie służy pakiet apache-mod_dir. Jego plikiem konfiguracyjnym jest
/etc/httpd/httpd.conf/59_mod_dir.conf
179
Poprzez dyrektyw˛e DirectoryIndex określa si˛e czego i w jakiej kolejności ma szukać
przegladarka.
˛
DirectoryIndex index.html index.html.var index.htm index.shtml \
index.cgi index.php
Oczywiście możemy podawać tutaj różne nazwy plików startowych stron w zależności od naszych potrzeb.
Strony użytkowników
Swobodne publikowanie stron internetowych przez użytkowników jest
możliwe dzi˛eki pakietowi apache-mod_userdir. Opcja UserDir w pliku
16_mod_userdir.conf definiuje nazw˛e katalogu przechowujacego
˛
strony
użytkowników wewnatrz
˛ ich katalogów domowych.
UserDir public_html
Przykład:
Użytkownik
Jan
Kowalski
posiada
konto
o
nazwie:
jan.
W
/home/users/jan jest jego katalog domowy. Swoja˛ stron˛e internetowa˛ umieszcza w
katalogu /home/users/jan/public_html, zaś dost˛ep do nie uzyskuje za pomoca˛
adresu http://example.net/~jan.
Aby strona si˛e wyświetliła należy ustawić odpowiednie prawa dost˛epu - tak by Apache (domyślnie z prawami użytkownika http) miał prawo do odczytu. Katalog domowy jan powinien mieć ustawione prawa 711. Katalog przechowujacy
˛ jego stron˛e
czyli public_html powinien mieć 755. Każdy katalog zawierajacy
˛ elementy strony
powinien mieć również uprawnienia 755. Pliki strony natomiast 644.
Virtual Hosts
Mechanizm hostów wirtualnych pozwala obsługiwać strony o różnych adresach domenowych na jednej maszynie. Mechanizm ten jest realizowany na dwa sposoby:
hosty oparte o adresy IP oraz oparte o nazwy, pierwsza z metod wymaga osobnego
adresu IP dla każdego wirtualnego hosta, drugi zaś korzysta z jednego. Z oczywistych wzgl˛edów dużo bardziej popularna jest druga z metod i właśnie ja˛ b˛edziemy
opisywać.
Obsługa hostów wirtualnych jest zwiazana
˛
z odpowiednia˛ konfiguracja˛ domen w
systemie DNS - wymaga wpisów typu IN A wskazujacych
˛
na nasz serwer WWW.
Konfiguracj˛e serwera DNS opisano w sekcja BIND - Serwer Nazw i b˛edzie docelowo
konieczna, jednak dla potrzeb testowych wystarcza˛ nam wpisy w pliku /etc/hosts,
który z kolei został opisany w sekcja Podstawowa konfiguracja sieci w Rozdział 15.
W naszym przykładzie dodamy obsług˛e domeny moja-strona.com, na poczatku
˛
należy stworzyć dodatkowy plik konfiguracji (dla porzadku)
˛
o nazwie np. vhosts.conf,
który umieścimy w katalogu /etc/httpd/httpd.conf/. Zakładamy, że wszystkie
vhosty b˛edziemy trzymać w katalogu /home/services/httpd/vhosts/. Plik b˛edzie
si˛e zaczynał od nast˛epujacego
˛
zestawu opcji:
NameVirtualHost *
<Directory /home/services/httpd/vhosts>
Order allow,deny
Allow from all
</Directory>
<VirtualHost _default_>
DocumentRoot /home/services/httpd/html/
</VirtualHost>
Opcja NameVirtualHost wskazuje, które adresy IP serwera maja˛ być używane do
obsługi hostów witrualnych, w tym wypadku wszystkie, co jest najcz˛eściej spoty180
kana˛ konfiguracja.˛ Sekcja Directory zezwala na dost˛ep do plików ze wskazanego
katalogu. Pierwszy zdefiniowany virtualhost (_default_) ma za zadanie wskazanie
serwerowi domyślnej strony, wyświetlanej w wypadku jeśli jakiś vhost nie jest skonfigurowany na naszym serwerze, w przeciwnym razie wyświetli si˛e strona pierwszego w kolejności vhosta. Teraz możemy dodawać vhosty, wg. przykładu:
<VirtualHost *>
ServerName moja-strona.com
DocumentRoot /home/services/httpd/vhosts/moja_strona
</VirtualHost>
Wewnatrz
˛ sekcji VirtualHost znajduje si˛e opcja ServerName, mówiaca
˛ o nazwie domenowej vhosta, a poniżej wskazanie sa˛ ścieżki do katalogu z plikami strony. Po
uruchomieniu mechanizmu hostów wirtualnych całkowicie bezużyteczne stana˛ si˛e
globalne opcje ServerName czy DocumentRoot, od tej pory konfiguracja w całości
opiera si˛e o vhosty. W konfiguracji hostów wirtualnych możemy umieszczać wiele
opcji używanych w głównym serwerze (np.: ServerAdmin, ErrorLog), tak zdefiniowane opcje przesłonia˛ globalne wartości.
Istnieje możliwość masowego konfigurowania vhostów, bez konieczności tworzenia
wpisów dla każdego po kolei, służy do tego moduł vhost-alias dostarczany wraz z
pakietem apache-mod_vhost_alias. Jego opis wykracza poza ramy tego rozdziału,
wi˛ecej na jego temat odnajdziemy w dokumentacji serwera7.
Ograniczanie dostepu
˛
na podstawie adresu
Czasami chcemy ograniczyć możliwość przegladania
˛
stron dla konkretnych adresów
lub klas adresowych. W tym celu użyjemy modułu apache-mod_authz_host, dzi˛eki niemu b˛edziemy mogli chronić przed dost˛epem do wskazanych katalogów. Jeżeli
potrzebujesz chronić jedynie jeden lub kilka plików, stwórz w obr˛ebie strony katalog
o dowolnej nazwie i umieść je w nim. Oczywiście musisz pami˛etać o przekonstruowaniu linków na stronie.
Do konfiguracji Apache dodajemy podobna˛ konstrukcj˛e konstrukcj˛e:
<Directory "/home/users/jan/public_html/intra">
Order allow,deny
Allow from 123.45.0.0/255.255.0.0
Allow from 56.67.9.34
</Directory>
Dost˛ep do katalogu intra maja˛ wszystkie komputery z określonej w przykładzie sieci oraz jeden komputer (badź
˛ urzadzenie
˛
udost˛epniajace
˛ NAT) o wymienionym adresie. Wszystkie połaczenia
˛
nie pasujace
˛ do tych kryteriów traktowane sa˛ jako deny,
zgodnie z porzadkiem
˛
wyznaczonym przez dyrektyw˛e Order.
Ograniczenie dostepu
˛
za pomoca˛ loginu i hasła
Apache udost˛epnia mechanizm autoryzacji, który używany jest do wyodr˛ebnienia
z serwisu pewnej cz˛eści przeznaczonej dla upoważnionych użytkowników. Ograniczenie działa na poziomie katalogów i podobnie jak w ograniczeniu dla adresu
(opisanego powyżej) nie można w ten sposób chronić poszczególnych plików.
Apache wspiera wiele rodzajów źródeł uwierzytelniajacych:
˛
pliki tekstowe, konta
systemowe, bazy LDAP i inne. My b˛edziemy zajmować si˛e autoryzacja˛ za pomoca˛
plików tekstowych, ze wzgl˛edu na popularność i prostot˛e tego rozwiazania.
˛
Istnieja˛ dwa protokoły przesyłania hasła Basic i Digest (w postaci skrótu). Metoda Digest jest bezpieczniejsza jednak praktycznie nie jest obsługiwana przez przegladarki
˛
WWW, tak wi˛ec pozostaje nam używanie metody Basic.
181
Zaczynamy od instalacji metapakietu apache-mod_auth oraz pakietu
htpasswd-apache. Teraz dodajemy do któregoś z plików konfiguracji regułk˛e
chroniac
˛ a˛ katalog :
<Directory "/home/users/jan/public_html/private">
AuthType Basic
AuthBasicProvider file
AuthName "Witaj Janie, zaloguj sie."
AuthUserFile /home/services/httpd/.htpasswd
Require valid-user
</Directory>
Opcja AuthUserFile wskazuje plik z loginami i hasłami użytkowników, jak widać
ścieżka ta jest inna niż chroniony katalog ze wzgl˛edów bezpieczeństwa. Opcja
Require określa jacy użytkownicy sa˛ akceptowani - tutaj każdy autoryzowany.
Teraz tworzymy plik z hasłami, poprzez dodanie pierwszego konta:
# htpasswd -c /home/services/httpd/.htpasswd jan
New password:
Re-type new password:
Adding password for user jan
Plikowi ustawiamy odpowiednie uprawnienia i własność, aby dost˛ep do niego miał
wyłacznie
˛
użytkownik http:
# chmod 600 /home/services/httpd/.htpasswd
# chown http.http /home/services/httpd/.htpasswd
Po restarcie każde odwołanie do katalogu b˛edzie wymagało podania loginu jan i hasła. Istnieje także możliwość dodania obsługi grup - mechanizmu zbliżonego działaniem do uniksowych grup systemowych.
W wielu wypadkach b˛edziemy chcieli dać możliwość użytkownikom tworzenia
plików z hasłami z wraz z plikami .htaccess w katalogu określonym przez
DocumentRoot. Stanowi to zagrożenie bezpieczeństwa, ze wzgl˛edu na możliwość
wyświetlenia zawartości tych plików. Możemy si˛e zabezpieczyć przed tym
instalujac
˛ pakiet apache-mod_authz_host, dzi˛eki któremu m.in. nie zostana˛
wysłane do przegladarki
˛
pliki .ht*
Obsługa skryptów PHP
Ze wzgl˛edu na duża˛ funkcjonalność j˛ezyk PHP stał si˛e już w zasadzie pewnym
standardem w tworzeniu interaktywnych stron internetowych. Współczesne serwisy
wykorzystuja˛ m. in. bazy danych, dlatego zostanie również opisane jak taka˛ obsług˛e zapewnić. Przegladaj
˛ ac
˛ list˛e dost˛epnych do zainstalowania pakietów z PHP na
pierwszy rzut oka widać nacisk twórców dystrybucji jaki został nałożony na modularność. Daje to niesamowita˛ wolność w wyborze tego co jest Ci dokładnie potrzebne.
Zaczynamy od instalacji pakietu apache-mod_php, w ten sposób otrzymamy podstawowa˛ wersj˛e PHP, dodatkowe pakiety instalujemy wtedy gdy potrzebna nam jest jakaś funkcjonalność. Najlepsza˛ metoda˛ sprawdzenia czy PHP działa jest użycie funkcji phpinfo(), aby z niej skorzystać stwórz plik z zawartościa˛ taka˛ jak poniżej:
<? phpinfo(); ?>
nast˛epnie należy go umieść w katalogu /home/services/httpd/html,
pod nazwa˛ np. info.php. Teraz wpisujemy w przegladarce
˛
adres
http://example.net/info.php, powinieneś uzyskać informacje m. in. na temat
wersji PHP, konfiguracji serwera oraz obsługiwanych modułów.
182
Obsługa różnego typu systemów bazodanowych rozbita jest na osobne pakiety zawierajace
˛ definicje funkcji PHP które ja˛ zapewniaja.˛ Poniżej w tabeli znajduje si˛e lista
która to odzwierciedla.
Tabela 17-1. Obsługa baz danych
Nazwa pakietu
Baza Danych
php-dba
Moduł dla PHP dodajacy
˛ obsług˛e dla
baz danych opartych na plikach (DBA).
php-dbase
Moduł PHP ze wsparciem dla DBase.
php-filepro
Moduł PHP dodajacy
˛ możliwość
dost˛epu (tylko do odczytu) do baz
danych filePro.
php-interbase
Moduł PHP umożliwiajacy
˛ dost˛ep do
baz danych InterBase i Firebird.
php-mssql
Moduł PHP dodajacy
˛ obsług˛e baz
danych MS SQL poprzez bibliotek˛e
FreeTDS.
php-mysql
˛ dost˛ep do
bazy danych MySQL.
php-odbc
Moduł PHP ze wsparciem dla ODBC.
php-pgsql
˛ dost˛ep do
bazy danych PostgreSQL.
php-sybase
Moduł PHP dodajacy
˛ obsług˛e baz
danych Sybase oraz MS SQL poprzez
bibliotek˛e SYBDB.
php-sybase-ct
Moduł PHP dodajacy
˛ obsług˛e baz
danych Sybase oraz MS SQL poprzez
CT-lib.
Aby skorzystać z którego kolwiek modułu wystarczy go po prostu zainstalować.
Przeprowadzajac
˛ instalacj˛e w trybie wsadowym pami˛etaj o zrestartowaniu usługi
apache, o czym zostaniesz przez poldka poinformowany. Dystrybucja nie posiada
niestety pakietów do obsługi bazy danych Oracle. Jeżeli jest Ci ona potrzebna musisz zbudować PHP właczaj
˛
ac
˛ obsług˛e oracla z serwera CVS, instalujac
˛ uprzednio
Oracla którego posiadasz.
Warto jeszcze wspomnieć o narz˛edziach wspomagajacych
˛
zarzadzanie
˛
bazami danych. Do obsługi bazy MySQL służy pakiet phpMyAdmin natomiast do PostgreSQL
zainstaluj phpPgAdmin. Szerzej o tych aplikacjach w dokumentacji do tych systemów.
CGI
Aby nasz Apache obsługiwał programy CGI wystarczy zainstalować pakiet
apache-mod_cgi. Po przeładowaniu demona programy CGI obsługiwane b˛eda
w katalogu /home/services/httpd/cgi-bin, zgodnie z ustawieniami w pliku
/etc/httpd/apache.conf.
Żeby przetestować CGI wystarczy że utworzymy plik o nast˛epujacej
˛ treści:
#!/bin/sh
echo "Content-type: text/html\n\n"
echo "Hello, World."
183
a nast˛epnie umieścimy go w odpowiednim katalogu z nazwa˛ np. cgi.sh,
nadamy mu prawo wykonywalności i w przegladarce
˛
podamy adres
http://example.net/cgi-bin/cgi.sh. Możemy do tego użyć również testowych
skryptów przychodzacych
˛
z pakietem apache-cgi_test.
Jeśli zechcemy wskazać wi˛ecej katalogów w których pozwolimy uruchamiać aplikacje CGI (np. dla hostów wirtualnych) wystarczy, że do któregoś z plików konfiguracji
dodamy odpowiednio skonfigurowana˛ opcj˛e ScriptAlias np.:
ScriptAlias /cgi-bin/ "/home/users/jan/cgi-bin/"
Ze wzgl˛edów bezpieczeństwa autorzy Apache zalecaja˛ by taki katalog leżał poza
ścieżka˛ wskazana˛ w opcji DocumentRoot.
Security Socket Layer (SSL)
Mechanizm ten wykorzystuje si˛e w serwisach wymagajacych
˛
od użytkownika autoryzacji. Najbardziej typowymi aplikacjami tego typu sa˛ różnego rodzaju klienci
poczty. SSL zapewnia szyfrowany kanał dla informacji przepływajacej
˛ od użytkownika do serwera. Dzi˛eki temu niemożliwe jest podsłuchanie hasła. UWAGA! Jeden
certyfikat SSL może zostać przypisany tylko dla jednego adresu IP.
Konfiguracj˛e zaczynamy od zainstalowania pakietu apache-mod_ssl. W wyniku instalacji utworzony zostanie plik /etc/httpd/httpd.conf/40_mod_ssl.conf. Zanim zaczniemy go konfigurować należy wygenerować certyfikaty. Służy do tego polecenie openssl. Program ten znajduje si˛e w pakiecie openssl-tools.
# openssl genrsa -out /etc/httpd/ssl/apache.key 1024
W wyniku tego polecenia zostanie utworzony plik apache.key który posłuży do
tworzenia certyfikatu. Robimy to w nast˛epujacy sposób.
# openssl req -new -x509 -days 365 -key /etc/httpd/ssl/apache.key \
-out /etc/httpd/ssl/apache.crt
Proces tworzenia certyfikatu b˛edzie wymagał podania kilku informacji. Zostaniesz o
nie poproszony trakcie jego trwania.
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:Województwo
Locality Name (eg, city) []:Miasto
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Firma
Organizational Unit Name (eg, section) []:Web Server
Common Name (eg, YOUR name) []:example.net
Email Address []:[email protected]
Pola, które widzisz w powyższym przykładzie należy wypełnić zgodnie z tym jak
zostało to przedstawione. W przypadku kiedy serwer jest prywatna˛ własnościa˛ i nie
należy do żadnej firmy, w polu Organization Name możesz wpisać imi˛e i nazwisko.
Para plików: klucz oraz certyfikat powinny mieć takie uprawnienia, aby użytkownik
http mógł je odczytywać.
Możemy teraz wyedytować plik /etc/httpd/httpd.conf/40_mod_ssl.conf. Pośród szeregu opcji interesuje nas w zasadzie tylko konfiguracja katalogu, do którego
połaczenie
˛
b˛edzie szyfrowane oraz ścieżki do plików z kluczem oraz certyfikatem.
Musimy odnaleźć poczatek
˛
sekcji o nazwie VirtualHost.
<VirtualHost _default_:443>
DocumentRoot "/home/services/httpd/html/webmail"
ServerName mail.example.net:443
ServerAdmin [email protected]
ErrorLog /var/log/httpd/error_log
TransferLog /var/log/httpd/access_log
184
Jak widać jej poczatek
˛
nie różni si˛e niczym od konfiguracji VirtualHosts. Zwróć
uwag˛e na opcj˛e ServerName. Powinna ona kończyć si˛e ciagiem
˛
:443 który oznacza
port na którym ma nasłuchiwać demon. Przechodzimy dalej i zmieniamy takie opcje
jak SSLCertificateFile oraz SSLCertificateKeyFile.
SSLCertificateFile /etc/httpd/ssl/apache.crt
SSLCertificateKeyFile /etc/httpd/ssl/apache.key
Podajemy tutaj ścieżki do plików które wygenerowaliśmy w poprzednim etapie.
Po zapisaniu i zakończeniu edycji pliku restartujemy Apache, aby nasze zmiany odniosły skutek. Aby nawiazać
˛
połaczenie
˛
szyfrowane z webmailem należy w przegla˛
darce wpisać adres https://example.net/webmail8. Aby ustanowić połaczenie
˛
szyfrowane i za każdym razem nie wpisywać https://, powinieneś użyć mechanizmu
vhosts. Stwórz katalog /home/services/httpd/html/mail dla którego zrobisz wpis
w pliku 20_mod_vhost_alias.conf. Czyli zgodnie z tym czego już si˛e dowiedziałeś,
robisz wpis w pliku strefy domeny oraz konfigurujesz apache. Natomiast w katalogu
/home/services/httpd/html/mail tworzysz plik o nazwie index.php z zawartościa˛ taka˛ jak w przykładzie.
<?php
/**
* index.php -- Displays the main frameset
*
* Copyright (c) 1999-2002 The SquirrelMail Project Team
* Licensed under the GNU GPL. For full terms see the file COPYING.
*
* Redirects to the login page.
*
* $Id: index.php,v 1.13 2002/02/19 15:05:03 philippe_mingo Exp $
*/
header("Location: https://poczta.example.net\n\n");
exit();
?>
Oczywiście domena, która jest podana na listingu musi odnosić si˛e do vhosta z opcja˛
DocumentRoot ustawiona˛ na /home/services/httpd/html/mail.
Indeksowana zawartość katalogu
Jest to bardzo przydatna funkcja, pozwalajaca
˛ w łatwy sposób udost˛epnić zawartość
katalogu na serwerze. Aby umożliwić indeksowanie musimy zainstalować moduł
apache-mod_autoindex.
poldek -i apache-mod_autoindex
Aby uruchomić indeksy musimy właczyć
˛
opcj˛e Indexes. W domyślnej konfiguracji,
Apache ma właczone
˛
indeksy dla wszystkich podkatalogów wewnatrz
˛
/home/services/httpd/html (w pliku 10_common.conf). Jeśli ustawiliśmy inaczej
to musimy właczać
˛
ta˛ opcj˛e dla każdego z katalogów osobno np.:
<Directory /home/services/httpd/html/katalog>
Options Indexes
</Directory>
Opcja nie zadziała wtedy, kiedy zainstalowaliśmy moduł apache-mod_dir i w katalogu znajduje si˛e plik określony przez DirectoryIndex.
185
Uwagi
Po każdej zmianie konfiguracji w katalogu /etc/httpd/httpd.conf konieczne jest
przeładowanie demona, aby na nowo odczytał swoje pliki konfiguracji. Możemy
użyć w tym celu odpowiedniego wywołania rc-skryptu:
# service httpd restart
Jeśli b˛edziemy modyfikować konfiguracj˛e działajacego
˛
serwera produkcyjnego,
to dobra˛ praktyka˛ jest wcześniejsze użycie programu apachectl z pakietu
apache-tools do sprawdzenia poprawności składni plików konfiguracji:
# apachectl configtest
Syntax OK
Na
szczególna˛
uwag˛e
zasługuja˛
parametry
rc-skryptu:
reload|force-reload|graceful np.:
# service httpd reload
Użycie któregoś z nich wywołuje "łagodny" restart serwera (graceful restart), który
pozwala dokończyć wykonywane prace przez procesy. Dzi˛eki temu restart nie jest
odczuwalny przez klientów. Parametry te maja˛ jeszcze jedna˛ ważna˛ zalet˛e, wywołanie ich powoduje sprawdzenie konfiguracji serwera przed rozpocz˛eciem restartu,
dzi˛eki czemu nie musimy do tego używać programu apachectl.
BIND - Serwer Nazw
DNS - Domain Name System
DNS jest systemem hierarchicznym. Na samym szczycie owej hierarchii stoja˛ tzw.
TLD (Top Level Domains), czyli domeny najwyższego rz˛edu. Zaliczaja˛ si˛e do nich
takie domeny jak .com (komercyjne), .pl (krajowe), .net (sieci) i inne. Sa˛ to domeny
powstałe na podstawie odpowiednich postanowień, opisane w specjalnych dokumentach. Każda z wymienionych (lub też nie wymienionych) tutaj TLD’s posiada
swoje subdomeny, np. pld-linux.org. Z kolei każda powstała w wyniku rejestracji danej nazwy domena może mieć swoje poddomeny, np. www.pld-linux.org. W ten sposób można tworzyć bardzo zag˛eszczone hierarchie w obr˛ebie danej domeny. Niniejszy rozdział dotyczy implementacji Bind określanego czasem jako named - jednego
z najpopularniejszych serwerów DNS.
Każda domena (zwana również strefa)
˛ musi mieć co najmniej dwa serwery DNS,
jest to wymóg registrarów, czyli instytucji oferujacych
˛
możliwość rejestracji domen.
Jeden z serwerów określa si˛e jako podstawowy (również master lub primary) a drugi
jako zapasowy (slave lub secondary).
Wstep
˛
Bind w PLD dziala w środowisku chroot, w katalogu /var/lib/named, musimy
o tym pami˛etać, przy niektórych operacjach diagnostycznych. Głównym
plikiem konfiguracyjnym jest /etc/named.conf, który jest symlinkiem do
/var/lib/named/etc/named.conf. Struktura katalogu /var/lib/named wyglada
˛
nast˛epujaco:
˛
dev/
etc/
186
M/
S/
named.pid
root.hint
Podobnie jak w normalnym środowisku, jest obecny tutaj katalog /dev, w
którym znajduja˛ si˛e urzadzenia
˛
konieczne do działania demona: /dev/null oraz
/dev/urandom. Katalog /etc jak zapewne si˛e domyślasz, przechowuje pliki
konfiguracyjne. U nas znajduje si˛e w nim jedynie named.conf. Kolejne katalogi:
M oraz S zostały przeznaczone do przechowywania plików stref, odpowiednio
master i slave. Plik named.pid przechowuje numer procesu systemowego. Ostatni
plik na liście - root.hint zawiera wpisy z adresami tzw. root serwerów, czyli
głównych serwerów DNS. Jest on konieczny do przeszukiwania serwerów DNS w
poszukiwaniu żadanych
˛
nazw, których nie utrzymuje nasz serwer.
Dodawanie stref DNS polega na definiowaniu obsługiwanych domen w pliku
/etc/named.conf, oraz tworzenia plików konfiguracji stref.
Głównym plikiem konfiguracyjnym serwera Bind jest /etc/named.conf. Znajduja˛
si˛e w nim podstawowe opcje usługi oraz informacje na temat obsługiwanych stref.
Poniżej zamieszczono domyślne wpisy, które znajduja˛ si˛e w tym pliku
options {
directory "/";
pid-file "named.pid";
auth-nxdomain yes;
datasize default;
};
zone "localhost" IN {
type master;
file "M/localhost.zone";
allow-update { none; };
allow-transfer { any; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "M/127.0.0.zone";
allow-update { none; };
allow-transfer { any; };
};
zone "." IN {
type hint;
file "root.hint";
};
Na samym poczatku
˛
pliku konfiguracyjnego znajduje si˛e sekcja options. Najbardziej
istotna˛ opcja˛ jest tutaj directory. Wskazuje ona na główny katalog przechowywania
plików stref. Być może zdziwi Ci˛e nieco parametr powyższej opcji. Jak już wcześniej
wspominałem Bind w PLD posiada własne chrootowane środowisko, dlatego można
taki zapis zastosować.
Zanim przejd˛e do omawiania pozostałych wpisów, należy si˛e jeszcze słowo wyjaśnienia na temat konstrukcji samego pliku. Na pierwszy rzut oka poszczególne wpisy sa˛ podzielone na sekcje. Te z kolei ograniczone sa˛ klamrami. Znak ; również pełni
tutaj rol˛e ogranicznika dla poszczególnych opcji jak i całych sekcji uj˛etych w klamry.
Warto o tym wiedzieć ze wzgl˛edu na ewentualne szukanie bł˛edów powstałych na
skutek edycji tego pliku.
Poniżej mamy zdefiniowane trzy sekcje stref zaczynajacych
˛
si˛e słowem kluczowym
zone. W powyższym przykładzie przedstawione sa˛ wpisy określajace
˛ localhosta. Sa˛
187
one typu master. Plik strefy w każdej z nich wskazany jest opcja˛ file. Strefa nie musi być aktualizowana, ani synchronizowana z serwerem slave, wi˛ec dwie pozostałe
opcje maja˛ parametr none oraz any. Ostatnia strefa służy do komunikacji naszego
binda z Root serwerami o których była mowa we wst˛epie. Bez tej strefy nie mógłby
on wyszukiwać nazw w internecie. Mówiac
˛ w przenośni byłby ślepy.
Każdorazowe odpytywanie Root Servers może si˛e okazać mało wydajne, ze wzgl˛edu
na duże czasy odpowiedzi. Dlatego, jeżeli chcemy przyspieszyć ten proces powinniśmy sekcj˛e option zmodyfikować o wpis taki jak poniżej
options {
forwarders { 194.204.159.1; 194.204.152.34; };
}
Oczywiście nie musimy posługiwać si˛e takimi adresami jak w przykładzie. Możemy sobie wybrać takie serwery DNS, które b˛eda˛ nam odpowiadały najszybciej np.
serwery naszego ISP.
W PLD zaleca si˛e, aby wszystkie pliki stref w zależności od typu domeny były przechowywane w katalogach /var/lib/named/M oraz /var/lib/named/S. Tak naprawd˛e o ścieżce do tych katalogów decyduja˛ wpisy w named.conf. Struktura plików
stref dla obu typów domen jest taka sama.
Przykładowa konfiguracja strefy typu primary
Zaczniemy od konfiguracji /etc/named.conf, budowa tego pliku była wyjaśniona
w poprzedniej cz˛eści tego rozdziału. Poniżej został zamieszczony przykładowy wpis
dla strefy na serwerze podstawowym:
zone "example.net" {
type master;
file "M/example.net";
allow-transfer { 123.45.67.89; };
notify yes;
};
Poszczególne opcje tej sekcji zostały omówione już na poczatku
˛
tego rozdziału. Podsumujmy wi˛ec dost˛epne informacje skupiajac
˛ si˛e na powyższym przykładzie:
• zone "example.net"
• type master
- nazwa strefy
- rodzaj serwera
• file "M/example.net"
- nazwa pliku z konfiguracja˛ strefy
- adres serwera, który ma możliwość
transferu całej strefy, Jeżeli posiadasz wi˛ecej niż jeden taki DNS, możesz je wpisać
pomi˛edzy klamry pami˛etajac
˛ o tym, aby rozdzielić poszczególne adresy IP,
znakiem ’;’.
• allow-transfer { 123.45.67.89; }
- opcja ta włacza
˛
powiadamianie zapasowego serwera DNS o zmianach w naszej domenie.
• notify yes
Musimy teraz utworzyć plik strefy dla domeny example.net wskazany przez opcj˛e
file. Poniżej zamieszczam treść przykładowego pliku strefy:
$TTL 86400
$ORIGIN example.net.
@
IN
SOA
ns1.example.net. root.example.net. (
2004022300 ;; serial
1200
;; refresh
1200
;; retry
2419200
;; expire
86400
;; TTL
188
)
@
@
@
@
ns1
ns2
mail
www
ftp
IN
IN
IN
IN
IN
IN
IN
IN
IN
NS
NS
MX
A
A
A
A
A
CNAME
ns1.example.net.
ns2.example.net.
10
mail.example.net.
123.45.67.8
123.45.67.8
90.12.34.237
123.45.67.8
34.5.6.78
www
Plik strefy można podzielić na trzy odr˛ebne sekcje. Pierwsza określa nazw˛e domeny
oraz okres ważności wpisów. Druga, kto ta˛ domena˛ zarzadza.
˛
W trzeciej znajduje si˛e
cała jej zawartość. Bardziej szczegółowy opis znajduje si˛e w poniższym wykazie. Kilka zdań o wyrażeniach stosowanych w plikach stref. Warto o nich pami˛etać. Wszystkie wpisy poprzedzone ;; b˛eda˛ ignorowane i traktowane jak komentarz. Kolejnym
ważnym znakiem jest znak kropki. Jego znaczenie omówi˛e poniżej w przykładzie.
@
IN
NS
ns1.example.net.
Jeżeli w powyższym wpisie pomin˛elibyśmy końcowy znak kropki, wówczas Bind
dokleiłby na końcu nazw˛e domeny. Wówczas z ns1.example.net zrobiłby si˛e wpis
ns1.example.net.example.net, co oczywiście nie jest pożadane.
˛
nast˛epnym znakiem
specjalnym na który warto zwrócić uwag˛e jest @. Otóż można go potraktować jako
pewnego rodzaju zmienna,˛ która przechowuje nazw˛e example.net. Jednym słowem,
example.net i @ to to samo.
- czas ważności rekordów w domenie wyrażony w sekundach; 86400
s. to jedna doba
• $TTL 86400
• $ORIGIN example.net.
- domena jaka˛ b˛edzie opisywał bieżacy
˛ plik strefy.
- Rekord typu SOA czyli
Start Of Authority. Możemy si˛e z niego dowiedzieć, kto zarzadza
˛
domena˛
([email protected]), jaki jest adres serwera primary DNS. Zwróć uwag˛e, że w
adresie [email protected] zamiast znaku @ użyta została kropka. Rekord SOA
posiada swoja˛ własna˛ struktur˛e o której poniżej. Zawarta jest ona pomi˛edzy
znakami ( ).
• @ IN SOA ns1.example.net. root.example.net.
- numer seryjny domeny. Powinien on być zwi˛ekszany
wraz z każda˛ jej modyfikacja.˛ W dobrym tonie jest utrzymywanie go w formacie
YYYYMMDDnn czyli rok, miesiac,
˛ dzień oraz numer modyfikacji w danym dniu.
• 2004022300 ;; serial
- To pole rekordu SOA definiuje jak cz˛esto serwery slave maja˛
sprawdzać czy dane o domenie nie zmieniły si˛e na masterze. Według RFC 10359
wartość ta powinna si˛e zawierać pomi˛edzy 1200 a 43200 (czyli od dwudziestu
minut do dwunastu godzin). W praktyce najlepsza wartość zawiera si˛e mi˛edzy
3600 a 7200 sekund.
• 1200 ;; refresh
- Czas po jakim secondary ma ponowić prób˛e kontaktu z masterem,
gdy taka si˛e nie powiedzie. Zalecana wartość pomi˛edzy 120 a 7200 sekund.
• 1200 ;; retry
- Ta wartość określa czas po jakim dane domeny maja˛ zostać
uznane za nieaktualne gdy serwer secondary nie b˛edzie mógł si˛e skontaktować z
primary. Zalecana wartość zawiera si˛e pomi˛edzy 1209600 a 2419200 sekund, czyli
od dwóch do czterech tygodni.
• 2419200 ;; expire
- Time To Live. Określa ile czasu informacja o danym rekordzie
ma być ważna. Jest to okres przez jaki informacja o naszej domenie b˛edzie
przechowywana przez serwer DNS, który ja˛ pobrał. Zalecana wartość zawiera si˛e
mi˛edzy 86400 a 432000 sekund, czyli przez okres od jednego do pi˛eciu dni.
• 86400 ;; TTL
Bezpośrednio pod rekordem SOA definiujemy, które serwery DNS b˛eda˛ obsługiwały
nasza˛ domen˛e. Jeszcze raz przypominam aby właściwie zamknać
˛ ten rekord. Bez
189
tego nasza domena nie b˛edzie działać. Do definiowania serwerów DNS służa˛ wpisy
typu IN NS.
@
@
IN
IN
NS
NS
ns1.example.net.
ns2.example.net.
Powyższy wpis mówi, że domen˛e example.net obsługuje serwer DNS ns1.example.net
oraz ns2.example.net. Jeżeli obie nazwy dotycza˛ komputerów, które wcześniej nie pełniły roli serwerów DNS, powienieś dodać wpisy takie jak poniżej.
ns1
ns2
IN
IN
A
A
123.45.67.8
90.12.34.237
ns1 oczywiście może wskazywać na adres serwera DNS który zapewne konfigurujesz; ns2 powinien wskazywać na Twojego secondary. Zrobiliśmy to posługujac
˛ si˛e
wpisami typu IN A. Jak zapewne pami˛etasz, brak końcowej kropki powoduje doklejenie do wpisanej nazwy tego co znajduje si˛e w zmiennej $ORIGIN. Możemy wi˛ec
uznać to co widzisz w powyższym przykładzie za postać skrócona˛ poniższego wpisu.
ns1.example.net.
ns2.example.net.
IN
IN
A
A
123.45.67.8
90.12.34.237
Wpisy typu IN A służa˛ do określania, że właśnie ten adres IP ma przypisana˛ taka˛
a nie inna˛ nazw˛e. Oczywiście do jednego adresu IP możesz stworzyć kilka takich
wpisów. Jeżeli posiadasz serwer poczty, powinieneś zrobić wpis mówiacy
˛ o tym, że
b˛edzie on obsługiwał poczt˛e dla domeny example.net.
@
IN
MX
10
mail.example.net
Dokładnie tak jak wcześniej wspomniałem, poczta, dla domeny example.net kierowana jest do serwera mail.example.net o priorytecie 10. Jest on tzw. MX’em. Rekord typu
IN MX służy właśnie do definiowania w DNS serwera poczty. Priorytet przydaje si˛e
wtedy, kiedy posiadasz kilka serwerów poczty w swojej domenie. Służy on do ustalenia porzadku;
˛
do którego serwera poczta ma trafić w pierwszej kolejności. Mniejszy
priorytet zapewnia pierwszeństwo.
Pozostałe wpisy dotycza˛ takich standardowych usług jak www czy ftp. Umieszczanie ich w pliku strefy nie jest obowiazkowe.
˛
Jednak domen˛e rejestruje si˛e zazwyczaj
na potrzeby www, ftp czy poczty, dlatego zostały one wymienione w przykładzie.
ftp
IN
CNAME
www
Powyżej umieszczono przykład rekordu typu IN CNAME, tworzy on dodatkowa˛ subdomen˛e dla hosta przypisanego już do innej nazwy. Specjaliści radza˛ by tego rodzaju
rekordy wskazywały wyłacznie
˛
na rekordy typu IN A.
Po zakończeniu konfiguracji musimy jeszcze uruchomić usług˛e.
# /etc/rc.d/init.d/named start
Przykładowa konfiguracja strefy typu secondary
Konfiguracja serwera secondary sprowadza si˛e do dokonania poniższego wpisu w
pliku /etc/named.conf.
zone "example.net" IN {
type slave;
file "S/example.net";
masters { 123.45.67.8; };
};
190
Jak widać wpis wyglada
˛ podobnie jak w przypadku serwera primary. Opcja type tym
razem ma wartość slave. Musimy też wskazać serwer primary. Robimy to używajac
˛
opcji masters, której wartość zawiera adres serwera primary DNS.
Obsługa protokołu IPv6
Podobnie jak wi˛ekszość usług w dystrybucji BIND posiada wsparcie dla protokołu
IPv6 (IPng). Oczywiście wcześniej komputer musi być podłaczony
˛
do tej sieci. W
tej cz˛eści rozdziału zostanie omówiona konfiguracja dla stref IN A oraz strefy odwrotnej. Narz˛edziem wspomagajacym
˛
konfiguracj˛e b˛edzie ipv6calc znajdujacy
˛ si˛e w
pakiecie o tej samej nazwie. Jak sama nazwa wskazuje jest to kalkulator adresów
IPv6.
• IN AAAA
Odpowiednikiem w IPv6 strefy IN A jest wpis IN AAAA. Każda z dotychczasowych
stref stworzona do tej pory dla protokołu IPv4 może mieć swój odpowiednik w
sieci IPv6. Możemy również stworzyć zupełnie nowe wpisy, które b˛eda˛ widoczne
jedynie w tej sieci.
moja
IN
AAAA 3ffe:1a:2b:3c::1
Umieszczenie
powyższego
wpisu
w
pliku
strefy
/var/lib/named/M/example.net spowoduje przypisanie nazwy moja.example.net
adresowi 3ffe:1a:2b:3c::1. Aby wpis zaczał
˛ obowiazywać
˛
należy zrestartować
usług˛e.
• IN PTR
Konfiguracj˛e strefy odwrotnej zaczniemy od stworzenia odpowiedniego wpisu w
pliku /etc/named.conf. Jak sama nazwa wskazuje b˛edzie on przypominał lustrzane odbicie adresu w zwykłej postaci. Aby mieć pewność, że nasza strefa b˛edzie poprawnie zapisana posłużymy si˛e wspomnianym we wst˛epie narz˛edziem
ipv6calc.
$ ipv6calc -r 3ffe:1a:2b:3c::/64
No input type specified, try autodetection...found type: ipv6addr
c.3.0.0.b.2.0.0.a.1.0.0.e.f.f.3.ip6.int.
Uzyskaliśmy w ten sposób informacje, że dla sieci o adresie 3ffe:1a:2b:3c::/64, strefa odwrotna posiada postać taka˛ jak na powyższym listingu. Wystarczy teraz to
zapisać w pliku konfiguracyjnym BIND’a.
zone "c.3.0.0.b.2.0.0.a.1.0.0.e.f.f.3.ip6.int" IN {
type master;
file "M/ipv6";
allow-transfer {
90.12.34.237;
};
};
Jak widać na pierwszy rzut oka, konfiguracja niczym si˛e praktycznie nie różni
od konfiguracji strefy dla IPv4. Jako nazw˛e strefy podaliśmy to co nam zwrócił
ipv6calc. Przyjrzyjmy si˛e teraz jak powinien wygladać
˛
plik dla tej strefy wskazany
dyrektywa˛ file.
$TTL
86400
$ORIGIN 0.1.0.0.e.2.0.0.c.0.0.4.e.f.f.3.ip6.int.
Pierwszy parametr to omawiany już wcześniej okres ważności rekordów. Jak widać na listingu wynosi on jeden dzień. Drugi z nich to de facto nazwa tej strefy.
Sama opcja $ORIGIN to swojego rodzaju zmienna, której wartość jest podstawiana
w miejsce @ oraz doklejana do tych nazw które nie posiadaja˛ na końcu specjalnego
znaku kropki.
191
@
IN
2004050600
3H
15M
SOA ns1.example.net. root.example.net. (
1W
1D )
Jak widać rekord IN SOA nie różni si˛e niczym od tego dla domeny IPv4.
@
@
IN
IN
NS
NS
ns1.example.net.
ns2.example.net.
Określamy które serwery przechowuja˛ nasza˛ domen˛e odwrotna.˛ Również tutaj
wszystko wyglada
˛ identycznie jak dla protokołu IPv4. Możemy teraz przystapić
˛
do konfigurowania strefy odwrotnej.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0
IN PTR
moja.example.net.
Dlaczego tyle zer? Odpowiedź na to znajdziesz obliczajac
˛ przy użyciu programu ipv6calc adres odwrotny dla 3ffe:1a:2b:3c::1. Robimy to w sposób identyczny
do poprzedniego przykładu jego użycia. W wyniku obliczeń b˛edzie on wygladał
˛
tak: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.3.0.0.b.2.0.0.a.1.0.0.e.f.f.3. Jak łatwo zauważyć, po
ostatnim zerze w listingu nie postawiliśmy kropki, a wi˛ec zostanie doklejona po
nim zawartość $ORIGIN.
Narz˛edziem pomocnym w odpytywaniu serwerów DNS, jest program host. Można nim również odpytywać o nazwy skonfigurowane dla protokołu IPv6. Jak by
wygladało
˛
zapytanie o nazw˛e moja.example.net?
$ host -n -i 3ffe:1a:2b:3c::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.3.0.0.b.2.0.0.a.1.0.0.e.f.f.3.\
ip6.int domain name pointer moja.example.net
Przełacznik
˛
-n oznacza, że b˛edziemy odpytywali stref˛e odwrotna,
˛ natomiast -i,
że jest to adres typu int. Domyślnie host szuka nazw typu arpa.
Rejestracja
Zanim zarejestrujemy domen˛e musimy mieć skonfigurowany podstawowy i zapasowy serwer nazw. Mamy możliwość zarejestrowania własnej domeny, badź
˛ skorzystać z usług darmowego oddelegowania nam subdomeny zarejestrowanej już domeny. Ceny rejestracji domen spadły w ostatnich latach tak bardzo, że używanie "obcej"
domeny stało si˛e mało profesjonalne i warto zarejestrować własna.˛
Jeżeli nie posiadasz serwera secondary, możesz poszukać firmy lub organizacji, która
za darmo utrzymuje zapasowe DNS-y. Możemy też umówić si˛e z administratorem
innej firmy na wzajemne prowadzenie serwerów secondary.
Diagnostyka
Jeśli chcemy przetestować poprawność składni pliku strefy, powinniśmy skorzystać
z narz˛edzia named-checkzone. Program sprawdzi poprawność pliku strefy i poda
w której linii wystapił
˛ bład
˛ np.:
# /usr/sbin/named-checkzone example.net /var/lib/named/M/example.net
Named generuje logi typu daemon, domyślnie syslogd umieszcza takie wpisy w pliku /var/log/daemon. Jeśli jednak nastapił
˛ problem z uruchomieniem demona, uniemożliwiajacy
˛ mu pisanie do logów, to możemy sprawdzić co si˛e dzieje uruchamiajac
˛
go bez przejścia w tło i z wypisaniem komunikatów na standardowe wyjście:
192
/usr/sbin/named -g -t /var/lib/named
Aby ostatecznie sprawdzić poprawność konfiguracji możemy odpytać nasz serwer
za pomoca˛ protokołu DNS. Użyjemy do tego programu host z pakietu bind-utils np.:
# /usr/sbin/host -t mx example.net
Zakończenie
Uwaga! Named nie powinien być resolwerem nazw dla maszyny na której pracuje, powinien nim być inny serwer DNS aby nie powstawały zap˛etlenia zapytań. Wyjatek
˛
stanowia˛ usługi pracujace
˛ w osobnych środowiskach chroot/vserver. Wi˛ecej o konfiguracji resolwera nazw znajdziemy w sekcja Podstawowa konfiguracja sieci w Rozdział
15.
CRON - Cykliczne wykonywanie zadań
CRON jest ważnym demonem systemowym, którego zadaniem jest uruchamianie
programów cyklicznie lub o określonej porze. Omówiona zostanie instalacja vixiecron, który oprócz standardowych usług posiada dodatkowe opcje konfiguracyjne i
zwi˛ekszone bezpieczeństwo
Instalacja
Program instalujemy za pomoca˛ poldka:
# poldek -i vixie-cron
Po zainstalowaniu program jest praktycznie gotowy do użycia. Można wi˛ec od razu
uruchomić demona korzystajac
˛ z polecenia:
# /etc/rc.d/init.d/crond start
Od tej pory demon może działać nieprzerwane - nie wymaga restartów po rekonfiguracji.
Budowa tabel
W cronie istnieje podział na zadania systemowe i zadania użytkowników. Pierwszych zwykle używa si˛e do prac administracyjnych, z drugich korzystaja˛ użytkownicy wedle własnych potrzeb (o ile maja˛ do tego prawo). Główna konfiguracja demona (systemowa) umieszczona jest w pliku /etc/cron.d/crontab, konfiguracje
lokalne użytkowników przechowywane sa˛ w plikach /var/spool/cron/{$login}.
O ile /etc/cron.d/crontab może być swobodnie modyfikowany za pomoca˛ edytora tekstu, o tyle użytkownicy powinni używać w tym celu odpowiedniego narz˛edzia
(opisanego w dalszej cz˛eści).
Pliki konfiguracji crona nazywane sa˛ tabelami, zarówno główny plik konfiguracji jak
i konfiguracje użytkowników maja˛ bardzo podobna˛ budow˛e. Sa˛ to pliki tekstowe o
ściśle ustalonej składni, w których jeden wiersz odpowiada jednemu zadaniu. Wiersz
tabeli systemowej ma nast˛epujac
˛ a˛ składni˛e:
{$data-czas} {$użytkownik} {$zadanie}
193
Nieco prostsza˛ budow˛e maja˛ tabele użytkowników:
{$data-czas} {$zadanie}
Pierwsze pole określa jak cz˛esto wykonywane jest zadanie, pole {$użytkownik} wyst˛epuje jedynie w konfiguracji globalnej (w /etc/cron.d/crontab) i wskazuje z jakimi prawami uruchamiane ma być zadanie. Trzecie pole to operacja która ma być
wykonywana. W tabelach użytkowników nie podaje si˛e nazwy użytkownika, gdyż
polecenia tam zawarte sa˛ automatycznie wykonywane z prawami ich właściciela.
Przykładowe zadania w /etc/cron.d/crontab:
02 01 * * *
root
find /home -size +100M > /root/duze_pliki.txt
Przykładowa konfiguracja zwykłego użytkownika:
30 * * * *
backup.sh
W tabelach oprócz zadań możemy definiować zmienne środowiskowe np.:
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=jakis_user
NICE=15
Pierwsza zmienna wskazuje powłok˛e (zamiast domyślnej /bin/sh), która ma być
używana do wywoływania zadań, druga to ścieżka do plików wykonywalnych.
Trzecie pole to konto użytkownika do którego b˛eda˛ wysyłane powiadomienia
poczta˛ elektroniczna˛ lub pełny adres e-mail, ostatnia zmienna to priorytet
wykonywanych zadań (liczba nice).
Format daty i czasu
Sekcja {$użytkownik} i {$zadanie} nie wymagaja˛ komentarza wi˛ec opisane zostanie
jedynie pole {$data-czas}. Pole to składa si˛e z pi˛eciu kolumn:
•
1-sza kolumna (zakres 0-59) oznacza minuty.
•
2-ga kolumna (zakres 0-23) oznacza godzin˛e.
•
3-cia kolumna (zakres 0-31) oznacza dzień miesiaca.
˛
•
4-ta kolumna (zakres 0-12) oznacza miesiac.
˛ (0 i 1 to styczeń)
•
5-ta kolumna (zakres 0-7) oznacza dzień tygodnia (0 i 7 to niedziela)
•
6-ta kolumna określa komend˛e jaka powinna zostać wykonana dla danego wiersza.
Gwiazdka "*" oznacza cały zakres z możliwego przedziału. Same zakresy w pierwszych pi˛eciu kolumnach moga˛ być reprezentowane w różny sposób. Wi˛ecej szczegółów na ten temat dowiemy si˛e wywołujac
˛ polecenie man 5 crontab
Program vixie-cron posiada także mało udokumentowany format wykonywania poleceń
Nazwa
-----@reboot
@yearly
@annually
@monthly
194
Działanie
------Uruchom jeden raz przy starcie systemu
Uruchom jeden raz w roku, "0 0 1 1 *"
To samo co @yearly
Uruchom jeden raz w miesiacu,
˛
"0 0 1 * *"
@weekly
@daily
@midnight
@hourly
Uruchom
Uruchom
To samo
Uruchom
jeden raz w tygodniu, "0 0 * * 0"
jeden raz dziennie, "0 0 * * *"
co @daily
raz na godzin˛
e, "0 * * * *"
Przykład:
@reboot
/usr/bin/rdate -s ntp.task.gda.pl
Tabele systemowe
Główna˛ konfiguracj˛e systemu tworzymy za pomoca˛ naszego ulubionego edytora
tekstu, poprzez modyfikacj˛e pliku /etc/cron.d/crontab. Jego zawartość b˛edzie podobna do poniżej przedstawionego przykładu:
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
[email protected]
NICE=15
# run-parts
01 * * * *
02 1 * * *
02 2 * * 0
02 3 1 * *
0-59/10 * * * *
15 18 * * 1-5
root
root
root
root
root
root
/bin/run-parts
/bin/run-parts
/bin/run-parts
/bin/run-parts
/bin/run-parts
/bin/run-parts
/etc/cron.hourly
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly
/etc/cron.10min
/etc/cron.gielda
Poniżej napisu # run-parts umieszczone sa˛ konfiguracje zadań, pierwsze cztery linijki stanowia˛ domyślna˛ konfiguracj˛e demona. Program run-parts służy do uruchamiania o jednej porze wszystkich programów we wskazanym katalogu. Dzi˛eki takim
opcjom możemy dodawać programy lub skrypty do odpowiednich katalogów bez
konieczności pisania regułek cron-a. Poniżej umieszczono opisy powyższych przykładów:
Wykonanie poleceń zawartych w pliku (plikach) katalogu /etc/cron.hourly codziennie, co godzin˛e - zaczynajac
˛ od pełnej pierwszej minuty (np. 02:01, 03:01 itd.):
01 * * * *
/bin/run-parts /etc/cron.hourly
Wykonanie poleceń zawartch w pliku (plikach) katalogu /etc/cron.daily raz dzienie (o godz. 01:02):
02 1 * * *
/bin/run-parts /etc/cron.daily
Wykonanie poleceń zawartych w pliku (plikach) katalogu /etc/cron.weekly raz w
tygodniu (w niedziele o godz. 02:02):
02 2 * * 0
/bin/run-parts /etc/cron.weekly
Wykonanie poleceń zawartych w pliku (plikach) katalogu /etc/cron.monthly raz
na miesiac
˛ (w pierwszy dzień miesiaca
˛ o godz. 03:02):
02 3 1 * *
/bin/run-parts /etc/cron.monthly
Wykonanie poleceń zawartych w pliku (plikach) katalogu /etc/cron.gielda raz
dziennie w dni robocze (od poniedziałku do piatku
˛
o godz. 18:15):
15 18 * * 1-5
/bin/run-parts /etc/cron.gielda
Wykonanie poleceń zawartych w pliku (plikach) katalogu /etc/cron.10min co 10
minut (każdego dnia, zaczynajac
˛ od pełnej godziny - czyli np. 01:00, 01:10, 01:20 itd.):
195
0-59/10 * * * * /bin/run-parts /etc/cron.10min
Tabele użytkowników
Domyślnie użytkownicy nie moga˛ tworzyć własnych zadań cron-a, aby im na to zezwolić każdy nich musi zostać dopisany do pliku /etc/cron/cron.allow.
Użytkownicy powinni używać narz˛edzia crontab, program ten pozwala na bardzo
łatwe zarzadzanie
˛
tabela˛ użytkownika. Przyjmuje parametry określajace
˛ rodzaj działania, które ma być wykonane na tabeli. Polecenie crontab -l wyświetla list˛e zdefiniowanych zadań, wywołanie crontab -e otworzy plik konfiguracji do edycji, zaś
crontab -r usunie cała˛ zawartość konfiguracji użytkownika.
Wybranie opcji edycji tabeli spowoduje otworzenie edytora tekstu określonego
zmienna˛ środowiskowa˛ EDITOR, po skończonej edycji plik zostanie automatycznie
poddany kontroli poprawności i zapisany jako /var/spool/cron/{$login}.
Najcz˛eściej popełniane bł˛edy przez użytkowników to zły format daty/czasu lub
brak znaku nowej linii po ostatnim wierszu.
Root ma dodatkowo do dyspozycji możliwość zarzadzania
˛
zadaniami dowolnego
użytkownika, w tym celu stosuje si˛e opcj˛e -u z podana˛ nazwa˛ użytkownika.
Komunikaty cron-a
Cron rejestruje wszystkie swoje prace do pliku /var/log/cron za pośrednictwem
demona syslogd, dodatkowo można wskazać adres e-mail, na który maja˛ docierać
informacje o wystapieniu
˛
bł˛edów w wykonywaniu zadań. Jeśli nie zdefiniuje zmiennej MAILTO w tabeli to poczta zostanie wysłana na lokalne konto właściciela tej tabeli. Poczta elektroniczna jest jedyna˛ forma˛ informowania zwykłych użytkowników o
ewentualnych bł˛edach zadań, gdyż nie maja˛ oni dost˛epu do logów.
Wysyłanie poczty elektronicznej zarówno do użytkowników lokalnych jak i
zewn˛etrznych b˛edzie wymagało instalacji lokalnego serwera poczty MTA. Może to
być niemal dowolny demon pocztowy, np.: Exim (opis w sekcja Exim - Transport
poczty elektronicznej (MTA)) lub Postfix (opis w sekcja Postfix - Transport poczty
elektronicznej (MTA)).
Aby łatwiej było analizować problemy, do wiadomości wysyłanej przez demon, dodawane sa˛ nagłówki X-Cron-Env, zawierajace
˛ dane środowiska np.:
X-Cron-Env:
X-Cron-Env:
X-Cron-Env:
X-Cron-Env:
X-Cron-Env:
X-Cron-Env:
X-Cron-Env:
<SHELL=/bin/sh>
<PATH=/sbin:/bin:/usr/sbin:/usr/bin>
<MAILTO=root>
<NICE=15>
<HOME=/root>
<LOGNAME=root>
<USER=root>
CUPS - Popularny system druku dla Uniksa
Wstep
˛
CUPS jest nowoczesnym i uniwersalnym systemem druku dla systemów uniksowych. Może być stosowany zarówno do drukowania lokalnego jak i do drukowania
196
w sieci - obsługuje domyślnie protokół IPP. Po poprawnym skonfigurowaniu urza˛
dzenia b˛edziemy mogli drukować z niemal każdego programu, CUPS akceptuje wywołania poleceń drukowania w stylu klasycznego systemu LPD.
System CUPS może być zarówno serwerem jak i klientem, o tym jaka˛ funkcj˛e b˛edzie
pełnić zainstalowane "urzadzenie"
˛
decyduje wybór specjalnego sterownika interfejsu: backendu(poza IPP) i konfiguracji.
Instalacja
Podstawowa cz˛eść CUPS:
$ poldek -i cups cups-clients
Nast˛epnie instalujemy jeden lub wi˛ecej kontrolerów interfejsów drukarki (protokół
IPP nie wymaga backendu):
• cups-backend-parallel
• cups-backend-serial
- port równoległy (parallel port)
- port szeregowy RS-232 (serial port)
• cups-backend-usb
- port szeregowy USB (usb printer)
• cups-backend-smb
- drukowanie zdalne w sieci SMB
W przypadku drukarek nie obsługujacych
˛
PostScriptu konieczne b˛eda˛ dodatkowe
pakiety:
$ poldek -i cups-filter-pstoraster ghostscript-esp
Do zdalnej administracji (za pomoca˛ HTTPS), konieczny b˛edzie program openssl:
$ poldek -i openssl-tools
Czas uruchomić demona:
$ /etc/rc.d/init.d/cups start
Zarzadzanie
˛
drukarkami
Operacje takie jak dodawanie, czy konfigurowanie drukarek moga˛ być dokonywane
na kilka sposobów:
•
HTTP
Popularnym sposobem jest konfiguracja przy pomocy przegladarki
˛
internetowej,
CUPS posiada wbudowany niewielki serwer WWW, z którym łaczymy
˛
si˛e dowolna˛
przegladark
˛
a˛ na adres serwera i port 631 np.:
$ lynx localhost:631
Z poziomu tej strony mamy dost˛ep do wielu opcji administracyjnych: konfiguracji
drukarek, zarzadzania
˛
klasami, zadaniami druku i innymi. Ten sposób zarzadza˛
nia systemem CUPS w niniejszej publikacji jest traktowany jako domyślny.
•
lpadmin
197
lpadmin jest programem administracyjnym dostarczanym z CUPS-em, obsługiwany jest całkowicie z linii wiersza poleceń. Jest to narz˛edzie zaawansowane, przez
co stosunkowo trudne w obsłudze, jego dokładny opis zawarto w dokumentacji.
•
Inne
Dla CUPS powstały wygodne programy zarzadzaj
˛
ace
˛ przeznaczone działajace
˛ w
środowiskach GNOME i KDE. Szczególnie pozytywnie przedstawia si˛e systemconfig-printer - wygodna aplikacja, której układ opcji przypomina konfiguracj˛e
przez WWW.
Dodanie drukarki
W tym rozdziale przedstawiono ogólny opis instalacji urzadzenia,
˛
szczegółowe informacje umieszczono w rozdziałach: Szczegóły dodawania drukarki lokalnej i Szczegóły
dodawania drukarki zdalnej.
Możemy użyć programu system-config-printer lub narz˛edzia dost˛epnego przez stron˛e WWW:
$ lynx localhost:631
nast˛epnie przechodzimy do opcji Managle Printers -> Add Printer.
Określamy nazw˛e drukarki oraz opcjonalnie komentarz i lokalizacj˛e, nast˛epnie wybieramy jeden z dost˛epnych na liście kontrolerów interfejsów drukarki (backend). Na
koniec wybieramy producenta i model drukarki.
System CUPS jest dostarczany z niewielka˛ ilościa˛ sterowników drukarek, jednak nie
należy si˛e jednak martwić jeśli na liście nie odnajdziemy szukanego urzadzenia.
˛
Coraz wi˛ecej producentów dostarcza ze sprz˛etem pliki PPD (w CUPS sa˛ używane również dla drukarek niepostcriptowych), możemy także skorzystać z bazy Foomatic
zawierajacej
˛ ogromna˛ liczb˛e sterowników.
Sterowniki Foomatic możemy zainstalować w postaci zbiorczego pakietu sterowników danego producenta. Przykładowo jeśli chcemy zainstalować sterowniki drukarek firmy Samsung to instalujemy pakiet cups-foomatic-db-Samsung. Możemy
również pobrać pojedyncze pliki PPD z z witryny http://www.linuxprinting.org10,
po wyszukaniu modelu drukarki (Driver Listings) należy kliknać
˛ link download PPD
w celu pobrania sterownika. Plik wskazujemy przy dodawaniu drukarki lub kopiujemy go do katalogu /usr/share/cups/model i uruchamiamy na nowo demona
cupsd:
# /etc/rc.d/init.d/cups restart
Po tej operacji przeprowadzamy normalna˛ instalacj˛e drukarki. Możemy ich wiele
zainstalować, to do której b˛eda˛ trafiać dokumenty zależy od tego, która˛ z nich ustawimy jako domyślna.˛
Szczegóły dodawania drukarki lokalnej
Dodanie drukarki lokalnej dotyczy drukarek podłaczonych
˛
bezpośrednio podłaczo˛
nych do komputera, na którym zainstalowany jest CUPS, w tym wypadku interesuja˛ nas interfejsy: Parallel, Serial i USB. Zanim zaczniemy proces konfiguracji,
musimy sie upewnić, że sa˛ załadowane odpowiednie moduły jadra
˛
(w przeciwnym
wypadku dany backend może być nieaktywny).
Drukarka podłaczona
˛
do portu równoległego b˛edzie wymagała modułów lp,
parport i parport_pc. Moduł lp dopisujemy do pliku /etc/modules, jeśli nie
198
używamy udeva to pozostałe moduły także. Drukarki podłaczane
˛
pod port LPT sa˛
dost˛epne za pomoca˛ urzadze
˛
ń /dev/lp*. W przypadku drukarek USB konieczny
b˛edzie moduł usblp oraz rzecz jasna moduł kontrolera USB, urzadzenia
˛
te b˛eda˛
dost˛epne za pomoca˛ /dev/usb/lp*. Wi˛ecej o modułach jadra
˛
i ich zarzadzaniu
˛
odnajdziemy w sekcja Moduły jadra
˛ w Rozdział 11.
CUPS od wersji 1.3 wymaga zdefiniowania opcji Group w pliku
/etc/cups/cupsd.conf, która wskazuje jaki użytkownik ma być używany dla
uruchamiania zewn˛etrznych programów - w tym backendów. Jako że urzadzenia
˛
w katalogu /dev maja˛ grup˛e ustawiona˛ na lp, taka˛ też podamy jako wartość
parametru:
Group lp
Dalsza˛ instalacj˛e przeprowadzamy zgodnie z zaprezentowanym wcześniej opisem
Dodanie drukarki.
Szczegóły dodawania drukarki zdalnej
•
IPP
Aby CUPS było klientem IPP musimy dodać drukark˛e z backendem IPP oraz podać prawidłowy URI zasobu, jako producenta wybieramy Raw, zaś jako model
Raw Queue. URI powinno mieć nast˛epujac
˛ a˛ postać:
ipp://{$serwer}/printers/{$drukarka}
($serwer to nazwa lub IP serwera druku, zaś $drukarka to nazwa drukarki). Adres
taki może wygladać
˛
nast˛epujaco:
˛
ipp://10.0.0.3/printers/laserowa
•
SMB
Jedyne co musimy zrobić to dodać drukark˛e z użyciem odpowiedniego backendu
- Windows Printer via SAMBA i podać prawidłowy URI, na koniec musimy wskazać sterownik danej drukarki. W przypadku systemów MS z serii 95/98/Me URI
powinno mieć nast˛epujac
˛ a˛ postać:
smb://{$serwer}/{$drukarka}
($serwer to nazwa lub IP serwera druku, zaś $drukarka to nazwa drukarki). Adres
taki może wygladać
˛
nast˛epujaco:
˛
smb://wodzu/laserowa
W przypadku systemów z serii NT (NT4, 2000, XP Professional) może być konieczne podanie konta użytkownika i hasła:
smb://{$użytkownik}:{$hasło}@{$serwer}/{$drukarka}
np.:
smb://jasio:mojehasło@wodzu/laserowa
Konfiguracja serwera
Aby udost˛epnić w sieci zainstalowana˛ drukark˛e, musimy odpowiednio
skonfigurować demona cupsd, jego konfiguracja jest przechowywana w pliku
/etc/cups/cupsd.conf.
199
Domyślnie CUPS pozwala jedynie na drukowanie lokalne, aby uzyskać dost˛ep z sieci musimy dokonać zmian w pliku konfiguracji. Należy odszukać sekcj˛e oznaczona˛
znacznikami <Location /></Location>. Dost˛ep z innych maszyn konfigurujemy
za pomoca˛ opcji Allow From {$klient} ($klient to nazwa lub adres IP lub klasa
adresów, którym udost˛epniamy drukark˛e). Poniższy przykład przedstawia udost˛epnienie drukarek dla lokalnego interfejsu i maszyny o adresie 10.0.0.12.
<Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From 10.0.0.12
</Location>
Jeśli chcemy mieć możliwość zdalnej administracji za pośrednictwem HTTP/HTTPS
powinniśmy dodatkowo ustawić dost˛ep (zgodnie z powyższymi wskazówkami) dla
sekcji: /admin, /admin/conf.
•
IPP
Protokół IPP jest używany domyślnie przez CUPS i nie wymaga żadnych dodatkowych przygotowań.
•
SMB
W systemie musi być zainstalowany i działajacy
˛ pakiet Samba. Aby systemy Microsoftu mogły "widzieć" drukarki CUPS należy dokonać modyfikacji w głównym
pliku konfiguracji Samby - /etc/samba/smb.conf. Należy usunać
˛ z niego wszystkie opcje dotyczace
˛ druku z sekcji [global], zaś w ich miejsce wstawić poniższe
linijki:
printing = cups
printcap name = cups
Na koniec należy przygotować sekcj˛e drukarek. Prosty przykład pliku konfiguracji
pakietu Samba może wygladać
˛
nast˛epujaco:
˛
[global]
netbios name = shilka
workgroup = pod_cisami
security = share
printing = cups
printcap name = cups
[printers]
comment = Drukarki
printable = yes
path = /var/spool/samba
Jako, że Windows pre-formatuje dokumenty zanim wyśle je przez sieć do drukarki, musimy nauczyć CUPS’a odpowiednio takie pre-formatowane dokumenty
obsługiwać. W tym celu musimy wyedytować plik /etc/cups/mime.convs i odkomentować w nim linijk˛e
application/octet-stream
application/vnd.cups-raw
w pliku /etc/cups/mime.types zaś, należy odkomentować linijk˛e
application/octet-stream
Po tych operacjach wymagany jest oczywiście restart usługi CUPS.
200
0
-
Przy tak skonfigurowanym serwerze drukark˛e w MS Windows dodajemy standardowo, musimy jedynie samemu dostarczyć odpowiedni sterownik. Istnieje możliwość
umieszczenia takiego sterownika na serwerze Samba, wymaga to jednak dodatkowych operacji konfiguracyjnych. Wi˛ecej na ten temat odnajdziemy w dokumentacji
Samby.
Zarzadzanie
˛
kolejka˛ druku
Zarzadzanie
˛
wydrukami jest możliwe z poziomu przegladarki
˛
internetowej, programów dla X-Window oraz z poziomu linii wiersza poleceń. Z pośród tych ostatnich
mamy do dyspozycji: lpstat, lpmove, cancel, lpq oraz lprm. Programy te znajduja˛
si˛e w pakiecie cups-clients.
Test drukarki i rozwiazywanie
˛
problemów
Drukarka powinna działać od razu po zainstalowaniu, można to przetestować z
poziomu panelu konfiguracji drukarki drukujac
˛ stron˛e testowa.˛ W razie problemów
pierwsza˛ rzecza˛ jaka˛ należy zrobić to przejrzeć plik rejestrowania bł˛edów (log):
/var/log/cups/error_log. Jeśli ciagle
˛
nie możemy odnaleźć źródła problemu
możemy spróbować właczyć
˛
wysoki poziom raportowania bł˛edów. Dokonujemy to
przez edycj˛e w pliku /etc/cups/cupsd.conf i przestawienie ustawienia opcji
"LogLevel" z "info " na "debug" lub " debug2" np.:
LogLevel debug2
Kiedy rozwia˛żemy problem należy przywrócić poprzedni poziom raportowania ze
wzgl˛edu na szybki przyrost obj˛etości logów. Po każdej modyfikacji pliku konfiguracji
należy przeładować demona:
DHCPD - Dynamic Host Configuration Protocol Daemon
DHCP to protokół pozwalajacy
˛ urzadzeniom
˛
pracujacym
˛
w sieci LAN na pobieranie
ich konfiguracji IP (adresu, maski podsieci, adresu rozgłoszeniowego itp.) z serwera.
Ułatwia on administracj˛e dużych i średnich sieci.
Instalacja
Aby uruchomić serwer DHCP musimy oczywiście zainstalować go. Instalacja w PLD
jest prosta:
# poldek -i dhcp
Konfiguracja usługi przechowywana jest w pliku /etc/dhcpd.conf , z pakietem dostarczona jest przykładowa konfiguracja, pozwalajaca
˛ uruchomić usług˛e po zmianie
zaledwie kilku wartości. Przedstawiona poniżej sekcja zawiera parametry dla określonej podsieci. Dla wi˛ekszej jasności w poniższym przykładzie użyto skróconej wersji konfiguracji.
ddns-update-style
ad-hoc;
# Sekcja konfiguracji hostów z podsieci o podanym adresie i masce
201
subnet 192.168.0.0 netmask 255.255.255.0 {
# domyślna brama sieciowa
option routers
192.168.0.1;
# maska
option subnet-mask
255.255.255.0;
# nazwa domeny (FQDN)
option domain-name
"domain.org";
# adres serwera DNS (kolejne dodajemy po przecinku)
option domain-name-servers
192.168.1.1;
# zakres dzierżawionych adresów IP (z właczon
˛
a˛ obsługa˛ protokołu BOOTP)
range dynamic-bootp 192.168.0.128 192.168.0.255;
# domyślny czas dzierżawy (w sekundach)
default-lease-time 21600;
# maksymalny czas dzierżawy (w sekundach)
max-lease-time 43200;
}
Wewnatrz
˛ przedstawionej sekcji (ograniczonej nawiasami klamrowymi) umieszczane sa˛ opcje jakie zwykle podajemy przy statycznej konfiguracji interfejsu sieci. Powyższa konfiguracja b˛edzie przydzielać komputerom dynamiczne adresy IP z zakresu 192.168.0.128 - 192.168.0.255 na okres 21600 sekund, jednak nie wi˛ekszy niż
43200 sekund.
I to już prawie koniec, teraz zostaje nam sprawdzenie pliku /etc/sysconfig/dhcpd
. Znajdujemy w nim linijki:
# The names of the network interfaces on which dhcpd should
# listen for broadcasts (separated by space)
DHCPD_INTERFACES=""
W cudzysłów wpisujemy nazwy interfejsów na których b˛edzie nasłuchiwał dhcpd
(np. eth1). Po tej operacji wystarczy uruchomić lub zrestartować usług˛e.
Statyczne przypisanie konfiguracji
Aby komputery mogły za każdym razem uzyskać taka˛ sama˛ konfiguracj˛e, musimy
dla każdego z nich dodać odpowiednie wpisy w pliku konfiguracji. Konfiguracje
hostów umieszczamy wewnatrz
˛ przedstawionej powyżej sekcji konfiguracji podsieci
(uwaga na nawiasy klamrowe).
host nazwa_hosta {
hardware ethernet 12:34:56:78:AB:CD;
fixed-address 192.168.0.20;
}
Poszczególne komputery identyfikujemy za pomoca˛ adresów sprz˛etowych kart sieciowych (MAC). Powyższy przykład wymusza przydzielenie adresu IP 192.168.0.20
maszynie o MAC-u 12:34:56:78:AB:CD. Adresy MAC odczytamy za pomoca˛ programu ip, lub iconfig, szczegóły na ten temat odnajdziemy w sekcja Narz˛edzia sieciowe w
Rozdział 16.
202
Inne opcje
Poniżej zamieszczono przykłady innych nieco rzadziej używanych opcji.
Domena NIS:
option nis-domain
"domain.org";
Opcje protokołu NetBIOS:
#Adres serwera WINS
option netbios-name-servers
192.168.1.1;
#Rodzaj w˛
ezła NetBIOS
option netbios-node-type 2;
Adres serwera czasu NTP:
option ntp-servers
192.168.1.1;
Uruchomienie
Serwer uruchamiamy nast˛epujaco:
˛
# /etc/rc.d/init.d/dhcpd start
Konfiguracja klienta
Szczegółowy opis konfiguracji klienta DHCP umieszczono w sekcja Ethernet w Rozdział 15. Jeśli zechcemy sprawdzić poprawność konfiguracji przydzielonej hostowi
to wystarczy użyć programu ip, lub iconfig, szczegóły odnajdziemy w sekcja Narz˛edzia sieciowe w Rozdział 16.
Uwagi
W wi˛ekszości wypadków najlepszym wyborem b˛edzie przypisywanie
niezmiennych adresów IP dla każdej z maszyn, pozwoli to zachować porzadek
˛
i
lepsza˛ kontrol˛e nad siecia.˛ Jest to absolutnie konieczne w wypadku serwerów oraz
routerów, jednak przy tego typu maszynach zaleca si˛e zrezygnowanie z DHCP na
korzyść statycznej konfiguracji.
Domyślnie logi demona sa˛ rejestrowane przez syslog-a z ustawionym źródłem
(facility) na "daemon". Tego rodzaju komunikaty zwykle sa˛ zapisywane do pliku
/var/log/daemon , dlatego tam właśnie powinniśmy szukać informacji jeśli
wystapi
˛ a˛ jakieś problemy.
Exim - Transport poczty elektronicznej (MTA)
Usługa MTA (ang. message transfer agent) jest odpowiedzialna za przesył m.in. email mi˛edzy serwerami. Najpopularniejszymi przedstawicielami tego typu usług sa:˛
Sendmail, Postfix czy opisany przez nas Exim. Oto zalety jakie przemawiaja˛ za wybraniem Exim-a jako naszego MTA:
203
•
Ponieważ Sendmail nie posiada nawet połowy jego funkcji
•
Autoryzacja w Exim-ie zaimplementowana jest domyślnie
•
Współpracuje z bazami MySQL i z Postgres-em, a także ze zwykłymi plikami tekstowymi
•
Tom Kistner napisał do Exim użyteczna łatk˛e, rozbudowywujac
˛ a˛ Exim o obsług˛e
programów antywirusowych, demona SpamAssasin (skanera antyspamowego)
oraz wykrywania bł˛edów MIME - dzi˛eki temu nie potrzebujemy wielkich i
zasobożernych programów w perlu
•
Za to Tomasz Kojm napisał bardzo dobry program antywirusowy: Clam AntiVirus
- darmowy, w dodatku rewelacyjnie współpracujacy
˛ z Exiscanem
Podsumowujac
˛ - Exim jest rewelacyjnym MTA. Jego możliwości konfiguracji pozwoliły mi na zbudowanie dosyć rozbudowanego serwera poczty obsługujacego
˛
zarówno konta lokalne jak i konta zapisane w bazie danych MySQL. Dodatkowe możliwości to np. przeszukiwanie plików konfiguracyjnych serwera cvs w poszukiwaniu
adresów docelowych dla aliasów w domenie cvs.rulez.pl. O rzeczach takich jak klasyfikowanie maili czy sa˛ spamem czy nie już nawet nie wspomn˛e. W dodatku Exim
jest całkiem bezpiecznym MTA (wersja 4.x wg. securityfocus jak narazie dorobiła si˛e
jednego bł˛edu - w końcu jakaś cena musi być za te wodotryski). Zreszta˛ konstrukcja
omawianego MTA na poczatku
˛
doprowadzała mnie do szału, gdyż Exim nie może
sobie poradzić z smtp-auth via PAM z racji braku uruchamiania autoryzacji z własnego uid/gid zamiast root ;-)
Instalacja
Instalacja pakietu jest prosta. Uruchamiamy program: poldek i wykonujemy:
poldek -i exim
Oczywiście zanim wykonamy zalecenie startu demona powinniśmy dokonać konfiguracji, która˛ opisuje nast˛epny rozdział.
Budowa pliku konfiguracji
Wszelkich zmian w konfiguracji dokonujemy w pliku /etc/mail/exim.conf. Na
poczatek
˛
wyjaśnimy jak zorganizowany jest plik konfiguracyjny, wyglada
˛ to mniej
wi˛ecej tak:
# główna sekcja ...
opcje i dyrektywy sekcji głównej
begin sekcja1
opcje i dyrektywy sekcji1
begin sekcja3
...
Tak wi˛ec plik ten jest zbudowany z sekcji, które rozpoczynaja˛ si˛e słowem begin nazwa, z wyjatkiem
˛
sekcji głównej, która jest na samym poczatku
˛
pliku i nie posiada
swojego begina. Sekcje również nie maja˛ żadnych słów kluczowych, które by je zamykały - po prostu poczatek
˛
begin nowej sekcji oznacza zakończenie poprzedniej. I
tak, standardowo mamy nast˛epujace
˛ sekcje:
204
•
główna - odpowiedzialna za podstawowe ustawienia Exim
•
acl - listy kontroli dost˛epu, filtrowania, odrzucania i akceptowania poczty
•
routers - hm, najprościej jest to przetłumaczyć jako routery, czyli reguły kierowania
wiadomości do odpowiednich transporterów
•
transports - tutaj tworzymy sposoby dor˛eczenia poczty
•
retry - ustawienia ponowień
•
rewrite - reguły do przepisywania nagłówków
•
authenticators - reguły do autoryzacji
Co to sa˛ te całe ’transportery’ i ’routery’? Właściwie to serce Exima. Jeżeli Exim dostaje jakiegoś maila to najpierw puszcza go przez routery, które można porównać do
reguł ipchains/iptables - jeżeli mail załapie si˛e na jakaś
˛ reguł˛e (router) to jest przekazywany do transportu określonego przez ten router. Inaczej mówiac
˛ router w Eximie
kieruje maila do odpowiedniego transportera. Transporter natomiast robi już z mailem co należy - dor˛ecza go lokalnie, albo przekierowywuje gdzieś indziej albo odsyła
do innego serwera. Wiem, że w tym momencie może wydawać si˛e to skomplikowane, ale nie przejmujcie si˛e, to tylko wiedza teoretyczna która na poczatku
˛
nie b˛edzie
wam potrzebna. Musiałem natomiast wam wytłumaczyć, że sa˛ sekcje i że musicie
nauczyć si˛e tego, iż jak napisz˛e ’dopisać w sekcji głównej’ to należy coś dopisać na
poczatku
˛
pliku.
Zanim zaczniemy konfiguracj˛e demona SMTP, musimy koniecznie dodać rekord MX
do każdej strefy DNS obsługiwanej przez nasz serwer. Informacje na ten temat zawarto w sekcja BIND - Serwer Nazw.
Domeny lokalne to takie, które Exim ma traktować jako ’swoje’ domeny. Mail zaadresowany @jakas.domena.lokalna który dotrze do Exim zostanie dostarczony lokalnie. Domeny takie definiuje w dyrektywie domainlist local_domains. Standardowo,
przyjmowana jest poczta wysyłana do domeny identycznej jak hostname serwera:
domainlist local_domains = @
Znak @ oznacza właśnie ’moja nazwa’. Aby dopisać kolejne domeny wystarczy dodać je do tej listy rozdzielajac
˛ je dwukropkami:
domainlist local_domains = @ : domena.pl : baseciq.org : \
/etc/mail/local_domains
Poza domena.pl, baseciq.org, Exim b˛edzie teraz także akceptował domeny wypisane
w pliku /etc/mail/local_domains. Domeny tam należy wpisywać w oddzielnych
linijkach. Exim o tyle fajnie działa, że po dopisaniu ścieżki do pliku, wystarczy go raz
zrestartować. Jakiekolwiek kombinacje w /etc/mail/local_domains nie b˛eda˛ wymagały restartu. Tak wi˛ec najwygodniej b˛edzie dopisać do pliku konfiguracyjnego:
domainlist local_domains = @ : /etc/mail/local_domains
I po prostu powpisywać wszystkie domeny do /etc/mail/local_domains.
Domeny dla których mamy być zapasowym MX’em tworzy si˛e bardzo łatwo. Linijk˛e
pod domainlist local_domains jest domainlist relay_to_domain. Działa to w taki
sam sposób jak konfiguracja domen lokalnych, czyli, piszemy:
domainlist relay_to_domains = /etc/mail/relay_to_domains
Od teraz, Exim b˛edzie akceptował każda˛ poczt˛e zaadresowana˛ do domen zawartych
w pliku /etc/mail/relay_to_domains. A co z nia˛ zrobi? Jak wiadomo, jeżeli domena ma kilka MX’ów, to Exim b˛edzie starał si˛e ja˛ dostarczyć do serwera o najniższym
priorytecie MX. Chyba że on ma najniższy, to wygeneruje bład.
˛
205
Relaying, czyli określenie kto może przez nasz serwer wysyłać poczt˛e. I tutaj, list˛e adresów i hostów buduje si˛e w podobny sposób do local_domains i relay_to_domains.
Wystarczy stworzyć list˛e o nazwie relay_from_hosts:
hostlist
relay_from_hosts = 127.0.0.1 : 192.168.0.0/16
Uwaga! Już w tym momencie możemy sprawdzić działania serwera. Wystarczy że
przeładujemy demona i wyślemy e-mail do istniejacego
˛
konta użytkownika. Przy
takiej konfiguracji poczta b˛edzie docierała do skrzynek typu mbox.
Skrzynki pocztowe
Exim potrafi umieszczać poczt˛e zarówno w skrzynkach typu mbox (pliki tekstowe w
/var/mail/) jak i coraz popularniejszych skrzynkach typu Maildir (pliki przechowywanie w katalogu umieszczonym w katalogu domowym użytkownika). Ze wzgl˛edu
na wsteczna˛ zgodność Exim domyślnie używa tych pierwszych, aby używać Maildira wykonujemy nast˛epujace
˛ czynności:
W sekcji konfiguracji transporterów odszukujemy opcj˛e "local_delivery", tam wstawiamy znak komentarza przed opcja˛ "file =" i dodajemy linijki:
maildir_format = true
directory=${home}/Mail/Maildir
Jak si˛e łatwo domyślić druga z opcji wskazuje miejsce przechowywanie skrzynek. Po
modyfikacji omawiana sekcja może wygladać
˛
nast˛epujaco:
˛
local_delivery:
driver = appendfile
# file = /var/mail/$local_part
delivery_date_add
envelope_to_add
return_path_add
group = mail
mode = 0660
maildir_format = true
directory=${home}/Mail/Maildir
Exim samodzielnie tworzy skrzynki pocztowe (oba rodzaje), wystarczy jedynie wysłać e-mail na konto użytkownika.
Możemy przekazać dostarczanie poczty do skrzynek programowi Procmail. Wystarczy, że w sekcji routerów usuniemy znaki komentarza z kolejnych wierszy zaczynajacych
˛
si˛e od "procmail:", podobnie post˛epujemy w sekcji transporterów w miejscu zaczynajacym
˛
si˛e od wiersza "procmail_pipe:". Na koniec musimy jeszcze tylko
umieścić plik konfiguracji Procmaila: .procmailrc w katalogu domowym użytkownika.
Różne opcje
Czasami (czytaj: gdy mamy sieczk˛e w /etc/hosts) Exim zgłasza si˛e nie jako serwer.domena.pl a jako sam ’serwer’. Jeżeli zmiana wpisów w /etc/hosts nie pomaga,
albo gdy chcemy aby nasze MTA przedstawiało si˛e inaczej niż hostname maszyny na
którym stoi wystarczy ustawić (badź
˛ dodać gdy jej nie ma) opcj˛e primary_hostname w
głównej sekcji:
primary_hostname = serwer.domena.pl
W czasach zabawy z Sendmail-em podawałem także sposób na ograniczenie bannera, który si˛e pojawiał po telnecie na port 25. W Exim-ie nie jest to skomplikowane i
służy do tego opcja smtp_banner w sekcji głównej:
206
smtp_banner = $primary_hostname ESMTP $tod_full
Spowoduje to wyświetlanie nast˛epujacego
˛
tekstu jako bannera:
220 serwer.domena.pl ESMTP Wed, 23 Jul 2003 15:18:04
+0200
Chyba nie musz˛e tłumaczyć, że aby usunać
˛ dat˛e należy wywalić $tod_full?
Teraz zajmiemy si˛e aliasami. Plik z aliasami powinien znajdować si˛e w
/etc/mail/aliases. Jest to czysty plik tekstowy, wprowadzone w nim zmiany
wymagaja˛ wydania polecenia newaliases. Restart demona nie jest konieczny. Jeżeli
jednak nie macie pewności czy tam powinien być plik z aliasami, w sekcji routers
odszukajcie ciag
˛ system_aliases: - jest to definicja routera odpowiedzialnego za
rozwiazywanie
˛
aliasów. Tam też, w linijce data widać ścieżk˛e do pliku z aliasami:
system_aliases:
driver = redirect
allow_fail
allow_defer
data = ${lookup{$local_part}lsearch{/etc/mail/aliases}}
file_transport = address_file
pipe_transport = address_pipe
Autoryzacja SMTP
Jeżeli z naszego SMTP korzystaja˛ użytkownicy spoza sieci lokalnej przyda nam si˛e
autoryzacja. Sprawa w Exim-ie jest dosyć zawiła. Otóż Exim zbyt wcześnie zrzuca
uprawnienia root, tak że opisywany na wielu stronach opis zrobienia autoryzacji via
PAM najcz˛eściej nie działa. Z pomoca˛ przyjdzie nam pakiet cyrus-sasl, a dokładniej
pwcheck daemon (w PLD cyrus-sasl-saslauthd). W sekcji AUTHENTICATORS wpisujemy nast˛epujace
˛ linijki (lub kasujemy komentarze #)
plain:
driver = plaintext
public_name = PLAIN
server_prompts = :
server_condition = ${if saslauthd{{$1}{$3}}{1}{0}}
# powyższy wpis zadziała przy saslauthd -a shadow, jeżeli
# uruchomicie saslauthd -a pam (np. PLD) wpiszcie wtedy:
# server_condition = ${if saslauthd{{$1}{$3}{smtp}}{1}{0}}
server_set_id = $2
login:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
server_condition = ${if saslauthd{{$1}{$2}}{1}{0}}
# powyższy wpis zadziała przy saslauthd -a shadow, jeżeli
# uruchomicie saslauthd -a pam (np. PLD) wpiszcie wtedy:
# server_condition = ${if saslauthd{{$1}{$2}{smtp}}{1}{0}}
server_set_id = $1
Ostatnia˛ rzecza˛ przy saslauthd (uruchomionym z opcja˛ -a pam) jaka˛ trzeba stworzyć
(lub sprawdzić czy jest) to plik /etc/pam.d/smtp:
#%PAM-1.0
#
# example PAM file for saslauthd - place it as /etc/pam.d/
# (e.g. /etc/pam.d/smtp if you want to use saslauthd for SMTP
# AUTH)
#
auth required /lib/security/pam_listfile.so
207
item=user sense=deny file=/etc/security/blacklist
onerr=succeed
auth required /lib/security/pam_unix.so
auth required /lib/security/pam_tally.so
file=/var/log/faillog onerr=succeed no_magic_root
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_tally.so deny=0
file=/var/log/faillog onerr=succeed no_magic_root
account required /lib/security/pam_unix.so
session required /lib/security/pam_unix.so
Pozostaje mi tylko wam przypomnieć, że przed sprawdzaniem autoryzacji należy
także uruchomić pwcheck saslauthd
# echo ’pwcheck_method:saslauthd’ > /etc/sasl/smtpd.conf
Syfrowanie SSL
Exim sobie bardzo dobrze radzi z połaczeniami
˛
szyfrowanymi przy użyciu protokołu
SSL (wspiera metod˛e STARTTLS). Wystarczy wygenerować odpowiednie certyfikaty:
$ openssl genrsa -out /etc/mail/exim.key 1024
Generating RSA private key, 1024 bit long modulus
.......++++++
..............................++++++
e is 65537 (0x10001)
$ openssl req -new -x509 -days 365 -key /etc/mail/exim.key -out \
/etc/mail/exim.crt
Using configuration from /var/lib/openssl/openssl.cnf
You are about to be asked to enter information that will be
incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ’.’, the field will be left blank.
----Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:Mazowsze
Locality Name (eg, city) []:Warsaw
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Baseciq Ltd.
Organizational Unit Name (eg, section) []:Baseciq’s Mail Server
Common Name (eg, YOUR name) []:viper.baseciq.org
Email Address []:[email protected]
Oczywiście na pytania odpowiadajcie podajac
˛ swoje dane... Po takim zabiegu do sekcji głównej Exim należy dopisać:
tls_certificate = /etc/mail/exim.crt
tls_privatekey = /etc/mail/exim.key
tls_advertise_hosts = *
Po tym zabiegu i restarcie Exim powinien bez problemu komunikować si˛e po SSL,
co zreszta˛ widać w logach:
2003-09-07 01:48:36 19vmnC-0006EG-27 <= [email protected] H=plug.atn.pl
[217.8.186.28] U=exim P=esmtp X=TLSv1:DES-CBC3-SHA:168 S=2909
id=ebb601c374e2$80dace00$cab00a12@fv
Dawniej Exim mógł nasłuchiwać porcie 465 jedynie przy użyciu inetd, w nowszych
wersjach wystraczy że ustawimy odpowiednie opcje:
208
daemon_smtp_ports = 25 : 465
tls_on_connect_ports = 465
Warto by było, żeby także pop3d obsługiwał SSL natywnie ssl (bez jakichś stunneli
i innych wynalazków). Ja osobiście polecam demonik tpop3d, którego konfiguracja
jest bardzo prosta. Instalujemy tpop3d:
# poldek -i tpop3d
a
nast˛epnie
wystarczy
że
standardowe
listen-address
w
pliku
/etc/tpop3d.confzmienimy na takie:
listen-address: 0.0.0.0;tls=stls,/etc/mail/exim.crt,/etc/mail/exim.key \
0.0.0.0;tls=immediate,/etc/mail/exim.crt,/etc/mail/exim.key
Od teraz tpop3d na porcie 110 b˛edzie obsługiwał SSL po wykonaniu komendy STLS
(np. TheBat potrafi tak zaczać
˛ sesj˛e SSL) a na porcie 995 b˛edzie od razu używał SSL
(TheBat, Outlook Express).
Quota
Generalnie nie ma sensu m˛eczyć kernela i filesystemu żeby pilnował quoty na poczt˛e.
Szczególnie gdy MTA samo sobie może z tym poradzić. Służy do tego parametr quota
w konfiguracji transportów. I tak, w najprostszy sposób można lokalna˛ quot˛e per
user ustawić w konfiguracji transportu local_delivery (odpowiedzialnego za lokalne
dostarczanie poczty):
local_delivery:
driver = appendfile
file = /var/mail/$local_part
delivery_date_add
envelope_to_add
return_path_add
# A tutaj dodajemy quot˛
e w wysokości 20MB:
quota = 20M
Proste, prawda? Tak naprawd˛e ma to zastosowanie w systemach poczty wirtualnej
gdzie możemy w bazie danych przechowywać quot˛e użytkownika i można skonstruować zapytanie SQL do odpytania ile miejsca ma dany użytkownik. Ale jeżeli
nie możecie sobie poradzić z quota˛ systemowa,˛ możecie zamiast quota = 20M dopisać coś takiego:
quota = ${lookup{$local_part}lsearch{/etc/mail/quota.conf}{$value}{0M}}
Od tego momentu w pliku /etc/mail/quota.conf możesz trzymać wielkości skrzynek dla poszczególnych użytkowników. Jeżeli ktoś nie zostanie tam wymieniony, to
nie b˛edzie miał żadnych limitów na swoja˛ skrzynk˛e pocztowa.˛ Plik taki powinien
wygladać
˛
mniej wi˛ecej tak:
lukasz: 100M
kflis: 5M
ania: 20M
I tak oto ja mam 100mb na poczt˛e, kubuś tylko 5, a siostra 20 MB ;) Podobnym parametrem każdego transportera jest message_size_limit. Wystarczy wpisać:
message_size_limit = 10M
Podobnie jak powyżej, można zrobić to na bazie pliku - wystarczy zamiast
/etc/mail/quota.conf użyć np. /etc/mail/size_limits.conf ;-) BTW. na końcu
209
linijki z quota,˛ gdzie mamy ’0M’ możemy wstawić np. ’20M’. Wtedy, osoby nie
dopisane do /etc/mail/quota.conf b˛eda˛ miały 20MB limitu (limit domyślny).
Oczywiście jak na Exim przystało, od quoty jest wi˛ecej bajerków. Chyba najbardziej
pożadanym
˛
b˛edzie opcja quota_warn_message. Jest to nic innego jak mail ostrzegaja˛
cy usera o tym, że skrzynka jest zapchana po same brzegi. Zanim jednak polecisz to
wdrażać, zainteresuj si˛e jak to działa. Otóż po dostarczeniu każdego maila Exim b˛edzie sprawdzał czy został przekroczony konkretny próg (podany w megabajtach lub
w procentowo). Jeżeli tak, wygeneruje on odpowiednia˛ wiadomość. I tak, dodajemy
do molestowanego przez nas local_delivery nast˛epujace
˛ opcje:
quota_warn_message = "\
Content-Type: text/plain; charset=ISO-8859-2\n\
To: $local_part@$domain\n\
Reply-to: Administratorzy sieci <[email protected]>\n\
Subject: Informacja o Twoim koncie pocztowym\n\
\n\
*** Ta wiadomość została wygenerowana automatycznie ***\n\
\n\
Uprzejmie informujemy, iż skrzynka pocztowa została zapełniona w 90%\n\
swojej pojemności. W przypadku 100% nie b˛
eda˛ dostarczane\n\
do Ciebie nowe wiadomości. Opróżnij skrzynk˛
e pocztowa˛ ze starych\n\
wiadomości.\n"
quota_warn_threshold = 90%
Dodanie skanerów antywirusowych
Aby Exim współpracował z jakimś antywirusem należy najpierw wybrać i zainstalować program antywirusowy. Doświadczenie uczy, że najlepszy jest program Clamav.
Instalujemy wi˛ec Clamav
# poldek -i clamav clamav-database
Po
zainstalowaniu
Clamav
musimy
zmodyfikować
plik
konfiguracyjny
/etc/mail/exim.conf w sekcji głównej ustawiamy typ antywirusa:
av_scanner = clamd:/var/lib/clamav/clamd.socket
Po dwukropku ustawiamy ścieżk˛e do socketu antywirusa (w przypadku clamav zajrzyj do pliku /etc/clamav.conf). W miejscu gdzie wpisaliśmy clamd, możemy
wpisać także i inny typ skanera. Niestety, żaden z innych obsługiwanych (sophie,
kavdaemon, drweb) skanerów nie jest darmowy. Jeżeli natomiast wolicie mks, to możecie użyć takiej opcji:
av_scanner = mksd
Kolejnym etapem, jest stworzenie reguł do filtrowania maili z wirusami. W tym celu,
dopisujemy do sekcji głównej pliku konfiguracyjnego Exim:
acl_smtp_data = exiscan
Teraz zaczynamy grzebanie w sekcji acl, gdzie dopisujemy (najlepiej na samym poczatku):
˛
exiscan:
deny message = Znaleziono wirusa. \n\
Virus or other harmful content found: $malware_name
delay = 1s
malware = *
warn message = X-MIME-Warning: Serious MIME defect detected ($demime_reason)
demime = *
210
condition = ${if >{$demime_errorlevel}{2}{1}{0}}
warn message = Message-ID: <E$message_id@$primary_hostname>
condition = ${if !def:h_Message-ID: {1}}
accept
Pierwszy wpis odpowiednio skanuje cały e-mail i jeśli zostanie znaleziony wirus lub
inna zawartość uznana za szkodliwa˛ przez skaner antywirusowy to taki mail jest odrzucany oraz informacja o znalezionym wirusie zostaje wyświetlona z jednosekudnowym opóźnieniem. Te opóźnienie ma na celu unikniecia ewentualnego zapchania serwera poczty poprzez ucia˛żliwego użytkownika co chwila próbujacego wysłać
poczt˛e uznana˛ za szkodliwa.˛ Kolejny warunek spowoduje iż maile z uszkodzonymi
nagłówkami MIME zostana˛ odpowiednio oznaczone (czyli, także, duże maile podzielone na cz˛eści, o czym niestety autor exiscana (aut. łatki dla Exim-a) nie wspomina, dlatego ich nie odrzucamy). Ostatni warunek ma na celu wyeliminowanie
sytuacji gdy jakaś wiadomość, która dotarła do naszego serwera poczty nie posiada unikalnego identyfikatora. W takim przypadku generujemy i dopisujemy własny
Message-ID.
Aby skaner av mógł sprawdzać poczt˛e Exima musi zostać dodany do grupy exim.
Dokonujemy tego poleceniem groupadd albo edytujac
˛ po prostu plik /etc/group:
[...]
exim:x:79:clamav,mail
[...]
Kolejny feature jaki daje exiscan to odrzucanie plików z załacznikiem
˛
o określonym
rozszerzeniu. W tym celu dopisujemy zaraz po exiscan: nast˛epujace
˛ linijki:
deny message = Niedozwolone zalaczniki. \n\
Blacklisted file extension ($found_extension) detected.
condition = ${if match \
{${lc:$mime_filename}} \
{\N(\.exe|\.pif|\.bat|\.scr|\.lnk|\.vbs)$\N} \
{1}{0}}
delay = 1s
log_message = Blacklisted file extension ($found_extension) detected.
Powyższa regółka ma na celu zablokowanie możliwości wysyłanie wiadomości, których załacznikami
˛
sa˛ pliki: *.exe, *.pif, *.bat, *.scr, *.lnk oraz *.vbs. Teraz, jeżeli nie
chcemy aby skanowane były maile pochodzace
˛ od danych adresów ip dopisujemy
(jeżeli chcemy aby Ci ludzie też nie mogli wysyłać plików *.com, to po poprzedniej
regułce, jeżeli oni b˛eda˛ mogli, to przed):
accept hosts = /etc/mail/dontscan
Teraz, w pliku /etc/mail/dontscan umieszczamy adresy IP badź
˛ klasy adresowe z
których poczta ma nie być skanowana.
Jeżeli natomiast chcecie, by poczta przeskanowana u was w przypadku gdy wróci
w jakiś sposób z powrotem do naszego serwera (np. poprzez alias na innym serwerze) nie była ponownie skanowana, możecie zaczać
˛ oznaczać poczt˛e odpowiednimi
znacznikami oraz przyjać
˛ że poczta z tym znacznikiem nie była ponownie skanowana. Tak wi˛ec, przed końcowym accept dodajemy:
warn message = X-Scan-Signature: ${hmac{md5}{atutajwpiszhaslo} \
{$body_linecount}}
Exim spowoduje dodanie zaszyfrowanego ciagu
˛ znaków składajacego
˛
si˛e z hasła i
wielkości maila. Dzi˛eki temu ktoś kto nie pozna waszego hasła nie b˛edzie mógł sfałszować informacji o tym że mail został już zeskanowany. Teraz, aby taka poczta przechodziła bez skanowania, na samym poczatku
˛
po exiscan: dopisujemy:
211
accept condition = ${if eq {${hmac{md5}{atutajwpiszhaslo} \
{$body_linecount}}}{$h_X-Scan-Signature:} {1}{0}}
Ustawienie takich regułek z tym samym hasłem na kilku serwerach spowoduje że
gdy mail b˛edzie przechodził przez kilka z nich, tylko jeden b˛edzie musiał go przeskanować.
Walka ze spamem
Zjawisko spamu jest niezwykle ucia˛żliwe. W niektórych Stanach w USA traktowane
jest w kategoriach kryminalnych. Zapewne znasz jego definicj˛e lub przynajmniej
wiesz jak spam wyglada.
˛
W skrócie jest to wiadomość e-mail, której nie chciałeś
otrzymać. Exim posiada wbudowana˛ obsług˛e filtra antyspamowego opartego na
technice dnsbl, może wykorzystwać zarówno czarne listy jak i białe listy
nadawców oraz adresów serwerów.
Kolejnym bardzo prostym ale niezwykle skutecznym w walce ze spamem jest maksymalne opóźnianie procesu komunikacji pomiedzy klientem wysyłajacym
˛
poczte a
serwerem MTA. Nie tylko odcina to cz˛eść robotów spamerskich ale także zmiejsza
ryzyko przecia˛żenia serwera.
Przejdźmy do konfiguracji. Wszystkie te wpisy powinny znaleść si˛e w sekcji ACL
CONFIGURATION w obr˛ebie acl_check_rcpt:.
Wymuszamy helo/ehlo
deny message = Wymagane RFC HELO/EHLO zanim wyslesz wiadomosc. \n\
RFCs mandate HELO/EHLO before mail can be sent.
condition = ${if or{{!def:sender_helo_name}{eq{$sender_helo_name}{}}}{yes}{no}}
delay = 5s
log_message = No HELO/EHLO.
Definujemy własne białe listy. Jeśli nasz zestaw regół okazałby si˛e zbyt restrycyjny możemy oznaczyć aby pewne domeny były traktowane "ulgowo".
accept domain = +local_domains
condition = /etc/mail/whitelist
Sprawdzamy czy serwer nadawcy figuruje na listach RBL
deny message = Serwer nadawcy figuruje na liscie RBL \n\
Server $sender_host_address is at RBL: \
$dnslist_domain\n$dnslist_text
delay = 5s
dnslists = blackholes.mail-abuse.org : \
dialup.mail-abuse.org : \
dnsbl.njabl.org : \
sbl.spamhaus.org : \
list.dsbl.org : \
cbl.abuseat.org : \
relays.ordb.org : \
bl.spamcop.net
hosts = ! +relay_from_hosts
log_message = Listed at RBL list: $dnslist_domain\n$dnslist_text.
deny message = Serwer nadawcy figuruje na liscie RBL \n\
Server $sender_host_address is at RBL: $dnslist_domain.
hosts = ! +relay_from_hosts
dnslists = bogusmx.frc-ignorant.org/$sender_host_name : \
dns.rfc-ignorant.org/$sender_host_name
delay = 5s
log_message = Listed at RFC-Ignorant.
Teraz dokonujemy weryfikacji podanego HELO
212
HELO nie może być postaci localhost.localhomain
deny message = Niepoprawne HELO. \n\
$sender_helo_name is a stupid HELO.
hosts = !+relay_from_hosts
condition = ${if match {$sender_helo_name}{\N^(127\.0\.0\.1|localhost(\.localdomain)?)
delay = 5s
log_message = Stupid localhost HELO.
HELO musi być nazwa˛ domenowa˛ (hostname)
deny message = HELO musi byc nazwa domenowa. \n\
HELO must be hostname.
condition = ${if !match {$sender_helo_name}\
{\N.*[A-Za-z].*\N}{yes}{no}}
delay = 5s
log_message = Helo must be hostname.
Według RFC821 HELO musi być pełna˛ nazwa˛ domenowa˛ (Fully Qualifield
Domain Name).
deny message = HELO nie wyglada poprawnie. Zobacz RFC 821. \n\
HELO must contain a Fully Qualifield Domain Name. See RFC821.
condition = ${if !match{$sender_helo_name} \
{\N.*[A-Za-z].*\..*[A-Za-z].*\N}{yes}{no}}
delay = 5s
log_message = HELO is not a FQDN.
Eliminujemy sytuacj˛e gdy nadawca jako HELO podaje serwer z naszej domeny np.
domena.pl
deny message = Wykryto zafalszowane RFC HELO. \n\
Fake HELO detected: $sender_helo_name.
condition = ${if eq{$sender_helo_name}\
{\N^(.*\.)?domena\.pl$\N}{yes}{no}}
delay = 5s
log_message = Fake HELO from host $sender_helo_name.
Kolejne dwa warunki sa˛ bardzo restrycyjnymi testami. Formalnie przez RFC nie jest
wymagane aby domena miała zdefiniowany rekord MX. Lecz każdy szanujacy
˛ si˛e
administrator poważnej domeny zawsze zadba aby odpowiednie serwery figurowaly jako MX. RFC zaleca aby jeśli już jest zdefiniowany rekord MX dla domeny, to aby
był on postaci FQDN
deny message = Brak zdefiniowanego rekordu MX dla domeny. \n\
No MX envelope sender domain $sender_address_domain.
hosts = ! : !+relay_from_hosts
senders = ! :
condition = ${if eq{${lookup dnsdb{mx=$sender_address_domain}{$value}fail}}{fail}{yes}
delay = 5s
log_message = No MX record in DNS.
deny message = Rekord MX w DNS musi byc postaci FQDN. \n\
MX for transport sender domain $sender_address_domain must be FQDN.
hosts = ! : !+relay_from_hosts
senders = ! :
condition = ${if !match {${lookup dnsdb{mx=$sender_address_domain}{$value}fail}}\
{\N.*[A-Za-z].*\..*[A-Za-z].*\N}{yes}{no}}
delay = 5s
log_message = MX record is not a FQDN.
Krótkie wyjaśnienie wykorzystanych opcji
213
• deny message
Określamy jaka informacja zwrotna pojawi si˛e u nadawcy.
• delay
Opóźnienie po jakim komunikat określnony jako message zostanie zwrócony
nadawcy.
• dnslist
Lista systemów z bazami blokujacymi
˛
serwery open relay. Wymienione tutaj powinny skutecznie powstrzymać spam. Jeżeli nadal dostajesz niechciane maile, wykonaj nast˛epujace
˛ czynności. Sprawdź w nagłówku wiadomości adres IP serwera,
który przekazał Twojemu MTA poczt˛e. Wejdź na stron˛e: www.ordb.org/lookup/11
i wpisz adres IP do sprawdzenia. Jeżeli wyszukiwanie w bazie ordb.org nie przyniesie rezultatów, wejdź tutaj: http://www.ordb.org/lookup/rbls/?host=w.x.y.z,
gdzie zamiast symbolicznego zapisu podajemy adres IP. Skonstruowane w ten
sposób zapytanie dokona sprawdzenia, czy dany adres IP figuruje na innych czarnych listach. Pozytywny rezultat testu powinien zwrócić w odpowiedzi list˛e systemów RBL (Relay Black List). Można ja˛ wykorzystać dopisujac
˛ do naszej regułki.
Uważaj na system block.blars.org figuruje w nim smtp.wp.pl.
• hosts
Podana lista serwerów. W powyższym przykładzie jest to !+relay_from_hosts
co oznacza, że cała regółka dotyczy połacze
˛ ń z wszystkich serwerów za wyjatkiem
˛
tych zdefiniowanych jako relay_from_hosts.
• log_message
Informacja jaka zostanie zapisana w dzienniku systemowym exima czyli
/var/log/exim/main.log
Teraz należałoby właczyć
˛
wszystkie usługi jakie zainstalowaliśmy
#
#
#
#
#
/etc/rc.d/init.d/exim start
/etc/rc.d/init.d/saslauthd start
/etc/rc.d/init.d/clamd start
/etc/rc.d/init.d/tpop3d start
/etc/rc.d/init.d/rc-inetd restart
Na koniec przykładowy zapis z dziennika systemowego Exima
2004-03-04 21:05:24 H=(sina.com) [218.79.119.92] F=< [email protected] > \
rejected RCPT < [email protected] >: \
Serwer 218.79.119.92 figuruje na czarnej liście dnsbl.sorbs.net
Obsługa wielu domen w Eximie
Jeżeli czytasz ta˛ cz˛eść opisu konfiguracji exima stanałeś
˛ przed problemem obsługi
przez niego wi˛ecej niż jednej domeny. Exim jest jak najbardziej do tego przystosowany. Poniżej zamieszczam listing z pliku /etc/mail/exim.conf
virtusertable_alias:
driver = redirect
allow_fail
allow_defer
214
data = ${lookup{$local_part@$domain}lsearch{/etc/mail/virtusertable}}
virtusertable_defaultalias:
driver = redirect
allow_fail
allow_defer
data = ${lookup{@$domain}lsearch{/etc/mail/virtusertable}}
Powyższy przykład umieść umieść na poczatku
˛
sekcji routers. Dla przypomnienia
dodam, że poczatek
˛
sekcji oznacza si˛e słowem kluczowym begin.
Jak słusznie zauważyłeś, wpisy z virtusertable do złudzenia przypominaja˛ te z
system_aliases. Działa to właściwie w ten sam sposób. Podczas odbierania przesyłki exim czyta linijk˛e data. Ma w niej zdefiniowane, że ma szukać na podstawie
local_partczyli to co jest przed znakiem @ oraz domain czyli cz˛eści domenowej adresu. Wartości które zostana˛ podstawione zamiast tych zmiennych zostana˛ porównane z plikiem /etc/mail/virtusertable. Jeżeli wynik porównania wypadnie pomyślnie poczta zostanie dostarczona do odpowiedniego użytkownika, jeżeli zaś nie,
odpytane zostana˛ aliasy systemowe. Jeżeli i tam użytkownik nie zostanie odnaleziony, zostanie wysłana wiadomość z odpowiednia˛ informacja˛ do nadawcy z komunikatem bł˛edu. Cz˛eść defaultalias jest prawie identyczna. Różnica tkwi jedynie w
opcji data. Sprawdzana jest jedynie cz˛eść domenowa. Poniżej zamieszczam listing z
pliku /etc/mail/virtusertable
[email protected] user
[email protected] user2
@jakasdomena.pl user3
Jak widać budowa pliku jest prosta i czytelna. User3 b˛edzie otrzymywał cała˛ poczt˛e
z domeny jakasdomena.pl. Po tych zabiegach exim powinien być już przygotowany
do obsługi wielu domen. Musisz pami˛etać aby go zrestartować po dokonaniu modyfikacji jego pliku konfiguracyjnego.
# /etc/rc.d/init.d/exim restart
Automatyczna odpowiedź - Vacations
W przypadku, gdy masz zamiar gdzieś wyjechać na dłużej i nie b˛edziesz miał dost˛epu do poczty, dobrym pomysłem jest ustawienie automagicznej odpowiedzi dla
ludzi, którzy do Ciebie pisza.˛ Tu z pomoca˛ przychodzi nam opcja w Eximie.
Na poczatku
˛
edytujemy plik /etc/mail/exim.conf i w sekcji routers przed
localuser router dodajemy nast˛epujace
˛ linijki:
user_vacation:
driver = accept
check_local_user
# nie odpisujemy na bł˛
edy badź
˛
listy dyskusyjne
condition = "${if or {{match {$h_precedence:} {(?i)junk|bulk|list}} {eq {$sender_a
no_expn
require_files = /var/mail/vacation/${local_part}/vacation.msg
# nie odpisujemy na maile od list dyskusyjnych oraz na powiadomienia o bł˛
edach
senders = " ! ^.*-request@.*:\
! ^.*@list*.*:\
! ^owner-.*@.*:\
! ^postmaster@.*:\
! ^listmaster@.*:\
! ^mailer-daemon@.*\
! ^root@.*"
transport = vacation_reply
215
unseen
user = ${local_part}
no_verify
Nast˛epnie tworzymy katalog /var/mail/vacation , w którym b˛eda˛ si˛e znajdować
katalogi zawierajace
˛ nazw˛e użytkownika oraz pliki z informacjami o powodzie jego nieobecności. Powód taki wpisujemy do pliku vacation.msg znajdujacego
˛
si˛e w
/var/mail/vacation/NAZWA_UŻYTKOWNIKA/. Gdy już mamy te ustawienia za soba˛
w sekcji transport dodajemy nast˛epujace
˛ linijki:
vacation_reply:
driver = autoreply
file = /var/mail/vacation/$local_part/vacation.msg
file_expand
from = System Automatycznej Odpowiedzi <$original_local_part@$original_domain>
log = /var/mail/vacation/$local_part/vacation.log
once = /var/mail/vacation/$local_part/vacation.db
once_repeat = 7d
subject = ${if def:h_Subject: {Re: ${quote:${escape:${length_50:$h_Subject:}}} (au
text = "\
Witaj $h_from\n\n\
Ta wiadomość została wygenerowana automatycznie\n\
Tekst poniżej zawiera informacj˛
e od użytkownika:\n\
====================================================\n\n\
"
to = "$sender_address"
Ważna˛ cz˛eścia˛ tutaj jest opcja once_repeat, która sprawdza jak cz˛esto nadawcy b˛eda˛
otrzymywać odpowiedzi. W tej konfiguracji jest to co 7dni.
To wszystko, teraz musimy jeszcze zrestartować Exima i możemy jechać na urlop.
# /etc/rc.d/init.d/exim restart
Heimdal - Implementacja protokołu Kerberos
Heimdal jest implementacja˛ nowoczesnego sieciowego protokołu uwierzytelniania
użytkowników Kerberos. Użytkownik po standardowym zalogowaniu za pomoca˛
hasła na czas trwania sesji otrzymuje specjalny unikalny klucz (w terminologii kerberos’a nazywany biletem (ang. ticket)) za pomoca˛ którego może uzyskać dost˛ep do
innych usług w sieci już bez konieczności dodatkowego podawania hasła.
Każda sieć posiada wydzielony serwer Kerberos, zwany KDC (Key Distibution Center) którego zadaniem jest zarzadzanie
˛
centralna˛ baza˛ kluczy (m.in. wydawanie nowych kluczy oraz odpowiadanie na pytania dotyczace
˛ ich autentyczności).
Uwaga:Kerberos nie zapewnia dystrybucji bazy użytkowników w sieci - do tego celu
najlepiej użyć usługi NIS.
Instalacja i konfiguracja KDC
Za pomoca˛ poldka instalujemy serwer i narz˛edzia heimdal’a:
# poldek -i heimdal heimdal-server
Edytujemy plik konfiguracyjny /etc/heimdal/krb5.conf. Plik ten używany jest
przez biblioteki heimdal’a i powinien być obecny na wszystkich maszynach, na których b˛edziemy używali kerberos’a (na serwerze i klientach)
[libdefaults]
default_realm = FOO.PL
216
clockskew = 300
v4_instance_resolve = false
[realms]
FOO.PL = {
kdc = kdc.foo.pl
kpasswd_server = kdc.foo.pl
admin_server = kdc.foo.pl
}
[domain_realm]
.foo.pl = FOO.PL
foo.pl = FOO.PL
default_realm określa domyślna˛ domen˛e kerberos’a. Zamiast FOO.PL wpisujemy
wybrana˛ nazw˛e domeny, typowo jest to pisana wielkimi literami nazwa naszej domeny dns. kdc.foo.pl zast˛epujemy adresem serwera, na którym uruchomiony jest
serwer KDC heimdal’a.
clockskew określa maksymalna˛ różnic˛e czasu (w sekundach) pomi˛edzy serwerem a
klientami (jeżeli różnica czasu b˛edzie wi˛eksza niż podana, kerberos odmówi współpracy) dlatego dobrze w sieci uruchomić także usług˛e synchronizacji czasu ntp.
Sekcja [realms] definiuje domeny kerberosa. Można tu wymienić kilka niezależnych domen, określajac
˛ dla nich lokalizacj˛e serwerów kerberosa. kdc.foo.pl zast˛epujemy oczywiście nazwa˛ hosta na którym b˛edzie uruchomiona usługa kdc.
Ostatnia sekcja [domain_realm]określa mapowanie nazw dns na domeny kerberosa. Na tej podstawie heimdal wie na podstawie nazwy dns hosta w jakiej domenie
kerberos’a si˛e znajduje. Nazwa dns zaczynajaca
˛ si˛e od kropki pasuje do dowolnej
poddomeny podanej domeny.
uruchamiamy usług˛e dystrybucji kluczy KDC:
# service heimdal start
Do zarzadzania
˛
domena˛ kerberos’a używamy narz˛edzia kadmin. Inicjalizujemy domen˛e i dodajemy użytkownika, w tym przypadku mrk (zostawiajac
˛ domyślnie proponowane wartości):
# kadmin -l
kadmin>init FOO.PL
kadmin>add mrk
Opcja -l uruchamia kadmin w trybie lokalnym, program musi być uruchomiony z
konta root. Możemy także dopisać do pliku /etc/heimdal/krb5.acl:
[email protected] all
dajac
˛ użytkownikowi [email protected] prawo do administracji kerberosem - w tym
przypadku kadmin wołamy z parametrem -p użytkownik
Logujemy si˛e w systemie na koncie zwykłego użytkownika (w naszym przykładzie
mrk) i próbujemy si˛e zalogować do domeny kerberosa:
$ kinit
kinit domyślnie próbuje uzyskać bilet dla zalogowanego użytkownika, można to
zmienić podajac
˛ użytkownika jako parametr.
Sprawdzamy, czy kerberos wystawił nam bilet (ticket):
$ klist
Credentials cache: FILE:/tmp/krb5cc_1000_pSN1Vv
Principal: [email protected]
Issued
Expires
Principal
217
Apr 13 11:02:40
Apr 13 21:02:40
krbtgt/[email protected]
Logowanie do systemu
Instalujemy moduł pam-pam_krb5.
# poldek -i pam-pam_krb5
Zmieniamy wybrane pliki /etc/pam.d/*, dodajac
˛ dodatkowo sprawdzanie hasła za
pomoca˛ nowego modułu:
Przykładowo /etc/pam.d/login wykorzystywany przez program login poprawiamy tak:
#zmieniamy linijk˛e
auth
required
pam_unix.so
sufficient
required
pam_unix.so
pam_krb5.so use_first_pass
na:
auth
auth
i dodajemy:
session optional pam_krb5.so
W ten sposób możemy si˛e zalogować przy użyciu standardowej metody sprawdzania haseł w /etc/shadow (pam_unix.so) lub w domenie kerberos’a (pam_krb5.so)
Analogicznie
poprawiamy
inne
pliki,
np.
/etc/pam.d/gdm,
/etc/pam.d/xscreensaver
Po tych poprawkach powinniśmy móc zalogować si˛e już podajac
˛ hasło kerberos’a.
Po zalogowaniu możemy jeszcze za pomoca˛ polecenia klist sprawdzić czy kerberos
wystawił nam bilet:
$ klist
Konfiguracja poszczególnych usług
Kolejnym etapem jest "skerberyzowanie" poszczególnych usług w naszej sieci tak,
by uwierzytelniały użytkownika na podstawie wystawionego biletu kerberos’a. Zaprezentujemy to na przykładzie sshd, cyrus-imap’a oraz apache’a - opis post˛epowania w przypadku innych usług obsługujacych
˛
uwierzytelnianie kerberos jest podobny, Każda skerberyzowana usługa musi mieć utworzone własne konto w domenie Kerberos’a (tzw. service account). Z kontem tym zwiazany
˛
jest klucz, który
musi być znany zarówno kdc i usłudze. Konto usługi przeważnie jest w postaci:
nazwa_usługi/hostname, przy czym hostname musi być pełna˛ nazwa˛ hosta wraz
z domena,˛ czyli tym, co zwraca hostname:
$ hostname --fqdn
Ponadto należy zadbać o poprawne odwzorowanie tej nazwy w DNS - opis jak właściwie ustawić hostname znajduje si˛e podstawach konfiguracji sieci
SSH
Tworzymy konto dla daemona sshd. Konto musi miec nazw˛e w postaci:
host/hostname
218
# kadmin -l
kadmin> add -r host/host.foo.pl
Parametr -r powoduje, że do konta zostanie przypisany losowy klucz (hasło). Klucz
ten jest zapisany jako jeden z atrybutów użytkownika w bazie użytkowników domeny Kerberos’a (dokładnie w /var/lib/heimdal/heimdal.db). By sshd miał także
dost˛ep do tego klucza robimy:
kadmin> ext_keytab host/host.foo.pl
Powyższe polecenie zapisuje klucz zwiazany
˛
z kontem usługi do tzw. tablicy kluczy
(keytab), z której to tablicy sshd może go pobrać. Klucz zostaje zapisany w domyślnej tablicy kluczy znajdujacej
˛ si˛e w pliku /etc/heimdal/krb5.keytab. Z tej tablicy
kluczy domyślnie korzystaja˛ usługi używajace
˛ kerberos’a.
By
sshd
uwierzytelniał
użytkowników
za
pomoca˛ kerberos’a
do
pliku
/etc/ssh/sshd_config dodajemy jeszcze linijki:
GSSAPIAuthentication yes
do pliku konfiguracyjnego klienta /etc/ssh/ssh_config dopisujemy:
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
Opcja GSSAPIDelegateCredentials określa, czy bilet kerberosa ma być przekazany
na maszyn˛e, na która˛ si˛e logujemy.
Po restarcie sshd, jeżeli mamy wystawiony bilet kerberosa powinniśmy móc zalogować si˛e przez ssh na nasz serwer bez pytania o hasło.
Powyższy opis dotyczy sytuacji, gdy serwer sshd znajduje si˛e na tej samej maszynie
co kdc. Jeżeli sshd jest na innej maszynie w sieci, musimy wyeksportować klucz do
innej tablicy kluczy:
kadmin> ext_keytab host/host.foo.pl sshd.keytab
a nast˛epnie przenieść plik sshd.keytab na maszyn˛e na której mamy uruchomione
sshd. Trzeba jeszcze poinformować sshd, że ma szukać klucza w innej lokalizacji niż
standardowe krb5.keytab. W pliku /etc/sysconfig/sshd dopisujemy:
export KRB5_KTNAME=/etc/heimdal/sshd.keytab
Cyrus IMAP
Doinstalowujemy plugin gssapi do sasl’a
# poldek -i cyrus-sasl-gssapi
Tworzymy konto dla cyrrus’a. Konto ma mieć nazw˛e w postaci imap/hostname:
kadmin> add -r imap/host.foo.pl
exportujemy klucz do tablicy kluczy:
kadmin> ext_keytab /etc/heimdal/cyrus.keytab
Wybieramy inna˛ niż domyślna tablic˛e kluczy, ponieważ cyrus imap pracuje z uprawnieniami użytkownika ’cyrus’ i jako taki nie ma prawa czytania domyślnej tablicy
/etc/heimdal/krb5.keytab.
Dajemy dost˛ep do tablicy kluczy użytkownikowi cyrus:
219
chown cyrus.root /etc/heimdal/cyrus.keytab
chmod 660 /etc/heimdal/cyrus.keytab
Na koniec musimy jeszcze poinformować cyrus’a gdzie ma szukać klucza. W pliku
/etc/sysconfig/cyrus-imapd dodajemy:
export KRB5_KTNAME=/etc/heimdal/cyrus.keytab
Przykładowe programy klienckie, które potrafia˛ użyć protokołu kerberos do uwierzytelnienia użytkownika to evolution i mutt
Apache
Doinstalowujemy moduł apache’a obsługujacy
˛ uwierzytelnianie za pomoca˛ kerberos’a:
# poldek -i apache-mod_auth_kerb
Dodajemy konto usługi w domenie kerberos’a:
kadmin> add -r HTTP/hostname
hostname zast˛epujac
˛ nazwa˛ hosta na którym uruchomiony jest apache.
Exportujemy klucz, zmieniamy uprawnienia:
kadmin> ext HTTP/hostname /etc/heimdal/httpd.keytab
# chown http.root /etc/heimdal/httpd.keytab
# chmod 660 /etc/heimdal/httpd.keytab
lokalizacj˛e tablicy kluczy możemy tak jak wcześniej podać apache’owi globalnie
przez zmienna˛ środowiskowa,˛ dopisujac
˛ do /etc/sysconfig/apache:
export KRB5_KTNAME=/etc/heimdal/httpd.keytab
Można to także zrobić za pomoca˛ dyrektywy Krb5Keytab w pliku konfiguracyjnym
apache’a
Przykładowa konfiguracja dost˛epu może wygladać
˛
nast˛epujaco:
˛
<Directory "/home/users/mrk/public_html/kerberos">
AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate on
KrbMethodK5Passwd on
KrbAuthRealms FOO.PL
Krb5Keytab /etc/heimdal/httpd.keytab
require user [email protected]
</Directory>
Próba dost˛epu z prawdopodobnie zakończy si˛e pytaniem o hasło. Naszym celem
jest jednak dost˛ep do serwisu www’a za pomoca˛ biletu kerberos’a, bez zb˛ednego
podawania hasła. W firefox’ie wpisujemy url: about:config, i szukamy pozycji:
network.negotiate-auth.delegation-uris
network.negotiate-auth.trusted-uris
Określaja˛ one url’e, dla których przegladarka
˛
ma zastosować rozszerzenie negotiate.
Wpisujemy tam nazwy dns naszego serwisu www oddzielone przecinkami. Teraz,
jeśli mamy aktualny bilet (sprawdzamy przez klist), powinniśmy zostać wpuszczeni
bez pytania o hasło. Rozszerzenie negotiate oprócz firefox’a powinny obsługiwać
także mozilla i epiphany - o innych mi nie wiadomo.
220
Jabber 2 - Serwer typu Instant Messaging
Wstep
˛
Protokół jabber służy głównie do przesyłania wiadomości typu Instant Messaging
(czyli działa podobnie jak inne znane komunikatory np. icq, tlen, gadu-gadu itp.).
Zaleta˛ jabbera jest to, że jest otwarty, zapewnia darmowa˛ i pełna˛ infrastruktur˛e (serwery, a także klienty) dla osób prywatnych i użytkowników komercyjnych. Charakteryzuje si˛e także dużym bezpieczeństwem - rozmowy, a także komunikacja mi˛edzy
serwerami może być szyfrowana.
W PLD jest kilka serwerów obsługujacych
˛
komunikacj˛e protokołu XMPP, który jest
fundamentem Jabbera - zatwierdzonym przez IETF w formie RFC (RFC od 3920 do
3923). Używany przez wielu ISP jabberd w wersji 1.4, zdobywajacy
˛ popularność ejaberd czy opisywany poniżej jabberd w wersji 2.0.
Opisana zostanie podstawowa konfiguracja, umożliwiajaca
˛ połaczenia
˛
szyfrowane,
a do składowania danych przez jabberd2 wykorzystamy silnik SQL Postgresql.
Instalacja
Pakiet jabberd2 instalujemy za pomoca˛ poldka:
poldek> install jabber-common jabberd
Oczywiście, jeżeli do tej pory nie mamy zainstalowanego Postgresql należy zainstalować go także. Należy pami˛etać, że jabberd2 może współpracować także z MySQL,
sqlite3, a także znacznie prostrza˛ wersja˛ bazy db.
Konfiguracja DNS i rekordów SRV
Zanim zaczniemy, musimy stworzyć domen˛e, która jednoznacznie b˛edzie wskazywała na maszyn˛e Jabbera. Dodamy także rekordy SRV, które służa˛ do zapytań domenowych przez demony Jabbera.
Przykład konfiguracji zostanie przedstawiony dla serwera nazw Bind. Zmian dokonujemy w odpowiednim pliku stref w katalogu /var/lib/named/M.
; Jabber
jabber
IN
_jabber._tcp.jabber
_xmpp-server._tcp.jabber
_xmpp-client._tcp.jabber
A
10.1.1.1
IN SRV 20 0 5269
IN SRV 20 0 5269
IN SRV 20 0 5222
;Tu wpisujemy IP naszej domeny
domena.org.
domena.org.
domena.org.
Oczywiście nie możemy zapomnieć o zmianie rekordu serial w strefie domeny i restarcie demona named
Konfiguracja portów (jeżeli korzystamy z firewall-a)
W przypadku wykorzystwania zapór ogniowych w systemie powinniśmy otworzyć
porty tcp dla nast˛epujacych
˛
portów:
•
5222 - Dla komunikacji klienckiej (połaczenie
˛
nieszyfrowane)
•
5223 - Dla komunikacji klienckiej (połaczenie
˛
szyfrowane SSL)
•
5269 - Dla komunikacji mi˛edzy serwerami Jabbera
•
5347 - Dla komunikacji mi˛edzy serwerami Jabbera, wykorzystany przez
dodatkowe transporty (np. transport GG)
221
Pami˛etać należy, że powyższe porty sa˛ ustalone umownie i w plikach konfiguracyjnych demona Jabber, a także rekordach SRV możemy je zmienić (np. dla portu
klienckiego ustalić port 80) - jednak zaleca si˛e pozostawić proponowane wyżej porty.
Oczywiście, jeżeli nie chcemy aby nasz serwer był widoczny na zewnatrz
˛ naszej sieci
(np. jest przeznaczony tylko dla wewn˛etrzej sieci intranetowej) nie otwieramy portu
przeznaczonego do komunikacji mi˛edzy serwerami (u nas to porty 5269 i 5347).
Podstawowa konfiguracja Jabberd2
Możemy wreszcie skonfigurować wst˛epnie usług˛e jabberd2. Wszystkie pliki konfiguracyjne znajduja˛ si˛e w katalogu /etc/jabber.
W pliku /etc/jabber/c2s.xml w okolicy tagu "local" dodajemy nasza˛ domen˛e:

<local>

<id>jabber.domena.org</id>
W pliku /etc/jabber/sm.xml w pierwszych linijkach także dodajemy nasza˛ domen˛e:
<sm>

<id>jabber.domena.org</id>
Jeżeli chcemy, aby nasz serwer komunikował si˛e z innymi serwerami w pliku
/etc/jabber/jabberd.cfg kasujemy "#" w linijce z "s2s":
# After sm and c2s are configured to use a fully qualified domain name
# and proper SRV records are set in DNS uncoment this to enable
# communication
# with other Jabber servers
s2s
/etc/jabber/s2s.xml
Podstawowa konfiguracja jest już zrobiona. Domyślne ustawienie tzw. "storage" czyli
sposobu trzymania przez jabbera informacji o użytkownikach jest zrobione w PLD w
db. Przy małej ilości użytkowników jest to wystarczajacy
˛ sposób. Jednak przy wi˛ekszej ich ilości, bardziej praktyczne jest trzymanie tych danych w bazie SQL.
Konfiguracja dla SQL (Postgresql)
Przy poprawnie działajacym
˛
postgresie, z uprawnionego dla niego użytkownika
tworzymy baz˛e jabberd2
$ createdb -U postgres jabberd2
222
Nast˛epnie przypisujemy do tej bazy użytkownika jabberd2 i ustalamy dla niego hasło
i opcje dost˛epu do bazy:
$ createuser -P -U
Enter password for
Enter it again:
Shall the new user
Shall the new user
CREATE USER
postgres jabberd2
user "jabberd2":
be allowed to create databases? (y/n) n
be allowed to create more new users? (y/n) n
Teraz musimy wypełnić nowoutworzona˛ baz˛e odpowiednimi tabelami i polami. Z
katalogu /usr/share/doc/jabberd-2* należy rozpakować (najlepiej do katalogu
użytkownika, który może działać na bazie postgresa) plik db-setup.pgsql.gz.
Po rozpakowaniu przechodzimy do katalogu, gdzie został rozpakowany plik
db-setup.pgsql i wykonujemy:
$ psql -U jabberd2 jabberd2
jabberd2=>\i db-setup.pgsql
Baza postgresa jest gotowa. Połaczenie
˛
z baza˛ b˛edzie odbywać si˛e po localhost, tak
wi˛ec musimy zadbać o to, żeby postgres umożliwiał takie połaczenie
˛
Została nam jeszcze konfiguracja w plikach jabbera.
W pliku /etc/jabber/sm.xml szukamy sekcji "storage" i zmieniamy na:

<storage>

<driver>pgsql</driver>
Dla porzadku
˛
dodamy, że zamiast pgsql, możemy także wykorzytać: mysql, ldap,
sqlite (w zależności od mechanizmu jaki wybraliśmy).
W tym samym pliku szukamy nast˛epnie sekcji "pgsql" aby w odpowiednim miejscu
wpisać hasło dost˛epu do bazy jabberd2. Możemy tam także zmienić sposób dost˛epu:

<pgsql>

<host>localhost</host>
<port>5432</port>

<dbname>jabberd2</dbname>

<user>jabberd2</user>
<pass>tu_wpisujemy_hasło_do_bazy</pass>
Podobne zmiany wykonujemy w pliku /etc/jabber/c2s.xml. Umożliwiaja˛ one autentykacje użytkowników jabbera:

<authreg>

<module>pgsql</module>
I dalej w tym samym pliku (sekcja "pgsql")

<pgsql>

<host>localhost</host>
<port>5432</port>
223

<dbname>jabberd2</dbname>

<user>jabberd2</user>
<pass>tu_wpisujemy_hasło_do_bazy</pass>
</pgsql>
Po zrestartowaniu demona jabberd możemy si˛e już cieszyć bardziej zaawansowana˛
funkcjonalnościa˛ naszego komunikatora.
Szyfrowanie
Przed konfiguracja˛ samego jabbera, musimy sprawdzić czy mamy pakiet openssl i
wygenerować klucz:
# openssl req -new -x509 -newkey rsa:1024 -days 3650 -keyout privkey.pem -out server.pe
sam parametr -days 3650 możemy ustawić na krótszy lub dłuższy (oznacza on długość ważności certyfikatu - w naszym przypadku 10 lat).
Po wykonaniu powyższego polecenia i wpisaniu odpowiedzi na zadane pytania
(zwróćmy tylko uwag˛e, abyśmy w polu Common Name wpisali nasza˛ domen˛e, obsługiwana˛ przez serwer jabbera) usuniemy hasło z klucza prywatnego:
# openssl rsa -in privkey.pem -out privkey.pem
Nast˛epnie połaczymy
˛
oba klucze w jeden plik i skasujemy klucz prywatny:
# cat privkey.pem >> server.pem
# rm privkey.pem
Zmieniamy nazw˛e naszego certyfikatu (dla porzadku),
˛
przenosimy w odpowiednie
miejsce i nadajemy prawa:
# mv server.pem /var/lib/openssl/certs/jabber.pem
# chown root:jabber /var/lib/openssl/certs/jabber.pem
# chmod 640 /var/lib/openssl/certs/jabber.pem
Została nam jeszcze konfiguracja Jabbera. W pliku /etc/jabber/c2s.xml znajdujemy tag "ssl-port" i odkomentujemy go:

<ssl-port>5223</ssl-port>
</local>
Zdejmujemy komentarz także z tagu "require-starttls" (kilka linijek wyżej):

<require-starttls/>
Teraz w każdym z pi˛eciu plików konfiguracyjnych znajdujacych
˛
si˛e w /etc/jabber
tj.
router.xml, sm.xml, resolver.xml, s2s.xml, c2s.xml
znajdujemy
zakomentowany ciag
˛ wskazujacy
˛ na nasz certyfikat:
<!-<pemfile>/etc/jabber/server.pem</pemfile>
-->
224
Kasujemy komentarze (czyli ) i wpisujemy odpowiednia˛ scieżk˛e do naszego
certyfikatu:
<pemfile>/var/lib/openssl/certs/jabber.pem</pemfile>
Kolejny restart demona jabber i możemy cieszyć si˛e połaczeniami
˛
szyfrowanymi.
Zakończenie
Opisane powyżej sposoby konfiguracji nie wyczerpuja˛ oczywiście wszystkich aspektów. Zach˛ecamy do odwiedzenia strony z oryginalna˛ dokumentacja˛ jabbera13. Mimo,
że niektórym może sprawić problem j˛ezyk angielski, to podane przykłady w jasny
sposób omawiaja˛ także zaawansowane zagadnienia.
MySQL - System Zarzadzania
˛
Relacyjnymi Bazami Danych (ang.
RDBMS)
Co to jest MySQL?
MySQL jest Systemem Zarzadzania
˛
Relacyjnymi Bazami Danych. Znany i ceniony
jest przede wszystkim ze wzgl˛edu na swoja˛ niebywała˛ wydajność i szybkość działania. Świetnie nadaje si˛e do obsługi projektów internetowych, ale nie tylko - z powodzeniem używany jest również w wielkich projektach informatycznych organizacji,
takich jak chociażby NASA. Przeciwnicy MySQL’a cz˛esto mówia,˛ jak to bardzo brakuje mu wielu ficzerów, które posiadaja˛ prawdziwe, duże systemy baz danych. Ze
swojego doświadczenia wiem, że cz˛eść z tych ludzi nawet nie rozróżnia wersji systemu, które oferuje nam firma MySQL AB (producent MySQL).
Ogólne cechy MySQL
•
Napisany w C i C++ (wydajność!).
•
API dla wielu j˛ezyków programowania: C, C++, Eiffel, Java, Perl, PHP, Python,
Ruby, Tcl.
•
Pełna wielowatkowość,
˛
korzystajaca
˛ z watków
˛
kernela. Oznacza to, że MySQL
b˛edzie pracował na maszynie wieloprocesorowej, jeśli tylko taka˛ posiadasz.
•
Opcjonalna obsługa transakcji.
•
B-drzewa z kompresowanymi indeksami. To wam si˛e przyda, jakbyście mieli wieeeelkie bazy ;) Wystarczy powiedzieć, że znaczaco
˛ wpływa na czas wyszukiwania
i pobierania danych (wierszy) z bazy.
•
Istnieje możliwość "osadzenia" (ang. embed) serwera MySQL w aplikacji, która˛ piszemy. Jeśli ktoś potrzebuje funkcjonalności systemu baz danych, a niekoniecznie
chce si˛e bawić w klient-serwer, to czemu nie?
•
Duża liczba typów danych w kolumnach. Liczby, ciagi
˛ znakowe, obiekty binarne
(BLOB), data & czas, typy wyliczeniowe, zestawy. Na uwag˛e zasługuje fakt, że w
MySQL możemy dana˛ kolumn˛e dostosować do pewnej wielkości danych, które
zamierzamy w niej przechowywać (np. TINYINT, a nie INT), tym samym uzyskujemy wi˛eksza˛ wydajność i mniejsze zużycie pami˛eci (również dyskowej). Istnieje
możliwość definiowania niektórych typów danych jako narodowych (różne standardy kodowania chociażby).
•
Obsługa klauzul agregujacych
˛
i grupujacych
˛
SQL.
225
•
Złaczenia
˛
zewn˛etrzne (LEFT & RIGHT).
•
Komenda SHOW pozwalajaca
˛ przegladać
˛
informacje na temat baz, tabel i indeksów. Komenda EXPLAIN opisujaca
˛ prac˛e optymalizatora zapytań.
•
Bardzo prosty (z punktu widzenia administratora) system zabezpieczeń. Wszystkie hasła sa˛ szyfrowane.
•
Połaczenia
˛
z serwerem przez: TCP/IP, ODBC, JDBC.
•
Lokalizacja (w sensie j˛ezykowym) serwera. Komunikaty m.in. po polsku.
Instalacja
Instalacj˛e oprogramowania przeprowadzimy oczywiście z pomoca˛ naszego poldka.
Logujemy si˛e jako root, badź
˛ używamy polecenia sudo, jeżeli mieliśmy je skonfigurowane do tego celu. Pierwsza˛ rzecza,˛ która˛ b˛edziemy musieli zrobić, jest ściagni˛
˛ ecie
i zainstalowanie odpowiednich pakietów z repozytorium PLD. Można zrobić to używajac
˛ zarówno trybu wsadowego, jak i interaktywnego. Podam oba sposoby, wybierz sobie ten, który bardziej Ci odpowiada :) (osobiście wol˛e tryb interaktywny, ze
wzgl˛edu na tab-completion).
Najpierw uruchamiamy poldka. Można podać mu flag˛e -n, która oznacza źródło,
z którego zamierzamy ściagać
˛
pakiety. Jeśli nie podamy tej flagi, wówczas poldek
skorzysta z pierwszego źródła wpisanego do pliku /etc/poldek.conf. Ja korzystam
ze słowackiego serwera firmy Bentel Ltd., ale to nie ma znaczenia.
Instalacja w trybie wsadowym
W trybie wsadowym poldka, instalacja wyglada
˛ nast˛epujaco:
˛
# poldek -n bentel -i mysql mysql-client mysql-libs
Instalacja w trybie interaktywnym
W trybie interaktywnym poldka, instalacja wyglada
˛ tak:
# poldek -n
Wczytywanie
Przeczytano
Wczytywanie
Przeczytano
bentel
ftp://spirit.bentel.sk/mirrors/PLD/[...]/packages.dir.gz...
5116 pakietów
/root/.poldek-cache/packages.dir.dbcache.var.lib.rpm.gz...
450 pakietów
Witaj w poldkowym trybie interaktywnym. Wpisz "help" aby otrzymać pomoc.
poldek>
Teraz przyst˛epujemy do instalacji pakietów MySQL:
poldek> install mysql mysql-client mysql-libs
poldek sam zadba o spełnienie wymaganych zależności.
Konfiguracja MySQL
Żeby móc sprawnie (i bezpiecznie) używać naszego świeżo zainstalowanego serwera, musimy go odpowiedno skonfigurować.
226
Otworzymy naszym ulubionym edytorem tekstu plik konfiguracyjny demona MySQL. W przypadku użycia edytora Vim wydajemy nast˛epujac
˛ a˛ komend˛e:
# vim /etc/mysql/clusters.conf
Jeżeli nie zamierzamy zmieniać lokacji, w której b˛edzie u nas pracował MySQL, to po
prostu odkomentujmy linijk˛e z MYSQL_DB_CLUSTERS, a jeżeli zamierzamy umieścić
serwer MySQL w innym miejscu, to należy ta˛ linijk˛e odkomentować, ale dodatkowo
zmienić ścieżk˛e.
# standard setting
MYSQL_DB_CLUSTERS="/var/lib/mysql"
Upewniamy si˛e, że jesteśmy zalogowani na konsoli jako root i wydajemy polecenie:
# /etc/rc.d/init.d/mysql init
Polecenie to b˛edzie nam potrzebne tylko przy pierwszym uruchomieniu serwera służy ono zainicjalizowaniu klastra baz danych. Powiedzmy, że nasz katalog jest
"formatowany", ok? ;) Jeżeli pojawiłby wam si˛e bład,
˛ mówiacy
˛ o duplikacie wpisu
localhost-mysql dla klucza 1 - możecie go zignorować.j
Teraz możemy przystapić
˛
już do edycji właściwiego pliku konfiguracyjnego
RDBMS.
Używajac
˛
naszego
ulubionego
edytora
otwieramy
plik
/var/lib/mysql/mysqld.conf
# vim /var/lib/mysql/mysqld.conf
Teraz możemy przystapić
˛
do jego edycji. Pierwsza˛ grupa˛ opcji, na jaka˛ trafiamy jest:
# This section must be the first!
[mysqld]
datadir
= /var/lib/mysql/mysqldb/db
pid-file
= /var/lib/mysql/mysqldb/mysql.pid
port
= 3306
socket
= /var/lib/mysql/mysqldb/mysql.sock
user
= mysql
datadir to oczywiście katalog, w którym składowane b˛eda˛ nasze bazy. Można zo-
stawić tak jak jest.
user to użytkownik "pod którym" b˛edzie działał nasz serwer, w sensie - uruchomie-
nie serwera wyglada
˛ tak, jakby to ten użytkownik, reprezentowany przez zmienna˛
user go uruchomił (proces należy do niego). Można zmienić, chociaż nie polecam.
Nie zalecane jest wykorzystanie do tego użytkownika root!
To co nas natomiast bardzo interesuje, z dwóch wzgl˛edów, to opcja port. Chodzi o
dwa przypadki:
•
Chcemy umożliwić dost˛ep do naszego serwera baz danych z zewnatrz,
˛
a admin
naszej sieci "łaskawie" przekierował nam jakiś port z bramki na nasz komputer, ale
niestety nie jest to port 3306, z którego standardowo korzysta MySQL. Edytujemy
sobie opcje port w ten sposób, żeby wskazywała na ten, który mamy dost˛epny.
•
Mamy maszyn˛e z zewn˛etrznym IP (taka,˛ do której można si˛e podłaczyć
˛
z Internetu), nie blokowaliśmy jednak dost˛epu do MySQL, ale chcielibyśmy podnieść choć
troszeczk˛e poziom bezpieczeństwa i udost˛epnić serwer MySQL na innym porcie.
Wybieramy i jakiś i wpisujemy go jako wartość opcji port.
# Don’t allow connections over the network by default
skip-networking
227
Jeżeli chcemy zablokować dost˛ep do serwera MySQL z zewnatrz
˛ (z sieci), to... nie
robimy nic. A jeśli chcemy umożliwić innym komputerom łaczenie
˛
si˛e z naszym serwerem, to należy wykomentować (dodać #) linijk˛e z skip-networking.
Gdyby nam si˛e kiedyś coś popsuło (zapomnieliśmy hasła, nie możemy dostać si˛e do
bazy), to przyda si˛e odkomentowanie tej opcji:
# Emergency option. Use only if you really need this.
#skip-grant-tables
Przydatna˛ rzecza˛ (ale w sumie tylko, jeśli zamierzamy udost˛epniać bazy na
zewnatrz),
˛
b˛edzie właczenie
˛
logowania połacze
˛ ń i zapytań (zwalnia prac˛e serwera).
Dodam, że można oczywiście zmienić standardowa˛ ścieżk˛e, do której zapisywane
sa˛ logi.
# Log connections and queries. It slows down MySQL so
# it’s disabled by default
# log
= /var/log/mysql/log
Opcje z grupy set-variable wpływaja˛ bezpośrednio na prac˛e i wydajność serwera,
nie b˛ed˛e si˛e wi˛ec w nie zagł˛ebiał. To troch˛e trudniejszy temat. Jak ktoś chce bardzo
zoptymalizować prac˛e swojego serwera, to polecam lektur˛e dokumentacji MySQL.
Przydatna jest również znajomość zagadnień relacyjnych baz danych i SQL’a. Przykładowo zerkniemy na jedna˛ zmienna:˛
#set-variable = max_connections=100
Odkomentowanie tej linijki pozwoli nam na ustawienie maksymalnej liczby poła˛
czeń, które nasz MySQL b˛edzie mógł przyjać
˛ i obsłużyć w danej chwili. Wszystko
zależy od tego, w jakim celu używamy naszego RDBMS - należy postawić sobie
pytanie - "ile osób może chcieć podłaczyć
˛
si˛e do mojego serwera w jednej chwili i
ile takich połacze
˛ ń przypada średnio na jedna˛ osob˛e?". Odpowiedź wpisujemy w
zmienna˛ max_connections. Innym pytaniem mogłoby być "czy skrypty obsługujace
˛
moje strony www korzystaja˛ ze stałych (persistent) połacze
˛ ń?"
Ponieważ "Polacy nie g˛esi i swój j˛ezyk maja"
˛ odkomentujemy jeszcze jedna˛ linijk˛e w
pliku konfiguracyjnym, aby właczyć
˛
polskie komunikaty:
# Language
language
= polish
W tej chwili nasz serwer powinien być już skonfigurowany do pracy. Upewniamy
si˛e, że jesteśmy zalogowani na konsoli jako root i wydajemy polecenie:
# /etc/rc.d/init.d/mysql start
Wywołanie tego skryptu startowego spowoduje uruchomienie demona MySQL w
systemie. Upewnijmy si˛e jeszcze, że nasz serwer baz danych rzeczywiście "wstał":
# /etc/rc.d/init.d/mysql status
MySQL cluster /var/lib/mysql: running
Jak widać na załaczonym
˛
obrazku serwer działa. Ponieważ w tej chwili jest zainstalowany w sposób domyślny i dlatego mało bezpieczny, należy ustawić jakieś hasło
dla użytkownika mysql:
# mysqladmin -u mysql -S /var/lib/mysql/mysqldb/mysql.sock password ’naszehaslo’
Po opcji -S podajemy scieżk˛e do pliku mysql.sock, który powinien znajdować si˛e w
katalogu, w którym umieściliśmy MySQL.
228
Demon MySQL
Demon MySQL standardowo startuje wraz z systemem, ale przydaje si˛e znać dwie
komendy. Aby właczyć
˛
lub wyłaczyć
˛
serwer, b˛edac
˛ zalogowanym jako root, badź
˛
używajac
˛ komendy sudo, wydajemy polecenie:
# /etc/rc.d/init.d/mysql start | stop
wstawiajac
˛ oczywiście opcje start lub stop, w zależności od tego, co chcemy zrobić.
mysqladmin
mysqladmin jest narz˛edziem, za pomoca˛ którego możemy tworzyć i usuwać bazy
oraz przeładowywać konfiguracj˛e. Nie b˛edziemy go używać do wyłaczania
˛
serwera, bo od tego jest skrypt omówiony powyżej. Narz˛edzie wywołuje si˛e poleceniem
mysqladmin, a flagi i argumenty (opcje) polecenia służa˛ do wykonywania określonych zadań. Ponieważ wcześniej zmieniliśmy hasło dla użytkownika mysql, winniśmy przy każdym poleceniu dodać -u mysql i -p na końcu (aby klient zapytał nas o
hasło), np tak dla komendy status:
# mysqladmin -u mysql status -p
Enter password:
Uptime: 6720 Threads: 1 Questions: 1 Slow queries: 0 Opens: 6 \
Flush tables: 1 Open tables: 0 Queries per second avg: 0.000
Kilka przydatnych komend:
•
create nazwabazy - tworzy nowa˛ baz˛e danych o nazwie nazwabazy.
•
drop nazwabazy - usuwa baz˛e danych o nazwie nazwabazy
•
flush-privileges albo reload - obie opcje robia˛ to samo - przeładowuja˛ tablice
uprawnień. Powinniśmy wykonać przeładowanie zawsze, gdy dodamy np
nowego użytkownika do jakiejś bazy, ponieważ do czasu przeładowania takie
konto jest nieaktywne.
mysqldump
mysqldump to program, służacy
˛ do "zrzucania" danych - czyli do robienia kopii
zapasowych. Polecenie to jest przydatne w przypadku wykonywania kopii zapasowych podczas aktualizacji MySQL czy też przenoszenia danych na inny serwer.
Kilka przydatnych opcji:
• --databases baza1 baza2...
- zrzuca dane z baz, których nazwy podaliśmy w
liście oddzielonymi spacjami.
• --all-databases
- to samo co wyżej ale dla wszystkich bazy.
- dodaje DROP TABLE do skryptów tworzacych
˛
tabele z
backup-u (jak b˛edziemy przywracać dane). Przydatne, kiedy np chcemy
przywrócić już istniejac
˛ a˛ tabel˛e. Spowoduje to najpierw jej usuni˛ecie, a nast˛epnie
utworzenie od nowa z danych, które mieliśmy w kopii zapasowej. Ogólnie, żeby
uniknać
˛ ewentualnych problemów z duplikatami wierszy, itp. warto ta˛ opcj˛e
właczyć.
˛
• --add-drop-table
- w kopii nie zostanie zawarta informacja o tworzeniu tabel
(nazwy tabel, typy pól, indeksy itp.). Przydatne, jeżeli chcemy zrobić kopi˛e tylko
danych, a nie całej struktury bazy.
229
• --no-create-info
- Ta opcja pozwala zapisać sama˛ informacj˛e o strukturze bazy i tabel,
nie zapisuje natomiast danych.
• --no-data
- tworzy kopi˛e bazy nazwabazy wraz z rozszerzonymi informacjami MySQL, blokowaniem tabel, itd. Chyba najcz˛eściej stosowana opcja przy
robieniu kopii zapasowych.
• --opt nazwabazy
Należy pami˛etać, że wynik polecenia mysqldump należy przekierować (>) do jakiegoś pliku. Podam może kilka przykładów użycia tego programu. Zrzucenie zawartości bazy baza1 do pliku baza1_bkp.sql:
# mysqldump -u mysql --databases baza1 > baza1_bkp.sql -p
Stworzenie kopii zapasowej struktury bazy (bez danych) baza2 i zapisanie jej w pliku
baza2_str.sql:
# mysqldump -u mysql --databases --no-data baza2 > baza2_str.sql -p
Niezwykle przydatna˛ opcja˛ jest --opt omówiona wcześniej. Polecam jej stosowanie
do wykonywania kopii całej bazy, włacznie
˛
ze struktura˛ tabel i samymi danymi. Aby
stworzyć pełna˛ kopi˛e zapasowa˛ bazy baza1 i zapisać ja˛ w pliku baza1_kopia.sql:
# mysqldump -u mysql --opt baza1 > baza1_kopia.sql -p
Przywracanie baz wykonanych poleceniem mysqldump wyglada
˛ tak:
# mysql -u mysql baza1 < baza1_kopia.sql -p
Inna metoda (w sumie różniaca
˛ si˛e zapisem):
# mysql -u mysql -e ’source /sciezka_do_pliku/baza1_kopia.sql’ baza1 -p
phpMyAdmin
TODO
NFS - Network File System
NFS jest to usługa pozwalajaca
˛ udost˛epniać zasoby dyskowe komputerom w sieci.
Serwer udost˛epnia katalog(i) klientom, którzy moga˛ je podmontować i działać jak na
lokalnym systemie plików. Ponadto można z niego uruchamiać stacje bezdyskowe
lub tworzyć rozproszone systemy plików.
Serwer
Najpierw instalujemy demona portmap (o ile nie jest już zainstalowany) oraz demona NFS poleceniem:
# poldek -i portmap nfs-utils
Serwer NFS jest gotowy do pracy od razu po zainstalowaniu, wystarczy jedynie uruchomić usług˛e portmap, a nast˛epnie nfs (dokładnie w tej kolejności). Teraz możemy
przejść do konfiguracji udziałów sieciowych. Do podstawowej pracy serwera nie ma
potrzeby konfigurowania czegokolwiek, w pozostałych wypadkach należy przyjrzeć
si˛e plikowi /etc/sysconfig/nfsd, który może wygladać
˛
nast˛epujaco:
˛
SERVICE_RUN_NICE_LEVEL="+0"
230
#RPCMOUNTOPTIONS="--no-nfs-version 3"
RPCNFSDCOUNT=8
NFSDTYPE=K
• SERVICE_RUN_NICE_LEVEL
- ustala priorytet serwera
- opcja dla jader
˛
z serii 2.2, dla
współczesnych kerneli powinna być zakomentowana
• #RPCMOUNTOPTIONS="--no-nfs-version 3"
• RPCNFSDCOUNT
- podaje liczb˛e instancji serwera, czyli ilu klientów może obsłużyć
jednocześnie
- podaje czy serwer ma pracować jako oddzielny demon (U), czy w trybie jadra
˛
(K). Zalecane jest to drugie z rozwiaza
˛ ń, gdyż zapewnia wi˛eksza˛ wydajność.
• NFSDTYPE
Modyfikacja pliku konfiguracji wymaga restartu uslugi.
Udostepnianie
˛
Uruchomiliśmy serwer, teraz przyszedł czas na udost˛epnienie zasobów. W pliku
/etc/exports definiuje si˛e udost˛epniane katalogi, ich list˛e podajemy w postaci wierszy, które maja˛ nast˛epujac
˛ a˛ składni˛e:
$katalog
$klient1($opcja1,$opcja2,...)
$klient2($opcja1,$opcja2,...)
•
$katalog - udost˛epniony katalog. Warto tutaj wspomnieć, że jeżeli udost˛epniamy
dany katalog to nie możemy udost˛epnić w nowej regułce katalogu b˛edacego
˛
jego
ojcem jak i synem, jeżeli leża˛ na tym samym systemie plików. Udost˛epnianie partycji FAT, itp. też nie jest dobrym rozwiazaniem.
˛
•
$klient - IP lub nazwa komputera, któremu udost˛epniamy katalog. Można podać
także cała˛ sieć, wtedy zezwolimy wszystkim komputerom w sieci na przegladanie
˛
i/lub zapisywanie do katalogu.
•
$opcje - tutaj możemy ustalić m.in. czy zasób ma być udost˛epniony tylko do
odczytu, czy także do zapisu, oraz nałożyć inne ograniczenia. Wszystkie opcje
opisane sa˛ w manualu (man exports).
Oto przykładowe wpisy do /etc/exports:
/srv/pub
/home
192.168.0.1(ro) 192.168.0.2(rw)
192.168.0.0/255.255.255.0(rw)
Pomijajac
˛ sensowność wpisów, pierwszy wiersz daje prawo odczytu katalogu
/srv/pub komputerowi 192.168.0.1 i prawo odczytu i zapisu komputerowi
192.168.0.2. Drugi z kolei daje prawo zapisu do katalogu /home komputerom z
podsieci 192.168.0.0/24. Jeżeli modyfikujemy /etc/exports w trakcie pracy
serwera to musimy poinformować demona, żeby ponownie odczytał plik
konfiguracji. Przed tym możemy sprawdzić czy nasze wpisy sa˛ poprawne:
# exportfs -v
Polecenie to wyświetli list˛e katalogów gotowych do wyeksportowania, jeśli któryś z
udziałów nie jest wyświetlony, to prawdopodobnie popełniliśmy jakiś bład
˛ w składni. Gdy jesteśmy pewni, że chcemy udost˛epnić udziały NFS, to wydajemy polecenie:
231
# exportfs -rv
W PLD stworzono grup˛e systemowa˛ fileshare, która ma prawo do modyfikowania
konfiguracji udziałów sieciowych (NFS i SMB), bez konieczności posiadania praw
root-a. Aby nadać użytkownikowi takie prawo wystarczy zapisać go do tej grupy,
opis zarzadzania
˛
grupami użytkowników opisano w sekcja Grupy w Rozdział 14.
Klient
Konfiguracj˛e klienta rozpoczynamy od zainstalowania i uruchomienia usługi
portmap. Jeśli chcemy, aby zasoby NFS były montowane w trakcie startu
systemu, instalujemy pakiet nfs-utils-clients, dostarczajacy
˛
wymagany rc-skrypt:
/etc/rc.d/init.d/nfsfs.
Teraz przyszedł czas na połaczenie
˛
si˛e z zasobem NFS, w tym celu musimy go zamontować np.:
# mount serwer.net:/srv/pub /mnt/net -t nfs
serwer.net to IP badź
˛ nazwa naszego serwera, /srv/pub jest przykładowym udost˛epnionym katalogiem na serwerze (wpisaliśmy go wcześniej do /etc/exports).
Katalog /mnt/net to przykładowe miejsce podmontowania zasobu. Można użyć do-
datkowo flagi -o a po niej podać potrzebne nam opcje montowania. Pełna˛ list˛e opcji
znajdziemy w podr˛eczniku systemowym: man 5 nfs.
Jeśli nic nie stoi na przeszkodzie abyśmy podłaczali
˛
zasób przy starcie systemu, to
dodajemy wpis do /etc/fstab:
192.168.0.1:/srv/pub
/mnt/net
nfs
rw,hard,intr
0
0
Wpis wyglada
˛ znajomo, ale uwag˛e zwracaja˛ opcje hard i intr. Otóż hard oznacza, że
programy korzystajace
˛ z zasobów NFS w momencie awarii serwera zostana˛ zawieszone w oczekiwaniu na dost˛ep do danych i nie b˛edzie możliwości ich odwieszenia
w postaci polecenia kill, chyba, że dodamy opcj˛e intr dzi˛eki czemu b˛edziemy mogli zabić dany proces. Zamiast hard możemy użyć opcji soft, jednak w przypadku
awarii serwera NFS sygnalizuje bład
˛ programom korzystajacym
˛
z zasobów. Wada˛
tego rozwiazania
˛
jest to, że nie wszystkie programy potrafia˛ poradzić sobie z takim
komunikatem i może dojść do utraty danych.
Bezpieczeństwo serwera
Musimy zadbać o bezpieczeństwo naszego serwera, podstawowym sposobem
zabezpieczania zasobu jest ograniczenie dost˛epu. Możemy go ograniczać za
pomoca˛ ustawień w pliku /etc/exports, za pomoca˛ filtra pakietów lub plików
/etc/tcpd/hosts.allow i /etc/tcpd/hosts.deny, co zostało przedstawione
poniżej.
Najpierw blokujemy wszystkim dost˛ep do naszych usług wpisujac
˛ do pliku pliku
/etc/tcpd/hosts.deny:
portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL
Nast˛epnie w /etc/tcpd/hosts.allow wpisujemy komputery, którym zezwalamy
na korzystanie z wymienionych usług. Możemy zarówno wpisać adresy IP komputerów jak i cała˛ podsieć.
portmap: 192.168.0.0/255.255.255.0
232
lockd: 192.168.0.0/255.255.255.0
rquotad: 192.168.0.0/255.255.255.0
mountd: 192.168.0.0/255.255.255.0
statd: 192.168.0.0/255.255.255.0
NFS nie obsługuje autoryzacji na poziomie użytkownika, a jedynie na poziomie hosta. Z tego wzgl˛edu nie bardzo nadaje si˛e do udost˛epniania w Internecie, jeśli to tylko
możliwe lepiej użyć protokołu FTP lub WebDAV.
Dostrajanie wydajności
Wolne działanie protokołu NFS wskazuje przeważnie na brak odpowiedniego dostrojenia połaczenia,
˛
wystarczy ustawić kilka opcji by uzyskać zaskakujaco
˛ duży
wzrost wydajności. Podane poniżej zalecenia dotycza˛ konfiguracji klienta.
Na poczatek
˛
zajmiemy si˛e opcjami rsize i wsize. Dzi˛eki nim możemy zwi˛ekszyć
szybkość odczytu i zapisu plików na serwer. Manual systemowy radzi by ustawić im
na wartości: rsize=8192 i wsize=8192. Linijka w pliku /etc/fstab b˛edzie wygladać
˛
teraz nast˛epujaco:
˛
192.168.0.1:/usr/local
/usr/local
nfs
rw,hard,intr,rsize=8192,wsize=8192
Domyślnie NFS działa w oparciu o protokół UDP, doświadczenie pokazuje jednak, że
przełaczenie
˛
w tryb TCP może w niektórych wypadkach zwi˛ekszyć szybkość przesyłu danych. Niestety nie każdy serwer NFS obsługuje połaczenia
˛
TCP, wi˛ec nie wsz˛edzie możemy użyć tej opcji. Na szcz˛eście PLD zawiera demona pozwalajacego
˛
na
używanie TCP. Aby właczyć
˛
ta˛ opcj˛e do linijki w pliku /etc/fstab dodajemy wpis
tcp np.:
192.168.0.1:/usr/local
/usr/local
nfs
rw,hard,intr,tcp
0
0
W przypadku protokołu NFS należy troch˛e eksperymentować z ustawieniami, na
poczatek
˛
dobrym pomysłem może być użycie obu powyższych wskazówek. Wi˛ecej
o dostrajaniu NFS-a można odnaleźć w podr˛eczniku systemowym.
PDNS (Power DNS) - Serwer Nazw
Power DNS14 zwany w dalszej cz˛eści tego dokumentu jako PDNS jest zaawansowanym i bardzo efektywnym serwerem nazw. Jego możliwości współpracy z LDAP lub
bazami SQL (Mysql i Postgresql) daja˛ szerokie możliwości tworzenia skryptów lub
interface zarzadzaj
˛
acych.
˛
Sam PDNS jest uważany za zdecydowanie bezpieczniejszy
niż Bind, a także od niego szybszy - zwłaszcza przy wi˛ekszej ilości obsługiwanych
domen.
Wstep
˛
W tym rozdziale zostanie omówiona podstawowa instalacja, konfiguracja z baza˛
Postgresql, a także wst˛epna konfiguracja przykładowej domeny. Oczywiście wi˛ecej
szczegółów możemy znaleźć w oryginalnej dokumentacji15.
Instalacja
Instalacja przebiega standardowo za pomoca˛ poldka.
poldek> install pdns
233
0
Do poprawnego działania naszej bazy potrzebujemy także postgresql (możemy także wykorzystać mysql lub ldap, a nawet pliki konfiguracyjne Bind-a). Tak wi˛ec jeżeli
nie mamy Postgresql to instalujemy go i poprawnie konfigurujemy.
Konfiguracja Postgresql dla PDNS
Nast˛epnym krokiem b˛edzie stworzenie bazy obsługiwanej przez PDNS w Postgresql. W tym celu możemy wykorzystać klienta dostarczanego razem z Postgresql psql. Możemy także do tego celu użyć innych wygodnych narz˛edzi np. phpPgAdmin
Najpierw z konta użytkownika uprawnionego do operacji na bazie tworzymy baz˛e:
$ createdb -U postgres powerdns
Tworzymy także użytkownika dla w/w bazy:
$ createuser -P -U
Enter password for
Enter it again:
Shall the new user
(y/n) n
Shall the new user
users? (y/n) n
CREATE USER
postgres pdns
user "pdns":
be allowed to create databases?
be allowed to create more new
Teraz za pomoca˛ swojego ulubionego klienta Postgresql wykonujemy poniższe polecenia SQL w celu stworzenia szkieletu bazy:
create table domains (
id
SERIAL PRIMARY KEY,
name
VARCHAR(255) NOT NULL,
master
VARCHAR(20) DEFAULT NULL,
last_check INT DEFAULT NULL,
type
VARCHAR(6) NOT NULL,
notified_serial INT DEFAULT NULL,
account
VARCHAR(40) DEFAULT NULL
);
CREATE UNIQUE INDEX name_index ON domains(name);
CREATE TABLE records (
id
SERIAL PRIMARY KEY,
domain_id
INT DEFAULT NULL,
name
type
content
ttl
INT DEFAULT NULL,
prio
INT DEFAULT NULL,
change_date INT DEFAULT NULL,
CONSTRAINT domain_exists
FOREIGN KEY(domain_id) REFERENCES domains(id)
ON DELETE CASCADE
);
CREATE INDEX rec_name_index ON records(name);
CREATE INDEX nametype_index ON records(name,type);
CREATE INDEX domain_id ON records(domain_id);
create table supermasters (
ip VARCHAR(25) NOT NULL,
nameserver VARCHAR(255) NOT NULL,
account VARCHAR(40) DEFAULT NULL
);
234
GRANT
GRANT
GRANT
GRANT
GRANT
SELECT
ALL ON
ALL ON
ALL ON
ALL ON
ON supermasters TO pdns;
domains TO pdns;
domains_id_seq TO pdns;
records TO pdns;
records_id_seq TO pdns;
Konfiguracja PDNS
W /etc/pdns/pdns.conf konfigurujemy działanie programu PDNS. Przykładowa
konfiguracja PDNSa współpracujacego
˛
z baza˛ Postgresql może wygladać
˛
nast˛epuja˛
co:
#chroot=/some/where # If set, chroot to this directory for more security
config-dir=/etc/pdns/
# Location of configuration directory (pdns.conf)
launch=gpgsql
# Launch this backend
#gpgsql-socket=/var/lib/pgsql/postmaster.pid
gpgsql-dbname=powerdns
# Nazwa bazy danych w psql
gpgsql-user=pdns
# Użytkownik bazy w psql
gpgsql-password=hasło_do_bazy_pdns
module-dir=/usr/lib/pdns
# Default directory for modules
#load-modules=
# Load this module - supply absolute or relative path
#local-address=0.0.0.0
# Local IPv4 address to which we bind
#local-ipv6=::
# Local IPv6 address to which we bind
#use-logfile=no
# Use a log file or syslog
#logfile=var/log/pdns.log # Logfile to use
allow-recursion=IP_ZEWN_DNS/maska,IP_ZEWN_DNS/maska
# Tu podajemy adresy zewn. serwe
# allow-recursion=194.204.152.34/24,194.204.159.1/24
# nameserver
setgid=djbdns
# If set, change group id to this gid for more security
setuid=pdns
# If set, change user id to this uid for more security
#slave=no
# Act as a slave (Ustawiamy na YES w przypadku
# pracy serwera PDNS jako SLAVE)
socket-dir=/var/run
# Where the controlsocket will live
webserver=yes
# Właczenie
˛
usługi monitorowania pracy PDNS przez WWW
webserver-address=10.1.1.1 # Adres IP strony monitorujacej
˛
prac˛
e PDNS
webserver-password=hasło_do_strony_monitorujacej
˛
webserver-port=8088
# port strony monitorujacej
˛
Krzyżyk "#" na poczatku
˛
oznacza komentarz badź
˛ wyłaczenie
˛
danej opcji. Oryginalne teksty komentarzy sa˛ na tyle czytelne, że tylko niektóre opcje skomentowalismy
po polsku.
Domeny
Praktycznie PDNS jest gotowy do pracy. Musimy jeszcze wypełnić treścia˛ baz˛e - czyli dodać domen˛e (domeny). Przykładowa˛ domen˛e zaprezentujemy w formie tzw.
"dump-a" bazy. Jest to na tyle czytelne, że skomentowane zostana˛ tylko niektóre
aspekty.
--- PostgreSQL database dump
-SET client_encoding = ’UNICODE’;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET search_path = public, pg_catalog;
235
--- Name: domains_id_seq; Type: SEQUENCE SET; Schema: public; Owner: pdns
-SELECT pg_catalog.setval(pg_catalog.pg_get_serial_sequence(’domains’, ’id’), 1, true);
--- Name: records_id_seq; Type: SEQUENCE SET; Schema: public; Owner: pdns
--
SELECT pg_catalog.setval(pg_catalog.pg_get_serial_sequence(’records’, ’id’), 16, true);
--- Data for Name: domains; Type: TABLE DATA; Schema: public; Owner: pdns
-INSERT INTO domains VALUES
INSERT INTO domains VALUES
-- W pierwszym ID podajemy
-- W drugim ID definiujemy
(1, ’foo.com’, NULL, NULL, ’NATIVE’, NULL, NULL);
(2, ’1.1.10.in-addr.arpa’, NULL, NULL, ’NATIVE’, NULL, NULL)
domen˛
e ’foo.com’
domen˛
e odwrotna˛ dla danego IP
--- Data for Name: records; Type: TABLE DATA; Schema: public; Owner: pdns
--- Poniżej zgodnie z określonymi ID definiowane sa˛ kolejno strefy
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
records
records
records
records
records
records
records
records
records
records
records
records
records
records
records
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
(2, 1, ’localhost.foo.com’, ’A’, ’127.0.0.1’, 120, NULL, NUL
(3, 1, ’www.foo.com’, ’A’, ’10.1.1.1’, 120, NULL, NULL);
(5, 1, ’dns.foo.com’, ’A’, ’10.1.1.1’, 120, NULL, NULL);
(6, 1, ’ftp.foo.com’, ’A’, ’10.1.1.1’, 120, NULL, NULL);
(7, 1, ’poczta.foo.com’, ’A’, ’10.1.1.1’, 120, NULL, NULL);
(8, 1, ’pop3.foo.com’, ’A’, ’10.1.1.1’, 120, NULL, NULL);
(9, 1, ’smtp.foo.com’, ’A’, ’10.1.1.1’, 120, NULL, NULL);
(10, 1, ’ssh.foo.com’, ’A’, ’10.1.1.1’, 120, NULL, NULL);
(11, 1, ’jabber.foo.com’, ’A’, ’10.1.1.1’, 120, NULL, NULL);
(1, 1, ’foo.com’, ’SOA’, ’localhost user.foo.com 1’, 86400,
(16, 1, ’foo.com’, ’TXT’, ’Serwer PDNS’, 300, NULL, NULL);
(17, 1, ’foo.com’, ’NS’, ’ns.foo.com’, 300, NULL, NULL);
(4, 1, ’mail.foo.com’, ’A’, ’10.1.1.1’, 120, NULL, NULL);
(18, 1, ’foo.com’, ’MX’, ’mail.foo.com’, 300, 5, NULL);
(19, 1, ’foo.com’, ’A’, ’10.1.1.1’, 300, 0, NULL);
-- Poniżej definiujemy rekordy SRV
INSERT INTO records VALUES (12, 1,
’SRV’, ’0 5269 foo.com’, 300, 10,
’SRV’, ’0 5269 foo.com’, 300, 10,
’SRV’, ’0 5222 foo.com’, 300, 10,
dla serwera Jabber
’_jabber._tcp.jabber.foo.com’,
NULL);
’_xmpp-server._tcp.jabber.foo.com’,
NULL);
’_xmpp-client._tcp.jabber.foo.com’,
NULL);
-- Domena odwrotna
INSERT INTO records VALUES (15, 2, ’1.1.1.10.in-addr.arpa’, ’PTR’, ’foo.com’, 86400, NU
INSERT INTO records VALUES (20, 2, ’1.1.10.in-addr.arpa’,
’SOA’, ’localhost root.localhost’, 86400, NULL, NULL);
INSERT INTO records VALUES (21, 2, ’1.1.10.in-addr.arpa’, ’NS’, ’nc.foo.com’, 86400, NU
--- Data for Name: supermasters; Type: TABLE DATA; Schema: public; Owner: pdns
---- PostgreSQL database dump complete
--
236
Wszelkie zmiany lub dodawanie nowych domen możemy wykonywać na bazie danych lub wykorzystujac
˛ do tego odpowiednie skrypty. Teraz możemy uruchomić demona PDNS wykorzystujac
˛ skrypt:
# /etc/init.d/pdns start
Należy pami˛etać, że jeżeli wcześniej używalismy BINDa badź
˛ innnego demona do
obsługi nazw domenowych, należy go przed uruchomieniem PDNS wyłaczyć.
˛
Po uruchomieniu serwisu możemy za pomoca˛ przegladarki
˛
http wejść na stron˛e
monitorujac
˛ a˛ prac˛e PDNS (odpowiednie opcje dotyczace
˛ tej usługi znajdziemy w
/etc/pdns/pdns.conf). Wywołanie zgodne z przykładowym wpisem w pdns.conf
to http://10.1.1.1:8088. Na stronie tej możemy odnaleźć wiele cennych informacji dotyczacych
˛
pracy naszego serwera nazw.
Postfix - Transport poczty elektronicznej (MTA)
Postfix jest MTU czyli w wielkim skrócie demonem poczty elektronicznej. No tak,
w sumie powiecie ściagamy
˛
poldkiem instalujemy i działa... działa ale chcemy coś
wi˛ecej... chcemy by nasz smtpd był ładnie skonfigurowany.
Zaczynamy
Ściagamy
˛
to co nam b˛edzie potrzebne. Wiadomo... postfix i dodatki, które mu sa˛
potrzebne:
poldek -i postfix cyrus-sasl cyrus-sasl-plain cyrus-sasl-saslauthd \
cyrus-sasl-login
A tutaj coś co b˛edzie nam potrzebne do tworzenia certyfikatów.
poldek -i openssl-tools
A tutaj coś żebyśmy mogli pobrać poczt˛e z serwera.
poldek -i tpop3d inetd rc-inetd
Konfiguracja
Przyszedł czas na konfiguracj˛e postfix-a.
# echo ’pwcheck_method:saslauthd’ > /etc/sasl/smtpd.conf
Należy jeszcze sprawdzić czy w /etc/pam.d/ znajduje si˛e plik smtp,
jeżeli nie to należy przegrać na to miejsce przykładowy konfig z
/usr/share/doc/cyrus-sasl-saslauthd-*/cyrus.pam.gz
, rozpakować i
nazwać plik smtp.
Uruchom saslauthd:
# /etc/rc.d/init.d/saslauthd start
Uruchom postfix-a:
# /etc/rc.d/init.d/postfix start
Teraz chcemy, żeby postfix wymagał autentykacji:
# postconf -e smtpd_sasl_auth_enable=yes
237
# postconf -e smtpd_recipient_restrictions=permit_mynetworks, \
reject_sender_login_mismatch,permit_sasl_authenticated, \
reject_unauth_destination
Teraz linijka dla popsutych Outlook-ów.
# postconf -e broken_sasl_auth_clients=yes
# postconf -e mynetworks=127.0.0.0/8,192.168.1.1/32
Restart postfix-a:
# /etc/rc.d/init.d/postfix restart
No i to wszystko razem powinno wygladać
˛
tak:
# postconf -n
alias_database = hash:/etc/mail/aliases
alias_maps = hash:/etc/mail/aliases
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/mail
daemon_directory = /usr/lib/postfix
debug_peer_level = 2
default_privs = nobody
mail_owner = postfix
mail_spool_directory = /var/mail
myhostname = networking.ee
mynetworks = 127.0.0.0/8, 192.168.1.1/32, 192.168.1.1/32
myorigin = $myhostname
queue_directory = /var/spool/postfix
setgid_group = maildrop
smtpd_recipient_restrictions = permit_mynetworks, \
smtpd_sasl_auth_enable = yes
Szyfrowanie
Właczamy
˛
teraz szyfrowanie wysyłania poczty oraz transmisji mi˛edzy MX-ami dla
różnych domen
Nast˛epnie generujemy certyfikat SSL. Podczas generowania certyfikatu b˛edziesz musiał odpowiedzieć na kilka prostych pytań.
Robimy to w sposób nast˛epujacy:
˛
#
#
#
#
openssl genrsa -out key.pem 1024
openssl req -new -x509 -key key.pem -out cert.pem
cat cert.pem >> key.pem; mv -f key.pem cert.pem
cp cert.pem /var/lib/openssl/certs/nasza.domena.pl.pem
Do pliku /etc/mail/main.cf należy dodać 4 linijki, takie jak poniżej:
smtpd_tls_cert_file = /var/lib/openssl/certs/nasza.domena.pl.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_use_tls = yes
smtp_use_tls = yes
W pliku /etc/mail/master.cf należy zastapić
˛
aktualna˛ linijk˛e czyli ta˛ z domyślnej
instalacji:
#smtps inet n - n
na nasza˛ aktualna:
˛
238
-
-
smtpd
smtps inet n - y smtpd -o smtpd_tls_wrappermode=yes \
-o smtpd_sasl_auth_enable=yes
Domeny
Jeżeli posiadamy wi˛ecej niż jedna˛ domen˛e na serwerze to w /etc/mail/main.cf
dopisujemy:
mydestination = $myhostname, jakas.domena.pl, \
costam.gdziestam.pl, PLD.biz.pl
Jeżeli chcemy aby nasz postfix obsługiwał wirtualne domeny (przyznawał si˛e do
nich) dopisujemy w /etc/mail/main.cf takie trzy linijki:
relay_domains = hash:/etc/mail/domains
virtual_maps = hash:/etc/mail/virtual
smtpd_sender_login_maps = hash:/etc/mail/virtual
Tworzymy /etc/mail/domains i robimy nastepujace
˛ wpisy:
# plik domains, w nim wpisane domeny dla których nasz serwer
#poczt˛
e b˛
edzie przyjmował.
pld-linux.org
relay
81.0.225.27
relay
Do /etc/mail/virtual dopisujemy na przykład coś takiego:
# plik virtual, w nim wpisane sa˛ konta w domenach które obsługujemy
# schemat wpisu
# [email protected]
konto_w_systemie
[email protected]
grifter
[email protected]
grifter
[email protected] grifter
# to ostatnie b˛
edzie nam później do amavisa potrzebne :)
Teraz musimy wklepać
# postmap /etc/mail/domains
# postmap /etc/mail/virtual
No i restart postfixa
Usprawnienia
Dodatkowe
wpisy
które
poprawia˛
prac˛e
naszego
postfix-a
Edytujemy
/etc/mail/main.cf i dodajemy nast˛epujace
˛ wpisy:
disable_vrfy_command = yes
# liczba odbiorców max 100 dla jednego maila
smtpd_recipient_limit = 100
smtpd_error_sleep_time = 5
smtpd_hard_error_limit = 10
smtpd_helo_required = yes
# ogranicz do 2 mega [2000000] wielkość przesyłki, właściwie majac
˛ \
# dobre łacze
˛
można
# wpisać 10 mega [10000000]
message_size_limit = 2000000
239
# spam fight! :>
header_checks = regexp:/etc/mail/header_checks
mail_name = PLD - $myhostname
smtpd_banner = $myhostname ESMTP $mail_name. We block/report all spam.
smtpd_soft_error_limit = 60
default_process_limit = 3
maps_rbl_domains = relays.ordb.org
smtpd_client_restrictions = reject_maps_rbl
Tworzymy /etc/mail/header_checks i dopisujemy:
/^To: .*friend@public/
REJECT Header-To address revoked \
due to too much spam.
/^Subject: ADV\W/
REJECT Header-Subject beginning with \
"spam" ADV tag rejected.
Końcowa konfiguracja
# postconf -n
alias_database = hash:/etc/mail/aliases
alias_maps = hash:/etc/mail/aliases
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/mail
daemon_directory = /usr/lib/postfix
debug_peer_level = 2
default_privs = nobody
default_process_limit = 3
disable_vrfy_command = yes
header_checks = regexp:/etc/mail/header_checks
mail_name = PLD - $myhostname
mail_owner = postfix
mail_spool_directory = /var/mail
maps_rbl_domains = relays.ordb.org
message_size_limit = 2000000
myhostname = networking.ee
mynetworks = 127.0.0.0/8,192.168.1.1/32
myorigin = $myhostname
queue_directory = /var/spool/postfix
relay_domains = hash:/etc/mail/domains
setgid_group = maildrop
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name. We block/report all spam.
smtpd_client_restrictions = reject_maps_rbl
smtpd_error_sleep_time = 5
smtpd_hard_error_limit = 10
smtpd_helo_required = yes
smtpd_recipient_limit = 100
smtpd_recipient_restrictions = permit_mynetworks, \
smtpd_sasl_auth_enable = yes
smtpd_soft_error_limit = 60
smtpd_tls_cert_file = /var/lib/openssl/certs/nasza.domena.pl.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_use_tls = yes
virtual_maps = hash:/etc/mail/virtual
smtpd_sender_login_maps = hash:/etc/mail/virtual
Zawartość master.cf
# grep -v ^# /etc/mail/master.cf
smtp
inet n - n -
240
smtpd
smtps
inet n - y - smtpd -o smtpd_tls_wrappermode=yes \
-o smtpd_sasl_auth_enable=yes
pickup
fifo n - n 60
1 pickup
cleanup
unix n - n 0 cleanup
qmgr
fifo n - n 300
1 qmgr
rewrite
unix - - n - trivial-rewrite
bounce
unix - - n 0 bounce
defer
unix - - n 0 bounce
flush
unix n - n 1000? 0 flush
smtp
unix - - n - smtp
showq
unix n - n - showq
error
unix - - n - error
local
unix - n n - local
virtual
unix - n n - virtual
lmtp
unix - - n - lmtp
cyrus
unix - n n - pipe flags=R user=cyrus \
argv=/usr/lib/cyrus/deliver -e -m ${extension} ${user}
uucp
unix - n n - pipe flags=Fqhu user=uucp \
argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail
unix - n n - pipe flags=F user=ftn \
argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp
unix - n n - pipe flags=Fq. user=foo \
argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient
tpop3d
tpop3d, czyli coś dzi˛eki czemu b˛edziemy mogli pobrać poczt˛e z serwera.
No i właczamy
˛
tpop3d-a
# /etc/rc.d/init.d/tpop3d start
amavis + mks
Przyst˛epujemy do instalacji i konfiguracji amavisa + mks :)
Instalujemy poldkiem mks, serwer mksd, bazy, oraz skrypt aktualizujacy
˛ bazy
poldek -i mks mksd mks-bases mks-updater mksd-clients
Teraz ściagamy
˛
jakiegoś wirusa i sprawdzamy czy mks32 działa...
# wget http://www.eicar.org/download/eicar.com
# mks32 eicar.com
mks_vir: init... 1.9.0 for Linux i386, 2003.07.02
mks_vir: database version 2003 7 11 13 23
mks_vir: init OK, scan mode
mks_vir: check file(s)
mks_vir: file: eicar.com
mks_vir:
--heuristic for virus Eicar.Test
mks_vir:
--heuristic for virus Eicar.Test
mks_vir: status: virus found: eicar.com
mks_vir: exit code: 0x01
Jeśli dostaliście coś takiego, tzn. że wszystko jest ok ;)
Teraz przetestujemy czy mksd działa poprawnie.
# /etc/rc.d/init.d/mksd start
# mkschk /root/skaner/eicar.com
VIR Eicar.Test /root/skaner/eicar.com
241
Jeśli dostałeś coś takiego, tzn. że wszystko jest okej. mksd przyśpiesza znacznie prac˛e
na słabych maszynach... wtedy znacznie odczujesz.
Instalujemy teraz amavisa
poldek -i amavisd-new
No i teraz najgorsze ;)
Edytujemy /etc/amavisd.conf
Odkomentuj lini˛e:
@bypass_spam_checks_maps
= (1);
# uncomment to DISABLE anti-spam code
Pozmieniaj odpowiednie linie
$mydomain = ’twoja.domena.pl’;
# (no useful default)
$daemon_user = ’amavis’; # (no default; customary: vscan or amavis)
$daemon_group = ’amavis’; # (no default; customary: vscan or amavis)
Możemy tutaj ustawić użytkownika amavis. Dodatkowo należy dopisać mksd do
grupy amavis, dzi˛eki czemu b˛edzie on mógł korzystać z katalogów z cz˛eściami maili
amavisa.
# grep amavis /etc/group
amavis:x:116:mksd
Zakomentuj lini˛e:
#$unix_socketname = "$MYHOME/amavisd.sock"; # amavis helper protocol socket
Jeśli nie chcesz żeby amavis używał pewnych pakerów to zakomentuj odpowiednie
linie, np.
#$unrar
=
’unrar’;
Usuń wszystkie wpisy na temat antywirusów (@av_scanners = ) i zastap
˛ to wpisem
z pliku README z archiwum mksd:
[’MkS_Vir daemon’,
’mksscan’, ’-s -Q {}’,
[0], [1..7],
qr/^... (\S+)/
],
Usuń wpisy z @av_scanners_backup =
W swoim systemie pocztowym (postfix) utwórz użytkownika (lub alias) "virusalert"
lub pozmieniaj wpisy:
$mailfrom_notify_admin
$mailfrom_notify_recip
$virus_admin
My zrobiliśmy wcześniej aliasa dla virusalert ;)
Ja sobie jeszcze dopisałem:
$hdrfrom_notify_sender = $mailfrom_notify_admin;
Jeśli nie chcesz aby nadawcy listów oraz admini dostawali informacje o wirusach
w domyślnym j˛ezyku (English) to odkomentuj linie i zrób własne wpisy w
/var/amavis/*.txt
# $notify_sender_templ
242
= read_text(’/var/amavis/notify_sender.txt’);
# $notify_virus_sender_templ=read_text(’/var/amavis/notify_virus_sender.txt’);
# $notify_virus_admin_templ = read_text(’/var/amavis/notify_virus_admin.txt’);
# $notify_virus_recips_templ=read_text(’/var/amavis/notify_virus_recips.txt’);
i zmień
#$bdy_encoding = ’iso-8859-1’;
# (default: ’iso-8859-1’)
na
$bdy_encoding = ’iso-8859-2’;
# (default: ’iso-8859-1’)
Według licencji powinieneś umieścić w notify_sender.txt reklam˛e
http://www.mks.com.pl gdyż jest do warunek licencji na używanie mks. Na końcu
pliku /usr/sbin/amavisd znajduja˛ si˛e przykładowe szablony.
W pliku /etc/mail/master.cf dopisujemy nowa˛ lini˛e:
localhost:10025 inet n
-
n
-
-
smtpd
No i restart postfix-a, amavisd-a i mks
# /etc/rc.d/init.d/mksd restart
# /etc/rc.d/init.d/amavisd restart
Teraz testujemy amavis-a:
# telnet 127.0.0.1 10024
Trying 127.0.0.1.10024...
Connected to localhost.
Escape character is ’^]’.
220 [127.0.0.1] ESMTP amavisd-new service ready
MAIL FROM: <root>
250 2.1.0 Sender root OK
RCPT TO: <root>
250 2.1.5 Recipient root OK
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: test bez wirusa
test
.
250 2.6.0 Ok, id=29569-01, from MTA: 250 Ok: queued as A1017FD1E
Dostałeś 250? To znaczy, ze amavisd sprawdził przesyłk˛e :) nie wierzysz? tail -n 100
-f /var/log/maillog
A teraz sprawdzimy jak reaguje na przesyłk˛e z wirusem:
# telnet 127.0.0.1 10024
Trying 127.0.0.1.10024...
Connected to localhost.
Escape character is ’^]’.
220 [127.0.0.1] ESMTP amavisd-new service ready
MAIL FROM: <root>
250 2.1.0 Sender root OK
RCPT TO: <root>
250 2.1.5 Recipient root OK
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: test z wirusem
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
.
250 2.5.0 Ok, but 1 BOUNCE
243
No i znalazł wirusa :) w logach mamy:
Jul 14 04:17:43 networking amavis[29569]: (29569-02) INFECTED (Eicar.Test),
<root> -> <root>, quarantine virus-20030714-041716-29569-02, \
Message-ID: , Hits: -
Teraz jeszcze mała obróbka plików cf od postfix-a ;)
Edytujemy /etc/mail/master.cf
Linijk˛
e:
smtp
inet
n
-
n
-
-
smtpd
zamieniamy na:
smtp
inet n n
smtpd -o \
content_filter=smtp-amavis:[127.0.0.1]:10024
oraz dodajemy jeszcze:
smtp-amavis unix -o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
n
-
2
smtp
Restart postfix-a:
i powinno wszystko nam pi˛eknie latać:)
Wyślij sobie eicar.com w załaczniku
˛
a zobaczysz, że smtp odrzuci i dostaniesz maila
z alertem :]
postifx.admin
TODO (http://high5.net/postfixadmin/)
PostgreSQL - Baza danych SQL
Co to jest PostgreSQL
PostgreSQL : The most advanced Open Source database system in the
world
PostgreSQL: Najbardziej zaawansowany system zarzadzania
˛
baza˛ danych na świecie
typu OpenSource - w taki oto sposób grupa rozwijajaca
˛ SZBD PostgreSQL reklamuje swój produkt. SZBD PostgreSQL jest implementacja˛ j˛ezyka SQL, która zawiera w
sobie bardzo wiele jego elementów, a na dodatek wprowadza wiele własnych rozszerzeń. Porównywany z mySQL oddaje mu pola przy małych instalacjach, które w
prosty, a szybki sposób maja˛ obsługiwać baz˛e danych - typu małe portale internetowe, proste bazy, i tym podobne. Jednakże SZBD PostgreSQL dostaje skrzydeł w
wi˛ekszych projektach, jest cz˛esto porównywany do bardzo rozbudowanego SZBD
Oracle. Cechy SZBD PostgreSQL to mi˛edzy innymi:
•
244
osadzane j˛ezyki proceduralne wykonywane przez baz˛e danych (plperl, pl/perlu,
plpgsql, plpython, pltcl, pl/tcl)
•
możliwość tworzenia funkcji w PostgreSQLu w j˛ezyku C, kompilowanych do bibliotek dynamicznych
•
sterowniki dost˛epu do bazy z j˛ezyków C, C++, python, perl, czy Java (poprzez
JDBC), ODBC
•
wysoce zaawansowana implementacja standardu SQL, obejmujaca
˛ SQL/92
•
obsługa BLOB (Binary Large OBjects) -- dużych obiektów binarnych, takich jak
pliki graficzne, itp.
•
obsługa pól typu AUTOINCREMENT jako SERIAL lub SEQUENCE
•
licencj˛e BSD, która umożliwia zamykanie kodu SZBD PostgreSQL przy dokonywaniu modyfikacji, co jest istotne w rozwiazaniach
˛
biznesowych
Uruchamiamy program poldek:
# poldek
Wykonujemy:
poldek>ls -l postgresql-*
Przykładowy wynik to:
poldek> ls -l postgresql-*
package
postgresql-7.4-0.8
postgresql-backend-devel-7.4-0.8
postgresql-clients-7.4-0.8
postgresql-devel-7.4-0.8
postgresql-doc-7.4-0.8
postgresql-ecpg-7.4-0.8
postgresql-ecpg-devel-7.4-0.8
postgresql-libs-7.4-0.8
postgresql-module-pgcrypto-7.4-0.8
postgresql-module-plperl-7.4-0.8
postgresql-module-plpgsql-7.4-0.8
postgresql-module-plpython-7.4-0.8
postgresql-module-pltcl-7.4-0.8
postgresql-static-7.4-0.8
postgresql-tcl-7.4-0.8
postgresql-tcl-devel-7.4-0.8
postgresql-tcl-static-7.4-0.8
17 packages, 18.6 MB
poldek>
build date
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
2003/12/16
20:45
20:45
20:45
20:45
20:45
20:45
20:45
20:45
20:45
20:45
20:45
20:45
20:45
20:45
20:45
20:45
20:45
8.8
1.4
1.5
93.0
5.3
479.0
17.0
252.0
91.0
30.0
100.0
35.0
44.0
303.0
38.0
0.0
36.0
size
MB
MB
MB
KB
MB
KB
KB
KB
KB
KB
KB
KB
KB
KB
KB
KB
KB
Do poprawnego działania SZBD PostgreSQL konieczne sa˛ nast˛epujace
˛ pakiety:
•
postgresql
•
postgresql-clients
•
postgresql-libs
Zatem można przystapić
˛
do ich instalacji, wpisujac
˛ nast˛epujace
˛ polecenie:
# poldek -i postgresql postgresql-clients postgresql-libs
245
Aby SZBD PostgreSQL skorzystał z wewn˛etrznych j˛ezyków plpgsql czy też plphpython należy doinstalować pakiety postgresql-module-plpgsql
# poldek -i postgresql-module-plpgsql
oraz
root# poldek -i postgresql-module-plpython
Konfiguracja PostgreSQLa w PLD
Wstepna
˛
konfiguracja
Edytujemy plik /etc/sysconfig/postgresql:
# vim /etc/sysconfig/postgresql
I wybieramy odopowiednie podejście do bazy danych. Polecam standard setting. Po
edycji wykonanie komendy
# grep PG_DB_CLUSTERS /etc/sysconfig/postgresql | egrep -v ^#
powinno dać wynik:
PG_DB_CLUSTERS="/var/lib/pgsql"
Sortowanie po polsku
poldek -i localedb-src && localedb-gen -l pl_PL && echo LANG=pl_PL \
>>/etc/sysconfig/i18n
TODO: locale tylko dla PostgreSQLa.
Inicjalizacja
Wykonujemy polecenie:
# service postgresql init
Podczas inicjalizacji SZBD PostgreSQL stworzy pliki potrzebne mu do przechowywania tabel, tabele systemowe jak i bazy danych template0 i template1 konieczne
do jego dalszego działania. Inicjalizacja PostgreSQLa nie jest równoznaczna z jego
uruchomieniem, o czym dalej.
Konfiguracja PostgreSQLa
W punkcie (3) (<- TODO, shufla docbook lame) został zainicjalizowany
cluster, w którym to można dodawać bazy danych. Trzeba teraz
odpowiednio skonfigurować tenże cluster. Przyda si˛e edycja plików
${PG_DB_CLUSTERS}/{postgresql.conf,pg_hba.conf}:
# vim /var/lib/pgsql/{postgresql.conf,pg_hba.conf}
Przydatna
opcja
to
/var/lib/pgsql/postgresql.conf.
246
tcpip_socket = true
w
pliku
Uruchomienie PostgreSQLa
# service postgresql start
Dodanie użytkownika
# su - postgres -c ’psql template1’
template1=# CREATE USER uzytkownik WITH ENCRYPTED PASSWORD ’hasło’ \
CREATEUSER CREATEDB;
CREATE USER
Użytkownik ‘uzytkownik’ b˛edzie miał możliwość tworzenia baz danych (za pomoca˛
createdb lub CREATE DATABASE z poziomu psql) jak i dodawania użytkowników
(createuser lub CREATE USER z poziomu psql).
Ostatni test
$ psql -h 127.0.0.1 template1
template-1=# SELECT count(*) FROM pg_database;
count
------2
(1 row)
Dodatki
Warto właczyć
˛
obsług˛e PostgreSQLa w PHP, instalujac
˛ pakiet php-pgsql, również
w perl-u perl-DBD-Pg lub perl-Pg, oraz w python-ie python-postgresql. Pakiet
postgresql-devel jest przydatny przy pisaniu aplikacji w C/C++ korzystajacych
˛
z PostgreSQLa. Dokumentacja do PostgreSQLa znajduje si˛e, a jakże, w pakiecie
postgresql-doc.
#
#
#
#
#
#
poldek
poldek
poldek
poldek
poldek
poldek
-i
-i
-i
-i
-i
-i
php-pgsql
perl-DBD-Pg
perl-Pg
python-postgresql
postgresql-devel
postgresql-doc
Odnośniki
•
www.postgresql.org - strona główna projektu16
•
www.postgresql.org.pl - polska strona projektu17
- Lokalna wersja FAQ,
instalowana z pakietem postgresql (może być także w oddzielnej paczce z
dokumentacja).
˛
• /usr/share/doc/postgresql-*/FAQ_polish.gz
247
ProFTPD - serwer FTP
Wstep
˛
Duża˛ zaleta˛ ProFTPD jest jego prostota. Plik konfiguracyjny demona do złudzenia
przypomina ten od Apache. Jego zrozumienie nie powinno sprawiać trudności.
Instalacja
Zanim przystapisz
˛
do instalacji powinieneś zdecydować w jakim trybie ma pracować
usługa. Jako demon, czy ma być uruchamiana poprzez superserwer inetd. Tryb inetd
polega na tym, że proces proftpd zostanie uruchomiony dopiero po odebraniu przez
inetd żadania
˛
o t˛e usług˛e. Natomiast w trybie daemon ProFTPD jest uruchomiony
cały czas i pracuje niezależnie od inetd. Tak wi˛ec, jeżeli Twój komputer, który przeznaczysz na serwer nie jest zbyt szybki, powinieneś wybrać ProFTPD uruchamianego poprzez inetd. Dystrybucja udost˛epnia obie te możliwości. Pakiet proftpd-inetd
zapewnia uruchamianie poprzez inetd, natomiast po zainstalowaniu usługi z pakietu proftpd-standalone uruchamiana ona b˛edzie w trybie daemon. W opisie posłużymy si˛e wersja˛ daemon. Instalujemy pakiet proftpd-standalone
Podstawowa konfiguracja demona
Jak już wspomniałem we wst˛epie, ProFTPD jest jednym z prostszych w konfiguracji
programów serwerowych. Wszystkie pliki potrzebne do jego skonfigurowania znajduja˛ si˛e w katalogu /etc/ftpd.
# ls -1 /etc/ftpd
ftpusers
proftpd.conf
W pliku ftpusers znajduje si˛e lista użytkowników, którym odebrana została możliwość logowania si˛e do serwera ftp. Poszczególne pozycje z tej listy zakończone sa˛
znakiem nowej linii, tak wi˛ec każda pozycja jest rozmieszczona jedna pod druga.˛
Natomiast plik proftpd.conf zawiera właściwa˛ konfiguracj˛e usługi.
ServerName
ServerIdent
ServerType
DeferWelcome
DefaultServer
DefaultRoot
• ServerName
"ProFTPD"
off
standalone
off
on
~
określa nazw˛e serwera wyświetlana˛ łacz
˛ acym
˛
si˛e z nim użytkown-
ikom.
pozwala na wyświetlenie wiadomości powitalnej podczas
połaczenia,
˛
np. zawartości pliku .message. Domyślnie wyłaczona.
˛
• ServerIdent
• ServerType
ustawia tryb pracy demona ProFTPD
• DeferWelcome
Nie pokazuje wiadomości powitalnej dopóki użytkownik si˛e nie
zautoryzuje.
• DefaultServer
Określamy konfiguracj˛e jako domyślna˛
Wyznaczamy nadrz˛edny dla każdego użytkownika katalog spoza
którego nie b˛edzie mógł wyjść. W listingu powyżej b˛edzie to katalog domowy.
• DefaultRoot
Poniżej znajduje si˛e szereg zakomentowanych opcji pozwalajacych
˛
na konfiguracj˛e
połacze
˛ ń bezpieczna˛ metoda˛ przy użyciu SSL. Jeżeli jesteś zainteresowany ich uży248
ciem powinieneś zapoznać si˛e z dokumentacja˛ on line18 serwera ProFTPD. Przechodzimy teraz do dalszej konfiguracji.
Port
Umask
User
Group
AuthPAMAuthoritative
21
022
ftp
ftp
on
Definiujemy tutaj port na którym serwer b˛edzie oczekiwał nadchodzacych
˛
połacze
˛ ń
• Port
Tryb umask 022 jest typowym standardem dla ogolnie dost˛epnych plików i
katalogów
• Umask
• User
Konto użytkownika na którego uprawnieniach pracuje usługa
• Group
Grupa do której należy konto użytkownika usługi
Dajemy możliwość autoryzacji użytkowników poprzez
moduł PAM jeśli jest to możliwe.
• AuthPAMAuthoritative
Przedstawione tutaj wartości poszczególnych opcji sa˛ domyślnie ustawiane w pliku
konfiguracyjnym w trakcie instalacji pakietu. Jak najbardziej możesz z nich korzystać. Na pewno nie powinieneś zmieniać takich ustawień jak użytkownik czy grupa,
port oraz sposób autoryzacji.
Konfiguracja dostepu
˛
<Directory />
AllowOverwrite
</Directory>
on
Zezwalamy na nadpisywanie plików w obr˛ebie katalogu do którego użytkownik
si˛e zaloguje. Poniżej w pliku znajduje si˛e przykładowa konfiguracja dla
użytkownika anonimowego. Sekcja mieści si˛e wewnatrz
˛
znacznika <Anonymous
~ftp></Anonymous>. Poniższy wykaz omawia najcz˛eściej wykorzystywane
dyrektywy w tej sekcji.
User
ftp
Group
ftp
AnonRequirePassword off
RequireValidShell off
• User - konto użytkownika którego prawa b˛edzie uzyskiwała osoba logujaca
˛ si˛e do
serwera
• Group
- grupa do której należy powyższe konto.
- w powyższym przykładzie wyłaczona.
˛
Umożliwia
użytkownikom anonimowym logowanie si˛e bez hasła.
• AnonRequirePassword
- opcja ta powoduje, że ProFTPD nie sprawdza czy dany
użytkownik, który si˛e loguje posiada przypisana˛ w /etc/shells powłok˛e.
• RequireValidShell
UserAlias anonymous ftp
MaxClients 10
DisplayLogin welcome.msg
DisplayFirstChdir .message
AllowStoreRestart on
249
- przyporzadkowuje
˛
nazw˛e użytkownika do systemowego konta. W
przykładzie anonymous został przypisany kontu ftp.
• UserAlias
• MaxClients - ilość jednoczesnych połacze
˛ ń anonimowych które b˛eda˛ realizowane
przez serwer.
• DisplayLogin
- określamy plik którego zawartość b˛edzie wyświetlana po starcie.
• DisplayFirstChdir
- plik którego zawartość b˛edzie wyświetlana po pierwszym
wejściu do katalogu.
• AllowStoreRestart
- pozwala klientom wznawiać upload.
<Limit WRITE>
DenyAll
</Limit>
Zabraniamy klientom pisania do katalogu /home/services/ftp/pub.
<Directory /home/services/ftp/pub/Incoming>
<Limit READ>
DenyAll
</Limit>
<Limit WRITE>
AllowAll
</Limit>
<Limit STOR>
AllowAll
</Limit>
</Directory>
Katalogowi Incoming zostały precyzyjnie określone prawa dost˛epu. W powyższym
przykładzie każdy ma dost˛ep do zapisu w tym katalogu natomiast nikt nie posiada
prawa do jego odczytywania.
Zakończenie
Dost˛ep do serwera ftp możemy ograniczać na kilka sposobów. Można limitować ilość
jednoczesnych połacze
˛ ń, stworzyć list˛e adresów IP, które b˛eda˛ miały prawo do zapisu czy odczytu określonych katalogów.
Na tym zakończymy podstawowa˛ konfiguracj˛e serwera ProFTPD. Wi˛ecej informacji
na jego temat znajdziesz na stronach z jego dokumentacja˛19.
Samba - współpraca z Windows
Samba jako Serwer domeny NT4 (PDC)
W tym rozdziale przedstawiona zostanie konfiguracja samby w roli serwera domeny
Microsoft Windows NT4 (PDC).
Instalacja
Do realizacji tego zadania potrzebne b˛eda˛ pakiety: samba i samba-clients. Znaczenie
poszczególnych pakietów:
250
•
samba - pakiet ten zawiera serwer samby
•
samba-clients - zestaw narz˛edzi przydatnych w poruszaniu si˛e w środowisku Microsoft Networks.
Proces instalacji pakietów przedstawiony został w dziale Zarzadzanie
˛
pakietami.
Konfiguracja
Przy użyciu dowolnego edytora otwieramy plik /etc/samba/smb.conf. Cała˛ konfiguracj˛e należy wykonać w sekcji [global]. Przyj˛eta w nim została nast˛epujaca
˛ konwencja: <opcja> = <wartość>. Jeżeli dana opcja ma kilka wartości, oddziela si˛e je znakiem spacji. Poszczególne opcje umieszczane sa˛ w osobnych liniach. Komentarze w
pliku rozpoczynaja˛ si˛e znakiem "#" lub ";". Poniżej znajduje si˛e wykaz najważniejszych opcji które należy ustawić podczas realizacji zadania.
workgroup = DOM
server string = File Server
announce as = NT Server
Ustawiamy nazw˛e domeny której członkiem b˛edzie nasz serwer oraz opcjonalnie
komentarz (opis) komputera i typ serwera (opcjonalnie).
domain logons = yes
domain master = yes
preferred master = yes
local master = yes
wins support = yes
os level = 255
Ustawiamy logowanie do domeny oraz bycie kontrolerem domeny Windows NT4 i
główna˛ przegladarka˛ komputerów w sieci.
security = user
Określamy poziom bezpieczeństwa. Nasza konfiguracja wymaga ustawień zabezpieczeń na poziomie użytkownika.
nt acl support = yes
nt pipe support = yes
Ustawiamy
time server = yes
Ustawiamy bycie serwerem czasu (opcjonalnie).
Nast˛epnie restartujemy SAMBE˛ i przyst˛epujemy do dalszej konfiguracji. W bazie
użytkowników Samby musi znaleźć si˛e konto administratora. B˛edzie ono wymagane
przy dołaczaniu
˛
stacji klienckich do domeny.
# smbpasswd -a root
New SMB password:
Retype new SMB password:
Added user root.
Hasło roota Samby nie powinno być identyczne z hasłem administratora systemu!
nast˛epnie tworzymy konta użytkowników - podobnie jak przy zwykłym serwowaniu plików, tak i tutaj potrzebujemy nie tylko wpisu w bazie Samby, ale i konta uniksowego.
# useradd -g users jurek
Pami˛etajmy też o utworzeniu wpisu w bazie użytkowników Samby:
# smbpasswd -a jurek
251
nast˛epnie ustawiamy mapowanie grup w linux na odpowiednie grupy windows-a,
poleceniem net groupmap. Domyślne ustawienia Samby (mapowanie na uniksowa˛
grup˛e -1) wymaga zmiany, która˛ wprowadzi polecenie net groupmap add:
# net groupmap add ntgroup="Domain Admins" unixgroup=domadmin type=d
Updated mapping entry for Domain Admins
Podobnie modyfikujemy wpisy dla grup Domain Users - decydujac
˛ si˛e na wybór
grupy users oraz Domain Guests - nobody: net groupmap.
# net groupmap add ntgroup="Domain Users" unixgroup=users type=d
Updated mapping entry for Domain Users
# net groupmap add ntgroup="Domain Guests" unixgroup=nobody type=d
Updated mapping entry for Domain Guests
# net groupmap add ntgroup="Users" unixgroup=users type=d
Add mapping entry for Users
Sprawdźmy, czy zmiany b˛eda˛ widoczne:
# net groupmap list
...
Domain Admins (S-1-5-21-353545269-2518139598-3611003224-512) -> domadmin
Domain Users (S-1-5-21-353545269-2518139598-3611003224-513) -> users
Domain Admins (S-1-5-21-353545269-2518139598-3611003224-514) -> nobody
Users (S-1-5-21-353545269-2518139598-3611003224-3001) -> users
..
Praca komputera w domenie wymaga założenia mu konta - tzw. Machine Trust Account. Jest to specyficzne konto, gdyż jego hasło ustalane jest przy podłaczaniu
˛
komputera do domeny i znane tylko parze klient-serwer. Dzi˛eki temu istnieje możliwość
sprawdzenia tożsamości próbujacego
˛
si˛e logować komputera - nawet gdy ktoś dołaczy
˛
maszyn˛e o tej samej nazwie, to nie powinien uzyskać możliwości dost˛epu do
domeny. Nazwy kont odpowiadaja˛ nazwom NetBIOS komputerów, ale z dołaczo˛
nym na końcu symbolem dolara. Dla stacji biuro b˛edzie to wi˛ec biuro$. Konto to
powinno być zablokowane, by niemożliwe było uzyskanie dost˛epu poprzez ssh, czy
też inne usługi systemu operacyjnego. Nie jest także konieczny katalog domowy, w
zamian za to zdecydujemy si˛e na umieszczenie kont w grupie machines - pozwoli
to w jakimś stopniu ogarnać
˛ szybko zwi˛ekszajac
˛ a˛ si˛e liczb˛e użytkowników systemu
serwera.
# groupadd machines
# useradd -c "Komputer biurowy" -g machines -d /dev/null -s /bin/false biuro$
# passwd -S biuro$
Password locked.
Wydaje si˛e, że powinniśmy teraz utworzyć odpowiedni wpis w bazie haseł Samby nie jest to jednak konieczne. Przy próbie podłaczenia
˛
komputera do domeny czynność ta zostanie wykonana automatycznie. Gdy jednak zajdzie potrzeba r˛ecznego
utworzenia wpisu, do wywołania smbpasswd dodać musimy parametr -m (machine):
# smbpasswd -a -m ksiegowosc
W tym przypadku nie podajemy symbolu $. Oczywiście cały proces
dodawania kont maszyn można zautomatyzować w tym celu należy dodać do
/etc/samba/smb.conf:
add machine script = /usr/sbin/useradd -d /var/lib/nobody -g machines -c ’Konto Maszyny
passwd chat debug = no
passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passwd:*all*aut
passwd program = /usr/bin/smbpasswd -L -a %u
i oczywiście utworzyć katalog /var/lib/nobody
252
# mkdir /var/lib/nobody
należy sie też upewnić czy nie mamy w smb.conf wpisu
# kto nie moze sie logowac do samby
invalid users = root
Aby dodać Windows XP Profesional lub Microsoft Windows NT Server 4.0 Standard
Edition (wersja Home nie obsługuje modelu domenowego w żaden sposób) należy
w rejestrze zmienić:
REGEDIT4
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\netlogon\parameters
"RequireSignOrSeal"=dword:00000000
lub z poziomu Local Group Policy wyłaczaj
˛
ac
˛ (Disabled) Security Options | Domain
Member | Digitally encrypt or sign secure channel data (always)
wiecej:
/usr/share/doc/samba-doc/Registry/WinXP_SignOrSeal.reg
Brian Getsinger (Apple Corp). Mac OS X Server Samba Primary Domain Controller
Configuration
http://www.afp548.com/Articles/system/sambapdc.html20
Sherlock Error logging a Win XP machine into a domain running Samba.
http://www.slakaz.org/articles/6.html
Serwer członkowski domeny NT4
W tym rozdziale przedstawiona zostanie konfiguracja samby w roli serwera członkowskiego domeny Microsoft Windows NT4. Zaleta˛ takiej konfiguracji jest możliwość budowania polityki praw dost˛epu do zasobów zgromadzonych na serwerze w
oparciu o konta użytkowników lokalnego serwera PDC.
Instalacja
Do realizacji tego zadania potrzebne b˛eda˛ trzy pakiety: samba, samba-clients oraz
samba-winbindd. Znaczenie poszczególnych pakietów:
•
samba - pakiet ten zawiera serwer samby
•
samba-clients - zestaw narz˛edzi przydatnych w poruszaniu si˛e w środowisku Microsoft Networks.
•
samba-winbindd - demon pozwalajacy
˛ na pobieranie uprawnień z serwera PDC.
Proces instalacji pakietów przedstawiony został w dziale Zarzadzanie
˛
pakietami.
Konfiguracja
Przy użyciu dowolnego edytora otwieramy plik /etc/samba/smb.conf. Cała˛ konfiguracj˛e z której b˛edzie również korzystał demon winbindd należy wykonać w sekcji
[global]. Przyj˛eta w nim została nast˛epujaca
˛ konwencja: <opcja> = <wartość>. Jeżeli dana opcja ma kilka wartości, oddziela si˛e je znakiem spacji. Poszczególne opcje
umieszczane sa˛ w osobnych liniach. Komentarze w pliku rozpoczynaja˛ si˛e znakiem
"#" lub ";". Poniżej znajduje si˛e wykaz najważniejszych opcji które należy ustawić
podczas realizacji zadania. Wykraczaja˛ one nieco poza czysta˛ konfiguracj˛e winbindd
ale sa˛ konieczne do jego prawidłowego działania.
253
workgroup = DOM
server string = File Server
Ustawiamy nazw˛e domeny której członkiem b˛edzie nasz serwer oraz opcjonalnie
komentarz (opis) komputera.
security = domain
Określamy poziom bezpieczeństwa. Nasza konfiguracja wymaga ustawień zabezpieczeń typu domenowego.
password server = PDC
Nazwa netbiosowa serwera PDC. To z tego właśnie serwera demon winbind b˛edzie
pobierał uprawnienia.
To tyle, jeżeli chodzi o ogólna˛ konfiguracj˛e samby. Teraz czas na dodanie kilku opcji
potrzebnych winbindowi.
winbind separator = +
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
client signing = yes
- znak, którym oddzielana b˛edzie nazwa użytkownika badź
˛
grupy od nazwy domeny. Np. "DOM+jan"
• winbind separator
- zakres uidów w systemie zarezerwowanych na użytkowników
domenowych
• idmap uid
• idmap gid
- zakres gidów w systemie przeznaczonych na grupy domenowe
Na tym możemy zakończyć edycj˛e pliku konfiguracyjnego samby. Aby nasza konfiguracja stała si˛e aktywna musimy przerestartować usług˛e.
/etc/rc.d/init.d/smb restart
W ślad za usługa˛ smb zostana˛ przerestartowane także nmbd oraz interesujacy
˛ nas
winbindd. Czynnościa˛ która˛ musimy bezwzgl˛ednie wykonać jest podłaczenie
˛
naszego serwera do domeny. Aby to uczynić wykonujemy poniższe polecenie:
# net rpc join -S PDC -U Administrator%hasło
Joined the domain DOM
Jeżeli w tym momencie miałbyś problemy ze skomunikowaniem si˛e z serwerem domeny możesz dodać do polecenia opcj˛e -I a po niej adres IP serwera PDC. Po pomyślnej operacji podłaczenia
˛
możemy sprawdzić działanie winbinda.
# wbinfo -g
DOM+Administrator
DOM+Basia
DOM+Darek
...
# wbinfo -g
DOM+Domain Admins
DOM+Domain Users
...
Opcja -u pokazuje list˛e użytkowników, natomiast -g list˛e grup.
Jeżeli wynik obu poleceń wyglada
˛ podobnie jak na listingu oznacza to, że winbind
pracuje poprawnie.
254
Zakończenie
Jakie korzyści płyna˛ z takiej konfiguracji samby? Otóż sprawdza si˛e ona w środowisku sieciowym w którym zasoby udost˛epniaja˛ zarówno serwery pracujace
˛ pod
kontrola˛ Windows jak i linuksa. Pozwala to na budowanie spójnej polityki bezpieczeństwa w oparciu o uwierzytelnianie użytkownika na poziomie domeny. Druga˛
z zalet jest prostota w implementacji. Dzi˛eki winbindd dost˛ep do grup oraz użytkowników domenowych odbywa si˛e w taki sam sposób jak do ich odpowiedników
lokalnych.
# chown DOM+Administrator.DOM+Domain\ Users plik.txt
Snort - Sieciowy System Wykrywania Włamań
Snort22 to bardzo silny sieciowy system wykrywania ataków (ang. Network Intrusion Detection System, NIDS), który daje szeroki zakres mechanizmów detekcji, mogacych
˛
w czasie rzeczywistym dokonywać analizy ruchu i rejestrowania pakietów w
sieciach opartych na protokołach IP/TCP/UDP/ICMP. Potrafi przeprowadzać analiz˛e strumieni pakietów, wyszukiwać i dopasowywać podejrzane treści, a także wykrywać wiele ataków i anomalii, takich jak przepełnienia bufora, skanowanie portów
typu stealth, ataki na usługi WWW, SMB, próby wykrywania systemu operacyjnego
i wiele innych.
Wymagania
Przed instalacja˛ Snorta warto zaopatrzyć si˛e w baz˛e danych (w opisie wykorzystano
MySQL) i serwer Apache z obsługa˛ PHP. W bazie b˛eda˛ składowane logi, a za wygodny interfejs do przegladania
˛
alarmów posłuży ACID (ang. Analysis Console for
Intrusion Databases).
Instalacja Snorta i ACID
Gdy mamy już baz˛e danych i serwer WWW z PHP, instalujemy nast˛epujace
˛ pakiety.
# poldek -i snort acid
Przed konfiguracja środowiska NIDS zakładamy dwie bazy, dla Snorta i dla archiwum alarmów.
# mysql -u mysql -p
Enter password:
mysql> create database snort_log;
Query OK, 1 row affected (0.01 sec)
mysql> create database snort_archive;
Query OK, 1 row affected (0.01 sec)
mysql> quit
Dodajemy tabele w taki sam sposób dla obu baz.
# gzip -d /usr/share/doc/snort-{wersja}/create_mysql.gz
# mysql -D snort_log -u mysql -p < \
/usr/share/doc/snort-{wersja}/create_mysql
# gzip -d /usr/share/doc/acid-{wersja}/create_acid_tbls_mysql.sql.gz
# mysql -D snort_log -u mysql -p < \
/usr/share/doc/acid-{wersja}/create_acid_tbls_mysql.sql
# mysql -D snort_archive -u mysql -p < \
255
/usr/share/doc/snort-{wersja}/create_mysql
# mysql -D snort_archive -u mysql -p < \
/usr/share/doc/acid-{wersja}/create_acid_tbls_mysql.sql
Nast˛epnie (najprościej przy użyciu popularnego narz˛edzia phpMyAdmin) tworzymy użytkownika i nadajemy mu prawa dla stworzonych baz.
Przechodzimy do edycji pliku /etc/acid_conf.php, w którym dodajemy parametry
dla połaczenia
˛
si˛e z bazami.
[...]
/* Alert DB connection parameters */
[...]
$alert_dbname
= "snort_log";
$alert_host
= "localhost";
$alert_port
= "3306";
$alert_user
= "login";
$alert_password = "haslo";
/* Archive DB connection parameters */
$archive_dbname
= "snort_archive";
$archive_host
= "localhost";
$archive_port
= "3306";
$archive_user
= "login.;
$archive_password = "haslo";
[...]
Teraz strona z interfejsem jest dost˛epna pod adresem http://twoje_ip/acid. Oczywiście dla bezpieczeństwa zalecane jest zastosowanie protokołu SSL do komunikacji z
zasobem i autoryzacji poprzez pakiet apache-mod_auth.
Snort zależnie od środowiska w jakim działa może generować duża˛ ilość zb˛ednych
alertów, te bardziej istotne można przenosić do drugiej bazy za pomoca˛ ACID, dla
przejrzystości ogółu.
Konfiguracja Snorta
Do działania jako sieciowy system wykrywania włamań, Snort potrzebuj˛e
sprecyzowania zasad funkcjonowania całości w głównym pliku konfiguracyjnym
snort.conf. W starszych wersjach systemu, wszystkie opcje, łacznie
˛
z regułami
ataków znajdowały si˛e w jednym pliku. Ciagła
˛
rozbudowa Snorta, rosnaca
˛ liczba
sygnatur i ogólna funkcjonalność, wymusiła rozdzielenie niektórych cz˛eści
konfiguracyjnych, w tym reguł ataków. Przejrzystość i spójność snort.conf została
przywrócona przy użyciu polecenia include, którym dołacza
˛
si˛e odpowiednie
zestawy sygnatur i inne cz˛eści konfiguracyjne, np.:
include: ścieżka_do_pliku/nazwa
Bazy reguł charakteryzuja˛ si˛e nazwa˛ pliku z końcówka˛ .rules, pierwszy człon nazwy zawiera rodzaj usługi lub typ ataku, którego dotyczy dany zestaw.
Pozostałymi plikami konfiguracyjnymi sa:˛
• classification.config - zawierajacy
˛ klasyfikatory rodzajów ataków z nadanym
priorytetem zagrożenia, tak jak poniżej:
config classification: web-application-attack,Web Application Attack,1
• reference.config
- posiadajacy
˛ skróty adresów do stron organizacji z baza˛
opisów ataków, np.:
config reference: bugtraq http://www.securityfocus.com/bid/
256
• threshold.conf
• unicode.map
- metody łagodzenia licznych, fałszywych alarmów,
- zestaw kodowanych znaków unicode, na potrzeby preprocesora
http_inspect.
Główny plik konfiguracyjny można podzielić na cztery sekcje. Pierwsza, odpowiedzialna jest za ustalanie zmiennych var, wykorzystywanych w składni reguł ataków.
Przyjmijmy że docelowo Snort ma monitorować dwie podsieci o adresach
192.168.1.0/24 i 192.168.2.0/24, jego pliki konfiguracyjne znajduja˛ si˛e bezpośrednio
w katalogu /etc/snort, a regułki w /etc/snort/rules.
# Adres sieci lokalnej
var HOME_NET [192.168.1.0/24,192.168.2.0/24]
# Adres sieci zewnetrznej
var EXTERNAL_NET !$HOME_NET
# Lista adresow serwerow znajdujacych sie w strefie chronionej
var DNS_SERVERS $HOME_NET
var SMTP_SERVERS $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var TELNET_SERVERS $HOME_NET
var SNMP_SERVERS $HOME_NET
# Lista portow
var HTTP_PORTS 80
var SHELLCODE_PORTS !80
var ORACLE_PORTS 1521
# Lista serwerow czat, komunikatorow
var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,]
# Scieżka do katalogu z regulami atakow
var RULE_PATH /etc/snort/rules
W tej samej sekcji znajduje si˛e zestaw parametrów uruchomieniowych, zaczynaja˛
cych si˛e od wyrażenia config (pełna ich lista znajduj˛e si˛e w dokumentacji):
# wybor interfejsu do nasłuchu (jeden demon Snorta moze
# obslugiwac tylko jeden interfejs sieciowy)
config interface: eth0
Druga cz˛eść głównego pliku konfiguracyjnego, zawiera ustawienia preprocesorów.
Parametry domyślne nie b˛eda˛ przedstawione w poniższym opisie. Kompletna˛ list˛e
opcji, można znaleźć w dokumentacji Snorta. Oto przykłady ustawień preprocesorów:
Frag2:
# detect_state_problems . zwraca alarm przy pokrywaniu sie fragmentow.
preprocessor frag2: detect_state_problems
Stream4, Stream4_reassemble:
# disable_evasion_alerts - brak alarmow przy nakladaniu sie
#pakietow TCP, detect_scans - detektor prob cichego skanowania,
# detect_state_problems - detektor nienaturalnego zachowania
# pakietow.
preprocessor stream4: disable_evasion_alerts \
detect_scans detect_state_problems
# both - skladanie sesji TCP w obu kierunkach pomiedzy
# klientem i serwerem,
# ports - lista portow, na ktorych ma dzialac reasemblacja.
preprocessor stream4_reassemble: both ports [ 21 25 80 143 110 ]
Http_inspect:
# iis_unicode_map - wskazuje plik z kodowaniem unicode i wybiera standardowe.
257
preprocessor http_inspect: global is_unicode_map unicode.map 1252
# profile - wybor profilu ustawien dla serwerow typu iis, apacze i all.
preprocessor http_inspect_server: server adres_IP_serwera_MS_IIS \
profile iis \
ports { 80 }
preprocessor http_inspect_server: server adres_IP_serwera_Apache \
profile apache \
ports { 80 }
Powyższy przykład przedstawia możliwość profilowania ustawień dla poszczególnych serwerów, które podlegaja˛ ochronie. Serwery IIS i Apache, pracuja˛ w odmienny sposób, a zarazem posiadaja˛ inne słabe punkty wykorzystywane podczas ataków. Operacja dostosowania ustawień skupia mechanizmy ochronne na odpowiednich metodach ataków dla danego typu serwera badź
˛ ich grupy w danej sieci obj˛etej
ochrona.˛
RPC_decode, Back Orfice, Telnet_decode, Arpspoof, Performance Monito:
# alert_fragments . wlacza alarm, przy fragmentowaniu pakietow RPC,
# Domyślne porty: 111 i 32771.
preprocessor rpc_decode: 111 32771 alert_fragments
preprocessor bo
preprocessor telnet_decode
preprocessor arpspoof
preprocessor arpspoof_detect_host: adresy_IP \
przypisane_do_nich_adresy_MAC
# console . wyswietlanie statystyk na ekranie,
# flow i events . statystyki badanego ruchu i ilosci dopasowanych
# regul,
# time . aktualizacja danych co 10s.
preprocessor perfmonitor: console flow events time 10
Flow i Flow-portscan:
# stats_interval . zapisywanie statystyk, 0 - wylaczone,
# hash . wybor metody mieszania.
preprocessor flow: stats_interval 0 hash 2
# server-watchnet . adresy IP, na ktorych flow bedzie
# prowadzic badania,
# server-learning-time . czas utrzymania punktow dla danego adresu IP,
# server-scanner-limit . ilosc zapytan decydujacych o przyznaniu
# statusu
#
skanowania z danego adresu,
# src-ignore-net, dst-ignore-net . lista ignorowanych adresow docelowych
#
i zrodlowych.
preprocessor flow-portscan: \
server-watchnet [xxx.xxx.xxx.xxx/xx] \
server-learning-time 14400 \
server-scanner-limit 10 \
src-ignore-net [xxx.xxx.xxx.xxx/xx, xxx.xxx.xxx.xxx/xx] \
dst-ignore-net [xxx.xxx.xxx.xxx/xx]
Trzecia sekcja snort.conf, zawiera metody konfiguracji modułów wyjściowych,
czyli różnych sposobów logowania wyników i tzw. akcji reguł. Na potrzeby tego
opisu wymieniony b˛edzie tylko przykład logowania do bazy MySQL.
output database: alert, mysql, user=login password=haslo \
dbname=snort_log host=127.0.0.1
Za pomoca˛ reguł akcji można tworzyć własne rodzaje reakcji na wykryte zdarzenie,
np.:
ruletype czerwony_alarm
{
type log
258
# zapis do demona syslogd, lokalnie
output alert_syslog: LOG_ALER
}
# Przykladowa regula:
czerwony_alarm $HOME_NET any -> $HOME_NET 6667 (msg:"Internal \
IRC Server";)
Czwarta, ostatnia cz˛eść, głównego pliku konfiguracyjnego, zawiera odniesienia
do zestawów reguł i wcześniej już opisanych plików, classification.config,
reference.config, threshold.conf (przykład poniżej).
include classification.config
include reference.config
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/dos.rules
(...)
# dodatkowy zestaw regul Bleeding Snort # http://www.bleedingsnort.com
include $RULE_PATH/bleeding.rules
include threshold.conf
Dostosowanie Snorta do swoich potrzeb obejmuje, obok konfiguracji preprocesorów
przede wszystkim decyzje, jakie zbiory reguł maja˛ być brane pod uwag˛e (czyli jakie
pliki z regułami maja˛ być dołaczane
˛
za pomoca˛ polecenia include). W środowisku, w
którym wszystkie serwery WWW to Apache, reguły chroniace
˛ serwer IIS b˛eda˛ generowały zupełnie niepotrzebne alarmy. Jeśli nie udost˛epniamy FTP, reguły opisujace
˛
ataki na t˛e usług˛e b˛eda˛ tylko spowalniały prac˛e całego systemu. To sprawy oczywiste, jednak właściwe dostosowanie NIDS do swoich potrzeb wymaga wiele pracy.
Dobranie odpowiednich dla danego środowiska reguł jest kluczowe dla działania
całego systemu, duża ilość fałszywych alarmów nie tylko zużywa zasoby (każda z
reguł musi być przecież przeanalizowana), ale może również bardzo skutecznie "zaciemnić" obraz, sprawiajac,
˛ że prawdziwy atak może przejść niezauważony w zalewie informacji mało istotnych. Obecna baza sygnatur liczy sobie około 2500 reguł i
jest praktycznie każdego dnia wzbogacana o nowe opisy ataków. Dla przybliżenia
wyst˛epujacych
˛
w bazie kategorii sygnatur, opisz˛e jakiego rodzaju ataki wykrywaja:˛
•
attack-responses - odpowiedzi usług na prób˛e ataku;
•
backdoor - działalność tzw. tylnych drzwi, trojanów, rootkitów;
•
bad-traffic - nieprawidłowy ruch, np. na port 0;
•
chat - aktywność różnego rodzaju komunikatorów;
•
ddod, dos - zmasowane ataki Distributed Denial of Service (rozproszony atak typu
- blokada usługi);
•
deleted - reguły przestarzałe, wykasowane;
•
dns - ataki na usług˛e Domain Name System;
•
experimental - zestaw eksperymentalnych reguł;
•
exploit - programy majace
˛ na celu wykorzystywanie bł˛edów w oprogramowaniu;
•
icmp-info, icmp - komunikaty ICMP z różnych programów, testujacych
˛
ruch;
•
imap, pop2, pop3, smtp - ataki na systemy pocztowe;
•
info - próby logowania na usługi Telnet, Ftp;
•
local - zestaw własnych reguł;
•
misc - różne, dotyczace
˛ usług CVS, MS Terminal, BOOT, UPnP itd.;
259
•
multimedia - strumienie audio, wideo;
•
mysql, sql, oracle - ataki na znane serwer baz danych;
•
netbios - anomalia zwiazane
˛
z protokołem Netbios/SMB;
•
nntp - ataki na serwer grup dyskusyjnych;
•
other-ids - działalność innych systemów IDS;
•
p2p - aktywność programów Peer to Peer;
•
policy - próby ataków na usługi policy ftp itp.
•
porn - aktywność stron pornograficznych;
•
rpc - ataki na usługi Remote Procedure Call;
•
finger, rservices, telnet - ataki na dość słabo zabezpieczone usługi uniksowe: finger,
rlogin, rsh, rexec, telnet;
•
scan - różnego rodzaju techniki skanowania portów;
•
shellcode - wykorzystanie nieprawidłowego kodu do prób przepełnienia bufora;
•
snmp - ataki na usługi SNMP;
•
tftp, ftp - zdarzenia zwiazane
˛
z przesyłaniem plików poprzez serwer ftp;
•
virus - transfer poczty z podejrzanym załacznikiem;
˛
•
web-attacks, web-misc, web-client, web-cgi, web-php, web-coldfusion, web-frontpage, webiis - ataki na różnego typu serwery WWW, przeważnie z wykorzystaniem bł˛edów
w skryptach cgi, php;
•
x11 - aktywności sesji serwera XFree86.
Aktualizacja reguł
Do aktualizacji sygnatur posłuży nam perlowy skrypt Oinkmaster23. Ma on duże
możliwości które pozwalaja˛ w prosty sposób zarzadzać
˛
regułami Snorta. Wymagane
pakiety do uruchomienia to: perl, perl-base, perl-modules i vixie-cron albo hc-cron .
Instalacja Oinkmaster
Ściagamy
˛
archiwum tar, rozpakowujemy, skrypt wgrywamy do katalogu
/usr/local/bin, a konfig do /etc:
# wget --passive-ftp \
ftp://ftp.it.su.se/pub/users/andreas/oinkmaster/oinkmaster-1.0.tar.gz
# tar -zxvpf oinkmaster-1.0.tar.gz
# cp oinkmaster-1.0/oinkmaster.pl /usr/local/bin/
# cp oinkmaster-1.0/oinkmaster.conf /etc/
Operacja aktualizacji odbywa si˛e po nast˛epujacej
˛ sekwencji komend:
# /usr/local/bin/oinkmaster.pl -o /etc/snort/rules/
Dodanie innego źródła reguł:
# /usr/local/bin/oinkmaster.pl -o /etc/snort/rules/ -q -u \
http://www.bleedingsnort.com/bleeding.rules.tar.gz
Aby aktualizacja odbywała si˛e automatycznie, w katalogu /etc/cron.daily tworzymy plik uprules.
# touch /etc/cron.daily/uprules
# chmod 700 /etc/cron.daily/uprules
260
I dodajemy do niego nast˛epujac
˛ a˛ zawartość, podajac
˛ adres e-mail na który ma zostać
wysłany raport z codziennej aktualizacji jeśli pojawia si˛e coś nowego:
TMP=‘mktemp /tmp/oinkmaster.XXXXXXXX‘ &&
(/usr/local/bin/oinkmaster.pl -o /etc/snort/rules/ \
-q > $TMP 2>&1;
if [ -s $TMP ]; then mail -s "Update Snort Rules" root@twoja_domena < $TMP; fi;
rm $TMP)
# dodatkowy zestaw regul Bleeding Snort - http://www.bleedingsnort.com
TMP=‘mktemp /tmp/oinkmaster.XXXXXXXX‘ &&
(/usr/local/bin/oinkmaster.pl -o /etc/snort/rules/ -q -u \
http://www.bleedingsnort.com/bleeding.rules.tar.gz > $TMP 2>&1;
if [ -s $TMP ]; then mail -s "Update Bleeding Rules" \
root@twoja_domena < $TMP; fi; rm $TMP)
/etc/rc.d/init.d/snort restart
Warto przyjżeć si˛e bliżej ciekawym funkcjonalnościom oinkmastera. W pliku konfiguracyjnym mamy możliwość wyłaczania
˛
poszczególnych regułek po nr sid, dodawania do nich własnych modyfikacji itp. Wtedy jest pewność że po aktualizacji,
nasze zmiany w plikach reguł nie b˛eda˛ nadpisywane.
Architektura Snorta
Snort jest logicznie podzielony na kilka komponentów, które współpracuja˛ ze soba˛
by wykrywać ataki i generować wyniki w odpowiednim formacie. Głównymi składnikami systemu sa:˛ dekoder pakietów (sniffer), preprocesory, silnik detekcji i moduł
wyjściowy.
W swej najprostszej formie Snort może działać jako sniffer. Przechwytuje pakiety z
warstwy łacza
˛
danych za pomoca˛ biblioteki pcap. Rozpoznaje różne protokoły modelu OSI - Ethernet, 802.11, Token Ring oraz wiele protokołów działajacych
˛
w wyższych warstwach jak: IP, TCP, UDP i ICMP. Surowe pakiety z warstwy łacza
˛
danych
(np. ramki Ethernetowe) po zdekodowaniu wadruj
˛
a˛ do preprocesorów (warstwa
transportowa), gdzie sa˛ testowane i w razie konieczności obrabiane na potrzeby silnika detekcji (warstwa sesji). Tam dokonywana jest analiza pakietów pod katem
˛
zbioru zadanych reguł. Nast˛epnie po wykryciu próby ataku badź
˛ anomalii sieciowych,
system przekazuje odpowiednie dane do modułu wyjściowego, który to decyduje o
zapisaniu wyniku wykrycia w logach lub wszcz˛eciu alarmu.
Tryby pracy
Snort umożliwia duża˛ swobod˛e konfiguracji, za pomoca˛ wielu parametrów, które pozwalaja˛ kontrolować trzy podstawowe tryby pracy programu: sniffer, packet logger
i network intrusion detection.
•
Sniffer Mode - wychwytuje wszystkie pakiety w danym segmencie sieci i
przedstawia ich zawartość na ekranie. Najprostszym sposobem użycia tego trybu
jest uruchomienie programu z parametrem -v w wyniku, czego Snort b˛edzie
wyświetlać informacje o nagłówkach IP, TCP/UDP/ICMP. Do uzyskania bardziej
szczegółowych danych o wychwyconych pakietach, służa˛ parametry -d (aby
monitorować ładunek pakietów) i -e (dodatkowe nagłówki warstwy łacza
˛
danych). Parametry można łaczyć
˛
razem, bez znaczenia jest ich kolejność (np.
snort -ved). Aby zakończyć prac˛e w tym trybie należy użyć sekwencji klawiszy
CTRL+C.
•
Packet Logger Mode - logowanie pakietów poprzez zapis na dysku. Czynność ta
odbywa si˛e po użyciu opcji -l, która˛ wskazujemy katalog, gdzie Snort b˛edzie
zapisywać w odpowiednio nazwanych podkatalogach i plikach, zawartość
261
zebranych pakietów. Program potrafi także zapisywać dane w formie binarnej
tak jak robi to znany sniffer tcpdump. Służy do tego opcja -b, po jej użyciu nie
trzeba stosować dodatkowych kombinacji parametrów -ved, ponieważ format
tcpdump, określa to, co ma być logowane (np. snort -b -l ./log). Uzyskane w
ten sposób informacje, można wykorzystać do późniejszej analizy za pomoca˛
programów rozpoznajacych
˛
format binarny tcpdump (np. Ethereal). Oczywiście
można ta˛ sama˛ czynność wykonać z wykorzystaniem Snorta, używajac
˛ opcji
-r, po czym przetworzyć sczytane pakiety dost˛epnymi trybami. Snort czytajac
˛
swoje dzienniki (tak samo działajac
˛ w trybie sniffera) przyjmuje parametry w
formacie BPF (Berkeley Packet Filter), dzi˛eki którym możemy sprecyzować (na
podstawie nagłówków), jakie konkretnie pakiety chcemy obserwować (np.
określić adres hosta, protokół, port). Jeśli np. interesuje nas tylko ruch na porcie
80 można uruchomić Snorta poleceniem: snort -r /var/log/snort/snort.log port
www, jeśli chcemy wyświetlić tylko odpowiedzi serwera www: snort -vde src
port www. Aby ignorować cały ruch z sieci np. 192.168.1.0 na port 80: snort
-vde not ( src net 192.168.1 and dst port 80). Połaczenie
˛
Snorta z filtrami BPF
znacznie zwi˛eksza wydajność całego systemu, gdyż filtrowanie BPF odbywa si˛e
w warstwie łacza
˛
danych (a wi˛ec na poziomie biblioteki pcap). Określajac
˛ w ten
sposób, jakie pakiety nas interesuja˛ (lub jakie chcemy zignorować) można dość
dokładnie "zaw˛ezić" obszar poszukiwań. Filtry BPF można również zapisać w
oddzielnym pliku i załadować w trakcie uruchamiania Snorta parametrem -F:
snort -r snort.log -F plik_z_bdf. Wi˛ecej na temat możliwości oferowanych przez
BPF można poczytać na stronach podr˛ecznika zarówno Snorta, jak i Tcpdump.
•
Network Intrusion Detection Mode - sieciowy system wykrywania włamań. Jest najbardziej skomplikowanym trybem działania programu. Za pomoca˛ parametru -c,
wskazujemy plik konfiguracyjny, w którym określane sa˛ zasady badania przechwyconego ruchu sieciowego, ustawienia preprocesorów, a także zestaw sygnatur
ataków. Aby program działał w tle jako demon, należy użyć opcji -D (np. snort
-d -D -c snort.conf). Reszta operatorów i ich opisy, jakie można wykorzystać przy
starcie programu, przedstawia parametr -h.
Preprocesory
Preprocesory zostały wprowadzone do Snorta w wersji 1.5. Pozwalaja˛ użytkownikom i programistom w prosty sposób na rozbudow˛e funkcjonalności całego systemu
poprzez pisanie dodatkowych modułów (ang. plugins).
Preprocesory analizuja˛ pakiety przed wykorzystaniem ich przez silnik detekcji. W
ten sposób zwi˛ekszaja˛ możliwości całego procesu wykrywania ataków sieciowych,
wzbogacajac
˛ go o zdolność składania (reasemblacji) pakietów, wykonywania specyficznych dla poszczególnych protokołów operacji (np. konwersja na ASCII znaków
z URI zakodowanych szesnastkowo, usuwanie ciagów
˛
binarnych z sesji FTP czy Telnet, normalizacja żada
˛ ń RPC), jak i wykrywania niezgodności z tymi protokołami.
Poniżej pokrótce opiszemy standardowy zestaw preprocesorów wchodzacych
˛
w
skład darmowej dystrybucji Snorta w wersji 2.1.3.
262
•
Frag2 - defragmentuje i normalizuje dane przychodzace
˛ w postaci fragmentów,
co utrudnia ukrywanie ataków prowadzonych za pomoca˛ nieprawidłowo sfragmentowanych pakietów IP. W tym celu wykorzystuje ustalony przez użytkownika bufor pami˛eci, w której przez określony czas przetrzymuje do badania pakiety z tablicy stanów połacze
˛ ń. Im wi˛eksza liczba sfragmentowanych pakietów
tym wymagany jest wi˛ekszy bufor. Defragmentacja, układajac
˛ datagramy IP w
jedna˛ całość, ułatwia dalsza˛ analiz˛e danych poprzez pozostałe preprocesory i silnik detekcji. Frag2 umożliwia wychwytywanie znanych ataków wykorzystujacych
˛
zniekształcenia fragmentów pakietów np. teardrop, fragroute.
•
Stream4 - rozwija model detekcji oparty na testowaniu pojedynczych pakietów
umożliwiajac
˛ śledzenie sesji (stanu połaczenia)
˛
TCP i składanie (reasemblacji)
strumieni TCP, co nie byłoby możliwe w mechanizmie opartym na wyszukiwaniu
wzorców. Na tym poziomie działa także wykrywanie niektórych prób
skanowania portów, gdzie wymagane jest notowanie prób łaczenia
˛
si˛e z
poszczególnymi usługami w określonych odst˛epach czasu oraz wykrywanie
prób oszukania Snorta za pomoca˛ narz˛edzi takich, jak np. Stick lub Snot, które
generuja˛ pojedyncze (niewchodzace
˛ w skład poprawnych sesji TCP) pakiety
majace
˛ za zadanie zalać mechanizm detekcji masa˛ fałszywych alarmów (sa˛ to
pakiety budowane na losowo wybranych sygnaturach). Snort broni si˛e przed
takimi technikami wykorzystujac
˛ stream4 preprocesor - losowe pakiety sa˛ dość
łatwo identyfikowane (i ignorowane), ponieważ nie należa˛ do prawidłowej sesji
TCP. Stream4 wychwytuje próby skanowania technikami: stealth, null, xmas, fin;
wykrywanie systemu operacyjnego - fingerprint i inne anomalia zwiazane
˛
z
protokołem TCP.
•
Flow i Flow-Portscan - posiada mechanizm śledzenia połacze
˛ ń, zapisujac
˛ całość do
tablicy stanów w celu dalszego przetwarzania. Na tej podstawie flow-portscan
wykrywa próby skanowania w bardziej wyrafinowany sposób niż preprocesory
stream4 i portscan. Celem wykrywania, sa˛ skany z jednego hosta do wielu i z
jednego hosta na wiele portów. Flow-portscan prowadzi statystyki na podstawie
punktacji różnych rodzajów połacze
˛ ń, np. jeśli jakaś usługa jest popularna i na jej
port przychodzi dużo zapytań, jednocześnie dostaje najmniej punktów w ogólnej
skali. Preprocesor posiada bardzo wiele opcji za pomoca,˛ których reguluje si˛e skale
punktacji, rozmiary tablicy wyników, tolerancj˛e niepowtarzalności zdarzeń itp.
•
HTTP Inspect - jest ogólnym dekoderem protokołu HTTP na poziomie warstwy aplikacyjnej. Za pomoca˛ ustalonego bufora wynajduje odpowiednia˛ składnie HTTP i
ja˛ normalizuje. HTTP Inspekt działa w obydwu trybach jednocześnie: client requests
(pol. zapytania klienta) i server responses (pol. odpowiedzi serwera). Mnoga liczba
dost˛epnych opcji w konfiguracji preprocesora, umożliwia dostosowanie ustawień do konkretnego typu serwera WWW. Głównymi zadaniami http_inspect jest
przetwarzanie adresów URI, konwertujac
˛ na ASCII znaki zakodowane w postaci
szesnastkowej. Utrudnia to ukrycie ataku przed modułem wykrywajacym
˛
sygnatury ataków przez zakodowanie typowych sekwencji. Dekoduje także znaki zakodowane jako Unicode, oraz wykrywa nielegalne kodowania, wykorzystywane
m.in. w ostatnich dziurach MS IIS.
•
Portscan Detector - wykrywa próby skanowania portów, polegajace
˛
na
przekroczeniu pewnej progowej liczby prób połacze
˛ ń z różnymi portami w
określonym przedziale czasu. Ze wzgl˛edu na brak możliwości unikni˛ecia
fałszywych alarmów w typowych przypadkach (np. obcia˛żony serwer DNS),
istnieje możliwość wyłaczenia
˛
alarmów wzbudzanych przez określone adresy IP
używajac
˛ dodatkowego procesora portscan-ignorehosts. Pozwala także, zapisać
wyniki w oddzielnym pliku dziennika.
•
Telnet Decode - usuwa z sesji TELNET i FTP binarne ciagi
˛ mogace
˛ utrudnić
wyszukiwanie z udziałem sygnatur ataków.
•
RPC Decode - normalizuje żadania
˛
po protokole RPC, utrudniajac
˛ ukrywanie podejrzanych pakietów za pomoca˛ mniejszych operacji.
•
Back Orifice detektor - wyszukuje w pakietach UDP próby połacze
˛ ń konia
trojańskiego Back Orifice i próbuje złamać zabezpieczajace
˛ je słabe kodowanie.
•
Arpspoof - wykrywa podejrzane pakiety ARP, mogace
˛ sygnalizować próby ARP
spoofingu.
•
Performance Monitor - udost˛epnia wszelkiego rodzaju statystyki liczbowe, odnośnie
ilości przeanalizowanych pakietów, zużycia procesora itp. Całość wyświetlana jest
na ekranie konsoli lub zapisywana do pliku, wg ustalonych wcześniej wartości.
Zarówno preprocesory, jak i mechanizm detekcji moga˛ zareagować w określony sposób. Po wychwyceniu pakietów, spełniajacych
˛
warunki nadane konfiguracja˛ preprocesorów lub regułami, podejmowane jest odpowiednie działanie (np. zapisanie pakietów badź
˛ alarm).
263
Moduł sygnatur
Główny mechanizm systemu detekcji zagrożeń polega na dopasowaniu przetworzonych pakietów i ich zrekonstruowanych strumieni z baza˛ sygnatur. System detekcji porównuje cechy pakietu ze zbiorem reguł. Po dopasowaniu, zostaje podj˛eta odpowiednia akcja. Do porównywalnych cech należa˛ atrybuty główne - adresy, porty
źródłowe i docelowe oraz opcje pomocnicze: flagi TCP identyfikujace
˛ np. żadania
˛
zwiazane
˛
z WWW, różne typy pakietów ICMP, opcje IP czy wreszcie sama treść pakietu. Na razie w głównej cz˛eści reguł możliwe jest śledzenie protokołów IP, ICMP,
TCP i UDP. Autorzy przewiduja˛ rozszerzenie Snorta o nast˛epne protokoły sieciowe,
m.in. IPX, GRE, czy protokoły wymiany informacji mi˛edzy routerami - RIP, OSPF
oraz IGRP.
Reguły identyfikowania ataku pozwalaja˛ na podj˛ecie pi˛eciu rodzajów akcji: przepuszczenia pakietu (pass), zapisania informacji do dziennika (log), ogłoszenia alarmu (alert), alarmowania i podj˛ecia do działania innej dynamicznej reguły (activate) i
pozostanie w spoczynku do czasu aktywowania przez reguł˛e activate, po czym działanie jako reguła log (dynamic).
Sygnatury Snorta zazwyczaj składaja˛ si˛e z dwóch głównych sekcji - nagłówka i ciała
(treści). Nagłówek określa m.in., jaka˛ akcj˛e należy podjać
˛ po przypasowaniu reguły, informacje o wykorzystanym protokole, adresy badź
˛ porty źródłowe i docelowe.
Ciało reguły pozwala rozwinać
˛ informacje zawarte w nagłówku, tu także podaje sia˛
treść wzbudzanych alarmów i różnego rodzaju informacje dodatkowe (np. odniesienia do bazy z opisami danego naruszenia, tzw. referencje - Bugtraq24, CERT25 czy
CVE26).
Najprostsze sygnatury obejmuja˛ wskazanie akcji, protokołu, kierunku, adresów i
portów b˛edacych
˛
przedmiotem obserwacji, jak np. poniższa reguła, stanowiaca
˛ reakcj˛e na prób˛e skorzystania z usługi pop3 (port 110):
log tcp any any -> 192.168.1.0/24 110
W sygnaturach można umieszczać zmienne zdefiniowane jako adresy sieci (wg
CIDR) lub porty zapisane w pliku konfiguracyjnym snort.conf:
log tcp $EXTERNAL_NET -> $HOME_NET 110
W podanych powyżej regułach wykorzystany był jednokierunkowy operator "->". J˛ezyk sygnatur umożliwia zadeklarowanie reguły, który dopasuje pakiety poruszajace
˛
si˛e w obu stronach operatorem dwukierunkowym "<>", np.:
alert tcp any any <> $HOME_NET 23
Do zasadniczej cz˛eści reguły można dodać ograniczone okragłymi
˛
nawiasami pole
opcjonalne (tzw. ciało), zawierajace
˛ definicj˛e bardziej złożonych i wyrafinowanych
działań zwiazanych
˛
z przej˛eciem danego pakietu. Użytkownik może także sformułować własny komunikat, np.:
log tcp $EXTERNAL_NET -> $HOME_NET 110 \
("msg: Proba polaczenia z pop3";)
Podj˛ete działania nie musza˛ być ograniczone do pojedynczej czynności. Średnik separuje deklaracje poszczególnych działań, jak w poniższym przykładzie, w którym
opcja˛ content testowana jest treść przesyłanego strumienia TCP, a w razie odnotowania podejrzanego ciagu
˛ znaków generowany jest odpowiedni komunikat:
alert tcp any any -> 192.168.1.0/24 80 (content: "/cgi-bin/phf"; \
msg: "PHF probe!";)
Opcji content można użyć nawet kilka razy w jednej regule. Pozwala to na wyszukiwanie wielu różnych ciagów
˛
znaków w obr˛ebie przesyłanych treści.
264
Warto nadmienić, iż do przeszukania treści pakietów i reasemblowanych strumieni używany jest obecnie najbardziej efektywny algorytm - Boyera-Moore’a, którego
wydajność rośnie wraz z długościa˛ poszukiwanych ciagów.
˛
Możliwość rekonstrukcji
całych strumieni transmisji TCP, wgladu
˛ w warstw˛e aplikacyjna˛ i efektywne wyszukiwanie treści pozwala na walk˛e przy użyciu Snorta również z zainfekowanymi załacznikami
˛
elektronicznych listów. Oprócz przeszukiwania treści pakietów możemy
badać pod różnymi katami
˛
ich nagłówki, m.in. pola i kody ICMP, pole TTL, rozmiary
fragmentacji czy numery sekwencji.
Bardzo silna˛ konstrukcja˛ w regułach Snorta jest możliwość aktywowania kolejnych
reguł po pierwszym dopasowaniu. Konstrukcja ta nosi nazw˛e activate/dynamic rules i wyglada
˛ w nast˛epujacy
˛ sposób:
activate tcp any any -> $HOME_NET 143 (flags: PA; content: \
"|E8C0FFFFFF|bin|;activates: 1; msg: "IMAP buffer overflow!";)
dynamic tcp any any -> $HOME_NET 143 (activated_by: 1; count: 50;)
Opcje activates i activated_by wia˛ża˛ reguły activate i dynamic. W powyższym
przykładzie wykrycie ataku typu buffer overflow na serwer IMAP powoduje uruchomienie kolejnej, dynamicznej reguły, która zbiera treść nast˛epnych 50 pakietów
(opcja count) w celu późniejszej analizy. Druga opcja w reguły dynamicznej jest obligatoryjna - reguła zawierajaca
˛ wyłacznie
˛
opcj˛e dowiazania
˛
do innej, macierzystej
konstrukcji jest bezużyteczna.
Nast˛epne godne uwagi parametry, to resp i react wspieraja˛ mechanizm elastycznego reagowania na atak. Opcja resp może doprowadzić do zerwania połaczenia,
˛
np. poprzez wysłanie do atakujacego
˛
komunikatu ICMP o niedost˛epności trasy do
zaatakowanego komputera, natomiast react służy do blokowania dost˛epu do usług
zwiazanych
˛
z WWW.
Ciekawe projekty
•
Nessus27 - sieciowy tester bezpieczeństwa, przydatny do określania skuteczności
skonfigurowanego przez nas Snorta.
•
SnortALog28 - skrypt Perlowy pozwalajacy
˛ na generowanie różnego rodzaju raportów, grafów i statystyk. Korzystajac
˛ z logów Snorta, format wygenerowanych
raportów może stanowić plik tekstowy, HTML, a nawet PDF.
•
Snort Inline29 - poprawka dla Snorta, umożliwiajaca
˛ współprace z regułami firewalla IPtables, stosowanego w systemach opartych na jadrze
˛
Linux. Specjalnie
sformułowane sygnatury Snorta, reaguja˛ na atak i blokuja˛ badź
˛ przekierowuja˛ za
pomoca˛ ściany ogniowej drog˛e pakietów pochodzacych
˛
od intruza.
•
SnortSam30 - jest to zestaw pluginów do Snorta pełniacych
˛
podobna˛ funkcje jak
Snort Inline, ale wspomagajaca
˛ wi˛eksza˛ liczb˛e różnego rodzaju zapór ogniowych
(m.in. Checkpoint Firewall-1, Cisco PIX, Cisco Routers z ACL, Netscreen, IP Filter
dla *BSD, Linux IPchains, Linux IPtables, WatchGuard Firebox).
•
FLoP31 - projekt ma na celu, przyspieszenie logowania w procesie wykrywania
włamań. Do tego wykorzystuje odpowiednie bufory i możliwość szybkiego zapisu
przez gniazdo unixowe do baz danych MySQL i PostgreSQL. Bardzo przydatne
narz˛edzie przy pracy w sieciach o dużej przepustowości.
265
Syslog-ng
Wstep
˛
W PLD domyślnie instalowanym systemem magazynowania zdarzeń systemowych
(logów) jest syslog-ng (syslog - new generation), zajał
˛ on miejsce klasycznego tandemu syslogd i kalogd. Jest to program o bogatych opcjach konfiguracji, zapewniajacy
˛
wi˛eksza˛ pewność działania, a co za tym idzie wi˛eksze bezpieczeństwo logów.
Wi˛eksze bezpieczeństwo zapewnia możliwość użycia protokołu TCP w komunikacji
z tzw. loghostem, aby jednak korzystać z dobrodziejstw tego protokołu na obu maszynach musi być użyty demon "nowej generacji". Możliwa jest także komunikacja
z klasycznym syslogiem, w tym wypadku musimy użyć protokołu UDP i portu 514
(wartość domyślna dla syslog-ng).
Konfiguracja
Syslog-ng jest dostarczany z rozbudowanym plikiem konfiguracji, znajdziemy w nim
wiele gotowych do wykorzystania przykładów.
Konfiguracja demona polega na zdefiniowaniu pewnych obiektów, a na nast˛epnie
połaczenie
˛
ich ze soba˛ w reguły. Mamy trzy rodzaje obiektów: źródła, filtry i cele. Źródła wskazuja˛ miejsca pochodzenia komunikatów, filtry pozwalaja˛ selekcjonować dane, cele zaś wskazuja˛ sposób i miejsce magazynowania logów (zwyczajowo jako pliki tekstowe w katalogu /var/log). Cała˛ konfiguracj˛e umieszczamy w jednym pliku:
/etc/syslog-ng/syslog-ng.conf.
•
Źródła - definiujemy je nast˛epujaco:
˛
source $nazwa { $źródło($opcje); };
najpopularniejsze źródła komunikatów to:
•
internal - komunikaty demona syslog-ng
•
tcp - komunikaty od innych komputerów w sieci (TCP)
•
udp - komunikaty od innych komputerów w sieci (UDP)
•
pipe - nazwane potoki
•
unix-stream - gniazda uniksowe
przykłady:
source
source
source
src
udp
tcp
{ internal(); };
{ udp(); };
{ tcp(ip(192.168.1.5) port(1999) max-connections(20)); };
Pierwszy z przykładów jest źródłem komunikatów syslog-a. Drugi tworzy źródło
komunikatów wysyłanych z dowolnej maszyny w sieci - nasłuch na domyślnym
porcie (514 UDP). Trzeci oczekuje komunikatów od komputera 192.168.1.5 na porcie 1999 z ograniczeniem do 20 połacze
˛ ń.
•
Filtry:
filter $nazwa { $rodzaj($wartość); };
rodzaje:
•
266
facility - pochodzenie zdarzenia: cron, daemon, mail, ... - szczegóły w dodatku
•
level - priorytet: emerg, alert, crit, ... - szczegóły w dodatku
•
host - filtrowane po nazwie hosta z użyciem wyrażeń regularnych
•
program - filtrowane po nazwie programu z użyciem wyrażeń regularnych
przykłady:
filter
filter
filter
filter
f_emergency
f_daemon
f_foo
f_su_sudo
{
{
{
{
level(emerg); };
facility(daemon); };
host("foo"); };
program("^su|sudo$"); };
Pierwszy przykładowy filtr przepuszcza jedynie powiadomienia o najpoważniejszych bł˛edach. Drugi zdarzenia pochodzace
˛ od demonów, trzeci wybiera zdarzenia pochodzace
˛ od komputera majacego
˛
w nazwie ciag
˛ "foo". Ostatni odfiltrowuje
zdarzenia wywoływane w skutek działania programów su i sudo - użycie wyrażeń
regularnych.
W filtrach możemy używać operatorów logicznych (and, or, not):
filter f_syslog
filter f_ppp
•
{ not facility(authpriv, cron, lpr, mail, news); };
{ facility(daemon) and program(pppd) or program(chat); };
Cele - ogólna definicja:
destination $nazwa { $cel($miejsce); };
najpopularniejsze cele:
•
file - plik tekstowy / urzadzenie
˛
znakowe (/dev/)
•
usertty - ekran terminala wskazanego użytkownika
•
tcp - komunikaty do loghosta (TCP)
•
udp - komunikaty do loghosta (UDP)
przykłady:
destination
destination
destination
destination
kernel
console_all
root
loghost
{
{
{
{
file("/var/log/kernel"); };
file("/dev/tty12"); };
usertty("root"); };
udp("10.0.0.1"); };
W pierwszym przykładnie komunikaty sa˛ kierowane do pliku /var/log/kernel,
w drugim b˛eda˛ wyświetlane na dwunastym wirtualnym terminalu. Trzeci cel spowoduje wyświetlanie komunikatu na ekranie terminala użytkownika root. Czwarty obiekt pozwoli na wysyłanie komunikatów do loghosta o adresie IP 10.0.0.1
(uwaga na zgodność protokołów TCP/UDP u nadawcy i odbiorcy).
•
Regułki - budujemy je na samym końcu, kiedy mamy już zdefiniowane źródła,
filtry i cele:
log { source($źródło); destination($cel); };
log { source($źródło); filter($filtr1); filter($filtr2); destination($cel); };
np.:
log { source(src);
log { source(src);
destination(console_all); };
filter(f_emergency); destination(loghost); };
Aby zmiany weszły w życie oraz utworzone zostały nowe pliki dzienników, należy
ponownie uruchomić demona:
267
# service syslog-ng reload
Test konfiguracji
Najlepsza˛ metoda˛ sprawdzenia konfiguracji sysloga jest wysłanie własnych komuników systemowych. Posłużymy si˛e w tym celu programem logger, pozwalajacym
˛
wysyłać dowolne komunikaty z wiersza poleceń. Dla naszych potrzeb wywołujemy
program nast˛epujaco:
˛
logger -p {$źródło}.{$poziom} {$komunikat} np.:
# logger -p mail.warning Test ostrzeżenia
Uwagi
•
Podobnie jak poprzednik nie kontroluje obj˛etości logów, tak wi˛ec nie można zapomnieć o programie rotujacym
˛
np. logrotate.
•
Domyślnie demon nie nasłuchuje komunikatów z sieci, definicja źródła za to
odpowiedzialna jest wykomentowana.
•
W ramach ochrony przed atakami DoS syslog-ng obsługuje domyślnie do 10
połacze
˛ ń sieciowych, aby to zmienić należy użyć parametru "max-connections" w
opcjach źródła (patrz przykłady).
Dodatek
System operacyjny posiada wewn˛etrzny, niezależny od demona logów, schemat klasyfikowania zdarzeń, dziela˛ si˛e one na dwie grupy:
Pochodzenie komunikatów (facility):
Tabela 17-2.
Priorytety (level):
Tabela 17-3.
Przypisy
1. http://www.alsa-project.org/main/index.php/Matrix:Main
2. http://www.alsa-project.org/
3. http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html
4. http://linux-muzyka.ixion.pl/
5. http://www.faqs.org/rfcs/rfc2616.html
6. http://httpd.apache.org/docs-2.2/
7. http://httpd.apache.org/docs/2.2/mod/mod_vhost_alias.html
8. #
9. http://www.ietf.org/rfc/rfc1035.txt
268
10. http://www.linuxprinting.org/
11. http://www.ordb.org/lookup/
12. http://www.ordb.org/lookup/rbls/?host=w.x.y.z
13. http://jabberd.jabberstudio.org/2/docs/
14. http://www.powerdns.com/
15. http://www.powerdns.com/en/documentation.aspx
16. http://www.postgresql.org/
17. http://www.postgresql.org.pl/
18. http://www.proftpd.org/docs/
19. http://www.proftpd.org/docs/
20. http://www.afp548.com/Articles/system/sambapdc.html
21. http://www.slakaz.org/articles/6.html
22. http://www.snort.org
23. http://oinkmaster.sourceforge.net/
24. http://www.securityfocus.com/bid
25. http://www.cert.org/
26. http://www.cve.mitre.org/
27. http://www.nessus.org/
28. http://jeremy.chartier.free.fr/snortalog/
29. http://snort-inline.sf.net/
30. http://www.snortsam.net/
31. http://www.geschke-online.de/FLoP/
269
270
Rozdział 18. X-Window
Rozdział opisuje konfiguracj˛e środowiska graficznego.
Wstep
˛
W rozdziale tym postaramy pomóc w stworzeniu systemu "biurkowego", czyli systemu z X-Window. B˛edziemy tu opisywać implementacj˛e X.Org, wi˛ecej na jej temat
można znaleźć na witrynie projektu http://www.x.org/wiki/. Sam proces tworzenia desktopu możemy podzielić na dwa etapy:
•
Instalacja i konfiguracja serwera protokołu X11
•
Instalacja i konfiguracja menedżera okienek dla X.org (przedstawimy tutaj KDE i
GNOME)
Od razu należy przestrzec, że środowisko graficzne jest obsługiwane przez skończona˛ liczb˛e urzadze
˛
ń (dotyczy to zwłaszcza kart graficznych) i może si˛e niestety zdarzyć, że posiadamy kart˛e graficzna,˛ która nie jest obsługiwana. Dotyczy to głównie
najnowszego sprz˛etu, starsze modele maja˛ dosyć dobre wsparcie.
W przypadku kart firm firm ATI i NVIDIA, mamy dost˛epne zarówno sterowniki b˛edace
˛ cz˛eścia˛ X.Org jak i sterowniki zamkni˛ete, tworzone przez samych producentów.
Nielicznymi zaletami tych drugich jest bardzo dobra wydajność i pełne wsparcie dla
akceleracji grafiki trójwymiarowej.
X-Server
Instalacja
Na poczatku,
˛
korzystajac
˛ z programu poldek instalujemy konieczne pakiety. W przypadku Ac b˛eda˛ to:
$ poldek -i X11 X11-modules X11-fonts-100dpi-ISO8859-2 X11-setup \
X11-imake X11-libs X11-Xserver X11-OpenGL-libs X11-fonts \
X11-common X11-fonts-base X11-xauth X11-fonts \
X11-fonts-75dpi-ISO8859-2 X11-OpenGL-core X11-fonts-100dpi \
X11-fonts-ISO8859-2 X11-sessreg
W Th zmieniły si˛e nazwy pakietów i sa˛ o wiele bardziej rozdrobnione, zaczynamy
od instalacji rdzenia X-Serwera i podstawowych sterowników:
$ poldek -i xorg-xserver-server \
xorg-driver-input-keyboard \
xorg-driver-input-mouse
Teraz powinniśmy zainstalować sterownik karty graficznej, możemy zainstalować
wszystkie dost˛epne (jeśli nie mamy pewności) lub ten właściwy. W ustaleniu, który
sterownik b˛edzie najbardziej odpowiedni pomoże nam zestawienie w dokumentacji
X.Org2. Nazwy pakietów ze sterownikami zaczynaja˛ sie od X11-driver- (w Ac) i od
xorg-driver-video- (W Th). W przypadku kart firmy nVidia instalujemy otwarty
sterownik:
$ poldek -i xorg-driver-video-nv
Jeśli mamy kart˛e ATI to wybieramy pakiet:
$ poldek -i xorg-driver-video-ati
271
Sterownikami z pełna˛ obsługa˛ 3D b˛edziemy mogli si˛e zajać
˛ później. Jeśli ciagle
˛
nie
wiemy jaki wybrać, to możemy zainstalować uniwersalny sterownik dla kart zgodnych z VESA:
$ poldek -i xorg-driver-video-vesa
W Ac ten sterownik znajduje si˛e w pakiecie X11-modules
Zanim zaczniemy konfiguracje˛
Użytkownicy myszek PS/2 lub USB, którzy nie korzystaja˛ z dobrodziejstw udeva
musza˛ załadować oprócz modułu huba USB moduły:
# modprobe psmouse
# modprobe usbhid
Aby moduły ładowały si˛e za każdym razem, gdy uruchamiamy system, należy dodać ich nazwy do pliku /etc/modules. Wi˛ecej o zarzadzaniu
˛
modułami w sekcja
˛
modułami w Rozdział 11.
Pierwsze uruchomienie
X.Org nie wymaga pliku konfiguracji do podstawowego działania, po uruchomieniu
automatycznie próbuje wykryć dołaczony
˛
sprz˛et. X-Serwer uruchamiamy nast˛epujaco:
˛
# X
Jeśli naszym oczom ukaże si˛e drobna, szara kratka z kursorem myszy w kształcie
krzyżyka (którym możemy poruszać), to oznacza, że aplikacja działa: wykryła sprz˛et
i załadowała prawidłowe sterowniki. Oznacza to też, że zainstalowaliśmy wszystkie
potrzebne komponenty do działania serwera. Aby wyjść z tego dosyć surowego środowiska korzystamy ze skrótu Ctrl+Alt+Backspace
Teraz możemy przejść do konfiguracji X-Servera lub do uruchomienia środowiska
graficznego. Warto przeprowadzić przynajmniej podstawowa˛ konfiguracj˛e, by uzyskać wi˛eksza˛ ergonomi˛e pracy, ustawić układ klawiatury dla danego j˛ezyka, czy obsłużyć dodatkowe możliwości sprz˛etu.
Konfiguracja
Generujemy wst˛epna˛ konfiguracj˛e serwera X11:
# X -configure
W wyniku działania w/w polecenia w katalogu domowym użytkownika (w tym
wypadku /root/) powstanie plik xorg.conf.new. X-Server stara si˛e rozpoznać używany przez nas sprz˛et i ustawia właściwe parametry w pliku konfiguracji.
Przenosimy plik we właściwe miejsce:
# mv ~/xorg.conf.new /etc/X11/xorg.conf
Teraz możemy spróbować, czy serwer nam si˛e uruchamia:
# X
dokładnie jak to wcześniej opisaliśmy.
272
W ten oto sposób mamy wst˛epnie skonfigurowany X-Server i możemy rozpoczać
˛
prac˛e w środowisku graficznym. Wskazówki bardziej wyrafinowanej konfiguracji
odnajdziemy w sekcja Zaawansowane. Cz˛eść z nich b˛edziemy mogli dokonać za pomoca˛ poniżej opisanych programów (np. xorgcfg -textmode), bardziej zaawansowane opcje ustawimy wyłacznie
˛
edytujac
˛ plik konfiguracji.
Inne sposoby konfiguracji
Z aplikacja˛ dostarczane sa˛ dodatkowo dwa programy do konfiguracji, obydwie można użyć do generowania pliku konfiguracji zamiast operacji X -configure, pozwalaja˛
na precyzyjnie ustawianie parametrów X-Servera X -configure, jednak wymagaja˛ też
wi˛ecej wiedzy i pracy.
• xorgcfg - program który może działać w dwóch trybach: graficznym i tekstowym
(z użyciem parametru -textmode). Program ma ta˛ zalet˛e, że może modyfikować
istniejacy
˛ plik konfiguracji. O ile wygod˛e trybu graficznego można uznać za
dyskusyjna,˛ o tyle tryb tekstowy nie powinien sprawiać nikomu problemów.
- jest to konsolowe narz˛edzie, które prowadzi krok po kroku przez
kolejne etapy konfiguracji. W zasadzie to przydaje si˛e do generowania pliku konfiguracji po raz pierwszy (zamiast X -configure), jeśli chce si˛e dokonać jakiejkolwiek zmiany trzeba przechodzić przez wszystkie kroki na nowo. Program ten dodatkowo dodaje do pliku liczne komentarze, co nie wszystkim odpowiada.
• xorgconfig
Rozwiazywanie
˛
problemów
Jeżeli pojawi si˛e jakiś problem musimy przeanalizować komunikaty wypisywane na
ekran i do pliku /var/log/Xorg.0.log. Bł˛edy sa˛ oznaczane dwoma literkami EE
np.:
(EE) Failed to load module "ati" (module does not exist, 0)
Powyższy komunikat informuje o brakujacym
˛
sterowniku do karty graficznej, najprawdopodobniej nie jest zainstalowany konieczny pakiet.
Środowisko graficzne (GUI)
Do wyboru mamy dwa pot˛eżne, zintegrowane środowiska: KDE i Gnome, nieco
mniejsze XFCE4, czy całkiem proste np. : blackbox, fluxbox b˛edace
˛ jedynie zarzad˛
cami okien i pulpitu. środowiska opisaliśmy w dalszych rozdziałach. Oprócz środowiska musimy wybrać sposób jego uruchamiania. Możemy uruchamiać je z wiersza
poleceń za pomoca˛ skryptu startx lub demonów GDM/KDM. Zagadnienia te szczegółowo omówiliśmy w sekcja Uruchamianie środowiska graficznego.
Zaawansowane
W tym miejscu zajmiemy si˛e bardziej zaawansowana˛ konfiguracja˛ X-Servera. Zakładam, że istnieje wst˛epnie skonfigurowany plik /etc/X11/xorg.conf, za pomoca˛
polecenia X -configure. Wiele opisanych tu czynności konfiguracyjnych dla konkretnych podsystemów, wykonujemy za pomoca˛ programu xorgcfg, uruchamiamy go w
trybie tekstowym :
# xorgcfg -textmode
273
Po uruchomieniu zobaczymy list˛e dost˛epnych kategorii, odpowiadaja˛ one
dalszym opisom. Przykładowo, aby skonfigurować myszk˛e, wybieramy z listy
opcj˛e: Configure mouse a nast˛epnie Edit Mouse0 itd. Po ustawieniu wszystkich
interesujacych
˛
nas opcji, wybieramy Write xorg.conf and quit
Bardziej zaawansowane b˛eda˛ wymagały ingerencji za pomoca˛ edytora tekstu, przypominam, że "obrabiamy" plik # /etc/X11/xorg.conf.
Mysz
Zakładam, że w programie wybraliśmy sekcj˛e konfiguracji myszki. Dla
współczesnych myszek, w konfiguracji protokołu wybieramy Auto, dla myszek
szeregowych wybierzemy Microsoft. Nast˛epnie konfigurator spyta o to, czy dla
myszek dwuprzyciskowych właczyć
˛
emulacj˛e trzeciego klawisza, w przypadku
myszek o wi˛ekszej ilości przycisków odpowiadamy negatywnie. Jako urzadzenie
˛
wybieramy /dev/input/mice. Po zapisaniu wybranej konfiguracji, otrzymamy
w sekcji ustawień myszy w pliku /etc/X11/xorg.conf fragment o zbliżonej
konstrukcji:
Section "InputDevice"
Identifier "Mouse0"
Driver
"mouse"
Option
"Protocol" "Auto"
Option
"Device" "/dev/input/mice"
Option
"ZAxisMapping" "4 5 6 7"
EndSection
Jeśli posiadamy myszk˛e z wieloma klawiszami i rolkami, a standardowy sterownik
nie radzi sobie z obsługa˛ wszystkich zdarzeń, to możemy wybrać bardziej nowoczesny i elegancki sposób na uruchomienie naszego sprz˛etu - evdev. Przykładowa instalacja i konfiguracja zostanie przedstawiona dla popularnej myszki Logitech MX500.
Pierwszym krokiem jest załadowanie modułu jadra
˛
modprobe evdev oraz instalacja
pakietu xorg-driver-input-evdev (X11-driver-evdev dla Ac). Nast˛epnie odszukujemy w
/proc/bus/input/devices numer urzadzenia
˛
eventX naszej myszki i wpisujemy do
konfiga X.Org poniższa˛ sekcj˛e:
Identifier "Mouse1"
Driver
"evdev"
Option
"Device"
Option
"Buttons"
EndSection
"/dev/input/event1"
"10"
Klawiatura
Nowo wygenerowany plik konfiguracji nie zawiera opcji lokalnych, aby je ustawić, z
menu programu wybieramy Configure keyboard, Jako model (Keyboard model)
wybieramy np. Generic 104-key PC, a w Keyboard layout ustawiamy Poland.
Powyższa operacja wygeneruje nast˛epujac
˛ a˛ konfiguracj˛e klawiatury:
Identifier "Keyboard0"
Driver
"kbd"
Option
"XkbModel" "pc104"
Option
"XkbLayout" "pl"
EndSection
W przypadku starszych wersji X.Org (w Ac) X -configure ustawiany jest zły sterownik klawiatury, należy go zmienić na kbd, jak na powyższym fragmencie. Możemy
to wykonać za pomoca˛ dowolnego edytora tekstu.
274
Jeśli posiadamy klawiatur˛e multimedialna˛ i chcemy wykorzystywać jej dodatkowe
klawisze, to musimy wybrać odpowiedni model klawiatury. Nasz wybór b˛edzie dotyczył wartości parametru XkbModel, nast˛epnie musimy sprawdzić za pomoca˛ programu xev czy wszystkie zdarzenia z klawiszy multimedialnych sa˛ prawidłowo obsługiwane przez X-serwer.
Monitor
Właściciele monitorów LCD/Plasma sa˛ na uprzywilejowanej pozycji, jeśli sterownik karty graficznej potrafi "porozumieć si˛e" z monitorem (za pomoca˛ DDC), to nie
sa˛ wymagane żadne czynności konfiguracyjne. Aby detekcja nast˛epowała automatycznie musimy w pliku konfiguracji postawić znak komentarza ("#") przed opcjami
HorizSync, VertRefresh.
W pozostałych przypadkach musimy określić parametry monitora. Wybierajac
˛ opcje
programu Configure monitor, b˛edziemy b˛edziemy mogli wybrać jakiś monitor z listy lub podać parametru własnego urzadzenia:
˛
Enter your own horizontal sync
range. Tu podajemy wartości HorizSync (w kHz) i VertRefresh w (Hz) zgodne ze
specyfikacja˛ naszego urzadzenia.
˛
Po zapisaniu pliku konfiguracji otrzymamy:
Section "Monitor"
Identifier "Monitor0"
HorizSync
31.5 - 96.0
VertRefresh 50 - 100
Option "DPMS"
EndSection
O ile HorizSync jest opcja˛ ściśle zależna˛ od możliwości monitora i pod żadnym pozorem nie powinniśmy jej dowolnie zmieniać, o tyle VertRefresh daje wi˛ecej swobody.
Za jej pomoca˛ ustawiamy odświeżanie obrazu, Nie możemy oczywiście przekroczyć
parametrów monitora, ale możemy ustawić minimalne odświeżanie, np. 85 - 85
wymusi cz˛estotliwość 85Hz. (oczywiście pod warunkiem, że nasz monitor, przy danej rozdzielczości pozwala na wyświetlanie z taka˛ wartościa).
˛
Rozdzielczość obrazu
Wst˛epnie plik konfiguracji nie zawiera żadnych definicji rozdzielczości i b˛edzie ona
ustalana automatycznie, co jest wskazane przy monitorach LCD/Plasma. W przypadku monitorów CRT, zapewne b˛edziemy chcieli użyć najbardziej ergonomicznej.
Mamy tu dwa wyjścia, możemy nic nie ustawiać w X.Org, ale za to ustawić ja˛ w aplikacjach konfiguracyjnych środowisk Gnome/KDE, lub ustawić ja˛ na stałe w konfiguracji X-serwera. Możliwości ustawień konfiguratorów w środowiskach graficznych
sa˛ dosyć skromne, dlatego niektórzy pokusza˛ si˛e zapewne o ustawienie odpowiednich wartości na stałe.
Po wybraniu Configure screen w programie, zostaniemy zapytani o ilość dost˛epnych kolorów, dla współczesnego sprz˛etu bez zastanowienia możemy wybrać 24bity
na piksel a nast˛epnie wybieramy list˛e rozdzielczości, które maja˛ być dost˛epne. W
wi˛ekszości wypadków wystarczy nam jedna rozdzielczość. Oczywiście musi być obsługiwana przez monitor. Zapisana konfiguracja może wygladać
˛
nast˛epujaco:
˛
Section "Screen"
Identifier "Screen0"
Device
"Card0"
Monitor
"Monitor0"
SubSection "Display"
Viewport
0 0
Depth
24
Modes "1024x768"
EndSubSection
275
EndSection
Zaawansowane - DPI
X.Org pozwala na wskazanie DPI (dots per inch), w celu lepszego dopasowania wielkości wyświetlanych czcionek ekranowych. W przypadku współczesnych monitorów, za pomoca˛ DDC odczytywany jest rozmiar obszaru wyświetlania, by automatycznie określić DPI. Dla monitorów, które nie posiadaja˛ takiej możliwości lub podaja˛
ja˛ nieprawidłowo, b˛edziemy mogli sami ten parametr ustawić. Wartość DPI można
też ustawić bezpośrednio w konfiguracji środowiska (np. w Gnome) my jednak pokażemy jak zrobić do w X-serwerze. W sekcji Monitor pliku konfiguracji należy dodać
opcj˛e:
DisplaySize $x $y
gdzie parametry $x i $y sa˛ wymiarami w milimetrach, odczytanymi z dokumentacji
urzadzenia
˛
lub po prostu zmierzonymi linijka.˛ Sekcja konfiguracji monitora może
wygladać
˛
nast˛epujaco:
˛
Section "Monitor"
Identifier "Monitor0"
HorizSync
31.5 - 96.0
VertRefresh 50 - 100
DisplaySize 269 201
EndSection
Zaawansowane - serwer czionek
Zaczynamy od instalacji serwera XFS(Th): xorg-app-xfs, w przypadku Ac jest to pakiet X11-xfs. Dla wygody założymy także, że b˛edziemy korzystać z serwera czcionek X11-xfs, który uruchamiamy poleceniem /etc/init.d/xfs start. Dlatego też
sekcja dotyczaca
˛ czcionek w pliku xorg.conf.new powinna wygladać
˛
podobnie do
podanego niżej przykładu:
Section "Files"
RgbPath
"/usr/X11R6/lib/X11/rgb"
#
FontPath
"/usr/X11R6/lib/X11/fonts/local/"
#
FontPath
"/usr/X11R6/lib/X11/fonts/misc/"
#
FontPath
"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
#
FontPath
"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
#
FontPath
"/usr/X11R6/lib/X11/fonts/Type1/"
#
FontPath
"/usr/X11R6/lib/X11/fonts/Speedo/"
#
FontPath
"/usr/X11R6/lib/X11/fonts/75dpi/"
#
FontPath
"/usr/X11R6/lib/X11/fonts/100dpi/"
FontPath
"unix/:7100"
#
ModulePath "/usr/X11R6/lib/modules"
EndSection
Czyli komentujemy wszystkie wywołania bezpośrednie do czcionek i przekazujemy
obsług˛e zarzadzania
˛
czcionkami serwerowi xfs.
Uwagi
Parametry monitora moga˛ być odczytywane za pomoca˛ modułu DDC, o ile monitor
jest właczony.
˛
Powinniśmy zatem właczać
˛
monitor przed uruchomieniem X-Servera
lub ustawić "na sztywno" jego parametry, inaczej w skrajnym wypadku obraz b˛edzie
miał rozdzielczość 640x480, przy odświeżaniu 60Hz.
276
Środowisko GNOME
Instalacja
GNOME jest rozbudowanym środowiskiem, dodatkowo filozofia mikropakietów w
PLD nie ułatwia jego instalacji poczatkuj
˛
acym.
˛
Aby temu zaradzić stworzone zostały
metapakiety, które oszcz˛edza˛ nam sporej ilości pracy, oto ich zestawienie:
•
metapackage-gnome - główna cz˛eść środowiska
•
metapackage-gnome-extras - dodatki
•
metapackage-gnome-extras-accessibility - narz˛edzie ułatwień dost˛epu
•
metapackage-gnome-office - pakiet aplikacji biurowych
Na poczatku
˛
powinien nam wystarczyć podstawowy metapakiet:
poldek> install metapackage-gnome
Teraz wystarczy uzbroić si˛e w cierpliwość, po instalacji wymagań metapakietu, możemy już samodzielnie doinstalować te kilka pakietów, albo od razu uruchomić środowisko. Filozofi˛e metapakietów omówiliśmy w sekcja Cechy pakietów w PLD w Rozdział 9.
Jeśli jednak jesteśmy zwolennikami instalacji tylko tego co jest potrzebne, musimy
instalować każdy pakiet z osobna:
poldek> install gnome-desktop gnome-session nautilus xscreensaver-gnome2 gnome-themes \
gnome-icon-theme gnome-panel gnome-splash-gnome metacity \
gnome-applets
Lista komponentów i aplikacji dla GNOME jest w PLD imponujaca,
˛ aby łatwiej było
si˛e odnaleźć w tym gaszczu,
˛
zach˛ecamy do zapoznania si˛e z zestawieniem aplikacji
w dalszej cz˛eści rozdziału.
Internacjonalizacja
Aby GNOME i GDM obsługiwały j˛ezyk inny niż angielski, należy ustawić tzw. Locale, co zostało opisane w sekcja Internacjonalizacja w Rozdział 12, a nast˛epnie wybrać
preferowany j˛ezyk: Language z menu GDM-a.
Dźwiek
˛
Zakładam, że już została skonfigurowana już ALSA, zgodnie ze wskazówkami opisanymi w sekcja ALSA - Dźwi˛ek w Linuksie w Rozdział 17. Od GNOME 2.26 dźwi˛ek
jest obsługiwany przez aplikacj˛e pulseaudio, zapewniajac
˛ a˛ programowe miksowanie dźwi˛eku z wielu źródeł, czy też przesyłanie strumienia za pośrednictwem sieci.
Instalujemy:
$ poldek -i pulseaudio pulseaudio-gconf pulseaudio-alsa gstreamer gstreamer-audiosink-e
instalujemy pakiety z pluginami dekodujacymi
˛
formaty wav,au oraz mp3:
$ poldek -i
gstreamer-audio-formats gstreamer-mad
instalujemy gnome-media, aplet do sterowania głośnościa,˛ odtwarzacz Totem i
opcjonalnie pakiet dźwi˛eków zdarzeń:
$ poldek -i gnome-media gnome-applets-mixer totem gnome-audio
277
Uruchomienie
Zanim uruchomimy środowisko, musimy si˛e upewnić, czy nazwa hosta (opcja
HOSTNAME z pliku /etc/sysconfig/network) jest przypisana do adresu IP. Aby
to ustawić, należy dodać odpowiedni wpis do pliku /etc/hosts, zgodnie ze
wskazówkami zawartymi w sekcja Podstawowa konfiguracja sieci w Rozdział 15, np.:
127.0.0.1
pldmachine
Szczegóły uruchamiania środowiska opisaliśmy w sekcja Uruchamianie środowiska
graficznego.
Administracja - GNOME System Tools
GST to zestaw wygodnych narz˛edzi administracyjnych, obsługujacych
˛
PolicyKit. Pozwala na zarzadzanie
˛
m.in. usługami, użytkownikami oraz siecia.˛ Instalacja:
$ poldek -i gnome-system-tools system-tools-backends
Uruchamiamy demona system-tools-backends:
# /etc/init.d/system-tools-backends start
Dodajemy użytkownika do grupy adm:
# groupmod -A jkowalski adm
Aplikacje administracyjne b˛edziemy mogli używać po ponownym zalogowaniu.
Przydatne drobiazgi
O wygodzie pracy w środowisku czasami decyduja˛ drobiazgi, oto lista takich niewielkich narz˛edzi, przydatnych w codziennej pracy:
•
gnome-volume-manager - narz˛edzie do zarzadzania
˛
woluminami wymiennymi:
montowaniem nośnikow, odtwarzaniem muzyki i innymi
•
gnome-utils-screenshot - program do szybkiego wykonywania zrzutów ekranu.
•
nautilus-cd-burner - rozszerzenie do nautilusa służace
˛ do nagrywania płyt
CD/DVD
•
gnome-system-monitor - monitor zasobów i procesów
•
gnome-utils-search-tool - wyszukiwarka plików
Oprócz tego mamy dost˛ep do wielu appletów, tematów graficznych i innych.
Godne polecenia aplikacje
Zaleta˛ złożonych środowisk takich jak GNOME czy KDE jest duża liczba programów, które dobrze integruja˛ si˛e ze środowiskiem, poniżej została zamieszczona lista
użytecznych programów.
278
•
gnome-terminal - rozbudowany emulator terminala z obsługa˛ zakładek
•
gcalctool - wielofunkcyjny kalkulator
•
totem - odtwarzacz audio i video.
•
Exaile, Quod Libet i Rhythmbox - wygodne odtwarzacze audio z dobra˛ obsługa˛
dużych bibliotek muzyki, wszystkie obsługuja˛ gstreamera.
•
eog - Eye of GNOME - narz˛edzie do przegladania
˛
obrazków
•
evince - program służacy
˛
do przegladania
˛
dokumentów w formatach pdf,
postscript i wielu innych.
•
gedit2 - edytor tekstu z obsługa˛ kolorowania składni j˛ezyków programowania i
wtyczek.
•
epiphany - przegladarka
˛
WWW z silnikiem renderujacym
˛
Gecko
•
evolution - rozbudowany klient poczty i narz˛edzie do planowania zadań
•
gajim - klient Jabbera
•
file-roller - zarzadca
˛
archiwów - jest graficznym interfejsem dla własciwych
narz˛edzi archiwizacji danych
•
Brasero (dawniej Bonfire) - komfortowe narz˛edzie do nagrywania płyt CD/DVD.
Wi˛ecej na stronie www.gnome.org/projects/3, warto też odwiedzić stron˛e
www.gnomefiles.org4, b˛edacej
˛ bogatym zestawieniem aplikacji bardziej lub mniej
zwiazanych
˛
ze środowiskiem.
Pomoc i rozwiazywanie
˛
problemów
GNOME jest dostarczane z pokaźna˛ dokumentacja˛ - niestety brak jest polskiego tłumaczenia. Jest dost˛epna dla aktywnego okna po wciśni˛eciu przycisku F1 lub po wywołaniu programu yelp - przegladarki
˛
dokumentacji. Musimy tylko doinstalować
konieczne pakiety:
$ poldek -i gnome-user-docs yelp
Jeśli natkniemy si˛e na jakieś problemy z działaniem aplikacji, na poczatek
˛
powinniśmy zajrzeć do specjalnego dziennika bł˛edów:
$ cat ~/.xsession-errors
Możemy też spróbować uruchomić dana˛ aplikacj˛e w wirtualnym terminalu (np. w
programie gnome-terminal), w celu odczytania komunikatów programu.
Środowisko KDE
Poniżej przedstawiamy list˛e zalecanych pakietów dla KDE:
kdeaddons-ark kdeadmin-kpackage kdebase-desktop kdebase-kate \
kdebase-konsole kdebase-kwrite kdegraphics-kfile \
kdegraphics-kghostview kdegraphics-kpdf kdemultimedia-akode \
kdemultimedia-juk kdemultimedia-kaboodle kdemultimedia-kfile \
kdemultimedia-kmid kdemultimedia-kmix kdemultimedia-kscd \
kdemultimedia-mpeglib kdenetwork-kget kdesdk-kfile \
kdeutils-ark kdeutils-kcalc kdeutils-kedit kdeutils-kfloppy \
kdeutils-kwalletmanager konqueror
Aby móc uruchomić KDE dla danego użytkownika, w jego katalogu domowym wykonujemy polecenie:
$ echo "kde" >.desktop
279
Od tej chwili, domyślnym środowiskiem graficznym dla tego użytkownika jest KDE,
które możemy uruchomić za pomoca˛ polecenia startx.
Blackbox - Szybki i lekki zarzadca
˛
okien
Wstep
˛
Blackbox jest lekkim menedżerem okien dla XFree86. Jest napisany w C++, a jego
projekt zakładał wydajność, niskie użycie pami˛eci oraz brak zależności od zewn˛etrznych bibliotek. Blackbox zabiera bardzo niewiele miejsca na ekranie na dekoracje
okien. Mimo swojego minimalizmu, jest bardzo wygodny i funkcjonalny. Zawiera
wszystko, czego oczekuje si˛e od menedżera okien - obsług˛e wirtualnych pulpitów,
okna typu sticky, zwijanie okien, okna pozbawione dekoracji. Posiada też pasek dokowania, zwany slitem, na którym moga˛ umieszczać si˛e aplety w stylu NEXTstep
(np. Window Maker, AfterStep) oraz okna w trybie withdrawn (np. gkrellm). Te cechy sprawiły, że Blackbox stał si˛e całkiem popularny wśród osób nie lubiacych
˛
przeładowania towarzyszacego
˛
środowiskom KDE i GNOME
Dzi˛eki swoim zaletom Blackbox stał si˛e na tyle znany, że wypaczkowało
˛
z niego kilka
odmian z nowymi cechami. Należa˛ do nich Fluxbox, Openbox i Kahakai. Blackbox i
jego pochodne sa˛ doskonałym wyborem, jeśli pożadane
˛
jest oszcz˛edzanie pami˛eci i
niskie wykorzystanie procesora. Sa˛ też dobre dla tych, którzy wola˛ elegancj˛e ponad
nadmiar elementów, jaki wyst˛epuje w popularnych środowiskach. My w tym opisie
zajmiemy si˛e instalacja˛ Blackbox.
Czas zainstalować potrzebne nam pakiety.
# poldek -i blackbox vfmg xinitrc
Instalacja zajmuje bardzo mało czasu, ponieważ jak już wspomniane zostało wcześniej Blackbox jest bardzo mało wymagajacy
˛ jeżeli chodzi o zasoby.
Konfiguracja
Teraz aby Blackbox był naszym domyślnym menadżerem okien należy ustawić go w
pliku /etc/sysconfig/desktop
# cat /etc/sysconfig/desktop
# PREFERRED can be GNOME, KDE or empty
# when left empty $DEFAULTWM will be started
PREFERRED=blackbox
DEFAULTWM=
# Default window manager to use. Should be basename of file from
# /etc/sysconfig/wmstyle/
WMSTYLE=
W tym momencie mamy już skonfigurowanego Blackbox i w zasadzie można by go
już uruchomić ale my skonfigurujemy sobie menu, aby było zgodne z zainstalowanymi przez nas programami
W tym celu z pomoca˛ przyjdzie nam program vfmg, który już wcześniej zainstalowaliśmy. Komendy które sa˛ poniżej należy wykonywać w katalogu domowym ~/
# mkdir ~/.blackbox
# vfmg blackbox > .blackbox/menu
280
Mamy już gotowe menu, ale nie ma w nim opcji "Wyjście", która jest niewatpliwie
˛
przydatna˛ opcja.˛
W ~/.blackbox/menu należy pod sam koniec dopisać "Wyjście" tak, aby 3 ostatnie
linijki wygladały
˛
nast˛epujaco:
˛
# tail -3 ~/.blackbox/menu
[end]
[exit] (Wyjście)
[end]
Dodatkowo należy edytować plik ~/.blackboxrc i zmienić w nim linijk˛e
session.menuFile na:
# grep menu .blackboxrc
session.menuFile:
.blackbox/menu
Majac
˛ już menu Blackbox możemy go wreszcie uruchomić:
# startx
Aby wszystko poprawnie funkcjonowało należy zapoznać si˛e z działem "Konfiguracja środowiska graficznego", który znajduje si˛e w dokumentacji PLD.
Fluxbox - Nastepca
˛
BlackBoxa
Wstep
˛
Młodszym bratem BlackBoxa jest Fluxbox, bazujacy
˛ na kodzie Blackboxa. Fluxbox
wyglada
˛ tak samo jak Blackbox, który korzysta z tych samych styli, kolorów, położenia okien i generalnie jest zachowana pełna kompatybilność z Blackboxem.
Jakie sa˛ wi˛ec różnice? Odpowiedź brzmi: DUŻE. Np:
•
Konfigurowalne taby okien
•
Pasek ikon (do zminimalizowanych okien)
•
Scroll myszki używany do zmiany obszarów roboczych.
•
Wsparcie dla KDE i GNOME, a także rozszerzone wsparcie dla WindowMakera.
•
i jeszcze wiele innych udogodnień.
Czas zainstalować potrzebne nam pakiety.
# poldek -i fluxbox fluxconf
Właściwie do pracy potrzebny nam jest tylko fluxbox, ale fluxconf troch˛e ułatwia
konfiguracje.
Konfiguracja
Aby fluxbox był naszym domyślnym menadżerem okien w .Xclients dajemy wpis.
exec fluxbox
281
wyglad
˛ menu można zmieniać edytujac
˛ plik ~/.fluxbox/menu
Przykładowy wpis:
[begin] (Fluxbox)
[exec]
(aterm) {aterm -tr}
[exec] (Run) {fbrun }
[submenu] (Net)
[exec] (PSI) {psi}
[end]
[end]
Możemy także automatycznie wygenerować menu korzystajac
˛ z programu vfmg.
Instalujemy go poleceniem:
# poldek -i vfmg
Nast˛epnie wydajemy polecenia:
# mkdir ~/.fluxbox
# vfmg blackbox > ~/.fluxbox/menu
Mamy już gotowe menu, ale nie ma w nim opcji "Wyjście", która jest niewatpliwie
˛
przydatna˛ opcja.˛
W ~/.fluxbox/menu należy pod sam koniec dopisać "Wyjście" tak, aby 3 ostatnie
linijki wygladały
˛
nast˛epujaco:
˛
# tail -3 ~/.blackbox/menu
[end]
[exit] (Wyjście)
[end]
Chcac
˛ dodać tło pulpitu możemy si˛e posłużyć np. programem dispalay z pakietu
ImageMagik. Instalujemy go:
# poldek -i ImageMagick
dodatkowo konieczne jest doinstalowanie modułów kodera dla plików np. jpeg, png
i tiff
# poldek -i ImageMagick-coder-jpeg-5.5.7.12-2 ImageMagick-coder-png-5.5.7.12-2 ImageMag
nast˛epnie w pliki ~/.fluxbox/init odszukujemy wpis:
session.screen0.rootCommand: i dodajemy: display -size ROZDZIELCOZŚĆ -window root NAZWA
u mnie wpis ten wyglada
˛ nast˛epujaco:
˛
session.screen0.rootCommand:
display -size 1024x768 \
-window root ~/DREAMVISIONS.jpg
I to by było właściwie już tyle, można już uruchomić naszego menagera okien poleceniem
# startx
Uruchamianie środowiska graficznego
Istnieja˛ dwie metody uruchamiania środowiska, pierwsza˛ jest uruchamianie systemu
na trzecim poziomie pracy (domyślnie) i autoryzowaniu si˛e w terminalu tekstowym.
282
Po zalogowaniu uruchamiamy program startx. Druga˛ możliwościa˛ jest instalacja jednego ze specjalnych demonów: gdm (dla Gnome) kdm (dla KDE) lub xdm i dokonywanie autoryzacji za ich pośrednictwem. Demony te działaja˛ na piatym
˛
poziomie
pracy, dlatego musimy skonfigurować system by domyślnie startował na tym poziomie. Estetyka i wygoda to nie jedyne zalety demonów, sa˛ one silnie zintegrowane ze
swoimi środowiskami, dzi˛eki czemu zapewniaja˛ wiele dodatkowych funkcji.
Skrypt startx
W tej metodzie po zalogowaniu si˛e w terminalu, użytkownik wydaje polecenie
startx. Na podstawie wpisu w pliku .xinitrc (w katalogu użytkownika)
uruchamiane jest wskazane tam środowisko. Aby używać tej metody, musimy
doinstalować potrzebne pakiety, w przypadku Ac wykonujemy polecenie:
$ poldek -i xinitrc-ng
W Th:
$ poldek -i xinitrc-ng xorg-app-xinit
Konfiguracja polega na umieszczeniu nazwy programu startowego środowiska w
pliku .xinitrc. Plik ten jest pełnoprawnym skryptem powłoki i obowiazuje
˛
w nim
jej składnia, wpis w nim można wykonać nast˛epujaco:
˛
$ echo "gnome-session" >~/.xinitrc
lub
$ echo "exec gnome-session" >~/.xinitrc
Aby uruchomić środowisko wykonujemy polecenie:
$ startx
Poniżej przedstawilimy list˛e programów startowych dla wybranych środowisk:
•
Gnome: gnome-session
•
KDE: startkde
•
XFCE: startxfce4
•
fluxbox: fluxbox
•
icewm: icewm
Jedynie w wyjatkowych
˛
sytuacjach powinniśmy używać tej metody do uruchamiania środowisk takich Gnome czy KDE, dla nich najlepiej korzytstać z opisanych poniżej GDM lub KDM.
GDM
Zaczynamy od instalacji demona GDM:
poldek> install gdm gdm-init
i już możemy go uruchomić:
# service gdm start
283
Powinniśmy móc si˛e teraz zalogować i uruchomić środowisko, jeśli wszystko działa prawidłowo to możemy ustawić by system uruchamiał si˛e ma piatem
˛
poziomie
pracy, zgodnie ze wskazówkami pod koniec rozdziału.
KDM
Instalujemy KDM
# poldek -i kdm
Dla lokalnej pracy nie trzeba nic specjalnie konfigurować, wi˛ec od razu możemy uruchomić demona poleceniem:
# /etc/init.d/kdm start
Pozostało nam jeszcze poinformować nasz system, że chcemy, aby nasz zarzadca
˛
uruchamiał si˛e po starcie systemu (na piatym
˛
poziomie).
Ustawienie poziomu pracy
W przypadku demonów GDM/KDM powinniśmy jeszcze skonfigurować system
tak, by domyślnie uruchamiał si˛e na piatym
˛
poziomie. pracy. Owe usługi uruchamiaja˛ si˛e tylko na tym poziomie, poza tym jest to domyślny poziom dla aplikacji
X-Window. Powinniśmy zmodyfikować plik /etc/inittab, zgodnie ze wskazówkami przedstawionymi w sekcja Zmiana poziomu pracy systemu w Rozdział 14. Wiersz
z opcja˛ initdefault powinien wygladać
˛
nast˛epujaco:
˛
id:5:initdefault:
Aby sprawdzić poprawność operacji, możemy zrestartować system.
Porady
Należy za wszelka˛ cen˛e unikać logowania si˛e jako administrator (root), jeśli chcemy
używać aplikacji wymagajacych
˛
wysokich uprawnień, powinniśmy je uruchamiać
za pomoca˛ programu sudo.
Karty firmy nVidia
Do zainstalowania kart graficznych firmy NVIDIA zalecamy wykorzystać firmowe
sterowniki nvidia. Z serwerem X11 dostarczany jest sterownik nv jednak w stosunku do firmowych sterowników jest zdecydowanie wolniejszy, chociaż w przypadku
wykorzystania rivafb jesteśmy zmuszeni do użycia otwartych sterowników nv.
Aby wczytać sterowniki firmowe, należy za pomoca˛ programu poldek zainstalować
pakiety:
# X11-driver-nvidia kernel-video-nvidia
Nast˛epnie w wygenerowanym pliku konfiguracyjnym serwera X11 dokonujemy
zmian w sekcji Device Card0:
Identifier
Driver
VendorName
BoardName
BusID
284
"Card0"
"nvidia"
"nVidia Corporation"
"NV5M64 [RIVA TNT2 Model 64/Model 64 Pro]"
"PCI:1:0:0"
Option
Option
Option
Option
Option
"HWCursor"
"CursorShadow"
"DPMS"
"noDCC"
"NoLogo"
"on"
"on"
"on"
"on"
"on"
Czyli praktycznie zamieniamy ciag
˛ znaków w linijce Driver z nv na nvidia.
Teraz wracamy do serwera X11 i jego testowego uruchomienia. W przypadku problemów standardowo zagladamy
˛
w logi.
Karty firmy ATI
Do zainstalowania kart graficznych firmy ATI zalecamy wykorzystać firmowe sterowniki firegl. Z serwerem X11 dostarczane sa˛ także otwarte sterowniki X11-driverati - jednak nie wykorzystuja˛ one wszystkich możliwości jakie daja˛ sterowniki firegl i
dopiero przy dużych problemach z nimi możemy jako awaryjne skonfigurować serwer X11 z otwartymi sterownikami ATI.
Instalacja i konfiguracja
Aby wczytać firegl, należy za pomoca˛ programu poldek zainstalować pakiety:
# X11-driver-firegl kernel-video-firegl
Nast˛epnie za pomoca˛ programu fglrxconfig generujemy plik konfiguracyjny dla serwera X11. Oprócz pytań zwiazanych
˛
z serwerem odpowiemy na szereg pytań dotyczacych
˛
karty graficznej i monitora (możemy np. zdecydować o tym czy chcemy
pracować w systemie jedno-monitorowym, czy też z monitorem i odbiornikiem TV).
Wygenerowany plik, tak jak przedstawiono to w rozdziale dotyczacym
˛
instalacji X11
należy z katalogu domowego użytkownika root do katalogu /etc/X11/ i dokonać
ewentualnych korekt dotyczacych
˛
myszy i obsługi czcionek
Aby karta graficzna została poprawnie zainicjowana musimy wczytać odpowiednie
moduły kernela. Na poczatku
˛
musi to być moduł, który umożliwi nam prace karty z
AGP - moduł ten jest zależny od posiadanej płyty głównej. Przykładowo dla płyt z
chipsetem nforce2 jest to moduł:
# modprobe nvidia-agp
Nast˛epnie wczytujemy moduł kernela obsługujacy
˛ karty ATI:
# modprobe fglrx
Aby zmiany były trwałe, dopiszmy oba moduły do pliku /etc/modules i wykonajmy polecenie depmod -a
Na koniec musimy si˛e upewnić, że mamy zamontowany pseudo-system plików shm
używany do obsługi dzielonej pami˛eci POSIX. Wymagany wpis w /etc/fstab wyglada
˛ nast˛epujaco:
˛
none
/dev/shm
tmpfs
defaults
0 0
Test konfiguracji
Teraz możemy wrócić do konfigurowania serwera X11 i jego testowego uruchomienia. Kiedy uruchomimy X-Window możemy sprawdzić poprawność konfiguracji pomoca˛ programów glxinfo oraz glxgears uruchamianych z emulatora terminala (np.
285
xterm-a). Pierwszy z nich wyświetla dokładne informacje o naszej karcie i sterowniku, zaś drugi to program do testowania wydajności. Dobrze skonfigurowana karta
graficzna pozwala osiagn
˛ ać
˛ wydajność kilku tysi˛ecy klatek na sekund˛e. W przypadku problemów standardowo zagladamy
˛
w logi.
Przypisy
1. http://www.x.org/wiki/
2. http://xorg.freedesktop.org/wiki/Projects/Drivers?action=show
3. http://www.gnome.org/projects/
4. http://www.gnomefiles.org
286
Rozdział 19. Możliwa droga do zostania szeregowym
developerem PLD
Co jest potrzebne
Każdego użytkownika Linuxa pracujacego
˛
na swojej maszynie nachodziła refleksja
na tematy filozoficzne - kto to wymyślił? kto to zrobił? i jak to zrobił? Pytania ciekawe
- Prezentujac
˛ sposób pracy przy PLD możemy cz˛eściowo zrozumieć mechanizmy
tworzenia takich projektów.
Naszym miejscem pracy b˛edzie samo PLD i dodatki, które poniżej spróbuje opisać.
W chwili pisania tego tekstu była to wersja 1.0 ”Ra”. Później jest już z górki - instalujemy par˛e pakietów - sam proces instalacji w praktycznie zostanie pomini˛ety, gdyż
użytkownicy już powinni wiedzieć co to jest poldek i jak si˛e go używa.
# rpm -qa |grep rpm
rpm-4.0.2-106
rpm-build-tools-4.0.2-106
rpm-utils-4.0.2-106
rpm-perlprov-4.0.2-106
rpm-build-4.0.2-106
rpm-devel-4.0.2-106
rpm-pythonprov-4.0.2-106
# rpm -qa |grep cvs
cvs-1.11.5-2
# rpm -qa |grep mc
mc-4.5.55-10
Zwróc˛e uwag˛e tylko na CVS. Sposób instalacji środowiska1 bardzo dobrze opisuje
Baseciq2 - ten krok należy wykonać ze szczególna˛ starannościa˛
Innym ważnym pakietem jest rpm plus dodatki. Głównym zaj˛eciem szeregowego
developera jest tworzenie lub modyfikacja plików .spec, które sa˛ głównym czynnikiem budowania pakietów RPM. Sa˛ jeszcze potrzebne różne inne pakiety i źródła ale to już w zależności od tego co b˛edziemy budować.
Źródła wiedzy
Najwi˛eksza˛ skarbnica˛ wiedzy o RPMie i budowaniu pakietów możemy znaleźć w
publikacji Maximum RPM3 - opis jest w j˛ezyku angielskim i nie jest mi znane tłumaczenie na nasz j˛ezyk. Na szcz˛eście sa˛ jeszcze inne źródełka, a także i niniejszy opis
- wi˛ec powinno nam być lżej przyswajać wiedz˛e. Szczególnie polecam stron˛e Grzegorza Niew˛egłowskiego4 (lub lokalna˛ kopi˛e)5 gdzie dużo teorii i praktycznych rad
może nam rozjaśnić w naszych głowach czym jest praca ze "specami".
Jest dost˛epny także opis stworzony przez Developera PLD6 lecz z tego co si˛e dowiedziałem jest już troch˛e leciwy i niektóre dane moga˛ być nieścisłe.
Po tej bombie teorii jaka˛ niestety musimy przejść, czeka nas przestudiowanie jeszcze
jednego dokumentu, którego najnowsza˛ wersj˛e możemy ściagn
˛ ać
˛ z CVS PLD. B˛edzie
to nasze pierwsze ćwiczenie.
Uruchamiamy terminal (czy to zwykły, czy też np. przez SSH) i wykonujemy kroki:
$ cd rpm
$ cvs get PLD-doc/devel-hints-pl.txt
U PLD-doc/devel-hints-pl.txt
$
287
Rozdział 19. Możliwa droga do zostania szeregowym developerem PLD
Jak widać kroki wykonujemy jako zwykły użytkownik (nie root) i tej zasady b˛edziemy si˛e konsekwentnie trzymali.
Do katalogu ~/rpm/PLD-doc/ ściagneliśmy
˛
z repozytorium PLD dokument tekstowy devel-hints-pl.txt7. W tym dokumencie zawarte sa˛ zalecenia i ustalenia jakich
powinniśmy si˛e trzymać aby tworzyć właściwe dla PLD pakiety RPM.
Przykład budowania
Teraz spróbujemy ściagn
˛ ać
˛ jakiś .spec z CVS PLD i zbudujemy sobie jakaś
˛ paczk˛e np. pakiet tar (przykład budowania ’ekg’ mogliśmy obejrzeć także podczas instalacji
CVS na stronie Baseciq8):
$ cd rpm
$ cvs get SPECS/tar.spec
U SPECS/tar.spec
$ cd SPECS/
$ rpmbuild -ba tar.spec
bład:
˛
File /home/users/marekc/rpm/SOURCES/tar-1.13.25.tar.gz: \
Nie ma takiego pliku ani katalogu
$ ./getsrc tar.spec
Trying to download sources for tar-1.13.25-7
Searching for file: tar-1.13.25.tar.gz
Trying CVS... OK
Searching for file: tar-non-english-man-pages.tar.bz2
Trying CVS... OK
Searching for file: tar-man_from_debian_tar_1.13.25-2.patch
Trying CVS... OK
Searching for file: tar-info.patch
Trying CVS... OK
Searching for file: tar-pipe.patch
Trying CVS... OK
Searching for file: tar-namecache.patch
Trying CVS... OK
Searching for file: tar-error.patch
Trying CVS... OK
Searching for file: tar-sock.patch
Trying CVS... OK
Searching for file: tar-nolibrt.patch
Trying CVS... OK
Searching for file: tar-man.patch
Trying CVS... OK
Searching for file: tar-ac25x.patch
Trying CVS... OK
Searching for file: tar-dots.patch
Trying CVS... OK
Searching for file: tar-pl.po-fix.patch
Trying CVS... OK
Download opreation completed: all files retrieved successfully
W przykładzie, za szybko chcieliśmy zbudować pakiet - zaraz po ściagni˛
˛ eciu
”tar.spec”.
Sam .spec bez źródeł jest jak karabin bez amunicji... Można wykorzystać skrypt ’builder’ (i później nawet zalecam go używać) w katalogu SPECS, który to sam przeanalizuje potrzeby i ściagnie
˛
odpowiedniego .speca (oczywiście jeżeli tylko zawiera go
repozytorium CVS), źródła i wykona paczki rpm i srpms - ale my nie b˛edziemy tutaj
sobie za bardzo ułatwiać pracy :-)
Po ściagni˛
˛ eciu plików dobrze jest obejrzeć danego .speca aby zobaczyć, co jest jeszcze potrzebne do zbudowania - można to zrobić zwykłym edytorem tekstowym lub
wykonać:
$ cat tar.spec |grep BuildReq
288
BuildRequires:
BuildRequires:
BuildRequires:
BuildRequires:
autoconf
automake
bison
gettext-devel
Wiemy już co nam jest potrzebne - Teraz sprawdzimy czy mamy te pakiety w naszym
PLD:
$ rpm -q autoconf
autoconf-2.53a-1
$ rpm -q automake
automake-1.6.3-1
$ rpm -q bison
pakiet bison nie jest zainstalowany
$ rpm -q gettext-devel
pakiet gettext-devel nie jest zainstalowany
$
Czyli dwóch, potrzebnych pakietów brak. A wi˛ec ’poldek’ rusza do boju (tutaj już
lepiej użyć konta ’root’ - chyba że mamy poldka skonfigurowanego do pracy ’sudo’):
# poldek
Wczytywanie
Wczytywanie
Wczytywanie
Wczytywanie
Wczytywanie
Wczytywanie
Przeczytano
ftp://ftp.pld-linux.org/dists/[...]/RPMS/packages.dir.gz...
ftp://ftp.pld-linux.org/dists/ra/[...]/packages.dir.gz...
ftp://ftp.pld-linux.org/dists/ra/[...]/packages.dir.gz...
ftp://ep09.kernel.pl/pub/People/[...]/packages.dir.gz...
ftp://ftp.pld-linux.org/dists/[...]/packages.dir.gz...
http://pld.mysza.eu.org/Ra/i686/packages.dir.gz...
6814 pakietów
Usuni˛
eto 16 zdublowanych pakietów z listy dost˛
epnych
Wczytywanie /root/.poldek-cache/packages.dir.dbcache.var.lib.rpm.gz...
Przeczytano 559 pakietów
Witaj w poldekowym trybie interaktywnym. Wpisz "help" aby otrzymać pomoc.
poldek> install bison gettext-devel
Zaznaczono 1 pakiet do instalacji:
I bison-1.35-5
Pobieranie ftp://ftp.pld-linux.org/dists/[...]/bison-1.35-5.i686.rpm...
.................................................. 100.0% [196.5K]
Uruchamianie rpm --upgrade -vh --root / --noorder...
Preparing... ########################################### [100%]
1:bison ########################################### [100%]
Installing set #2
Zaznaczono 1 pakiet do instalacji:
I gettext-devel-0.10.40-4
Pobieranie ftp://[...]/gettext-devel-0.10.40-4.i686.rpm...
.................................................. 100.0% [295.6K]
Uruchamianie rpm --upgrade -vh --root / --noorder...
Preparing... ########################################### [100%]
1:gettext-devel ########################################### [100%]
poldek>
I jak tu nie kochać Poldka? :-)
Mamy już teoretycznie wszystko aby zbudować pakiet ’tar’. Wracamy wi˛ec do naszego zwykłego konta i:
$ rpmbuild -ba tar.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.22007
Patch #0 (tar-man_from_debian_tar_1.13.25-2.patch):
Patch #1 (tar-info.patch):
Patch #2 (tar-pipe.patch):
289
Patch #3 (tar-namecache.patch):
Patch #4 (tar-error.patch):
Patch #5 (tar-sock.patch):
Patch #6 (tar-nolibrt.patch):
Patch #7 (tar-man.patch):
Patch #8 (tar-ac25x.patch):
Patch #9 (tar-dots.patch):
Patch #10 (tar-pl.po-fix.patch):
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.97619
[...]
Zapisano: /home/users/marekc/rpm/SRPMS/tar-1.13.25-7.src.rpm
Zapisano: /home/users/marekc/rpm/RPMS/tar-1.13.25-7.i686.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.54009
+ umask 022
+ cd /home/users/marekc/rpm/BUILD
+ _autoreqprov=n
+ [ n = y ]
+ cd tar-1.13.25
+ rm -rf /home/users/marekc/tmp/tar-1.13.25-root-marekc
+ exit 0
$
[...] oznacza, wyci˛ete przeze mnie komunikaty jakie generuje kompilowany ’tar’.
Polecenie ’rpmbuild -ba ’ każe nam zbudować ze speca kompletny pakiet - ale to już
wiemy z teoretycznych szkoleń ;-)
Wszelkie komunikaty w razie jakiegoś bł˛edu podczas budowania możemy odnaleźć
w pliku: ’/var/tmp/rpm-tmp.22007’
Widzimy, że gotowe pakiety mamy w określonych katalogach i możemy je spokojnie
zainstalować. A komunikat ’exit 0’ oznacza brak bł˛edów podczas budowania.
Nasz pierwszy pakiet został zbudowany.
Pozostaje jednak niedosyt - ciagle
˛ czujemy, że jak na razie korzystamy z czyjeś pracy,
a w końcu pragniemy także coś zrobić dla potomności i sami chcemy stworzyć plik
.spec
Pierwszy spec
No to zaczynamy. Naszym pierwszym (a właściwie moim) wykonanym specem b˛edzie Mantis9 czyli system kontroli bł˛edów oparty o stron˛e WWW (PHP) i baz˛e SQL
Mysql.
Tutaj mała dygresja - wi˛ekszość pakietów powstaje dlatego, że danemu Developerowi był on akurat potrzebny; oznacza to że nie ma sensu pisanie na list˛e dyskusyjna˛
z prośba˛ o stworzenie określonego pakietu bo można otrzymać par˛e przykrych komentarzy (w najlepszym razie).
Pierwsza˛ czynnościa˛ jest zainstalowanie pakietu ze źródeł. Potem notujemy sobie co
należy zrobić aby dany pakiet zaczał
˛ działać - wszystko po to aby przewidzieć co dany .spec powinien zrobić aby pakiet pracował w miar˛e bezproblemowo po instalacji
RPMa - Można to zanotować np. na kartce papieru - ale od czego mamy komputery?
Moje notatki wygladały
˛
tak:
// MANTIS
// Mysql init
# cd /etc/rc.d/init.d
# ./mysql init
# /usr/bin/mysqladmin -u mysql password ’password’
290
// Tworzenie bazy w mysql
# mysqladmin -umysql -p create bugtracker
# cd /mantis/sql
# mysql -umysql -p bugtracker < db_generate.sql
// Plik config_inc.php
// Sprawdzenie i poprawka
http:/mantis/admin/check.php
// Pierwsze logowanie
u: administrator
p: root
Dodać nowe i skasować stare :-)
// co potrzebne do uruchomienia
- mysql
- mysql-client
- php
- php-common
- php-pcre
- php-mysql
- apache
// do rpma (zmiany w zwiazku
˛
z j˛
ezykiem)
plik: config_defaults_inc.php
$g_default_language = ’english’;
$g_default_language = ’polish’;
// Zamiana łańcucha w config_defaults_inc.php
sed -e s/$g_default_language = ’english’;/$g_default_language = ’polish’;/g
config_defaults_inc.php
// Zamiana usera z root na mysql
w config_inc.php
Do każdego pakietu należy podchodzić indywidualnie - dlatego par˛e słów o samym
mantisie. System jest oparty o gotowe pliki składajace
˛ si˛e na stron˛e WWW, dokumentacje i plik potrzebny do stworzenia odpowiedniej bazy Mysql. Nie b˛edziemy
dokonywali żadnych kompilacji - wi˛ec uprości to nasz proces budowania i testowania pakietu.
Łacz
˛ ac
˛ informacje zawarte w dostarczonej dokumentacji i własnych notatek wiemy
już że głównym zadaniem naszego RPMa b˛edzie takie zaprojektowanie go, aby odpowiednie pliki PHP zostały przekopiowane w odpowiednie miejsce, dokonać niezb˛ednych poprawek w plikach konfiguracyjnych lub innych poprawek, które naszym zdaniem moga˛ ułatwić prac˛e przyszłym użytkownikom. Pami˛etajmy jednak
żeby nie przedobrzyć.
Niestety nie wszystko uda nam si˛e zautomatyzować - dlatego stworzymy dwa pliki tekstowe (w dwóch wersjach j˛ezykowych PL i EN) z krótkim opisem, co należy
wykonać aby system zadziałał.
Wydaje mi si˛e także, że dobrym zwyczajem jest po zainstalowaniu źródeł przewidzieć właściwe zależności, aby nasz pakiet działał bez problemu na innym komputerze. Na przykład w instrukcji do instalacji mantisa w wymaganiach jest wymieniony
m.in. pakiet PHP - W PLD po instalacji samego PHP, mantis b˛edzie wyświetlał bł˛edy.
Okazuje si˛e że pakiety w PLD sa˛ maksymalnie ”rozdrobnione” i do działania potrzebny jest jeszcze pakiet ’php-pcre’ - a do tego, żeby strony PHP odpowiednio komunikowały si˛e z baza˛ ’mysql’ jest potrzeba zainstalowania ’php-mysql’. Zależności
może być wiele i moim skromnym zdaniem lepiej żebyśmy umieścili jakiś nadmiarowy pakiet w zależnościach niż żeby jakiegoś brakowało.
W naszym przypadku po zainstalowaniu i uruchomieniu pakietu Mantis ze źródeł,
wystarczy wykonać np. ’rpm -qa |grep php’ aby wybrać odpowiednie pliki. To samo
robimy z ’mysql’ i ’apache’.
291
Zaczynamy od stworzenia pliku (możemy użyć polecenia ’touch’) lub korzystamy
z innego pliku .spec w celu modyfikacji do naszych potrzeb (np. ’cvs get
SPECS/template.spec’ spowoduje ściagni˛
˛ ecie szkieletu z CVS PLD). Otwieramy go
w naszym ulubionym edytorze tekstowym (vim, emacs, pico, mcedit itp.)
Summary: The Mantis Bug Tracker
Summary(pl): Mantis - System Kontroli Bł˛
edów
Name: mantis
Version: 0.18.0a4
# define _alpha a4
Release: 1
License: GPL
Group: Development/Tools
[...]
Zaczynamy wypełniać tzw. preambuł˛e, czyli wst˛ep w którym opisujemy nasz pakiet
- myśl˛e, że wyjaśnianie powyższego nie jest specjalnie potrzebne. Zwróc˛e tylko uwag˛e na lini˛e ’Version’ i ’Ralease’ - zgodnie z devel-hints-pl.txt10 powinno ono raczej
wygladać
˛
tak (ponieważ ta wersja mantis’a jest określona jako alpha):
Version: 0.18.0 %define alpha a4 Release: 0.%{_alpha}.1
ale u mnie powodowało to bład
˛ przy budowaniu, gdyż jak dalej zobaczymy nazwa
źródeł korzysta z pola ’Version’ i każda manipulacja na nim powoduje potrzeb˛e przebudowania .speca lub zmian˛e nazwy archiwum w którym sa˛ źródła (co jest bardzo
złym nawykiem i karygodnym bł˛edem!). Tak wi˛ec w końcu zostawiłem tak jak jest i
nikt specjalnie nie zwrócił mi na to uwagi :-) (przyp. autora: jednak późniejsza praktyka pokaże nam, że zmiany takie sa˛ jednak chlebem powszednim wi˛ec nie bójmy
si˛e ich dokonywać)
[...]
Source0: http://dl.sourceforge.net/mantisbt/%{name}-%{version}.tar.gz
# Source0-md5: 4c730c1ecf7a2449ef915387d85c1952
Source1: %{name}-doc-PLD.tar.gz
URL: http://mantisbt.sourceforge.net/
[...]
Dalej mamy opis źródełek - w PLD podaje si˛e go najcz˛eściej w formie
linku plus fraza %{name}-%{version}.tar.gz i tak naprawd˛e ta fraza jest
najważniejsza do zbudowania pakietu, ponieważ URL (w naszym przypadku
http://dl.sourceforge.net/mantisbt/) jest ignorowany. Tak wi˛ec z makra %name
i %version budowana jest nazwa pakietu i taka nazwa jest wyszukiwana w
~/rpm/SOURCES/
Źródeł programu może być kilka. U nas wyst˛epuje jeszcze Source111 - jest to dodatkowa dokumentacja składajaca
˛ si˛e z dwóch plików tekstowych zawierajaca
˛ dodatkowe
wskazówki po instalacyjne. Pierwotnie próbowałem zrobić to korzystajac
˛ z mechanizmu Patch i polecenia:
diff -urN katalog_z_oryginałem
źródła-powód.patch
katalog_z_poprawionym_oryginałem
>
opisanego w devel-manual12 (rozdział 1.2.2), ale mechanizm ten nie pozwala tworzyć
nowych plików wi˛ec pozostało tylko wykonać dodatkowe źródła.
Pami˛etajmy także aby w żadnym przypadku nie modyfikować r˛ecznie źródeł
programu. Prawidłowy .spec powinien wykorzystywać natywne źródła, a wszelkie
zmiany dokonujemy w %build, %install lub za pomoca˛ patch’ów.
Sygnatura md5 po # jest wynikiem wykorzystania tzw. distfiles i na razie to musi
nam wystarczyć. Distfiles omówimy gdy b˛edziemy zapisywać do CVS PLD - czyli
niepr˛edko ;-)
292
[...]
Requires: apache >= 1.3.27-4
Requires: apache-mod_dir >= 1.3.27-4
Requires: php >= 4.0.3
Requires: php-mysql >= 4.0.3
Requires: php-pcre >= 4.3.1-4
Requires: php-common >= 4.3.1-4
Requires: mysql >= 3.23.2
Requires: mysql-client >= 3.23.56-1
Requires: sed
BuildArch: noarch
BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
[...]
W ’Requires’ podajemy zależności, czyli co musi być zainstalowane aby dany pakiet
działał lub żeby wykonały si˛e poprawnie polecenia wykonywane przez .spec (np.
sekcja %post)
W ’BuildArch’ architektur˛e pod który przeznaczony jest RPM - u nas jest to ’noarch’
czyli bez żadnej konkretnej architektury - z moich obserwacji wynika że developerzy
PLD omijaja˛ to pole - chyba że jest to właśnie ’noarch’.
’BuildRoot’ jest bardzo ważnym tagiem - na szcz˛eście wyst˛epuje zawsze w takiej
postaci jak u nas - a oznacza katalog w którym rpm b˛edzie budował pakiet z sekcji
%install naszego .speca.
[...]
%define _mantisdir /home/services/httpd/mantis
# define _mantisdir /home/httpd/html/mantis
%description
Mantis is a web-based bugtracking system.
%description -l pl
Mantis jest systemem kontroli bł˛
edów opartym na interfejsie \
WWW i MySQL.
[...]
W tej cz˛eści wykorzystujemy przydatna˛ właściwość RPMa czyli definiowanie stałych. W naszym przykładzie ’_mantisdir’ jest katalogiem w którym b˛eda˛ zainstalowane pliki dla serwera WEB. Tutaj mała uwaga dotyczaca
˛ komentarza ’#’ - Gdy definiujemy makro wtedy komentarz nie działa, dlatego usun˛eliśmy ’%’ przed słowem
’define’ (możemy także użyć frazy ’%%’) czyli gdybyśmy napisali:
%define _mantisdir /home/services/httpd/mantis
# %define _mantisdir /home/httpd/html/mantis
To wtedy stała ’_mantisdir’ miała by wartość /home/httpd/html/mantis, mimo że
nie taka jest nasz intencja - Nie musz˛e chyba wyjaśniać jakie to może spowodować
problemy?
W ’%description’ opisujemy krótko charakterystyk˛e pakietu, a niżej widzimy jak to
zrobić dla opisu w j˛ezyku polskim - później RPM wykorzystujac
˛ zmienne locale wyświetla odpowiednia˛ wersj˛e j˛ezykowa˛ ’description’ gdy sobie tego od RPMa życzymy.
[...]
%prep
%setup -q -a1
[...]
293
Od tego momentu skończyliśmy wypełniać dane preambuły. Sekcja %prep może wykonać skrypt potrzebny przed instalacja˛ plików. My akurat nic przed instalacja˛ robić
nie musimy dlatego sekcja ta jest pusta.
Dalej jest ’%setup -q -a1’ - czyli rozpakowanie źródeł do katalogu zdefiniowanego
wcześniej przez ’BuildRoot’. Dodatkowe parametry tego tagu wyłaczaj
˛
a˛ komunikaty przy rozpakowaniu ’-q’, a parametr ’-a1’ określa które źródła należy rozpakować.
Po ’%setup’ możemy także korzystać z makra ’%patch’ który nakłada łatki na źródła. Umożliwia to taka˛ modyfikacj˛e źródeł jakie tylko chcemy bez potrzeby zmian w
samych źródłach (o czym pisaliśmy wcześniej).
[...]
%install
rm -rf $RPM_BUILD_ROOT
install -d $RPM_BUILD_ROOT%{_mantisdir}
cp -af *.php admin core css graphs images lang sql \
$RPM_BUILD_ROOT%{_mantisdir}
sed -e ’s/root/mysql/g’ config_inc.php.sample > \
$RPM_BUILD_ROOT%{_mantisdir}/config_inc.php
[...]
Tak naprawd˛e w wi˛ekszości pakietów przed ’%install’ wykonywane jest makro
’%build’, które kompiluje nam źródła, a w najprostszej postaci wyglada
˛ tak:
%build %configure make
U nas nie ma potrzeby wykonywania żadnych kompilacji wi˛ec od razu wykonywana
jest sekcja ’%install’. Na poczatku
˛
czyścimy sobie katalog w którym b˛edziemy instalowali nasz program (czyli ’fake root’) - mimo że prawdopodobnie jest pusty - ale
lepiej dmuchać na zimne. Potem dokonujemy instalacji pakietu przekazujac
˛ mu w
parametrze ’-d’ że docelowo ma być zainstalowany w ’fake root’, ale same pliki pojawia˛ si˛e w naszym katalogu tymczasowym (TMPDIR), dlatego później za pomoca˛
polecenia ’cp’ kopiujemy pliki, jakie sa˛ potrzebne, do właściwego ’fake root’ - zauważmy że pomin˛eliśmy np. katalog ’doc’.
Nast˛epnie jeszcze za pomoca˛ komendy ’SED’ dokonujemy drobnej poprawki w pliku
konfiguracyjnym mantisa - zamieniajac
˛ domyślnego użytkownika MYSQL z ’root’
na ’mysql’. Taka˛ poprawk˛e mogliśmy wykonać wcześniej w sekcji ’%prep’ i tagu
’%patch’ ale przy tak małych poprawkach bardziej efektywniej jest to zrobić tutaj.
[...]
%clean
rm -rf $RPM_BUILD_ROOT
[...]
Tag ’%clean’ jest w .specach tworzonych dla PLD obowiazkowy
˛
i określa co należy
zrobić gdy cały pakiet zostanie zbudowany. Tutaj mała uwaga - ten tag w tym miejscu nie oznacza że jest w tej chwili wykonany - jeżeli by tak było, to wyst˛epujacy
˛
później tag ’%files’ miałby niejakie problemy z nieistniejacymi
˛
już plikami. Czyli po
poprawnym zbudowaniu pakietu, wykonywane jest makro ’%clean’, a w przypadku
jakiegokolwiek bł˛edu, nie jest - czyli rozpakowane i zainstalowane źródła pozostaja.˛
Umożliwia nam to np. diagnostyk˛e w przypadku bł˛edów podczas budowania pakietu.
[...]
%post
if [ "$LANG" = "pl_PL" ]; then
#sed -e "s/= ’english’;/= ’polish’;/g" \
294
%{_mantisdir}/config_defaults_inc.php > \
#%{_mantisdir}/config_defaults_inc_PLD.php
#mv -f %{_mantisdir}/config_defaults_inc_PLD.php \
%{_mantisdir}/config_defaults_inc.php
echo
echo "Mantis zapisany..."
echo "Wi˛
ecej: /usr/share/doc/mantis-%{version}/PLD_Install_PL.txt.gz"
echo
else
echo
echo "Mantis loaded..."
echo "More: /usr/share/doc/mantis-%{version}/PLD_Install_EN.txt.gz"
echo
fi
[...]
Tutaj mamy przykład co możemy zrobić z plikami, które b˛eda˛ instalowane po zbudowaniu pakietu. Makro ’%post’ wykonywane jest przez RPM podczas instalacji
pakietu. Zakomentowane polecenia umożliwiaja˛ zmian˛e w zainstalowanym pliku
’config_defaults_inc.php’ zgodnie z zawartościa˛ zmiennej locale ’LANG’. Później w
zależności od tej zmiennej wyświetlany jest komunikat w j˛ezyku PL lub EN.
Zadacie pytanie dlaczego cz˛eść tych poleceń jest ”wyłaczona"
˛
- otóż, później gdy
dany .spec chcemy już udost˛epnić ogółowi zostanie on sprawdzony pod wzgl˛edem
”czystości rasowej” :-) - W tym przypadku okazało si˛e, że taka zmiana w plikach konfiguracyjnych, może spowodować kłopoty podczas np. zmiany użytkownika. Programy korzystajace
˛ z ’locale’ powinny odpowiednio reagować na zmiany ’locale’ np. po modyfikacji LANG na ’EN_en’ zaczać
˛ pracować po angielsku - W naszym
przypadku strona PHP nie zacznie pracować po angielsku, dlatego dodany został
w/w komentarz, a w pliku ’PLD_Install_PL.txt.gz’, który jest dodatkowa˛ instrukcja,˛
co należy zrobić po instalacji pakietu RPM aby ’mantis’ po uruchomieniu rozmawiał
z nami po polsku.
[...]
%files
%defattr(644,root,root,755)
%doc doc/* PLD_Install_PL.txt PLD_Install_EN.txt config_inc.php.sample
%dir %{_mantisdir}
%{_mantisdir}/admin/
%{_mantisdir}/core/
%{_mantisdir}/css/
%{_mantisdir}/graphs/
%{_mantisdir}/images/
%{_mantisdir}/lang/
%{_mantisdir}/sql/
%{_mantisdir}/account*
%{_mantisdir}/bug*
%{_mantisdir}/core.*
%{_mantisdir}/csv*
%{_mantisdir}/docum*
%{_mantisdir}/file*
%{_mantisdir}/history*
%{_mantisdir}/index*
%{_mantisdir}/jump*
%{_mantisdir}/log*
%{_mantisdir}/ma*
%{_mantisdir}/me*
%{_mantisdir}/news*
%{_mantisdir}/print*
%{_mantisdir}/proj*
%{_mantisdir}/set*
%{_mantisdir}/sig*
%{_mantisdir}/sum*
295
%{_mantisdir}/view*
%config(noreplace) %{_mantisdir}/config_inc.php
%config(noreplace) %{_mantisdir}/config_defaults_inc.php
%exclude %{_mantisdir}/core/.cvsignore
[...]
Dochodzimy powoli do finału :-). W sekcji tej określamy co, gdzie i jak ma zostać
zainstalowane u użytkownika instalujacego
˛
naszego RPMa. Tag %files jest bardzo
ważny gdyż bł˛edy spowodowane tutaj moga˛ uniemożliwić działanie pakietu u końcowego użytkownika. W ’podtagu’:
%defattr(644,root,root,755)
określamy domyślne atrybuty instalowanych plików - możemy oczywiście określać
atrybuty dla każdego pliku osobno.
Nast˛epnie w:
%doc doc/* PLD_Install_PL.txt PLD_Install_EN.txt config_inc.php.sample
określamy nasze pliki, które znajda˛ si˛e w dokumentacji. Czyli katalog ’doc/’ z katalogu ’TMPDIR’ i pliki z ’SOURCE1’ oraz ’config_inc.php.sample’ zostana˛ spakowane
i przy instalacji pakietu RPM umieszczone w domyślnym katalogu dokumentacji w PLD jest to /usr/share/doc/...
I wreszcie w:
%dir %{_mantisdir}
nakazujemy podczas instalacji RPM’a stworzenie katalogu zgodnie ze stała˛ ’%{_mantisdir}’ i kopiujemy pliki jakie sa˛ poniżej tego tagu. Na poczatku
˛
nie wypisywałem
wszystkich tych katalogów i plików indywidualnie, a po prostu użyłem frazy:
%{_mantisdir}
Jednak przy takiej konstrukcji i wykorzystaniu makra %config(noreplace), pojawi si˛e
bład
˛ podczas budowania pakietu:
[...]
RPM build errors:
File listed twice: /home/services/httpd/mantis/config_defaults_inc.php
File listed twice: /home/services/httpd/mantis/config_inc.php
Czyli dwa pliki miały podwójne znaczenie - wyst˛epowały na liście do skopiowania i jako pliki konfiguracyjne. Dlatego trzeba niestety zrobić list˛e plików jak to my
zrobiliśmy minus pliki, które znajda˛ si˛e w makro ’%config’. Samo makro ’%config’
pozwala szczególnie traktować pliki konfiguracyjnie podczas kasowania RPMa lub
jego aktualizacji.
Ostatnie makro:
’%exclude %{_mantisdir}/core/.cvsignore’
nakazuje wyłaczenie
˛
pliku z pakietu RPM - w tym przypadku jest to pozostałość po
CVS mantisa.
I to już koniec naszej pracy. Po wykonaniu polecenia ’rpmbuild -ba mantis.spec’ powinien nam zbudować si˛e pakiet rpm i srpm. Zostaje jeszcze przetestowanie czy
wszystkie pliki sa˛ tam gdzie chcieliśmy, czy maja˛ odpowiednie prawa i czy pakiet
działa tak jak powinien. Jeszcze ewentualne poprawki i musimy przepuścić nasza˛
prac˛e przez zestaw adaptujacy
˛ ’adapter.awk’.
Ściagamy
˛
go z CVSu:
$ cvs get SPECS/adapter.awk
U SPECS/adapter.awk
296
$
nast˛epnie zmieniamy nazw˛e pliku .speca dodajac
˛ na końcu np. org i wykonujemy:
$ ./adapter.awk mantis.spec.org > mantis.spec
$
W wyniku tej operacji otrzymamy ’mantis.spec’ który zostaje przystosowany do wymagań PLD. Zainteresowanych zmianami, zapraszam do przestudiowania ’nowego’
.speca.
Teraz możemy szukać kogoś, kto umieści naszego .speca i źródła w repozytorium
CVS PLD. Mamy do dyspozycji list˛e developerów: w mailu umieszczajac
˛ załacznik
˛
z naszym .specem (oczywiście bez źródeł - lub jeżeli mamy jakieś własne źródła to
umieszczamy je na jakieś stronie WWW lub innym ftp. i podajemy linka - źródła
natywne powinny dać si˛e ściagn
˛ ać
˛ z lokacji jaka˛ umieściliśmy w naszym .specu.).
Załacznik
˛
powinien być typu plain-text.
Można także spróbować na grupie IRC #PLD znaleźć ofiar˛e, która umieści nasza˛ prac˛e w repozytorium.
Dobrze też w czasie nauki robienia .speców podgladać
˛
jak to robia˛ inni - W repozytorium CVS jest naprawd˛e z czego wybierać. A my nabywajac
˛ umiej˛etność czytania
plików .spec możemy skupić si˛e już tylko na odpowiednim ich napisaniu.
W końcu otrzymamy możliwość zapisu do CVS i wtedy czytamy nast˛epna˛ cz˛eść
poradnika ”W krainie CVS”
Przypisy
1. http://developer-doc.pld-linux.org/baseciq/slack2pld.html
2. http://www.baseciq.org/
3. http://developer-doc.pld-linux.org/maximum%20rpm/index.htm
4. http://lubuska.zapto.org/~hoppke/too_much_to_learn/rpm/index.html
5. http://developer-doc.pld-linux.org/hoppke/too_much_to_learn/rpm/index.htm
6. http://developer-doc.pld-linux.org/develmanual/develmanual-packages.html
7. http://developer-doc.pld-linux.org/develhints/developer_hints.htm
8. http://developer-doc.pld-linux.org/baseciq/slack2pld.html
9. http://mantisbt.sourceforge.net/
10. http://developer-doc.pld-linux.org/develhints/developer_hints.htm
11. http://developer-doc.pld-linux.org/source1.htm
12. http://developer-doc.pld-linux.org/develmanual/develmanual-packages.html
297
298
Rozdział 20. W krainie CVS - czyli wielki kocioł
Wstep
˛
Umiemy już w miar˛e klecić nowe spece, naprawiać stare - chcemy dołaczyć
˛
do drużyny PLD... Musimy mieć wi˛ec możliwość pogrania na boisku, a nie tylko zasiadać
na trybunach jako widz. Naszym boiskiem b˛edzie CVS a możliwość czytania i pisania do niego (Read-Write) naszym sposobem na gr˛e :)
Jak to życiu, aby coś dostać musimy najpierw si˛e postarać i wykonać par˛e czynności.
Żeby otrzymać własne konto CVS należy uzyskać poparcie już aktywnych deweloperów. Zwykle osoby wykazujace
˛ si˛e aktywnościa˛ na listach dyskusyjnych (podsyłajace
˛
patche, itp.) pr˛edzej czy później sa˛ wr˛ecz proszone o zgłoszenie si˛e po konto. W typowym przypadku wystarczy, że trzech deweloperów wyrazi poparcie kandydata na
dewelopera (trzeci z nich powinien wskazać mu dokad
˛ powinien si˛e zgłosić po konto). Osoba popierajaca
˛ kandydata jednocześnie staje si˛e jego opiekunem i nadzoruje
jego działania w poczatkowej
˛
fazie. W przypadku gdyby, mimo poparcia przez niektórych, osoba kandydata wywoływała kontrowersje, decyzja o jego przyj˛eciu (lub
nie) b˛edzie podj˛eta zgodnie z obowiazuj
˛ ac
˛ a˛ procedura˛ rozwiazywania
˛
konfliktów.
Kiedy już zostaniemy przyj˛eci, musimy wymyśleć sobie ksywk˛e i hasło. Potem z
linii poleceń wykonujemy jednolinijkowe polecenie - wstawiajac
˛ za login i haslo odpowiednie dane:
perl -e ’print "login:" . crypt("haslo", join "", (".", "/", 0..9, "A".."Z", "a".."z")[rand 64,
rand 64]) . "\n"’
w wyniku którego otrzymamy ciag
˛ znaków podobny do:
login:/APGG.cfeqPpk
Ciag
˛ ten kopiujemy do listu e-mail z prośba˛ o możliwość RW na CVS PLD i wysyłamy na adres [email protected]
To na razie wszystko co możemy zrobić - trzeba czekać na odpowiedź od władzy
CVS. Po kilku, kilkunastu lub kilkudziesi˛eciu dniach przyjdzie mail z odpowiedzia.˛
U mnie była to wiadomość podobna do:
Quoting Marek Ciesielski <[email protected]>:
> Prosze o dostep RW do CVS PLD.
> dane do <login>:/APGG.cfeqPpk // oczywiście tej linii
// w mailu nie ma - dodałem ja˛ dla przykładu :)
Witam,
twoje konto zostało założone, prosz˛
e dopisz si˛
e do CVSROOT/users
-Admin CVS <imi˛
e i nazwisko> :)
Czyli pierwsze formalności mamy za soba.˛ Możemy już działać na CVS. Jednak proponuj˛e znowu troch˛e teorii - tym razem zdecydowana wi˛ekszość dokumentacji jest
w j˛ezyku angielskim. Mamy wi˛ec bardzo dobry, oficjalny podr˛ecznik CVS2 (uwaga
ponad 800KB), ksia˛żk˛e kucharska˛ CVS3 (uwaga ponad 600KB) - jest także opis po
polsku4 - stworzony przez developerów PLD, a także ksia˛żka z cyklu leksykon kieszonkowy "CVS" Gregor N. Purdy (koszt ok. 10PLN) - tak wi˛ec jest w czym wybierać.
Jeszcze raz zwróćmy uwag˛e na maila którego otrzymaliśmy. Jest tam coś o dopisaniu
"users". Musimy wykonać zalecenie. Aby to zrobić musimy znowu przygotować sobie środowisko CVS - albo modyfikujac
˛ istniejace,
˛ dotychczasowe konto "anonymous" albo tworzac
˛ od poczatku
˛
środowsko w nowym katalogu. Ja wybrałem pierwszy
sposób (troch˛e wbrew zaleceniom z dokumentacji - ale za to szybszy), polega on na
modyfikacji każdego pliku "Root" w podkatalogach "CVS" - należy tam wpisać fraz˛e:
299
:pserver:<nasz_login>@cvs.pld-linux.org:/cvsroot
Czyli w naszym przypadku wchodzimy do katalogu ./rpm i wchodzimy do każdego podkatalogu "CVS" i zmieniamy r˛ecznie plik "Root" - nie ma w tej chwili tych
katalogów wiele, wi˛ec nie powinno to sprawić kłopotu.
Proponuj˛e także poustawiać sobie zmienne CVS np. CVSEDITOR itp. (szczegóły oczywiście dokumentacja).
Nast˛epnie możemy już spróbować zalogować si˛e do CVS PLD:
$ cvs login
Logging in to :pserver:<nasz_login>@cvs.pld-linux.org:2401/cvsroot
CVS password:
$
Wpisujemy hasło które wymyśleliśmy i jesteśmy zalogowani. Każdy komunikat bł˛edu oznacza że coś wcześniej źle wykonaliśmy, albo że np. nie działa sieć. Login wykonujemy praktycznie raz i dopóki nie wykonamy polecenia "cvs logout" jesteśmy
ciagle
˛ gotowi do pracy.
Czas już zabrać si˛e za plik "users"
$ cvs get CVSROOT/users
U CVSROOT/users
$
Do naszego lokalnego repozytorium, do katalogu CVSROOT ściagneliśmy
˛
plik users,
który służy w PLD do wpisania aliasu pocztowego - przy okazji możemy zobaczyć
w jakim towarzystwie przyjdzie nam pracować :)
nasz_login:użytkownik_mail@domena_naszego_email:Imi˛e
Nazwisko:[email protected]
i
Ostatnie pole jest opcjonalne - wypełniamy je tylko jeśli posiadamy swój własny JID
(o ile go posiadamy). Jeśli z różnych przyczyn nie korzystamy z Jabbera - omijamy
t˛e cz˛eść i zatrzymujemy si˛e na imieniu i nazwisku. Dla zainteresowanych - istnieje
oficjalny serwer Jabbera projektu PLD Linux - konta na nim zakłada Mariusz Mazur.
Edytujemy odpowiednio wi˛ec plik users (pami˛etajmy, żeby zachować alfabetyczna˛
kolejność wpisów) - wystarczy tylko drobna znajomość alfabetu i robimy nasz pierwszy commit - czyli potwierdzamy zmiany.
$ cvs ci CVSROOT/users // po tym poleceniu edytujemy log
Checking in CVSROOT/users;
/cvsroot/CVSROOT/users,v <-- users
new revision: 1.40; previous revision: 1.39
done
cvs server: Rebuilding administrative file database
Mailing the commit message
$
Po wydaniu polecenia cvs ci CVSROOT/users otworzy si˛e nasz ulubiony edytor i
pojawi si˛e coś podobnego do:
- added nasz_login // tu wpisujemy komentarz z kreseczka˛ i po angielsku!!!
CVS: --------------------------------------------------------------------CVS: Enter Log. Lines beginning with ‘CVS:‘ are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Updated Files:
CVS: CVSROOT/users
CVS: ---------------------------------------------------------------------
Właśnie dokonaliśmy pierwszej zmiany w repozytorium PLD. Od tej chwili każdy
mail adresowany na <nasz_login>@pld-linux.org trafi na nasza˛ skrzynk˛e pocztowa.˛
300
Dalsza cz˛eść naszych rozważań b˛edzie już w formie konkretnych przykładów, ponieważ to co chcemy zrobić w repozytorium CVS PLD zależy od konkretnych potrzeb.
Od tej chwili nikt już nas za raczk˛
˛ e nie b˛edzie prowadził, a czekaja˛ nas pot, krew,
łzy i pierwsze "recenzje" naszych poczynań - np. na grupie PLD-devel czy kanale
#PLD - a jedynymi nagrodami b˛edzie brak tych recenzji, zdobyta wiedza, satysfakcja
i działajace
˛ paczki, których przez chwil˛e nikt na świecie nie b˛edzie miał :)
Dodawanie plików do CVS PLD
Każdy nowy plik, który chcemy umieścić w repozytorium należy dodać za pomoca˛
polecenia "cvs add"
$ cvs add nasz_nowy_pakiet.spec
cvs server: scheduling file ‘nasz_nowy_pakiet.spec’ for addition
cvs server: use ’cvs commit’ to add this file permanently
$
Jak widać z komentarza, aby zakończyć dodanie pliku należy zatwierdzić zmian˛e za
pomoca˛ polecenia "cvs ci" (polecenia podaj˛e w formie skróconej) - Samo zatwierdzanie (commit) robiliśmy już wcześniej przy okazji pliku "users".
Aktualizacja plików
Pliki możemy zaktualizować wzgl˛edem CVS - jeżeli nasz plik jest nowszy nie zostanie dokonana żadna zmiana na naszym lokalnym repozytorium. Aktualizacja˛ nie
dokonujemy zmian na zdalnym repozytorium.
Jeżeli w danym katalogu mamy już zdefiniowana˛ kartotek˛e (czyli mamy już odpowiedni podkatalog CVS) to aktualizacja˛ możemy ściagn
˛ ać
˛ nowy plik.
$ cvs up python.spec
P python.spec
$
W powyższym przykładzie dokonaliśmy aktualizacji pliku "python.spec". Literka
"P" określa stan aktualizacji. Poniżej przedstawi˛e możlwe kody:
•
"A" - Plik dodany. Oznacza że na pliku dokonano operacji "ADD" (czyli dodanie
do repozytorium) ale nie wykonano commitu (zatwierdzenia)
•
"C" - Plik aktualizowany jest w konflikcie ze zdalnym repozytorium. Czyli np.
dokonaliśmy zmian na lokalnym repozytorium i nasz plik jest "nowszy" wzgl˛edem
zdalnego repozytorium.
•
"M" - Plik został zmodyfikowany w zdalnym repozytorium ale nie było żadnych
konfliktów.
•
"P" - Plik był "łatany" przez serwer (kod podobny do "U")
•
"R" - Plik usuni˛ety ale nie zatwierdzony. Czyli dokonano operacji "cvs remove" ale
nie zatwierdzono zmian (poleceniem "cvs ci")
•
"U" - Plik został zaktualizowany
•
"?" - Plik jest w naszym repozytorium lokalnym ale nie ma go w zdalnym repozytorium CVS
301
Zatwierdzanie zmian i Distfiles
Sam przykład zatwierdzania zmian mogliśmy poznać wcześniej. Jest to najcz˛eściej
wykonywana operacja na CVS.
Jednak chciałbym zwrócić uwag˛e na inny sposób składowania źródeł natywnych.
W pewnym momencie okazuje si˛e, że składowanie wszystkich plików w repozytorium CVS jest mało efektywne i powoduje zbyt duże obcia˛żenia serwerów. Dlatego
też w PLD zastosowano mechanizm Distfiles5 którego krótki opis możemy odszukać tu6. W wielkim skrócie oznacza to że preparujac
˛ odpowiednio spec (pami˛etacie
tajemnicze md5?) i korzystajac
˛ z odpowiednich opcji programu ./builder możemy
sterować ściaganiem
˛
plików do distfiles. Tak naprawd˛e najcz˛eściej wykorzystane sa˛
dwie opcje ./builder - "5" i "U". Jest to także powód używania programu ./builder (a
nie frazy "rpmbuild -ba"), którego kopi˛e najlepiej ściagn
˛ ać
˛ z CVS. Pami˛etajmy także
o tym, że w systemie istnieje inny builder, który jest dostarczany z narz˛edziami rpm
ale oczywiście nie ma on możliwości pracy z distfiles. I jeszcze jedna uwaga: Distfiles jest przeznaczony tylko dla źródeł natywnych - wszelkie patche i nasze pliki
dodajemy normalnie do CVS (najcz˛eściej do katalogu SOURCES).
Oto przykłady użycia ./builder z odpowiednimi opcjami:
$ ./builder -5 mantis.spec
# $Revision: 6218 $, $Date: 2004-09-26 17:31:14 +0200 (nie, 26 wrz 2004) $
--20:32:59-- http://dl.sourceforge.net/mantisbt/mantis-0.18.0a4.tar.gz
=> ‘mantis-0.18.0a4.tar.gz’
Translacja dl.sourceforge.net... zrobiono.
Łaczenie
˛
si˛
e z dl.sourceforge.net[193.1.219.87]:80... połaczono
˛
si˛
e.
Żadanie
˛
HTTP wysłano, oczekiwanie na odpowiedź... 200 OK
Długość: 485,797 [application/x-tar]
100%[====================================>] 485,797 17.99K/s ETA 00:00
20:33:25 (17.99 KB/s) - zapisano ‘mantis-0.18.0a4.tar.gz’ [485797/485797]
Updating source-0 md5.
$
Opcje "5" i "U" sa˛ podobne, z tym że "5" próbuje poprawić md5 korzystajac
˛ z istniejacego
˛
sources w lokalnym repozytorium. Natomiast "U" próbuje zawsze ściagn
˛ ać
˛
źródła z podanego przez spec URL. Taka jest teoria. Ja praktycznie używam opcji "U"
kasujac
˛ wcześniej źródła z lokalnego repozytorium, ponieważ w innym przypadku
wyskakuja˛ dziwne bł˛edy o konflikcie z parametrem -nd
$ ./builder -U mantis.spec
# $Revision: 6218 $, $Date: 2004-09-26 17:31:14 +0200 (nie, 26 wrz 2004) $
--20:44:39-- http://dl.sourceforge.net/mantisbt/mantis-0.18.0a4.tar.gz
=> ‘mantis-0.18.0a4.tar.gz’
Translacja dl.sourceforge.net... zrobiono.
Łaczenie
˛
si˛
e z dl.sourceforge.net[193.190.198.97]:80... połaczono
˛
si˛
e.
Żadanie
˛
HTTP wysłano, oczekiwanie na odpowiedź... 200 OK
Długość: 485,797 [application/x-gzip]
100%[====================================>] 485,797 18.80K/s ETA 00:00
20:45:04 (18.80 KB/s) - zapisano ‘mantis-0.18.0a4.tar.gz’ [485797/485797]
Updating source-0 md5.
$
Odnogi (Branche) i Etykiety (Tag)
W każdym wi˛ekszym CVSie, projekty główne rozgał˛eziaja˛ si˛e tworzac
˛ tzw. branche
- W przypadku PLD np. istnieje stabilny, lecz już troche leciwy branch "RA-branch",
który wywodzi si˛e z brancha głównego HEAD. W pewnym momencie RA-branch
302
został "zamrożony" i dokonywane sa˛ na nim tylko zmiany zawierajace
˛ poprawki
poważnych bł˛edów lub aktualizacje zwiazane
˛
z bezpieczeństwem. Branch HEAD
"żyje" dalej i sa˛ w nim dokonywane zmiany i powstaja˛ nowe pakiety. Odgał˛ezień
może być (i jest) wiele, co na poczatku
˛
troche gmatwa spojrzenie na CVS ale później
doceniamy zalety tego rozwiazania.
˛
Dane odnogi maja˛ przydzielone odpowiednie
etykiety "lepkie" (ang. sticky tag) - czyli etykieta jest przekazywana każdej nast˛epnej
wersji w danej odnodze. Zwykłe etykiety (ang. tag) możemy użyć np. do okreslenia
indywidualnego stanu danego pliku - określajac
˛ np. tag STABLE, UNSTABLE lub
DEVELOP.
Jeżeli chodzi o etykietowanie to trzeba zachować rozwag˛e. Musimy być pewni że
wiemy co chcemy osiagn
˛ ać,
˛ bo możemy popsuć prac˛e komuś innemu (dotyczy to
także zmian w cudzych specach).
Praktycznie najcz˛eściej wykorzystywane sa˛ nast˛epujace
˛ opcje zwiazane
˛
z odnogami
i etykietami:
$ cvs status -v mldonkey.spec // Statystyka odnóg i etykiet
===================================================================
File: mldonkey.spec Status: Up-to-date
Working revision: 1.14.2.8 // Rewizja (wersja) robocza na lokalnym CVS
Repository revision: 1.14.2.8 /cvsroot/SPECS/mldonkey.spec,v
// Rewizja na zdalnym CVS
Sticky Tag: RA-branch (branch: 1.14.2)
// Dane dotyczace
˛
lepkiej etykiety - zwiazanej
˛
z branchem (odnoga)
˛
Sticky Date: (none)
Sticky Options: (none)
Existing Tags: // Istniejace
˛
etykiety zwykłe
mldonkey-2_5_3-2 (revision: 1.14.2.7)
STABLE (revision: 1.14.2.7)
mldonkey-2_5-1 (revision: 1.14.2.2)
RA-branch (branch: 1.14.2)
$
Sam sposób robienia odnóg pozostawiam innym - lepiej poczytać np. opis CVS PLD7
bo sam tego jeszcze nie robiłem :). Etykietowanie możemy wykonać np.: majac
˛ plik
w naszym lokalnym repozytorium wydajemy polecenie:
cvs tag UNSTABLE plik.spec
czyli plik.spec otrzymał etykiet˛e UNSTABLE.
Ostatnim przykładem b˛edzie przenoszenie zmian mi˛edzy odnogami (branchami).
Robiac
˛ jakiś spec w głównej odnodze HEAD doszliśmy do wniosku, że zmiany można ogłosić w odnodze RA-branch. Można spróbować wykonać polecenie:
cvs update -r RA-branch -j HEAD mldonkey.init
ale najcz˛eściej różnice mi˛edzy wersjami w odnogach sa˛ tak duże, że otrzymamy komunikat o braku automatycznej możliwości przeniesienia zmian. Wtedy można rozwiazać
˛
ten problem innym sposobem. Tworzymy np. w podkatalogu "SPECS" katalog "RA-branch" (nazwa katalogu jest nieistotna, ale pomocna). W podkatalogu "RAbranch" wykonujemy:
$
$
$
$
$
$
cvs get -A SPECS/plik.spec // parametr "A" usuwa tag
cd SPECS
cvs tag -b RA-branch plik.spec // nowy tag dla odnogi RA-branch
cp z_HEAD_plik.spec // podmieniamy plik na właściwy z HEAD
cvs commit -r RA-branch plik.spec // zatwierdzamy zmiany jako RA-branch
303
Myśl˛e że komentarze sa˛ czytelne. Gdy zrobimy co najmniej jedna˛ taka˛ operacj˛e, to
istniejacy
˛ katalog RA-branch może nam służyć do późniejszych operacji kopiowania
zmian mi˛edzy odnogami (np. korzystajac
˛ z opcji "cvs up".
Zlecenia dla builderów
Zdarza si˛e cz˛esto, że chcemy dać sygnał iż dany pakiet powinien zostać przebudowany przez buildery PLD (czyli takie zdalne komputery-muły8 robocze, które przygotowuja˛ pakiety) - wtedy podczas wpisywania komentarza po wydaniu polecenia
"cvs ci" należy napisać np.
- updated to version 2.5.3. Release 1 STBR for RA update general
STBR jest skrótem od "Send To Builder Request"
Zakończenie
Zbliżamy si˛e do końca naszego praktycznego poradnika. Nie zostało poruszonych
wiele kwestii, które wyjda˛ w codziennej pracy. Dlatego mamy do pomocy dokumentacj˛e, listy dyskusyjne, IRC, zasoby CVS i przegladark˛
˛
e GOOGLE ;). Praca ta miała
na celu wprowadzić w świat pracy developerskiej i pokazać praktyczne rozwiazania
˛
niektórych problemów - reszta zależy od naszej wiedzy i pracowitości - i pami˛etajmy, że najważniejsze to rozwijać swoje zdolności, bo od tego zależy nasza przyszłość
i przyszłość projektu dla którego pracujemy :)
Przypisy
1. mailto:[email protected]
2. http://developer-doc.pld-linux.org/cvs_official_eng/cederqvist-1.11.6.html
3. http://developer-doc.pld-linux.org/cvs_book/cvsbook.html
4. http://developer-doc.pld-linux.org/cvs_pld/cvs_pld.html
5. http://developer-doc.pld-linux.org/distfiles/distfiles.htm
6. http://developer-doc.pld-linux.org/distfiles/distfiles.htm
7. http://developer-doc.pld-linux.org/cvs_pld/cvs_pld.html
8. http://buildlogs.pld-linux.org/
304
Rozdział 21. O podreczniku
˛
Autorzy dokumentacji PLD
W tworzeniu tej pracy pośrednio lub bezpośrednio udział wzieli (w kolejności alfabetycznej):
•
Abramowicz Michał (abram)
•
Boguszewski Paweł (pawelb) <pawelb.at.pld-linux.org>
•
Buziak Tomasz (uho) <uho.at.xhost.one.pl>
•
Chomicki Arkadiusz (ChomAr) <chomar.at.wla.pl>
•
Ciesielski Marek (ciesiel) <ciesiel.at.pld-linux.org>
•
Doliński Marcin <averne.at.pld-linux.org>
•
Drozd Rafał (Grifter)
•
Gandecki Łukasz (gozda) <gozda.at.pld-linux.org>
•
Goł˛ebiowski Adam (adamg) <adamg.at.pld-linux.org>
•
Krakowiak Paweł
•
Królikowski Krzysztof <krolik.at.pld-linux.org>
•
Kwiatkowski Paweł (qwiat) <qwiat.at.o2.pl>
•
Mozer Łukasz Jarosław (Baseciq)
•
Nowak Łukasz (Shufla) <Lukasz.at.Nowak.eu.org>
•
Panasiewicz Michał (wolvverine) <wolvverine.at.pld-linux.org>
•
Paszkiewicz Sławomir (PaSzCzUs) <paszczus.at.pld-linux.org>
•
Pawłowicz Sergiusz (Ser)
•
Poślad Marcin (Lop)
•
Rudnicki Daniel Dominik (sardzent)<sardzent.at.pld-linux.org>
•
Sikora Paweł <pluto.at.pld-linux.org>
•
Szafko Bartłomiej
•
Wojtaszek Marek (speedo) <speedo.at.linux.pl>
305
Rozdział 21. O podr˛eczniku
306
Rozdział 22. Licencja i prawa autorskie
Tłumaczenie Licencji GNU Wolnej Dokumentacji
Niniejsza dokumentacja jest wydawana na licencji GNU Wolnej Dokumentacji.
Oryginalny tekst licencji wersji 1.2 w j˛ezyku angielskim możemy odnaleźć na
stronie GNU Free Documentation License1. Tłumaczenie starszej wersji 1.1 zostanie
tutaj przytoczone i znajduje si˛e na stronie GNU.org.pl2. Różnice mi˛edzy wersja˛ 1.1 a
1.2 niniejszej licencji w wersji angielskiej możemy przeczytać korzystajac
˛ z tego
odnośnika3
Wersja 1.1, marzec 2000
Copyright (c) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA Zezwala si˛e na kopiowanie i rozpowszechnianie wiernych kopii
niniejszego dokumentu licencyjnego, jednak bez prawa wprowadzania zmian.
0. Preambuła
Celem niniejszej licencji jest zagwarantowanie wolnego dost˛epu do podr˛ecznika, treści ksia˛żki i wszelkiej dokumentacji w formie pisanej oraz zapewnienie każdemu
użytkownikowi swobody kopiowania i rozpowszechniania wyżej wymienionych,
z dokonywaniem modyfikacji lub bez, zarówno w celach komercyjnych, jak i nie
komercyjnych. Ponad to Licencja ta pozwala przyznać zasługi autorowi i wydawcy
przy jednoczesnym ich zwolnieniu z odpowiedzialności za modyfikacje dokonywane przez innych.
Niniejsza Licencja zastrzega też, że wszelkie prace powstałe na podstawie tego dokumentu musza˛ nosić cech˛e wolnego dost˛epu w tym samym sensie co produkt oryginalny. Licencja stanowi uzupełnienie Powszechnej Licencji Publicznej GNU (GNU
General Public License), która jest licencja˛ dotyczac
˛ a˛ wolnego oprogramowania.
Niniejsza Licencja została opracowana z zamiarem zastosowania jej do podr˛eczników do wolnego oprogramowania, ponieważ wolne oprogramowanie wymaga wolnej dokumentacji: wolny program powinien być rozpowszechniany z podr˛ecznikami, których dotycza˛ te same prawa, które wia˛ża˛ si˛e z oprogramowaniem. Licencja
ta nie ogranicza si˛e jednak do podr˛eczników oprogramowania. Można ja˛ stosować
do różnych dokumentów tekstowych, bez wzgl˛edu na ich przedmiot oraz niezależnie od tego, czy zostały opublikowane w postaci ksia˛żki drukowanej. Stosowanie tej
Licencji zalecane jest głównie w przypadku prac, których celem jest instruktaż lub
pomoc podr˛eczna.
1. Zastosowanie i definicje
Niniejsza Licencja stosuje si˛e do podr˛eczników i innych prac, na których umieszczona jest pochodzaca
˛ od właściciela praw autorskich informacja, że dana praca może
być rozpowszechniana wyłacznie
˛
na warunkach niniejszej Licencji. Używane poniżej
słowo "Dokument" odnosić si˛e b˛edzie do wszelkich tego typu publikacji. Ich odbiorcy nazywani b˛eda˛ licencjobiorcami.
"Zmodyfikowana wersja" Dokumentu oznacza wszelkie prace zawierajace
˛ Dokument lub jego cz˛eść w postaci dosłownej badź
˛ zmodyfikowanej i/lub przełożonej
na inny j˛ezyk.
"Sekcja˛ drugorz˛edna"
˛ nazywa si˛e dodatek opatrzony odr˛ebnym tytułem lub sekcj˛e
poczatkow
˛
a˛ Dokumentu, która dotyczy wyłacznie
˛
zwiazku
˛
wydawców lub autorów
Dokumentu z ogólna˛ tematyka˛ Dokumentu (lub zagadnieniami z nia˛ zwiazanymi)
˛
307
i nie zawiera żadnych treści bezpośrednio zwiazanych
˛
z ogólna˛ tematyka˛ (na przykład, jeżeli Dokument stanowi w cz˛eści podr˛ecznik matematyki, Sekcja drugorz˛edna
nie może wyjaśniać zagadnień matematycznych). Wyżej wyjaśniany zwiazek
˛
może
si˛e natomiast wyrażać w aspektach historycznym, prawnym, komercyjnym, filozoficznym, etycznym lub politycznym.
"Sekcje niezmienne" to takie Sekcje drugorz˛edne, których tytuły sa˛ ustalone jako tytuły Sekcji niezmiennych w nocie informujacej,
˛
że Dokument został opublikowany
na warunkach Licencji.
"Treść okładki" to pewne krótkie fragmenty tekstu, które w nocie informujacej,
˛
że Dokument został opublikowany na warunkach Licencji, sa˛ opisywane jako "do umieszczenia na przedniej okładce" lub "do umieszczenia na tylnej okładce".
"Jawna" kopia Dokumentu oznacza kopi˛e czytelna˛ dla komputera, zapisana˛ w formacie, którego specyfikacja jest publicznie dost˛epna. Zawartość tej kopii może być
ogladana
˛
i edytowana bezpośrednio za pomoca˛ typowego edytora tekstu lub (w
przypadku obrazów złożonych z pikseli) za pomoca˛ typowego programu graficznego lub (w przypadku rysunków) za pomoca˛ ogólnie dost˛epnego edytora rysunków.
Ponadto kopia ta stanowi odpowiednie dane wejściowe dla programów formatuja˛
cych tekst lub dla programów konwertujacych
˛
do różnych formatów odpowiednich
dla programów formatujacych
˛
tekst. Kopia spełniajaca
˛ powyższe warunki, w której
jednak zostały wstawione znaczniki majace
˛ na celu utrudnienie dalszych modyfikacji
przez czytelników, nie jest Jawna. Kopi˛e, która nie jest "Jawna", nazywa si˛e "Niejawna".
˛
Przykładowe formaty kopii Jawnych to: czysty tekst ASCII bez znaczników, format
wejściowy Texinfo, format wejściowy LaTeX, SGML lub XML wykorzystujace
˛ publicznie dost˛epne DTD, standardowy prosty HTML przeznaczony do r˛ecznej modyfikacji. Formaty niejawne to na przykład PostScript, PDF, formaty własne, które
moga˛ być odczytywane i edytowane jedynie przez własne edytory tekstu, SGML lub
XML, dla których DTD i/lub narz˛edzia przetwarzajace
˛ nie sa˛ ogólnie dost˛epne, oraz
HTML wygenerowany maszynowo przez niektóre procesory tekstu jedynie w celu
uzyskania danych wynikowych.
"Strona tytułowa" oznacza, w przypadku ksia˛żki drukowanej, sama˛ stron˛e tytułowa˛
oraz kolejne strony zawierajace
˛ informacje, które zgodnie z ta˛ Licencja˛ musza˛ pojawić si˛e na stronie tytułowej. W przypadku prac w formatach nieposiadajacych
˛
strony
tytułowej "Strona tytułowa" oznacza tekst pojawiajacy
˛ si˛e najbliżej tytułu pracy, poprzedzajacy
˛ poczatek
˛
tekstu głównego.
2. Kopiowanie dosłowne
Licencjobiorca może kopiować i rozprowadzać Dokument komercyjnie lub niekomercyjnie, w dowolnej postaci, pod warunkiem zamieszczenia na każdej kopii Dokumentu treści Licencji, informacji o prawie autorskim oraz noty mówiacej,
˛
że do Dokumentu ma zastosowanie niniejsza Licencja, a także pod warunkiem nie umieszczania
żadnych dodatkowych ograniczeń, które nie wynikaja˛ z Licencji. Licencjobiorca nie
ma prawa używać żadnych technicznych metod pomiarowych utrudniajacych
˛
lub
kontrolujacych
˛
czytanie lub dalsze kopiowanie utworzonych i rozpowszechnianych
przez siebie kopii. Może jednak pobierać opłaty za udost˛epnianie kopii. W przypadku dystrybucji dużej liczby kopii Licencjobiorca jest zobowiazany
˛
przestrzegać
warunków wymienionych w punkcie 3.
Licencjobiorca może także wypożyczać kopie na warunkach opisanych powyżej, a
także wystawiać je publicznie.
3. Kopiowanie ilościowe
Jeżeli Licencjobiorca publikuje drukowane kopie Dokumentu w liczbie wi˛ekszej niż
100, a licencja Dokumentu wymaga umieszczenia Treści okładki, należy dołaczyć
˛
kopie okładek, które zawieraja˛ cała˛ wyraźna˛ i czytelna˛ Treść okładki: treść przedniej
308
okładki, na przedniej okładce, a treść tylnej okładki, na tylnej okładce. Obie okładki
musza˛ też jasno i czytelnie informować o Licencjobiorcy jako wydawcy tych kopii.
Okładka przednia musi przedstawiać pełny tytuł; wszystkie słowa musza˛ być równie dobrze widoczne i czytelne. Licencjobiorca może na okładkach umieszczać także
inne informacje dodatkowe. Kopiowanie ze zmianami ograniczonymi do okładek,
dopóki nie narusza tytułu Dokumentu i spełnia opisane warunki, może być traktowane pod innymi wzgl˛edami jako kopiowanie dosłowne.
Jeżeli napisy wymagane na którejś z okładek sa˛ zbyt obszerne, by mogły pozostać
czytelne po ich umieszczeniu, Licencjobiorca powinien umieścić ich poczatek(tak
˛
a˛
ilość, jaka wydaje si˛e rozsadna)
˛
na rzeczywistej okładce, a pozostała˛ cz˛eść na sasied˛
nich stronach.
W przypadku publikowania lub rozpowszechniania Niejawnych kopii Dokumentu
w liczbie wi˛ekszej niż 100, Licencjobiorca zobowiazany
˛
jest albo dołaczyć
˛
do każdej
z nich Jawna˛ kopi˛e czytelna˛ dla komputera, albo wymienić w lub przy każdej kopii
Niejawnej publicznie dost˛epna˛ w sieci komputerowej lokalizacj˛e pełnej kopii Jawnej
Dokumentu, bez żadnych informacji dodanych -- lokalizacj˛e, do której każdy użytkownik sieci miałby bezpłatny anonimowy dost˛ep za pomoca˛ standardowych publicznych protokołów sieciowych. W przypadku drugim Licencjobiorca musi podjać
˛
odpowiednie środki ostrożności, by wymieniona kopia Jawna pozostała dost˛epna we
wskazanej lokalizacji przynajmniej przez rok od momentu rozpowszechnienia ostatniej kopii Niejawnej (bezpośredniego lub przez agentów albo sprzedawców) danego
wydania.
Zaleca si˛e, choć nie wymaga, aby przed rozpocz˛eciem rozpowszechniania dużej liczby kopii Dokumentu, Licencjobiorca skontaktował si˛e z jego autorami celem uzyskania uaktualnionej wersji Dokumentu.
4. Modyfikacje
Licencjobiorca może kopiować i rozpowszechniać Zmodyfikowana˛ wersj˛e
Dokumentu na zasadach wymienionych powyżej w punkcie 2 i 3 pod warunkiem
ścisłego przestrzegania niniejszej Licencji. Zmodyfikowana wersja pełni wtedy
rol˛e Dokumentu, a wi˛ec Licencja dotyczaca
˛
modyfikacji i rozpowszechniania
Zmodyfikowanej wersji przenoszona jest na każdego, kto posiada jej kopi˛e. Ponadto
Licencjobiorca musi w stosunku do Zmodyfikowanej wersji spełnić nast˛epujace
˛
wymogi:
•
A. Użyć na Stronie tytułowej (i na okładkach, o ile istnieja)
˛ tytułu innego niż tytuł
Dokumentu i innego niż tytuły poprzednich wersji (które, o ile istniały, powinny
zostać wymienione w Dokumencie, w sekcji Historia). Tytułu jednej z ostatnich
wersji Licencjobiorca może użyć, jeżeli jej wydawca wyrazi na to zgod˛e.
•
B. Wymienić na Stronie tytułowej, jako autorów, jedna˛ lub kilka osób albo jednostek odpowiedzialnych za autorstwo modyfikacji Zmodyfikowanej wersji, a także
przynajmniej pi˛eciu spośród pierwotnych autorów Dokumentu (wszystkich, jeśli
było ich mniej niż pi˛eciu).
•
C. Umieścić na Stronie tytułowej nazw˛e wydawcy Zmodyfikowanej wersji.
•
D. Zachować wszelkie noty o prawach autorskich zawarte w Dokumencie.
•
E. Dodać odpowiednia˛ not˛e o prawach autorskich dotyczacych
˛
modyfikacji obok
innych not o prawach autorskich.
•
F. Bezpośrednio po notach o prawach autorskich, zamieścić not˛e licencyjna˛
zezwalajac
˛ a˛ na publiczne użytkowanie Zmodyfikowanej wersji na zasadach
niniejszej Licencji w postaci podanej w Załaczniku
˛
poniżej.
•
G. Zachować w nocie licencyjnej pełna˛ list˛e Sekcji niezmiennych i wymaganych
Treści okładki podanych w nocie licencyjnej Dokumentu.
•
H. Dołaczyć
˛
niezmieniona˛ kopi˛e niniejszej Licencji.
309
•
I. Zachować sekcj˛e zatytułowana˛ "Historia" oraz jej tytuł i dodać do niej informacj˛e dotyczac
˛ a˛ przynajmniej tytułu, roku publikacji, nowych autorów i wydawcy
Zmodyfikowanej wersji zgodnie z danymi zamieszczonymi na Stronie tytułowej.
Jeżeli w Dokumencie nie istnieje sekcja pod tytułem "Historia", należy ja˛ utworzyć,
podajac
˛ tytuł, rok, autorów i wydawc˛e Dokumentu zgodnie z danymi zamieszczonymi na stronie tytułowej, a nast˛epnie dodajac
˛ informacj˛e dotyczac
˛ a˛ Zmodyfikowanej wersji, jak opisano w poprzednim zdaniu.
•
J. Zachować wymieniona˛ w Dokumencie (jeśli taka istniała) informacj˛e o lokalizacji sieciowej, publicznie dost˛epnej Jawnej kopii Dokumentu, a także o podanych
w Dokumencie lokalizacjach sieciowych poprzednich wersji, na których został on
oparty. Informacje te moga˛ si˛e znajdować w sekcji "Historia". Zezwala si˛e na pomini˛ecie lokalizacji sieciowej prac, które zostały wydane przynajmniej cztery lata
przed samym Dokumentem, a także tych, których pierwotny wydawca wyraża na
to zgod˛e.
•
K. W każdej sekcji zatytułowanej "Podzi˛ekowania" lub "Dedykacje" zachować tytuł
i treść, oddajac
˛ również ton każdego z podzi˛ekowań i dedykacji.
•
L. Zachować wszelkie Sekcje niezmienne Dokumentu w niezmienionej postaci
(dotyczy zarówno treści, jak i tytułu). Numery sekcji i równoważne im oznaczenia
nie sa˛ traktowane jako należace
˛ do tytułów sekcji.
•
M. Usunać
˛ wszelkie sekcje zatytułowane "Adnotacje". Nie musza˛ one być
załaczane
˛
w Zmodyfikowanej wersji.
•
N. Nie nadawać żadnej z istniejacych
˛
sekcji tytułu "Adnotacje" ani tytułu pokrywajacego
˛
si˛e z jakakolwiek
˛
Sekcja˛ niezmienna.˛
Jeżeli Zmodyfikowana wersja zawiera nowe sekcje poczatkowe
˛
lub dodatki stanowiace
˛ Sekcje drugorz˛edne i nie zawierajace
˛ materiału skopiowanego z Dokumentu,
Licencjobiorca może je lub ich cz˛eść oznaczyć jako sekcje niezmienne. W tym celu
musi on dodać ich tytuły do listy Sekcji niezmiennych zawartej w nocie licencyjnej
Zmodyfikowanej wersji. Tytuły te musza˛ być różne od tytułów pozostałych sekcji.
Licencjobiorca może dodać sekcj˛e "Adnotacje", pod warunkiem, że nie zawiera ona
żadnych treści innych niż adnotacje dotyczace
˛ Zmodyfikowanej wersji -- moga˛ to
być na przykład stwierdzenia o recenzji koleżeńskiej albo o akceptacji tekstu przez
organizacj˛e jako autorytatywnej definicji standardu.
Na końcu listy Treści okładki w Zmodyfikowanej wersji, Licencjobiorca może dodać fragment "do umieszczenia na przedniej okładce" o długości nie przekraczaja˛
cej pi˛eciu słów, a także fragment o długości do 25 słów "do umieszczenia na tylnej
okładce". Przez każda˛ jednostk˛e (lub na mocy ustaleń przez nia˛ poczynionych) może zostać dodany tylko jeden fragment z przeznaczeniem na przednia˛ okładk˛e i jeden z przeznaczeniem na tylna.˛ Jeżeli Dokument zawiera już treść okładki dla danej
okładki, dodana˛ uprzednio przez Licencjobiorc˛e lub w ramach ustaleń z jednostka,˛
w imieniu której działa Licencjobiorca, nowa treść okładki nie może zostać dodana.
Dopuszcza si˛e jednak zastapienie
˛
poprzedniej treści okładki nowa˛ pod warunkiem
wyraźnej zgody poprzedniego wydawcy, od którego stara treść pochodzi.
Niniejsza Licencja nie oznacza, iż autor (autorzy) i wydawca (wydawcy) wyrażaja˛
zgod˛e na publiczne używanie ich nazwisk w celu zapewnienia autorytetu jakiejkolwiek Zmodyfikowanej wersji.
5. Łaczenie
˛
dokumentów
Licencjobiorca może łaczyć
˛
Dokument z innymi dokumentami wydanymi na warunkach niniejszej Licencji, na warunkach podanych dla wersji zmodyfikowanych w
cz˛eści 4 powyżej, jednak tylko wtedy, gdy w połaczeniu
˛
zostana˛ zawarte wszystkie
Sekcje niezmienne wszystkich oryginalnych dokumentów w postaci niezmodyfikowanej i gdy b˛eda˛ one wymienione jako Sekcje niezmienne połaczenia
˛
w jego nocie
licencyjnej.
310
Połaczenie
˛
wymaga tylko jednej kopii niniejszej Licencji, a kilka identycznych Sekcji
niezmiennych może zostać zastapionych
˛
jedna.˛ Jeżeli istnieje kilka Sekcji niezmiennych o tym samym tytule, ale różnej zawartości, Licencjobiorca jest zobowiazany
˛
uczynić tytuł każdej z nich unikalnym poprzez dodanie na jego końcu, w nawiasach,
nazwy oryginalnego autora lub wydawcy danej sekcji, o ile jest znany, lub unikalnego numeru. Podobne poprawki wymagane sa˛ w tytułach sekcji na liście Sekcji niezmiennych w nocie licencyjnej połaczenia.
˛
W połaczeniu
˛
Licencjobiorca musi zawrzeć wszystkie sekcje zatytułowane "Historia"
z dokumentów oryginalnych, tworzac
˛ jedna˛ sekcj˛e "Historia". Podobnie ma postapić
˛
z sekcjami "Podzi˛ekowania" i "Dedykacje". Wszystkie sekcje zatytułowane "Adnotacje" należy usunać.
˛
6. Zbiory dokumentów
Licencjobiorca może utworzyć zbiór składajacy
˛ si˛e z Dokumentu i innych dokumentów wydanych zgodnie z niniejsza˛ Licencja˛ i zastapić
˛ poszczególne kopie Licencji pochodzace
˛ z tych dokumentów jedna˛ kopia˛ dołaczon
˛
a˛ do zbioru, pod warunkiem zachowania zasad Licencji dotyczacych
˛
kopii dosłownych we wszelkich innych aspektach każdego z dokumentów.
Z takiego zbioru Licencjobiorca może wyodr˛ebnić pojedynczy dokument i rozpowszechniać go niezależnie na zasadach niniejszej Licencji, pod warunkiem zamieszczenia w wyodr˛ebnionym dokumencie kopii niniejszej Licencji oraz zachowania zasad Licencji we wszystkich aspektach dotyczacych
˛
dosłownej kopii tego dokumentu.
7. Zestawienia z pracami niezależnymi
Kompilacja Dokumentu lub jego pochodnych z innymi oddzielnymi i niezależnymi
dokumentami lub pracami nie jest uznawana za Zmodyfikowana˛ wersj˛e Dokumentu, chyba że odnosza˛ si˛e do niej jako do całości prawa autorskie. Taka kompilacja
jest nazywana zestawieniem, a niniejsza Licencja nie dotyczy samodzielnych prac
skompilowanych z Dokumentem, jeśli nie sa˛ to pochodne Dokumentu.
Jeżeli do kopii Dokumentu odnosza˛ si˛e wymagania dotyczace
˛ Treści okładki wymienione w cz˛eści 3 i jeżeli Dokument stanowi mniej niż jedna˛ czwarta˛ całości zestawienia, Treść okładki Dokumentu może być umieszczona na okładkach zamykajacych
˛
Dokument w obr˛ebie zestawienia. W przeciwnym razie Treść okładki musi si˛e pojawić na okładkach całego zestawienia.
8. Tłumaczenie
Tłumaczenie jest uznawane za rodzaj modyfikacji, a wi˛ec Licencjobiorca może rozpowszechniać tłumaczenia Dokumentu na zasadach wymienionych w punkcie 4. Zastapienie
˛
Sekcji niezmiennych ich tłumaczeniem wymaga specjalnej zgody właścicieli prawa autorskiego. Dopuszcza si˛e jednak zamieszczanie tłumaczeń wybranych lub
wszystkich Sekcji niezmiennych obok ich wersji oryginalnych. Podanie tłumaczenia
niniejszej Licencji możliwe jest pod warunkiem zamieszczenia także jej oryginalnej
wersji angielskiej. W przypadku niezgodności pomi˛edzy zamieszczonym tłumaczeniem a oryginalna˛ wersja˛ angielska˛ niniejszej Licencji moc prawna˛ ma oryginalna
wersja angielska.
9. Wygaśniecie
˛
Poza przypadkami jednoznacznie dopuszczonymi na warunkach niniejszej Licencji
nie zezwala si˛e Licencjobiorcy na kopiowanie, modyfikowanie, czy rozpowszechnianie Dokumentu ani też na cedowanie praw licencyjnych. We wszystkich pozostałych
311
wypadkach każda próba kopiowania, modyfikowania lub rozpowszechniania Dokumentu albo cedowania praw licencyjnych jest nieważna i powoduje automatyczne wygaśni˛ecie praw, które licencjobiorca nabył z tytułu Licencji. Niemniej jednak
w odniesieniu do stron, które już otrzymały od Licencjobiorcy kopie albo prawa w
ramach niniejszej Licencji, licencje nie zostana˛ anulowane, dopóki strony te w pełni
si˛e do nich stosuja.˛
10. Przyszłe wersje Licencji
W miar˛e potrzeby Free Software Foundation może publikować nowe poprawione
wersje GNU Free Documenation License. Wersje te musza˛ pozostawać w duchu podobnym do wersji obecnej, choć moga˛ si˛e różnić w szczegółach dotyczacych
˛
nowych
problemów czy zagadnień. Patrz http://www.gnu.org/copyleft/. Każdej wersji niniejszej Licencji nadaje si˛e wyróżniajacy
˛ ja˛ numer. Jeżeli w Dokumencie podaje si˛e
numer wersji Licencji, oznaczajacy,
˛ iż odnosi si˛e do niego podana "lub jakakolwiek
późniejsza" wersja licencji, Licencjobiorca ma do wyboru stosować si˛e do postanowień i warunków albo tej wersji, albo którejkolwiek wersji późniejszej opublikowanej oficjalnie (nie jako propozycja) przez Free Software Foundation. Jeśli Dokument
nie podaje numeru wersji niniejszej Licencji, Licencjobiorca może wybrać dowolna˛
wersj˛e kiedykolwiek opublikowana˛ (nie jako propozycja) przez Free Software Foundation.
Załacznik:
˛
Jak zastosować t˛e Licencj˛e dla swojego dokumentu.
Aby zastosować t˛e Licencj˛e w stosunku do dokumentu swojego autorstwa, dołacz
˛
kopi˛e Licencji do dokumentu i zamieść nast˛epujac
˛ a˛ informacj˛e o prawach autorskich
i uwagi o licencji bezpośrednio po stronie tytułowej.
Copyright (c) ROK TWOJE IMIE I NAZWISKO Udziela si˛e zezwolenia do kopiowania rozpowszechniania i/lub modyfikacj˛e tego dokumentu zgodnie z zasadami
Licencji GNU Wolnej Dokumentacji w wersji 1.1 lub dowolnej późniejszej opublikowanej przez Free Software Foundation; wraz z zawartymi Sekcjami Niezmiennymi
LISTA TYTUŁÓW SEKCJI, wraz z Tekstem na Przedniej Okładce LISTA i z Tekstem
na Tylnej Okładce LISTA. Kopia licencji załaczona
˛
jest w sekcji zatytułowanej "GNU
Free Documentation License"
Jeśli nie zamieszczasz Sekcji Niezmiennych, napisz "nie zawiera Sekcji Niezmiennych" zamiast spisu sekcji niezmiennych. Jeśli nie umieszczasz Teksu na Przedniej
Okładce wpisz "bez Tekstu na Okładce" w miejsce "wraz z Tekstem na Przedniej
Okładce LISTA", analogicznie postap
˛ z "Tekstem na Tylnej Okładce"
Jeśli w twoim dokumencie zawarte sa˛ nieszablonowe przykłady kodu programu, zalecamy abyś także uwolnił te przykłady wybierajac
˛ licencj˛e wolnego oprogramowania, taka˛ jak Powszechna Licencja Publiczna GNU, w celu zapewnienia możliwości
ich użycia w wolnym oprogramowaniu.
Przypisy
1. http://www.fsf.org/copyleft/fdl.html
2. http://gnu.org.pl/text/GFDL-pl.html
3. http://www.fsf.org/licenses/fdl-1.2-diff.txt
312

PLD Linux Distribution

Transkrypt

Podobne dokumenty

WMag nr 5 1