PLD Linux Distribution

Podręcznik użytkownika, administratora i twórcy

Historia zmian
Zmiana $Rev: 12145 $
beta

Spis treści

I. Informacje podstawowe
1. Wprowadzenie
Streszczenie
Konwencje użyte w tej książce
O tym podręczniku
Krótka historia PLD
Informacje o PLD
Podstawowe informacje
Założenia PLD
System
Bezpieczeństwo
Sieć
Pakiety
Cechy użytkowe
Oficjalne wersje PLD
Model rozwoju PLD Linux Distribution
Projekty związane z PLD
2. Zasoby sieciowe PLD
Ważne adresy
Źródła obrazów ISO
Serwery z pakietami
FTP - serwer podstawowy
FTP - serwery lustrzane
HTTP - serwer podstawowy
HTTP - serwery lustrzane
RSYNC
3. Historia powstania naszego logo
Wstęp
Loga duże
Ikony do umieszczania na stronach WWW
Ikony stworzone przez użytkowników
Galeria rysunków Karola Kreńskiego
II. Instalacja
4. Instalacja przy użyciu chroota
Wstęp
Przygotowanie
Uruchomienie
Partycje/woluminy
Systemy plików
Konfiguracja sieci
Proxy
Konfiguracja Poldka
Instalacja
Instalacja pakietów
Przygotowanie do instalacji kernela
Instalacja kernela
Bootloader
UDEV
Konta użytkowników
Operacje końcowe
5. Aktualizacje
Aktualizacja z Ra do Ac
III. Podręcznik użytkownika
6. Podstawy
Wstęp
Włączanie i wyłączanie systemu
Podstawowe operacje na plikach i katalogach
Poruszanie się w drzewie katalogów
Data i czas
Edycja plików konfiguracyjnych
Podstawowe narzędzia kontroli sieci TCP/IP
Ping
Traceroute
MTR
Proxy
7. Zasoby systemu
Ilość miejsca na dysku
Procesy i zasoby
Jak sprawdzić kto jest zalogowany oprócz nas?
IV. Podręcznik administratora
8. Zarządzanie pakietami
Informacje podstawowe
Wstęp
Pakiety w PLD
Menadżery pakietów
Pobieranie pakietów
Cechy pakietów w PLD
Zależności między pakietami
Wymagania (requires) i własności (provides)
Zawartość pakietów
Konwencja nazw pakietów w PLD
Metapakiety
Komunikaty
Wpływ pakietów na pracę systemu
Wpływ pakietów na pliki konfiguracji
Architektury pakietów
Wybór architektury
Procesory
Źródła pakietów
Ścieżki do podstawowych źródeł w konfiguracji Poldka
Cykl życia pakietu
Budowanie pakietów
Wstęp
Budowanie
Zarządzanie
Poldek
Wstęp
Pliki konfiguracji
Konfiguracja pobierania pakietów
Inne opcje
Tryby pracy
Tryb interaktywny
Tryb wsadowy
Pierwsze kroki z Poldkiem
Zarządzanie pakietami
Źródła
Porady
RPM
Instalowanie pakietów
Aktualizowanie pakietów
Odinstalowywanie pakietów
Uwagi
Bezpieczeństwo
Uruchamianie Poldka
Podpisy pakietów
Zaawansowane operacje
Lista ostatnio instalowanych pakietów
Odinstalowanie "opornych" pakietów
Repackage - bezpieczna aktualizacja
Kontrola integralności systemu
Naprawa bazy RPM
Reinstalacja wszystkich pakietów - zmiana architektury
9. Bootloader
Wstęp
Parametry jadra
MBR czy bootsector?
Frame buffer (bufor ramki)
LILO
Konfiguracja podstawowa
Inne systemy operacyjne
Frame Buffer
Graficzne menu
Zakończenie
GRUB
Nazewnictwo urządzeń
Konfiguracja podstawowa
Instalacja
Inne systemy operacyjne
Frame Buffer
Graficzne menu
Bezpieczeństwo bootloadera
Uwagi
rc-boot
Wstęp
Podstawowa konfiguracja
Tworzenie "obrazów"
Uwagi
10. Kernel i urządzenia
Jądro systemu
Koncepcja jądra w PLD
Informacje o używanym jądrze
Rodzaje jąder systemowych
Aktualizacja
Zależności
Uwagi
Parametry jądra
Moduły jądra
Czym są?
Załadowanie właściwego modułu dla urządzenia
Konfiguracja modułów
Statyczne zarządzanie modułami
Określenie modułu dla urządzenia
Zarządzanie modułami
/etc/modules
/etc/modprobe.conf
Udev - dynamiczna obsługa sprzętu
Instalacja
Konfiguracja
Udev w praktyce
Uwagi
Initrd
Wstęp
Przygotowanie
Automatyczne generowanie initrd
Ręczne generowanie initrd
Gdy zawiedzie geninitrd
Bootloader
Uwagi
Urządzenia
Podstawowe informacje o urządzeniu
Systemy plików-urządzeń
UDEV
Jaki system wybrać?
11. Konfiguracja systemu
Podstawowe ustawienia
Konfiguracja skryptów startowych
Opcje związane z jądrem
Opcje uruchamiania systemu
Usługi
Ustawienia konsoli
Internacjonalizacja
Wstęp
Internacjonalizacja konsoli i programów
Myszka pod konsolą
Wstęp
Szeregowa
PS/2, TouchPad, TrackPoint
USB
Zakończenie
Porady
Strefa czasowa
Zegar
Zmienne środowiskowe
Przeglądanie
Konfiguracja globalna
Konfiguracja lokalna
PLDconf - Narzędzie do konfiguracji systemu
Kluczowe pliki
/etc/inittab
/etc/fstab
/etc/passwd
/etc/shadow
/etc/group
/etc/shells
/etc/motd
/etc/nologin
12. Pamięci masowe
Wstęp
Nazewnictwo urządzeń masowych
Numerowanie partycji
Urządenia ATA (IDE)
Urządenia SCSI/SATA/USB Storage
Dyskietki elastyczne
LVM
RAID programowy
Urządzenia w GRUB-ie
Podział na partycje
Partycje
Zanim zaczniemy
Wymagane miejsce na system
Plan podziału dysku
Programy do zarządzania partycjami
Podział
Zakończenie
Systemy plików
Wybór systemu plików
Tworzenie systemu plików
Tworzenie obszaru wymiany
Podmontowanie partycji / aktywacja swapu
Poznanie typu systemu plików
Formatowanie
RAID programowy
Instalacja
Planowanie macierzy
Tworzenie macierzy RAID
Konfiguracja
Initrd
Bootloader
Diagnostyka
Porady
Dodatki
LVM
Planowanie woluminów
Instalacja
Budowanie woluminów
Konfiguracja startowa
Narzędzia diagnostyczne
Zarządzanie: powiększanie woluminu
Porady
Naprawa
Uszkodzenia fizyczne
Naprawa systemu plików
13. Administracja
Ratowanie systemu
Wstęp
Uruchomienie na niskim poziomie pracy
Uruchomienie RescueCD
Naprawa systemu plików
Naprawa konfiguracji
Operacja chroota
Uwagi
Zarządzanie podsystemami i usługami
Budowa systemu rc-skryptów
Zarzadzanie podsystememi/usługami
Konfiguracja rc-skryptów
Zależności
Usługi a poziomy pracy
Zmiana poziomu pracy systemu
Konta użytkowników
Dodanie
Usunięcie
Modyfikacja
Hasło
Zarządzanie kontami
Grupy
Dodanie grupy
Zapisanie do grup
Usunięcie grupy
Uwagi
Zarządzanie uprawnieniami
Bezpieczeństwo
Dostępne narzędzia
Dostęp do konta root
SUID
/proc
chroot i vserver
Statyczny VIM
Pakiety
14. Interfejsy sieciowe
Wstęp
Podstawowa konfiguracja sieci
Brama domyślna
Odwzorowanie nazw - serwery DNS
Nazwa hosta
Odwzorowanie nazw - konfiguracja zaawansowana
Inne opcje
Ethernet
Urządzenie
Statyczna konfiguracja karty sieciowej
Dynamiczna konfiguracja karty sieciowej (DHCP)
Aktywacja sieci
WiFi
Wstęp
Sterowniki dedykowane
Sterowniki z NdisWrapperem
Sieć WEP
Sieć WPA2-PSK
Aktywacja i diagnostyka
Neostrada+ z modemem USB firmy Sagem
Wprowadzenie
Instalacja
Konfiguracja
Uruchomienie i post konfiguracja
Neostrada+ z modemem USB firmy Alcatel - Thompson
Przygotowanie do instalacji
Konfiguracja
Uruchomienie i zakończenie
xDSL z interfejsem Ethernet
Wprowadzenie
Konfiguracja
Uwagi
Zaawansowane opcje interfejsów
HotPlug
Narzędzia
Inne opcje
Wzory konfiguracji
15. Zastosowania sieciowe
Routing statyczny
Wstępna konfiguracja
Tablica routingu
Zarządzanie trasami
Zakończenie
NAT
DNAT
SNAT i MASQUERADE
Zakończenie.
Podział łącza w zależności od serwisów
Wstęp
Podstawy
Przekierowanie p2p i połączeń podobnych
PPP over SSH - Tunel IPv4
Wstęp
Konfiguracja
Uruchomienie
VTun - Tunel IPv4
Wstęp
Konfiguracja
Uruchomienie
Narzędzia sieciowe
Konfiguracja interfejsow
Zarządzanie interfejsami
Adresy sprzętowe (MAC)
ARP
Serwery nazw (DNS)
Wydajność sieci
Monitorowanie sieci
Zakończenie
16. Usługi dostępne w PLD
Usługi - wstęp
ALSA - Dźwięk w Linuksie
Instalacja
Konfiguracja z użyciem systemu UDEV
Konfiguracja statyczna
Ustawienie miksera i testowanie
Zaawansowana obsługa miksera
Uwagi
Apache - Serwer stron internetowych
Wstęp
Instalacja
Pliki konfiguracji
Podstawowa konfiguracja
Strony użytkowników
Virtual Hosts
Ograniczanie dostępu na podstawie adresu
Ograniczenie dostępu za pomocą loginu i hasła
Obsługa skryptów PHP
CGI
Security Socket Layer (SSL)
Indeksowana zawartość katalogu
Uwagi
BIND - Serwer Nazw
DNS - Domain Name System
Wstęp
Podstawowa konfiguracja
Przykładowa konfiguracja strefy typu primary
Przykładowa konfiguracja strefy typu secondary
Obsługa protokołu IPv6
Rejestracja
Diagnostyka
Zakończenie
CRON - Cykliczne wykonywanie zadań
Instalacja
Budowa tabel
Format daty i czasu
Tabele systemowe
Tabele użytkowników
Komunikaty cron-a
CUPS - Popularny system druku dla Uniksa
Wstęp
Instalacja
Zarządzanie drukarkami
Dodanie drukarki
Szczegóły dodawania drukarki lokalnej
Szczegóły dodawania drukarki zdalnej
Konfiguracja serwera
Zarządzanie kolejką druku
Test drukarki i rozwiązywanie problemów
DHCPD - Dynamic Host Configuration Protocol Daemon
Instalacja
Podstawowa konfiguracja
Statyczne przypisanie konfiguracji
Inne opcje
Uruchomienie
Konfiguracja klienta
Uwagi
Exim - Transport poczty elektronicznej (MTA)
Instalacja
Budowa pliku konfiguracji
Podstawowa konfiguracja
Skrzynki pocztowe
Różne opcje
Autoryzacja SMTP
Syfrowanie SSL
Quota
Dodanie skanerów antywirusowych
Walka ze spamem
Obsługa wielu domen w Eximie
Automatyczna odpowiedź - Vacations
Heimdal - Implementacja protokołu Kerberos
Instalacja i konfiguracja KDC
Logowanie do systemu
Konfiguracja poszczególnych usług
Jabber 2 - Serwer typu Instant Messaging
Wstęp
Instalacja
Konfiguracja DNS i rekordów SRV
Konfiguracja portów (jeżeli korzystamy z firewall-a)
Podstawowa konfiguracja Jabberd2
Konfiguracja dla SQL (Postgresql)
Szyfrowanie
Zakończenie
MySQL - System Zarządzania Relacyjnymi Bazami Danych (ang. RDBMS)
Co to jest MySQL?
Ogólne cechy MySQL
Instalacja
Konfiguracja MySQL
Demon MySQL
mysqladmin
mysqldump
phpMyAdmin
NFS - Network File System
Serwer
Udostępnianie
Klient
Bezpieczeństwo serwera
Dostrajanie wydajności
PDNS (Power DNS) - Serwer Nazw
Wstęp
Instalacja
Konfiguracja Postgresql dla PDNS
Konfiguracja PDNS
Domeny
Postfix - Transport poczty elektronicznej (MTA)
Zaczynamy
Konfiguracja
Szyfrowanie
Domeny
Usprawnienia
Końcowa konfiguracja
tpop3d
amavis + mks
postifx.admin
PostgreSQL - Baza danych SQL
Co to jest PostgreSQL
Instalacja pakietów
Konfiguracja PostgreSQLa w PLD
Inicjalizacja
Konfiguracja PostgreSQLa
Uruchomienie PostgreSQLa
Dodanie użytkownika
Ostatni test
Dodatki
Odnośniki
ProFTPD - serwer FTP
Wstęp
Instalacja
Podstawowa konfiguracja demona
Konfiguracja dostępu
Zakończenie
Samba - współpraca z Windows
Samba jako Serwer domeny NT4 (PDC)
Serwer członkowski domeny NT4
Snort - Sieciowy System Wykrywania Włamań
Wymagania
Instalacja Snorta i ACID
Konfiguracja Snorta
Aktualizacja reguł
Instalacja Oinkmaster
Architektura Snorta
Tryby pracy
Preprocesory
Moduł sygnatur
Ciekawe projekty
Syslog-ng
Wstęp
Konfiguracja
Test konfiguracji
Uwagi
Dodatek
17. X-Window
Wstęp
X-Server
Instalacja
Zanim zaczniemy konfigurację
Pierwsze uruchomienie
Konfiguracja
Inne sposoby konfiguracji
Rozwiązywanie problemów
Środowisko graficzne (GUI)
Zaawansowane
Mysz
Klawiatura
Monitor
Rozdzielczość obrazu
Zaawansowane - DPI
Zaawansowane - serwer czionek
Uwagi
Środowisko GNOME
Instalacja
Internacjonalizacja
Dźwięk
Uruchomienie
Administracja - GNOME System Tools
Przydatne drobiazgi
Godne polecenia aplikacje
Pomoc i rozwiązywanie problemów
Środowisko KDE
Blackbox - Szybki i lekki zarządca okien
Wstęp
Instalacja pakietów
Konfiguracja
Fluxbox - Następca BlackBoxa
Wstęp
Instalacja pakietów
Konfiguracja
Uruchamianie środowiska graficznego
Skrypt startx
GDM
KDM
Ustawienie poziomu pracy
Porady
Karty firmy nVidia
Karty firmy ATI
Instalacja i konfiguracja
Test konfiguracji
V. Tworzenie PLD - Praktyczny poradnik
18. Możliwa droga do zostania szeregowym developerem PLD
Co jest potrzebne
Źródła wiedzy
Przykład budowania
Pierwszy spec
19. W krainie CVS - czyli wielki kocioł
Wstęp
Dodawanie plików do CVS PLD
Aktualizacja plików
Zatwierdzanie zmian i Distfiles
Odnogi (Branche) i Etykiety (Tag)
Zlecenia dla builderów
Zakończenie
VI. O podręczniku
20. O podręczniku
Autorzy dokumentacji PLD
21. Licencja i prawa autorskie
Tłumaczenie Licencji GNU Wolnej Dokumentacji
Wersja 1.1, marzec 2000
0. Preambuła
1. Zastosowanie i definicje

Spis rysunków

3.1. Logo główne
3.2. Logo główne z cieniowaniem
3.3. Ikona na www 1
3.4. Ikona na www 2
3.5. Ikona na www 3
3.6. Ikona na www 4
3.7. Ikona na www 5
3.8. Ikona na www 6
3.9. Ikona stworzona przez "muche"
3.10. Ikona stworzona przez Łukasza "Baseciq" Mozera

Spis tabel

8.1. Opis zawartości pakietów w zależności od ich nazwy
8.2. Lista nazw kodowych architektur i odpowiadających im rodzin procesorów:
9.1. Parametry jądra
9.2. Tryby bufora ramki
10.1. Kernele
13.1. Popularne akcje skryptów startowych
13.2. Dostępne poziomy pracy
13.3.
16.1. Obsługa baz danych
16.2.
16.3.

Część I. Informacje podstawowe

Rozdział 1. Wprowadzenie

Streszczenie

Dziękujemy za zainteresowanie się PLD Linux Distribution™!

W tym rozdziale przedstawione zostaną różne aspekty dotyczące projektu PLD, takie jak jego historia, cele, model rozwoju, itp.

Konwencje użyte w tej książce

Aby jak najlepiej zrozumieć i przyswoić informacje zawarte w tym podręczniku, warto zapoznać się wpierw z użytymi konwencjami.

$ komenda

W ten sposób opisywane są komendy, które wykonać możemy z uprawnieniami użytkownika.

# komenda

Tutaj natomiast przedstawiona została komenda, którą należy wykonać z poziomu użytkownika root, czyli administratora.

Zbyt długie linie zrzutów ekranowych, które nie mieszczą się w jednej linii, podzielone są przy pomocy znaku \. Czyli:

# komenda z_bardzo_\
długim_parametrem

należy zinterpretować jako:

# komenda z_bardzo_długim_parametrem

W dokumentacji dosyć często korzysta się z następującej konstrukcji:

{$zmienna}

Tak oznaczane są miejsca, w których użytkownik może lub musi samodzielnie dokonać wyboru i wstawić w miejsce ciągu znaków {$zmienna} odpowiednią wartość.

Niejdnokrotnie w nazwach plików pojawia się znak "gwiazdki", który należy odczytywać podobnie jak robi to powłoka (shell), a więc zastępuje dowolny ciąg znaków, przykładowo:

/katalog/plik.*

oznacza wszytskie pliki zaczynjące się od plik. w katalogu /katalog.

O tym podręczniku

Celem tego podręcznika jest pomoc w zainstalowaniu PLD Linux Distribution™ na Twojej maszynie. Nie jest to i nigdy nie będzie zamiennik dokumentacji systemowej. Jeśli będzie to Twoja pierwsza instalacja Linuksa, gorąco zachęcamy Cię do przeczytania wpierw tego podręcznika. Nawet jeśli jesteś doświadczonym użytkownikiem, warto przestudiować instrukcje dotyczące instalacji, aby upewnić się, że wszystko pójdzie gładko.

Oprócz niniejszej dokumentacji możemy szukać pomocy w wielu innych miejscach. Prężnie działają listy dyskusyjne oraz oficjalne kanały IRC (#PLD i #PLDhelp). Na często zadawane pytania (FAQ) odpowiedzi można znaleźć na głównej stronie WWW.

Jeśli uważasz, że dokumentacja jest niepełna, znalazłeś błędy, lub chciałbyś do nas dołączyć prosimy o wysłanie informacji na listę dyskusyjną lub o kontakt z jednym z autorów dokumentacji, których listę zamieszczono w „Autorzy dokumentacji PLD”

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, że już takową robią. Nic jednak z tego nie wynikało. Wreszcie, w lipcu 1998, zawiązał się projekt mający na celu stworzenie polskiej dystrybucji Linuxa. Projekt PLD, czyli Polish(ed) Linux Distribution, był na tyle dobrze zorganizowany, by przetrwać trudne początki. Nie obeszło się oczywiście bez burzliwych dyskusji na temat kształtu dystrybucji, doboru oprogramowania jak również wersji jądra, na której projekt ma być rozwijany. W efekcie zdecydowano się prowadzić równolegle dwa projekty. Pierwszy został nazwany PLD-devel i był forpocztą dla obecnego PLD-stable. Prace nad 1.1 PLD (devel) koordynowali przede wszystkim Wojtek Ślusarczyk, Marcin Korzonek i Arek Miśkiewicz. Miała to być 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łaściwej PLD-stable.

Nieco później, przede wszystkim z braku wolnego czasu z prac nad projektem wycofali się Wojtek Ślusarczyk, Andrzej Nakonieczny oraz Marcin Korzonek. Tomasz Kłoczko postanowił kontynuować prace nad PLD, gromadząc wokół siebie coraz to większą liczbę developerów. Pojawiła się domena pld.org.pl, a wraz z nią liczne adresy "funkcjonalne", takie jak ftp.pld.org.pl, www.pld.org.pl czy cvs.pld.org.pl. Ruch na listach mailingowych stawał się coraz większy, widać było, iż projekt zyskiwał na popularności.

22 listopada 2002 roku światło dzienne ujrzała pierwsza stabilna wersja dystrybucji PLD Linux Distribution 1.0 (Ra). Jeszcze w czasie jej stabilizacji rozpoczęły się prace nad kolejną wersją.

Twórcy projektu zakładali uniwersalność PLD, która pozwalałaby na korzystanie z dystrybucji przez użytkowników z całego świata, jednak pojawiły się obawy, że nazwa Polish(ed) Linux Distribution ™ odstraszy potencjalnych odbiorców z innych krajów. Postanowiono, że zmieniona zostanie nazwa projektu. Pozostawiono charakterystyczny skrót "PLD" w niezmienionej postaci, zmieniono zaś jego rozwinięcie - nazwa "PLD" stała się rekurencyjnym skrótem od PLD Linux Distribution™.

Pierwszego kwietnia 2007 roku wydana została wersja Ac, długi okres rozwoju przyzwyczaił użytkowników do nieustających aktualizacji oprogramowania. Taki model rozwoju dystrybucji okazał się na tyle wygodny, że postanowiono by kolejne wydanie miały być rozwijane bez końca. Oznacza to, że na razie nie są planowane żadne kolejne wydania, a do stabilnej gałęzi pakietów nieprzerwanie trafiają aktualizacje.

Informacje o PLD

Podstawowe informacje

PLD-Linux jest dystrybucją rozwijaną głównie w Polsce. Jest to produkt grupy entuzjastów Linuksa chcącej stworzyć system operacyjny dopasowany do własnych potrzeb. Aktualnie rozwojem dystrybucji interesuje się około 200 osób, z pośród nich najbardziej aktywna jest grupa 50 deweloperów.

PLD jest jednym z najaktywniejszych projektów Open Source na świecie. Dzięki temu powstała jedna z największych dystrybucji Linuksa, w trakcie prac nad drugą wersją systemu (Ac) ilość dostępnych pakietów zbliżyła się do trzynastu tysięcy.

Założenia PLD

Jedną z największych bolączek administratorów jest chroniczny brak czasu, dlatego bardzo istotne jest zminimalizowanie nakładu pracy przy codziennych zajęciach administracyjnych. Mając to na uwadze, stworzono dystrybucję, która zapewnia wysokie bezpieczeństwo i łatwość administracji. PLD jest tak projektowane by w możliwie najkrótszym czasie uruchomić bezpieczny, wydajny i łatwy w zarządzaniu system produkcyjny. Założono, że administrator nie może tracić czasu na kompilację jądra, programów czy też pisania rc-skryptów.

PLD jest uniwersalną i elastyczną dystrybucją, dzięki czemu sprawdzi się w różnorodnych zastosowaniach. Przy jej tworzeniu, główny nacisk jest jednak kładziony na niezawodne działanie usług. Utarło się nawet powiedzenie, że PLD jest dystrybucją tworzoną przez administratorów dla administratorów, mamy więc do czynienia z systemem dobrze przygotowanym do pracy w roli serwera.

Nie oznacza to bynajmniej, że PLD nie nadaje się na system dla stacji roboczej, doskonale sprawdza się również w tym zastosowaniu. Zwykły użytkownik nie znajdzie tu wielu ułatwiających życie początkującym narzędzi, aby używać PLD konieczna jest solidna porcja wiedzy. Mamy nadzieję, że niniejszy podręcznik będzie pomocny w jej zdobyciu.

Poniżej przedstawiono zestawienie najciekawszych cech systemu.

System

  • w systemie dostępne są silnie zmodularyzowane jądra, dzięki czemu w ogromnej większości wypadków nie trzeba go kompilować na nowo; wystarczy wybrać właściwy kernel i załadować potrzebne moduły

  • w PLD zastosowano skrypty startowe (rc-skrypty) typu System-V, Pozwoliło to na maksymalne zautomatyzowanie procesu instalacji usług systemowych.

  • podobną koncepcją do rc-inetd™ kierowano się w tworzeniu pakietu rc-boot™, pozwala on na łatwe zarządzania bootloaderami

  • używanie FHS 2.x jako specyfikacji struktury katalogów

  • całkowite odejście od termcap™ i libtermcap™ (w PLD nie ma pakietu z libtermcap i samego termcapa; ani jeden pakiet nie jest związany z termcapem)

  • uporządkowane rozmieszczenia plików w gałęzi /usr - żaden pakiet dystrybucyjny nie umieszcza plików w katalogach wewnątrz /usr/local

Bezpieczeństwo

  • domyślne jądro zawiera grsecurity

  • restrykcyjne uprawnienia dla użytkowników

  • przystosowanie do łatwego przejścia systemu na alternatywne metody autoryzacji (i -- w zależności od potrzeb -- szyfrowania) komunikacji po sieci, jak PAM, czy GSAPI, TSL/SSL... Jest bardzo prawdopodobne, że już w niedługiej perspektywie dużą rolę zacznie tu odgrywać SASL. W praktyce owo łatwe dostosowywanie do np. kerberyzacji systemu jest realizowane także z użyciem rc-inetd, która to platforma ułatwia znakomicie podmianę różnych serwisów na wersje skerberyzowane czy też wykorzystujące inne mechanizmy jak np. socks5 (tutaj jeszcze jest mało zrobione, ale furtka jest szeroko i jednoznacznie otwarta)

  • mechanizm sys-chroot™ ułatwiający zarządzanie środowiskami typu chroot oraz dobre wsparcie dla środowisk Linux VServer

Sieć

  • PLD posiada najlepszą obsługę przyszłościowego protokołu IPv6 z pośród innych dystrybucji Linuksa.

  • używanie iproute2™ jako podstawowego narzędzia do operowania na interfejsach sieciowych, dzięki czemu np. skrypty startowe z PLD są prostsze i krótsze mimo większej funkcjonalności w stosunku do swoich odpowiedników z RH; inną zaletą jest wsteczna kompatybilność z opisem interfejsów sieciowych z tym, co jest stosowane w initscripts z RH; kolejną cechą skryptów startowych jest to, że -- w zależności od preferencji użytkownika -- mogą one wyświetlać wszystkie komunikaty po polsku

  • PLD zawiera rc-inetd™ - interfejs do zarządzania usługami typu inetd. Pozwala zarządzać takimi usługami (np.: telnetd, cvs-pserver) bez znaczenia jakiego typu demon inetd jest używany

Pakiety

  • PLD zawiera ogromne ilości gotowych, binarnych pakietów; pozwala to uniknąć instalacji oprogramowania spoza dystrybucji

  • w dystrybucji używane są pakiety typu RPM™, do zarządzania nimi stworzono program o swojsko brzmiącej nazwie Poldek™, można też używać klasycznego programu RPM

  • możliwość samodzielnego budowania pakietów RPM pozwoli na łatwe skompilowanie pakietu z nietypową funkcjonalnością

  • znaczna liczba programów podzielona jest na mniejsze pakiety, pozwalające instalować tylko te elementy systemu, które są akurat potrzebne

  • pakiety często są wstępnie skonfigurowane i gotowe do działania, ponadto nakładane są na nie istotne łaty

  • w PLD nie są faworyzowane żadne z usług czy programów. To czego używamy zależy tylko od nas

  • pełne przygotowanie pakietów do automatycznego uaktualnienia. Pakiety z RH kompletnie nie są na to przygotowane. Przygotowanie to wiąże się z restartowaniem serwisów przy ich uaktualnieniu, odpowiednim przygotowywaniem procedur uaktualnienia w taki sposób, by umożliwić automatyczną aktualizację nawet przy zmianie plików konfiguracyjnych

  • kompresowanie wszystkich plików dokumentacji z użyciem gzip (bzip2 nic w praktyce tu nie wnosi, a dostarcza tylko nowych kłopotów, czego doświadczają od czasu do czasu użytkownicy Mandrake)

  • separacja bibliotek statycznych w osobne podpakiety {$nazwa}-static (nie każdy tego potrzebuje), a nagłówków do {$nazwa}-devel

  • uzupełnianie opisów pakietów i dokumentacji w różnych językach. W dużej części robi się to niejako przy okazji. Użytkownik może sobie skonfigurować i zainstalować wybrane oprogramowanie ze wsparciem dla preferowanego zestawu języków, np.: angielski i niemiecki czy też angielski i polski (zasoby dla innych języków zostaną pominięte). Tak unikalną możliwość konfiguracji osiągamy dzięki konsekwentnemu oznaczaniu zasobów narodowych makrem %lang() w poszczególnych pakietach

Cechy użytkowe

  • PLD jest systemem przyjaznym dla programisty. Dostępne są narzędzia do tworzenia aplikacji w wielu językach programowania. Dotyczy wielu "standardowych" języków programowania takich jak C, C++, Perl czy Python. Dostępne są też kompilatory do nieco mniej znanych języków takich jak SML, Prolog, OCaml jak też eksperymentalne kompilatory: Cyclone, Ksi. Dodatkowo mamy wybór wielu narzędzi programistycznych i bibliotek.

  • maksymalna automatyzacja różnych powtarzalnych czynności (dotyczy to zarówno metodologii bieżącej pracy jak i zawartości pakietów)

  • dystrybucja jest przystosowana do obsługi wielu języków narodowych, a w tym języka polskiego. Jest to najlepiej przygotowana dystrybucja na potrzeby polskich użytkowników

  • brak nałożonych z góry ograniczeń co do zestawu pakietów, jakie mogą być w dystrybucji. W praktyce oznacza to, że użytkownik ma do dyspozycji wszystko, co udało się nam zebrać, Jeżeli coś zostanie opracowane i przystosowane do tego, żeby mogło współgrać z resztą pakietów, to znaczy, że komuś było potrzebne, więc może komuś przydać się w przyszłości

Oficjalne wersje PLD

W PLDwersjom dystrybucji nadawane numery oraz dwuliterowe oznaczenia kodowe, które pochodzą od skrótowych oznaczeń pierwiastków. Pierwszej wersji PLD nadano oznaczenie Ra (Rad), zaś kolejne odpowiadają nazwom pierwiastków poukładanych zgodnie z kolejnością określoną przez ich liczbę atomową. Aktualnie mmy trzy oficjalne wydania: Ra, Ac, Th, jest też nieoficjalny fork Titanium prowadzony przez jednego z deweloperów.

Model rozwoju PLD Linux Distribution

Rozwój PLD Linux Distribution przebiega w sposób otwarty i elastyczny. Efekt końcowy to wynik nakładu wielu osób, nie tylko developerów posiadających prawo zapisu do repozytorium CVS (o którym poniżej), ale także użytkowników zgłaszających informacje o błędach lub nadsyłających poprawki lub propozycje zmian. Z chęcią przyjmiemy nowych developerów, a osoby chcące być bardziej związane z projektem powinny zapisać się na listę dyskusyjną developerów pld-devel-pl@lists.pld-linux.org.

Informacje o PLD i sposobie jego rozwoju:

  • Repozytorium CVS

    Źródła PLD Linux Distribution trzymane są w repozytorium CVS (Concurrent Versions System, http://www.cyclic.com/CVS/index.html), wolnodostępnym systemie kontroli wersji dostarczanym wraz z naszą dystrybucją. Serwer CVS PLD Linux Distribution (http://cvs.pld-linux.org/) jest dostępny 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 doń commitującym (określenie commit pochodzi z podręcznika systemowego cvs).

  • Serwer DistFiles

    W zamierzchłych czasach wszystkie pliki (a więc kody ź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óżnych problemów. A to osoba posiadające stosunkowo wolne łącze zaczęła wrzucać kilkudziesięcio megabajtowy plik, skutecznie blokując możliwość pracy innym developerom na kilka godzin. Uciążliwe były też pozostające tzw. 'locki', czyli blokady na modułach repozytorium (przede wszystkim SOURCES/). Rozwiązaniem tych problemów było wprowadzenie w maju 2003 roku serwera DistFiles, do którego przeniesiono większość plików binarnych z CVS.

  • Core Developers Group

    Gdyby PLD Linux Distribution było firmą, Core Developers Group najtrafniej można by określić jako Radę Nadzorczą. Jej celem jest podejmowanie w sposób demokratyczny krytycznych dla dystrybucji decyzji oraz rozwiązywanie konfliktów, których nie dało się zażegnać w inny sposób. W skład Grupy wchodzą developerzy aktywnie udzielający się w projekcie.

  • Lista dyskusyjna pld-devel-pl@lists.pld-linux.org

    Na liście tej prowadzone są dyskusje na temat bieżących prac nad dystrybucją, jak również ustalane są plany na przyszłość. Jeśli nie posiadasz prawa zapisu do repozytorium, a chciałbyś podzielić się efektami swych prac z innymi, lista ta jest najlepszym miejscem na poinformowanie o tym fakcie.

  • Buildery

    Mianem builderów określane są specjalnie przygotowane środowiska (często na dedykowanych maszynach), na których budowane są pakiety, które później zostaną umieszczone na serwerach FTP projektu. Każda z linii dystrybucji ma swoje oddzielne buildery, stworzone z pakietów dla niej przeznaczonych.

    Nie wszyscy developerzy mają prawo do puszczania zleceń na buildery, czyli rozkazów zbudowania poszczególnych pakietów - przywiliej ten ma ledwie garstka osób, zaznajomionych z automatyką oraz znających potrzeby danej dystrybucji. Rzadko kiedy zachodzi potrzeba bezpośredniego grzebania w strukturze danego środowiska - codzienna praca opiera się na wysyłaniu odpowiednio przygotowanych maili, podpisanych kluczem PGP osoby uprawnionej.

Projekty związane z PLD

  • Rescue CD

    Jest to niewielka dystrybucja startująca z płyty CD, bez konieczności instalacji na twardym dysku. Zawiera zestaw wyspecjalizowanych narzędzi pomocnych w przypadku usuwania awarii systemu. Rescue CD oparto o jądro PLD i wyposażono w zestaw najbardziej niezbędnych programów, dzięki czemu udało się uzyskać niewielkie rozmiary dystrybucji. Pozwala to załadowanie całości do pamięci operacyjnej, a następnie a wyjęcie płyty CD z czytnika. Lista dostępnych programów jest umieszczona na domowej stronie WWW projektu.

  • PLD Live CD http://livecd.pl/

    Pierwszy, oparty o PLD Ac projekt, mający na celu stworzenie kompletnej dystrybucji Linuksa startującej z płyty CD, zawiera znaczną ilość narzędzi i programów użytkowych. PLD Live jest przygotowane dla zwykłych użytkowników chcących bliżej poznać PLD, zawiera system X Window i liczne programy użytkowe. Z założ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 środowiska GNOME

  • PLD-Linux LiveCD http://kde4.livecd.pld-linux.org/index.php

    Wersja Live zbudowana na bazie Titanium i środowiska KDE

Rozdział 2. Zasoby sieciowe PLD

Ważne adresy

Źródła obrazów ISO

Obrazy ISO są katalogowane wg. schematu {$serwer}/{$wersja}/{$arch} np.: ftp.iso.pld-linux.org/2.0/i586. Wersje systemu szerzej opisano w „ Oficjalne wersje PLD ”, zaś architektury w „Architektury pakietów”.

Dla każdego z obrazów ISO dostępna jest suma MD5, umieszczona w pliku o rozszerzeniu md5. Dzięki niej będziemy mogli sprawdzić przed nagraniem czy pobrany obraz nie zawiera żadnych zmian. Do obliczenia skrótów MD5 w pod systemami uniksowymi posłużymy się programem md5sum, zaś w systemach Microsoftu użyjemy dostępnego na serwerze programu md5sum.exe.

Serwery FTP z obrazami ISO:

Serwery z pakietami

Pakiety są katalogowane wg. schematu {$serwer}/dists/{$wersja}/{$źródło}/{$arch} np.: ftp.pld-linux.org/dists/2.0/PLD/i586/. Wersje systemu szerzej opisano w „ Oficjalne wersje PLD ”, źródła w „Źródła pakietów”, zaś architektury w „Architektury pakietów”.

PLD możemy zainstalować z sieci za pomocą protokołu FTP, HTTP lub RSYNC. Pakiety możemy pobierać z głównego serwera PLD lub z jednego z wielu lustrzanych.

FTP - serwer podstawowy

FTP - serwery lustrzane

HTTP - serwer podstawowy

HTTP - serwery lustrzane

RSYNC

Osoby zainteresowane udostępnianiem serwera lustrzanego przy pomocy protokołu RSYNC proszone są o kontakt z nami w celu uzyskania szczegółowych informacji:

Rozdział 3. Historia powstania naszego logo

Wstęp

Pomysł na nasze logo zrodził się w głowie Agnieszki Sloty. Projekt graficzny został stworzony przez Marcina Mierzejewskiego (Kevin) i Maćka Zielińskiego.

Loga duże

  • Może być używane tylko wtedy, gdy:

    • produkt z logiem jest używany zgodnie z udokumentowanymi na www.pld-linux.org zasadami (na przykład oficjalne płyty CD)

    • uzyskają aprobatę PLD Linuksa™ do używania loga w określonych celach

  • Część całkowitego produktu uznana jest oficjalnie za należącą do PLD™ (tak jak jest to opisane w punkcie pierwszym) i jeśli posiada wyraźnie zaznaczone informacje, że tylko ta cześć została zatwierdzona

  • Zastrzegamy sobie prawo do unieważnienia i modyfikacji licencji dla danego produktu

Pozwolenie na używanie oficjalnego loga zostało przyznane dla wszelkiego typu odzieży (t-shirty, czapki, itd) ale pod warunkiem, że są one wykonywane przez developerów PLD™ i nie są sprzedawane dla zysku.

Wyjaśnienie: Licencja "zapożyczona" z Debiana™.

Rysunek 3.1. Logo główne

Logo główne

Rysunek 3.2. Logo główne z cieniowaniem

Logo główne z cieniowaniem

Ikony do umieszczania na stronach WWW

Powered by PLD Linux

To logo i jego zmodyfikowane wersje mogą być zamieszczane dla podkreślenia poparcia dla projektu, lecz nie oznacza ono, że dany produkt jest częścią projektu.

Przypomnienie: docenimy jeśli dodasz do obrazka link wskazujący na www.pld-linux.org i umieścisz go na swojej stronie.

Rysunek 3.3. Ikona na www 1

Ikona na www 1

Rysunek 3.4. Ikona na www 2

Ikona na www 2

Rysunek 3.5. Ikona na www 3

Ikona na www 3

Rysunek 3.6. Ikona na www 4

Ikona na www 4

Rysunek 3.7. Ikona na www 5

Ikona na www 5

Rysunek 3.8. Ikona na www 6

Ikona na www 6

Ikony stworzone przez użytkowników

To logo i jego zmodyfikowane wersje mogą być zamieszczane dla podkreślenia poparcia dla projektu, lecz nie oznacza ono, że dany produkt jest częścią projektu.

Przypomnienie: docenimy jeśli dodasz do obrazka link wskazujący na www.pld-linux.org i umieścisz go na swojej stronie.

Rysunek 3.9. Ikona stworzona przez "muche"

Ikona stworzona przez "muche"

Rysunek 3.10. Ikona stworzona przez Łukasza "Baseciq" Mozera

Ikona stworzona przez Łukasza "Baseciq" Mozera

Galeria rysunków Karola Kreńskiego

Pod tym adresem http://www.inf.sgsp.edu.pl/pub/MALUNKI/PLD/ Karol Kreński "Mimooh" umieścił sporą galerię obrazków związanych z PLD Linux Distribution

Część II. Instalacja

Rozdział 4. Instalacja przy użyciu chroota

Instalacja systemu przy użyciu chroot

Wstęp

Mamy możliwość zainstalowania PLD™ przy użyciu innego systemu operacyjnego, sposób ten ma tę zaletę, że daje nam okazję dobrego poznania PLD już na etapie instalacji, a ponadto umożliwia wykonanie bardziej wyrafinowanych operacji, które są niedostępne z poziomu instalatora. Ta metoda instalacji pozwala zainstalować bardzo małą wersję systemu, (ok. 120MB), która wystarcza do uruchomienia systemu, skonfigurowania sieci, Poldka™ i pobrania kolejnych pakietów.

Do instalacji możemy użyć działającej dystrybucji, jednak najwygodniejsze będzie użycie dystrybucji typu live: RescueCD™ lub PLD-Live™. Użycie systemu z płyty CD ma tą zaletę, że instalacja może być wykonywana na docelowej maszynie, co ułatwi nam stworzenie prawidłowego obrazu initrd. Do instalacji Th należy użyć RescueCD 2.90 lub nowszej (kiedy się pojawią), zaś do instalacji Ac - jednej ze starszych wersji np. 2.01.

Osoby ciekawe jak wygląda przebieg instalacji "na żywo", mogą obejrzeć nagranie przykładowej instalacji.

Uwaga! W niniejszym rozdziale nie zawarto wielu zbyt szczegółowych opisów, dlatego w przypadku drukowania na papierze może być konieczne dodrukowanie innych rozdziałów dokumentacji.

Przygotowanie

Uruchomienie

W przypadku instalacji z działającego systemu musimy podłączyć dysk twardy do komputera i uruchomić go. W przypadku płyty CD typu live - w BIOS-ie maszyny docelowej włączamy opcję startu systemu z płyty, a następnie umieszczamy nośnik w napędzie i czekamy na start systemu.

Współczesne dystrybucje typu live same wykrywają sprzęt i ładują odpowiednie moduły kernela, jeśli jednak to się nie powiedzie to musimy wtedy wykonać tę operację samodzielnie, więcej na ten temat w „Statyczne zarządzanie modułami”. Interesują nas jedynie moduły kontrolera ATA/SATA/SCSI oraz interfejsu sieciowego.

Partycje/woluminy

System możemy zainstalować na klasycznych partycjach dyskowych, woluminach LVM lub programowych macierzach, instalacja z chroot-a daje w tej kwestii dużą swobodę. Opis tworzenia woluminów LVM przedstawiliśmy w „LVM” zaś macierzy w „RAID programowy”. Dla ułatwienia jednak dalsze przykłady będą 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 porządku utworzymy go już na tym etapie. Przykłady będą dotyczyły dysku /dev/sda. Nazewnictwo urządzeń masowych wyczerpująco przedstawiono w „Nazewnictwo urządzeń masowych”.

Na uprzywilejowanej pozycją będą tym razem użytkownicy kompletnych systemów, które umożliwiają użycie programu GParted™ lub QTParted™, w przeciwnym wypadku użyjemy programu fdisk™ lub cfdisk™ np.:

# cfdisk /dev/sda

Podział dysku na partycje szerzej opisano w „Podział na partycje”. Zakładamy, że na pierwszej partycji dysku IDE umieścimy obszar wymiany, zaś na drugiej główny system plików.

Systemy plików

Inicjujemy obszar wymiany:

# mkswap /dev/sda1

Tworzymy system plików (np. ext3):

# mkfs.ext3 /dev/sda2

Powyższe operacje omówiliśmy dokładnie w „Systemy plików”.

Zapamiętujemy układ partycji i systemów plików, gdyż będzie 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/sda2 /pldroot

Jeśli system ma używać większej ilości partycji (np. dla /boot) to montujemy je wszystkie.

Konfiguracja sieci

Założyliśmy, że będziemy instalować pakiety z sieci, dlatego musimy skonfigurować połączenie. W opisach przyjęliśmy, że maszyna jest podłączona do sieci Ethernet.

W przypadku RescueCD system domyślnie próbuje pobrać konfigurację z DHCP, dlatego od razu po uruchomieniu powinniśmy mieć działającą sieć. Jeśli w sieci nie ma takiego serwera to musimy statycznie przydzielić parametry połączenia. Zakładając, że chcemy ustawić adres 192.168.0.2 z maską /24 parametry pliku konfiguracji interfejsu (np.: /etc/sysconfig/interfaces/ifcfg-eth0) powinny mieć następujące wartości:

DEVICE=eth0
IPADDR=192.168.0.2/24
ONBOOT=yes
BOOTPROTO=none

W pliku /etc/sysconfig/static-routes dodajemy trasę 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ę sieci szerzej opisano w „Wstęp”.

Proxy

Jeśli potrzebujemy skorzystać z proxy ustawiamy odpowiednią zmienną środowiskową np.:

# export ftp_proxy=w3cache.dialog.net.pl:8080

Szczegóły konfiguracji proxy odnajdziemy w „Proxy”.

Konfiguracja Poldka

Zaczynamy od ustawienia najlepiej dopasowanej architektury instalowanych pakietów, za pomocą opcji _pld_arch w pliku /etc/poldek/repos.d/pld.conf. Więcej o architekturach pakietów w „Architektury pakietów”. Dobrym pomysłem jest ustawienie opcji, umożliwiającej 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ępnie w konfiguracji Poldka musimy wskazać ten katalog, odszukujemy w pliku /etc/poldek/poldek.conf opcję cachedir, w której definiujemy ścieżkę do katalogu:

cachedir = /pldroot/var/cache/poldek-cache

Instalacja

Instalacja pakietów

Zanim zaczniemy instalować pakiety musimy mieć świadomość, że zachodzi między nimi wiele zależności. Zostaną zainstalowane wszystkie wymagane dodatkowo pakiety, jednak nie mamy wpływu na kolejność instalacji. Zdarza się, że pakiet wymaga pliku lub programu, którego jeszcze nie ma w instalowanym systemie, przez co nie mogą być wykonane pewne operacje poinstalacyjne. Pojawią się nam wtedy na ekranie komunikaty błędów, nie należy się tym martwić, gdyż naprawimy ten problem reinstalując pakiet. Musimy jedynie wywołać instalację z opcją --reinstall

Instalację rozpoczynamy od inicjacji bazy danych pakietów:

# rpm --root /pldroot --initdb

W tej części instalacji zainstalujemy kolejno pakiety: setup, FHS, dev, pwdutils, chkconfig, dhcpcd, poldek, vim (lub inny edytor), geninitrd, module-init-tools, cpio, bootloader lilo lub grub, mount oraz mingetty. Możemy dodatkowo zainstalować wiele innych pakietów, jednak możemy spokojnie to wykonać z działającego już systemu.

Mamy możliwość użycia trybu interaktywnego Poldka:

# poldek --root /pldroot

poldek> install setup FHS dev pwdutils chkconfig dhcpcd poldek vim geninitrd \
module-init-tools cpio grub mount login mingetty

lub wsadowego

# poldek --root /pldroot -i setup FHS dev pwdutils chkconfig \ 
dhcpcd poldek vim geninitrd module-init-tools cpio grub mount login mingetty

Jeśli zdecydowaliśmy sie macierze dyskowe, to powinniśmy zainstalować dodatkowo pakiety: mdadm i mdadm-initrd (jeśli jest na głównym systemie plików). Jeśli używamy woluminów logicznych (LVM) to potrzebujemy pakiety odpowiednio lvm2 i lvm2-initrd.

Przygotowanie do instalacji kernela

Przed instalacją jądra musimy wykonać operacje konieczne do prawidłowego wygenerowania initrd:

  • Montujemy pseudo-system plików /proc:

    # mount /proc /pldroot/proc -o bind

  • Konfigurujemy plik /pldroot/etc/fstab, tak by wpisy odpowiadały wybranemu przez nas układowi partycji i systemów plików. Dla przykładów z początku rozdziału wpisy będą wyglądały następująco.:

    /dev/sda1 swap swap defaults 0 0
    /dev/sda2 /    ext3 defaults 0 0

    Więcej w „Kluczowe pliki”.

  • Dokonać 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 wybrać, który kernel zainstalujemy, na początek powinniśmy się zainteresować pakietami: kernel, kernel-grsecurity i ew. ich odmiany z SMP. W wyborze może pomóc nam opis kerneli w „Jądro systemu”. Kiedy już wybraliśmy, instalujemy wybrany pakiet:

# poldek --root /pldroot -i kernel

Jeśli nie pominęliśmy żadnego kroku, to powinien nam się wygenerować prawidłowy obraz initrd, w przeciwnym wypadku musimy to wykonać samodzielnie wg. opisu zamieszczonego w „Initrd”.

Bootloader

Jeśli wybraliśmy LILO™ jako bootloader to powinniśmy odpowiednio zmodyfikować plik konfiguracji (/pldroot/etc/lilo.conf), w przypadku użytej w przykładach konfiguracji będzie wyglądał on następująco:

boot=/dev/sda
read-only
lba32
prompt
timeout=100

image=/boot/vmlinuz
	label=pld
	root=/dev/sda2
	initrd=/boot/initrd

Kiedy konfiguracja jest skończona wydajemy polecenie:

# chroot /pldroot /sbin/lilo

W przypadku GRUB-a™ plik konfiguracji (/pldroot/boot/grub/menu.lst) powinien wyglądać tak:

timeout 10

title  pld
root (hd0,1)
kernel /boot/vmlinuz boot=/dev/sda
initrd /boot/initrd

Teraz instalujemy bootloader:

# chroot /pldroot /sbin/grub

Kiedy zgłosi się nam powłoka GRUB-a kolejno wydamy następujące polecenia:

grub> root (hd0,1)
grub> setup (hd0)
grub> quit

Konfigurację bootloadera wyczerpująco przedstawiono w „Wstęp”. Jeśli gałąź /boot ma być na macierzy to powinniśmy umieścić bootloader na wszystkich wchodzących w skład tej macierzy dyskach, szczegóły tej operacji przedstawiliśmy w „RAID programowy”.

UDEV

Jeśli chcemy używać systemu urządzeń udev, to jest doskonała okazja żeby go zainstalować. Podstawowe pakiety wymagają urządzeń z pakietu dev, dlatego możemy go zainstalować dopiero teraz:

# poldek --root /pldroot -i udev
# poldek --root /pldroot -e dev

Urządzenia dev oraz udev zostały opisane w „Urządzenia”.

Konta użytkowników

Aby móc się zalogować do nowego systemu musimy nadać hasło dla root-a:

# chroot /pldroot /usr/bin/passwd

Nic nie stoi na przeszkodzie, żeby utworzyć konta użytkowników i skonfigurować uprawnienia. W tym celu posłużymy się narzędziami z pakietu shadow™ lub pwdutils™, zanim to jednak zrobimy musimy ustalić z jakiej powłoki będą korzystać użytkownicy. Domyślnie oba pakiety ustawiają użytkownikom powłokę /bin/bash, dlatego przy tworzeniu kont musimy ustawić ją na /bin/sh, lub zainstalować Basha.

Zakładając, że mamy zainstalowanego Basha dodajemy konto użytkownika następująco:

# chroot /pldroot /usr/sbin/useradd -m jkowalski

# chroot /pldroot /usr/bin/passwd jkowalski

Szczegółowy opis narzędzi z pakietu pwdutils znajdziemy w „Konta użytkowników”.

Operacje końcowe

Przed restartem musimy odmontować systemy plików:

# umount /pldroot/proc
# umount /pldroot

Na koniec wpisujemy polecenie reboot, wyjmujemy płytę z napędu i czekamy aż uruchomi się nowy system.

Rozdział 5. Aktualizacje

Aktualizacja systemu PLD z RA do AC

Aktualizacja z Ra do Ac

Gdy mamy zainstalowane już na dysku PLD 1.x, aby przejść do 2.0 (AC) nie musimy od nowa instalować całego systemu. Możemy posłużyć się skryptem ra2ac. Pakiety z tego skryptu standardowo pobierane są z ftp. Czynnością którą musimy wykonać zanim posłużymy się skryptem to aktualizacja kernela do wersji 2.4.x. Gotowe pakiety możemy pobrać z dwóch źródeł w zależności od architektury.

Cała aktualizacja systemu sprowadzi się do uruchomienia skryptu i ręcznej rekonfiguracji nowych wersji usług.

Należy pamiętać, że AC jest na kernelu 2.6, lub 2.4 do wyboru, w tych kernelach nie ma ipchains-ów, zamiast tego jest narzędzie nazywające się iptables. Pomimo iż służy do tego samego, regułki mają inną składnie. W kernelach 2.4 i 2.6 niektóre moduły urządzeń inaczej się nazywają, więc na to też należy być przygotowanym.

Skrypt jest przeznaczony dla ludzi, którzy wiedzą co robią i mają ogólne pojęcie o linuksie, jeżeli jesteś początkującym użytkownikiem PLD, to lepszą decyzją będzie od nowa zainstalowanie systemu.

Pierwszym krokiem powinno być zrobienie kopii zapasowej plików konfiguracyjnych - najlepiej przekopiować gdzieś cały katalog /etc, jeżeli masz np. postgresa, to ważne jest abyś zrzucił gdzieś bazy. O innych ważnych usługach i zmianach w konfiguracjach powinniśmy poczytać wcześniej. Wiele nowszych pakietów, stare pliki konfiguracyjne przekopiuje do plików z rozszerzeniem *.old

Zainstalowanego na komputerze kde™ lub gnome™ najlepiej jest usunąć (łącznie z katalogami i plikami zaczynającymi się od .kde i .gnome w katalogach domowych użytkowników) - gdyż zmiany są bardzo duże i praca ze starymi ustawieniami powoduje często wadliwą prace. Generalnie ważne jest aby aktualizować jak najmniejszą liczbę pakietów, wtedy wszystko powinno pójść w miarę gładko. Resztę pakietów można później ręcznie doinstalować po aktualizacji.

Teraz pobieramy z cvsu skrypt ra2ac poleceniem:

# cvs -d :pserver:cvs@cvs.pld-linux.org:/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 www

Następnie uruchamiamy ra2ac:

# sh raac-converter/ra2ac

Czekamy aż skończy się instalowanie pakietów, na przewijające się niespełnione zależności i błędy nie zważamy :)

I na samym końcu najbardziej nieprzyjemna część aktualizacji - konfiguracja. Należy teraz większość usług jeszcze raz przekonfigurować, część usług będzie potrzebowała tylko przekopiowania konfigu z Ra, jednak inne (np. exim™, postfix™) wymagają od administratora edycji nowych plików konfiguracyjnych. Ważne jest żeby poczytać w dokumentacji o zmianach w plikach konfiguracyjnych między wersjami które mieliśmy w RA, a wersjami występującymi teraz po skończeniu działania skryptu.

Część III. Podręcznik użytkownika

Rozdział 6. Podstawy

W tym rozdziale znajdziesz podstawowe komendy i czynności, które powinieneś znać.

Wstęp

Dokument, który aktualnie czytasz zawiera minimalny zestaw instrukcji i porad koniecnych do instalacji i zarządzania dystrybucją PLD Linux™. Większość opisywanych mechanizmów i narzędzi ma o wiele większe możliwości, aby je poznać powinniśmy używać podręczników systemowych info™ i man™ (przestarzały). Aby z nich korzystać musisz je zainstalować (o ile nie są już zainstalowane) poleceniami:

poldek -U man
poldek -U info

W skrócie z podręcznika korzystamy następująco:

info {$hasło}

{$hasło} może być nazwą programu, biblioteki, pliku konfiguracyjnego. Dodatkową dokumentację odnajdziemy w katalogu /usr/share/doc, tam też możemy odnaleźć przykładowe pliki konfiguracji, historię zmian programu, licencje i wiele innych informacji.

Jeśli szukasz prostego narzędzia o konkretnych możliwościach możemy przejrzeć dokumentację systemową zestawu coreutils™:

info coreutils

Możesz również szukać pomocy na listach dyskusyjnych, IRC-u, czy forum. Listę tych jak i wielu innych użytecznych adresów odnajdziesz w „Ważne adresy”.

Włączanie i wyłączanie systemu

Tradycyjną metodą wyłączania komputera jest komenda shutdown, np.:

# shutdown -h now

Lub poweroff dająca ten sam efekt.

Użycie komendy halt jest też właściwe.

# halt

Aby zresetować system wpisujemy reboot albo korzystamy z kombinacji klawiszy CTRL+ALT+DEL.

W trakcie pracy możemy dowolnie przełączać się pomiędzy trybami pracy. Służy do tego polecenie init {$nr} ({$nr} to liczba oznaczająca tryb pracy) np.

# init 5

Zmianę poziomu pracy szerzej opisano tutaj: „Zmiana poziomu pracy systemu”

Podstawowe operacje na plikach i katalogach

Zawartość plików wyświetlamy poleceniem cat.

$ cat archiwum

Jeśli chcemy przyjrzeć się plikowi, który nie mieści się na ekranie po wykonania cat możemy uzyskać poleceniem less. Możemy wtedy przeglądać plik używając "strzałek", a kiedy skończymy - naciskamy q.

$ less plik

Komendą touch możemy modyfikować znaczniki czasu pliku, częściej jednak używa się jej do tworzenia pustych plików.

$ touch pusty_plik

Polecenie mkdir tworzy katalog.

$ mkdir archiwum

Za pomocą polecenia rmdir usuwamy puste katalogi.

$ rmdir archiwum

Plik możemy przenieść, albo zmienić jego nazwę, za pomocą 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łuży polecenie cp.

$ cp listing podkatalog/

Kasujemy poleceniem rm.

$ rm plik        	// Kasuje plik.
$ rm *           	// Kasuje wszystkie pliki w danym katalogu.
$ rm * -i        	// Kasuje wszystkie pliki w danym katalogu z potwierdzeniem.
$ rm * -f        	// Kasuje wszystkie pliki w danym katalogu bez pytania.
$ rm -r          	// Kasuje wszystkie pliki, także te w podkatalogach
$ rm -rf /home/  	// Kasuje wszystkie pliki i katalogi w katalogu /home/

Poruszanie się w drzewie katalogów

Do poruszania się w drzewie katalogów w trybie tekstowym można używać programu Midnight Commander™ uruchamianego poleceniem mc, jednak nie każdy go instaluje, więc warto zapoznać się z kilkoma poleceniami przedstawionymi w tym rozdziale.

Do poruszania się w drzewie katalogów używamy polecenia cd ścieżka np.:

$ cd /home/users/zenek/

Ten sam efekt uzyskamy poleceniem

$ cd users/zenek/

wykonanym w katalogu /home

Kilka innych przykładów przedstawiamy poniżej.

W systemach uniksowych wyróżniamy kilka rodzajów specjalnych katalogów. Najważniejszym w całym drzewie jest katalog główny -korzeń (ang. root) oznaczany przez ukośnik: "/"

$ cd /

Często po lewej stronie ścieżki podaje się korzeń aby wskazać położenie katalogu lub pliku bez względu na miejsce z którego wydajemy polecenie np.:

$cd /etc/sysconfig

Polecenie ls powoduje wyświetlenie zawartości katalogu. Należy po nim podać nazwę katalogu, który chcemy zobaczyć, w przeciwnym wypadku wyświetlona zostanie zawartość katalogu bieżącego.

$ls /
bin   dev  home    lib    mnt  proc  sbin     srv  tmp  var
boot  etc  initrd  media  opt  root  selinux  sys  usr
$cd /home
$ls
services  users

Parametr -a powoduje, że funkcja pokazuje również pliki ukryte (zaczynające się od kropki). -R powoduje wylistowanie również podfolderów.

Polecenie pwd powoduje wyświetlenie ścieżki bieżącego katalogu.

$cd users/bart
$pwd
/home/users/bart/

Ważnym katalogiem jest katalog domowy użytkownika - oznaczany znakiem tyldy (~). Każdy użytkownik może używać w ścieżce tego znaku i zawsze będzie oznaczał jego własny katalog domowy np.:

$ ls ~/dokumenty

Kolejnym takim katalogiem jest katalog nadrzędny oznaczany za pomocą dwóch kropek. Będąc w katalogu: /home/users/zenek możemy przejść o jeden poziom do góry używając polecenia

cd ..

Dzięki temu znajdziemy się w katalogu /home/users.

Data i czas

By wyświetlić aktualny czas i datę systemową posługujemy się komendą date:

$ date sob kwi 26 23:48:33 CEST 2003

Oprócz możliwości wyświetlania daty i czasu w niemal dowolnym formacie, pozwoli nam na ustawianie czasu systemowego. Szczegółowy opis programu znajdziemy w podręczniku man.

Czas działania komputera sprawdzamy komendą uptime.

$ uptime
5:27pm  up  6:51,  4 users,  load average: 0.32, 0.08, 0.02

W sytuacji gdy chcemy z zmierzyć czas potrzeby na wykonanie operacji/czynności/procesu to posługujemy się komendą time.

$ 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. Zaletą tego rozwiązania jest możliwość konfigurowania systemu przy pomocy bardzo prostych narzędzi, wadą zaś to że można łatwo popełnić błąd. Dlatego jeśli chcemy tylko przeglądać plik powinniśmy użyć programu less np.:

# less /etc/poldek/poldek.conf

Jeśli jesteśmy pewni że chcemy dokonać zmian, powinniśmy wcześniej wykonać kopię zapasową pliku (pliki kopii zapasowej kończy się tyldą).

# cp /etc/poldek/poldek.conf /etc/poldek/poldek.conf~

Teraz możemy zacząć modyfikować plik, domyślnie instalowanym edytorem plików jest vim, dlatego dobrze jest umieć się nim posługiwać choćby w podstawowym zakresie. Bardzo użyteczną cechą Vima jest kolorowanie składni podstawowych plików konfiguracji (o ile nasz terminal jest kolorowy), dzięki czemu łatwo możemy zauważyć ewentualne błędy.

Aby otworzyć nim plik do edycji wydajemy polecenie

# vim /etc/poldek/poldek.conf

Po otworzeniu pliku jesteśmy w trybie wydawania poleceń, aby przejść do trybu edycji naciskamy klawisz i. Teraz możemy wprowadzać zmiany. Po wykonaniu zmian naciskamy klawisz Esc aby powrócić do trybu wydawania poleceń. Teraz należy opuścić program jednym z poniższych poleceń: :q - wyjście z programu jeśli nie dokonaliśmy żadnych zmian; :wq - wyjście z zapisaniem zmian do pliku; :q! - wyjście z programu bez zapisywania dokonanych zmian.

Początkującym można zaproponować edytor mcedit będący częścią programu mc (Midnight Commander), inne nieco mniej popularne edytory to: emacs, pico, joe

Należy pamiętać o tym, że prawo zapisu plików w katalogu konfiguracji systemu (/etc) ma tylko superużytkownik (root) i z takimi uprawnieniami należy uruchamiać edytor. Pliki konfiguracyjne w linuksie muszą kończyć się znakiem nowej linii, dlatego przed zapisem należy pamiętać o sprawdzeniu czy jest wstawiony. Po raz kolejny swoją przewagę nad innymi edytorami pokazuje Vim, który automatycznie wstawia znak nowej linii.

Podstawowe narzędzia kontroli sieci TCP/IP

Aby używać przedstawionych tu programów, należy mieć uprawnienia superużytkownika lub być zapisanym do odpowiedniej grupy. Listę grup i odpowiadających im uprawnień zamieszczono w „Zarządzanie uprawnieniami”. Bardziej zaawansowane narzędzia sieciowe opisano w „Narzędzia sieciowe”.

Ping

Najczęściej używanym narzędziem diagnostycznym jest program ping™ - pozwala on zbadać istnienie połączenia między dwoma komputerami, drogę pomiędzy nimi, czas potrzebny na przejś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 określania stanu sieci i określonych hostów, śledzenia i usuwania problemów sprzętowych, testowania, mierzenia i zarządzania siecią, oraz do badania sieci. Polecenie ping {$nazwa/$numer_IP} wysyła specjalne pakiety ICMP do wskazanego komputera i czeka na odpowiedź. Możemy podawać 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ę programu przerywamy skrótem ctrl+c

Na powyższym wydruku przedstawiono 3 odpowiedzi na wysłane pakiety. Jeden wiersz oznacza odpowiedź na jeden pakiet, dla każdego z nich podawane są parametry trasy pomiędzy komputerami. Najistotniejszym parametrem jest czas odpowiedzi (time). W przypadku problemów z siecią część pakietów może zostać zagubiona, będzie wskazywane przez specjalny licznik (icmp_seq) oraz przez końcowe statystyki. Brak jakiejkolwiek odpowiedzi można interpretować jako brak połączenia sieciowego z interesującym nas komputerem, blokadę tego typu pakietów na komputerze zdalnym lub zwyczajne wyłączenie maszyny. Na końcu wyświetlane są dodatkowo szczegółowe statystyki. Przy prawidłowym połączeniu czas odpowiedzi dla sieci lokalnej zazwyczaj nie przekracza 1 ms zaś w internecie może sięgnąć nawet kilkuset ms.

Komenda może dać również efekt podobny do poniż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

Może to oznaczać, że w naszej sieci zabronione jest wysyłanie pingów poza LAN.

Traceroute

Nieco bardziej zaawansowanym programem jest traceroute™. Pokazuje on trasę jaką przechodzą pakiety między naszym komputerem, a sprawdzanym przez nas hostem. Wskazuje on czasy przesłania pakietów pomiędzy sąsiadującymi ze sobą routerami (tzw. czasy przeskoków), znajdującymi się na trasie połączenia dwóch maszyn. Pozwala śledzić trasę pakietów oraz wykrywać różnego rodzaje problemy w sieciach np.: błądzenie pakietów w sieci, "wąskie gardła" sieci, oraz awarie połączeń.

$ 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 widać, polecenie to wypisuje linie zawierające TTL, adres bramki oraz czas przebycia każdej z próbek z różnych gatewayów. Jeśli nie było odpowiedzi w ciągu trzech sekund to dla próbki drukowane jest '*'

MTR

Godnym uwagi programem jest MTR™, jest narzędziem łączącym funkcje opisanych wcześniej programów. Program ten śledzi trasę połączenia między dwoma punktami podobnie jak traceroute™ i odświeża wyniki w regularnych odstępach czasu.

$ mtr pld-linux.org

Proxy

Zdarza się, że chcemy lub musimy korzystać z serwera pośredniczącego (proxy), w tym celu trzeba wskazać programowi jego adres i port. Konfiguracja proxy w GNU/Linuksie zależy od programu klienckiego i może być wykonana na jeden z trzech sposobów, oto ich lista:

  • zmienne środowiskowe - z nich korzystają głównie programy działające w trybie znakowym np.: lynx™, wget™, poldek™. Definiujemy je następująco: {$protokół}_proxy np. serwer proxy dla FTP wskazujemy za pomocą zmiennej ftp_proxy zaś dla HTTP za pomocą http_proxy np.:

    export ftp_proxy=w3cache.dialog.net.pl:8080

    Są programy, które akceptują nazwy tych zmiennych napisanych wyłącznie wielkimi literami, tak więc dla wygody i pewności możemy zdefiniować obie wersje. Więcej o zmiennych środowiskowych znajdziemy w „Zmienne środowiskowe”.

  • opcje programu - wiele bardziej rozbudowanych aplikacji używa własnej konfiguracji proxy. Są to przeważnie programy dla środowiska X-Window np.: gFTP™, Firefox™, Opera™.

  • konfiguracja środowiska - programy ściśle związane ze środowiskami graficznymi Gnome™ lub KDE™ używają ustawień tychże środowisk. Do tego typu programów należą np.: Epiphany™, Konqueror™.

Rozdział 7. Zasoby systemu

Tutaj opisano sposób badania zasobów systemu operacyjnego.

Ilość miejsca na dysku

Wiele poleceń zwracających wielkości zajmowanej pamięci obsługuje parametr -h przedstawiający wielkości w jednostkach bardziej wygodnych dla człowieka.

Komenda df służy do pokazania ilości miejsca na zamontowanych partycjach.

$ df -h
System plików        rozm. użyte dost. %uż. zamont. na
/dev/hdc1              36G  5.6G   29G  16% /

Natomiast komendą du można sprawdzać objętość plików oraz całych katalogów. Uruchomienie du -h wyświetli listę plików, katalogów i ich objętości (z bieżącego 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 pomocą opcji -s uzyskamy sumę objętości wszystkich plików

$ du -sh /bin
3,4M    /bin

Procesy i zasoby

Listę wszystkich uruchomionych procesów oraz dotyczące ich dane otrzymamy dzięki poleceniu ps

$ ps aux

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root      1350  0.0  0.1  1788  868 ?        Ss   May27   0:00 syslog-ng
zenek     2252  0.0  1.2 11316 6668 ?        Ss   May27   0:01 xfce4-session
root      2301  0.0  0.3  2748 1556 tty2     Ss   May27   0:00 -bash

Oraz w formie drzewa procesów rodziców i procesów potomnych

$ ps xf

 PID TTY      STAT   TIME COMMAND
2459 ?        S      0:32 xmms
2460 ?        S      0:00  \_ xmms
2461 ?        S      0:00      \_ xmms
2465 ?        S      0:00      \_ xmms
2816 ?        S      0:00      \_ xmms

W przypadku potrzeby ciągłego śledzenia zmian w systemie możemy użyć programu top. Program ten pokazuje najbardziej zasobożerne procesy. Dodatkowo na bieżąco wyświetla całkowite zużycie procesora (CPU), pamięci operacyjnej(Mem) oraz zajętość 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 USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                        
2240 root      15   0 62644  24m  45m S  1.6  4.9   7:37.40 X                                                              
2892 zenek     16   0  1880  928 1672 R  0.6  0.2   0:00.05 top                                                            
2695 zenek     16   0  6532 3824 5056 R  0.3  0.7   0:01.63 xterm                                                          
   1 root      16   0  1532  584 1372 S  0.0  0.1   0:00.82 init                                                           

Informacje o samej pamięci i przestrzeni wymiany uzyskamy dzięki komendzie free

$ free
             total       used       free     shared    buffers     cached
Mem:        516244     445536      70708          0      11880     332728
-/+ buffers/cache:     100928     415316
Swap:      1076312          0    1076312

Całkowita ilość zużytej pamięci (razem z buforami dyskowymi) mieści się w pierwszym wierszu w kolumnie USED. Zaś ilość pamięci zużytej jedynie przez programy mieści się w drugim wierszu w tej samej kolumnie.

Do śledzenia zmian zużycia zasobów systemu w funkcji czasu warto polecić program vmstat z liczbą sekund w parametrze. Podany czas jest odstępem pomiędzy pomiarami, program pokazuje zmiany w wykorzystaniu pamięci, obszaru wymiany, czasu procesora, przerwań czy wielkości transferu do i z urządzeń 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 oznaczeń kolumn odnajdziemy w podręczniku systemowym man/info.

Do procesów których jesteśmy właścicielami możemy wysyłać sygnały (root może wysłać sygnał do każdego procesu). Aby zakończyć jakiś proces należy do procesu wysłać sygnał TERM. Dokonuje się tego poleceniem kill lub killall. Pierwsze zabija proces o podanym numerze PID (unikalnym identyfikatorze procesu) np.:

$ kill 2901

Drugie z poleceń zabija wszystkie procesy, które mają podaną nazwę np.:

$ killall xmms

Sygnał TERM może być nieskuteczny w niektórych wypadkach, wtedy należy użyć bardziej brutalnej metody - sygnału KILL. Możemy go wysłać programem kill lub killall z odpowiednim parametrem: "-9" lub "-KILL":

kill -9 2901

W systemach uniksowych można ustawiać priorytety uruchamianym programom bądź też modyfikować bieżący priorytet działającego procesu. Priorytet jest nazywany jest "liczbą nice". Mówi ona jak mili jesteśmy dla systemu i innych użytkowników. Priorytet możemy ustawiać od -20 do +19, przy czym domyślna wartość zazwyczaj wynosi 0. Ujemne wartości oznaczają wyższy priorytet, zaś dodatnie niższy. Ujemną wartość może nadać tylko superużytkownik.

Aby uruchomić proces z priorytetem innym niż domyślny należy użyć programu nice np.:

$ nice -n +5 mc

Działającym procesom można zmieniać priorytet. Aby to zrobić używamy polecenia renice:

$ renice +5 mc

Jak sprawdzić kto jest zalogowany oprócz nas?

Pierwszą komendą jest who. Podaje ona nam nazwę użytkownika, terminal na którym jest zalogowany oraz czas rozpoczęcia pracy.

$ who
gozda    tty1         Apr 18 10:52
gozda    pts/1        Apr 18 16:21
gozda    pts/4        Apr 18 11:06
gozda    pts/6        Apr 18 14:46
gozda    pts/8        Apr 18 16:25
gozda    pts/9        Apr 18 18:25
gozda    pts/10       Apr 18 18:29

Kolejna komenda w pokazuje nam kto jest zalogowany i co robi na poszczególnych sesjach.

$ w
6:56pm  up  8:05, 7 users,  load average: 1.94, 1.75, 1.61
USER     TTY      FROM  LOGIN@   IDLE   JCPU   PCPU  WHAT
gozda    tty1     -     10:52am  8:03m 16.67s  0.02s  sh /usr/X11R6/bin/startx
gozda    pts/1    -     4:21pm  6:45   5.37s  5.32s  irssi
gozda    pts/4    -     11:06am 37:46   3.22s  3.17s  ekg
gozda    pts/6    -     2:46pm 10:17  12.66s  1.08s  mp3blaster
gozda    pts/9    -     6:25pm  0.00s  0.12s  0.03s  w
gozda    pts/10   -     6:29pm 22:07   3:58   0.02s  ./mozilla-bin

Komenda users. Pokazuje ona pseudonimy użytkowników zalogowanych w systemie.

$ users
gozda gozda gozda gozda gozda gozda gozda

Poleceniem whoami dowiadujemy się, jak nazywa się użytkownik, na którym pracujemy.

$ whoami
gozda

Część IV. Podręcznik administratora

Spis treści

8. Zarządzanie pakietami
Informacje podstawowe
Wstęp
Pakiety w PLD
Menadżery pakietów
Pobieranie pakietów
Cechy pakietów w PLD
Zależności między pakietami
Wymagania (requires) i własności (provides)
Zawartość pakietów
Konwencja nazw pakietów w PLD
Metapakiety
Komunikaty
Wpływ pakietów na pracę systemu
Wpływ pakietów na pliki konfiguracji
Architektury pakietów
Wybór architektury
Procesory
Źródła pakietów
Ścieżki do podstawowych źródeł w konfiguracji Poldka
Cykl życia pakietu
Budowanie pakietów
Wstęp
Budowanie
Zarządzanie
Poldek
Wstęp
Pliki konfiguracji
Konfiguracja pobierania pakietów
Inne opcje
Tryby pracy
Tryb interaktywny
Tryb wsadowy
Pierwsze kroki z Poldkiem
Zarządzanie pakietami
Źródła
Porady
RPM
Instalowanie pakietów
Aktualizowanie pakietów
Odinstalowywanie pakietów
Uwagi
Bezpieczeństwo
Uruchamianie Poldka
Podpisy pakietów
Zaawansowane operacje
Lista ostatnio instalowanych pakietów
Odinstalowanie "opornych" pakietów
Repackage - bezpieczna aktualizacja
Kontrola integralności systemu
Naprawa bazy RPM
Reinstalacja wszystkich pakietów - zmiana architektury
9. Bootloader
Wstęp
Parametry jadra
MBR czy bootsector?
Frame buffer (bufor ramki)
LILO
Konfiguracja podstawowa
Inne systemy operacyjne
Frame Buffer
Graficzne menu
Zakończenie
GRUB
Nazewnictwo urządzeń
Konfiguracja podstawowa
Instalacja
Inne systemy operacyjne
Frame Buffer
Graficzne menu
Bezpieczeństwo bootloadera
Uwagi
rc-boot
Wstęp
Podstawowa konfiguracja
Tworzenie "obrazów"
Uwagi
10. Kernel i urządzenia
Jądro systemu
Koncepcja jądra w PLD
Informacje o używanym jądrze
Rodzaje jąder systemowych
Aktualizacja
Zależności
Uwagi
Parametry jądra
Moduły jądra
Czym są?
Załadowanie właściwego modułu dla urządzenia
Konfiguracja modułów
Statyczne zarządzanie modułami
Określenie modułu dla urządzenia
Zarządzanie modułami
/etc/modules
/etc/modprobe.conf
Udev - dynamiczna obsługa sprzętu
Instalacja
Konfiguracja
Udev w praktyce
Uwagi
Initrd
Wstęp
Przygotowanie
Automatyczne generowanie initrd
Ręczne generowanie initrd
Gdy zawiedzie geninitrd
Bootloader
Uwagi
Urządzenia
Podstawowe informacje o urządzeniu
Systemy plików-urządzeń
UDEV
Jaki system wybrać?
11. Konfiguracja systemu
Podstawowe ustawienia
Konfiguracja skryptów startowych
Opcje związane z jądrem
Opcje uruchamiania systemu
Usługi
Ustawienia konsoli
Internacjonalizacja
Wstęp
Internacjonalizacja konsoli i programów
Myszka pod konsolą
Wstęp
Szeregowa
PS/2, TouchPad, TrackPoint
USB
Zakończenie
Porady
Strefa czasowa
Zegar
Zmienne środowiskowe
Przeglądanie
Konfiguracja globalna
Konfiguracja lokalna
PLDconf - Narzędzie do konfiguracji systemu
Kluczowe pliki
/etc/inittab
/etc/fstab
/etc/passwd
/etc/shadow
/etc/group
/etc/shells
/etc/motd
/etc/nologin
12. Pamięci masowe
Wstęp
Nazewnictwo urządzeń masowych
Numerowanie partycji
Urządenia ATA (IDE)
Urządenia SCSI/SATA/USB Storage
Dyskietki elastyczne
LVM
RAID programowy
Urządzenia w GRUB-ie
Podział na partycje
Partycje
Zanim zaczniemy
Wymagane miejsce na system
Plan podziału dysku
Programy do zarządzania partycjami
Podział
Zakończenie
Systemy plików
Wybór systemu plików
Tworzenie systemu plików
Tworzenie obszaru wymiany
Podmontowanie partycji / aktywacja swapu
Poznanie typu systemu plików
Formatowanie
RAID programowy
Instalacja
Planowanie macierzy
Tworzenie macierzy RAID
Konfiguracja
Initrd
Bootloader
Diagnostyka
Porady
Dodatki
LVM
Planowanie woluminów
Instalacja
Budowanie woluminów
Konfiguracja startowa
Narzędzia diagnostyczne
Zarządzanie: powiększanie woluminu
Porady
Naprawa
Uszkodzenia fizyczne
Naprawa systemu plików
13. Administracja
Ratowanie systemu
Wstęp
Uruchomienie na niskim poziomie pracy
Uruchomienie RescueCD
Naprawa systemu plików
Naprawa konfiguracji
Operacja chroota
Uwagi
Zarządzanie podsystemami i usługami
Budowa systemu rc-skryptów
Zarzadzanie podsystememi/usługami
Konfiguracja rc-skryptów
Zależności
Usługi a poziomy pracy
Zmiana poziomu pracy systemu
Konta użytkowników
Dodanie
Usunięcie
Modyfikacja
Hasło
Zarządzanie kontami
Grupy
Dodanie grupy
Zapisanie do grup
Usunięcie grupy
Uwagi
Zarządzanie uprawnieniami
Bezpieczeństwo
Dostępne narzędzia
Dostęp do konta root
SUID
/proc
chroot i vserver
Statyczny VIM
Pakiety
14. Interfejsy sieciowe
Wstęp
Podstawowa konfiguracja sieci
Brama domyślna
Odwzorowanie nazw - serwery DNS
Nazwa hosta
Odwzorowanie nazw - konfiguracja zaawansowana
Inne opcje
Ethernet
Urządzenie
Statyczna konfiguracja karty sieciowej
Dynamiczna konfiguracja karty sieciowej (DHCP)
Aktywacja sieci
WiFi
Wstęp
Sterowniki dedykowane
Sterowniki z NdisWrapperem
Sieć WEP
Sieć WPA2-PSK
Aktywacja i diagnostyka
Neostrada+ z modemem USB firmy Sagem
Wprowadzenie
Instalacja
Konfiguracja
Uruchomienie i post konfiguracja
Neostrada+ z modemem USB firmy Alcatel - Thompson
Przygotowanie do instalacji
Konfiguracja
Uruchomienie i zakończenie
xDSL z interfejsem Ethernet
Wprowadzenie
Konfiguracja
Uwagi
Zaawansowane opcje interfejsów
HotPlug
Narzędzia
Inne opcje
Wzory konfiguracji
15. Zastosowania sieciowe
Routing statyczny
Wstępna konfiguracja
Tablica routingu
Zarządzanie trasami
Zakończenie
NAT
DNAT
SNAT i MASQUERADE
Zakończenie.
Podział łącza w zależności od serwisów
Wstęp
Podstawy
Przekierowanie p2p i połączeń podobnych
PPP over SSH - Tunel IPv4
Wstęp
Konfiguracja
Uruchomienie
VTun - Tunel IPv4
Wstęp
Konfiguracja
Uruchomienie
Narzędzia sieciowe
Konfiguracja interfejsow
Zarządzanie interfejsami
Adresy sprzętowe (MAC)
ARP
Serwery nazw (DNS)
Wydajność sieci
Monitorowanie sieci
Zakończenie
16. Usługi dostępne w PLD
Usługi - wstęp
ALSA - Dźwięk w Linuksie
Instalacja
Konfiguracja z użyciem systemu UDEV
Konfiguracja statyczna
Ustawienie miksera i testowanie
Zaawansowana obsługa miksera
Uwagi
Apache - Serwer stron internetowych
Wstęp
Instalacja
Pliki konfiguracji
Podstawowa konfiguracja
Strony użytkowników
Virtual Hosts
Ograniczanie dostępu na podstawie adresu
Ograniczenie dostępu za pomocą loginu i hasła
Obsługa skryptów PHP
CGI
Security Socket Layer (SSL)
Indeksowana zawartość katalogu
Uwagi
BIND - Serwer Nazw
DNS - Domain Name System
Wstęp
Podstawowa konfiguracja
Przykładowa konfiguracja strefy typu primary
Przykładowa konfiguracja strefy typu secondary
Obsługa protokołu IPv6
Rejestracja
Diagnostyka
Zakończenie
CRON - Cykliczne wykonywanie zadań
Instalacja
Budowa tabel
Format daty i czasu
Tabele systemowe
Tabele użytkowników
Komunikaty cron-a
CUPS - Popularny system druku dla Uniksa
Wstęp
Instalacja
Zarządzanie drukarkami
Dodanie drukarki
Szczegóły dodawania drukarki lokalnej
Szczegóły dodawania drukarki zdalnej
Konfiguracja serwera
Zarządzanie kolejką druku
Test drukarki i rozwiązywanie problemów
DHCPD - Dynamic Host Configuration Protocol Daemon
Instalacja
Podstawowa konfiguracja
Statyczne przypisanie konfiguracji
Inne opcje
Uruchomienie
Konfiguracja klienta
Uwagi
Exim - Transport poczty elektronicznej (MTA)
Instalacja
Budowa pliku konfiguracji
Podstawowa konfiguracja
Skrzynki pocztowe
Różne opcje
Autoryzacja SMTP
Syfrowanie SSL
Quota
Dodanie skanerów antywirusowych
Walka ze spamem
Obsługa wielu domen w Eximie
Automatyczna odpowiedź - Vacations
Heimdal - Implementacja protokołu Kerberos
Instalacja i konfiguracja KDC
Logowanie do systemu
Konfiguracja poszczególnych usług
Jabber 2 - Serwer typu Instant Messaging
Wstęp
Instalacja
Konfiguracja DNS i rekordów SRV
Konfiguracja portów (jeżeli korzystamy z firewall-a)
Podstawowa konfiguracja Jabberd2
Konfiguracja dla SQL (Postgresql)
Szyfrowanie
Zakończenie
MySQL - System Zarządzania Relacyjnymi Bazami Danych (ang. RDBMS)
Co to jest MySQL?
Ogólne cechy MySQL
Instalacja
Konfiguracja MySQL
Demon MySQL
mysqladmin
mysqldump
phpMyAdmin
NFS - Network File System
Serwer
Udostępnianie
Klient
Bezpieczeństwo serwera
Dostrajanie wydajności
PDNS (Power DNS) - Serwer Nazw
Wstęp
Instalacja
Konfiguracja Postgresql dla PDNS
Konfiguracja PDNS
Domeny
Postfix - Transport poczty elektronicznej (MTA)
Zaczynamy
Konfiguracja
Szyfrowanie
Domeny
Usprawnienia
Końcowa konfiguracja
tpop3d
amavis + mks
postifx.admin
PostgreSQL - Baza danych SQL
Co to jest PostgreSQL
Instalacja pakietów
Konfiguracja PostgreSQLa w PLD
Inicjalizacja
Konfiguracja PostgreSQLa
Uruchomienie PostgreSQLa
Dodanie użytkownika
Ostatni test
Dodatki
Odnośniki
ProFTPD - serwer FTP
Wstęp
Instalacja
Podstawowa konfiguracja demona
Konfiguracja dostępu
Zakończenie
Samba - współpraca z Windows
Samba jako Serwer domeny NT4 (PDC)
Serwer członkowski domeny NT4
Snort - Sieciowy System Wykrywania Włamań
Wymagania
Instalacja Snorta i ACID
Konfiguracja Snorta
Aktualizacja reguł
Instalacja Oinkmaster
Architektura Snorta
Tryby pracy
Preprocesory
Moduł sygnatur
Ciekawe projekty
Syslog-ng
Wstęp
Konfiguracja
Test konfiguracji
Uwagi
Dodatek
17. X-Window
Wstęp
X-Server
Instalacja
Zanim zaczniemy konfigurację
Pierwsze uruchomienie
Konfiguracja
Inne sposoby konfiguracji
Rozwiązywanie problemów
Środowisko graficzne (GUI)
Zaawansowane
Mysz
Klawiatura
Monitor
Rozdzielczość obrazu
Zaawansowane - DPI
Zaawansowane - serwer czionek
Uwagi
Środowisko GNOME
Instalacja
Internacjonalizacja
Dźwięk
Uruchomienie
Administracja - GNOME System Tools
Przydatne drobiazgi
Godne polecenia aplikacje
Pomoc i rozwiązywanie problemów
Środowisko KDE
Blackbox - Szybki i lekki zarządca okien
Wstęp
Instalacja pakietów
Konfiguracja
Fluxbox - Następca BlackBoxa
Wstęp
Instalacja pakietów
Konfiguracja
Uruchamianie środowiska graficznego
Skrypt startx
GDM
KDM
Ustawienie poziomu pracy
Porady
Karty firmy nVidia
Karty firmy ATI
Instalacja i konfiguracja
Test konfiguracji

Rozdział 8. Zarządzanie pakietami

Ten rozdział opisuje metody zarządzania pakietami w systemie PLD.

Informacje podstawowe

Wstęp

Instalowanie, deinstalowanie oraz aktualizowanie składników systemu operacyjnego to jedne z najważniejszych zadań administratora. Zautomatyzowanie tych procesów pozwala na znaczne przyspieszenie i ułatwienie zarządzania systemem.

W świecie Otwartego Oprogramowania pomiędzy programami istnieją liczne powiązania, które w efekcie wymuszają konieczność instalacji dodatkowych programów i/lub bibliotek. Pominięcie tych zależności spowoduje problemy z działaniem programu lub całkowity jego brak. Śledzenie tych zależności może przyprawić o ból głowy większość administratorów. Na szczęście istnieją mechanizmy i narzędzia, które pomagają znacznie zautomatyzować ten proces.

Pakiety w PLD

Elementy systemu operacyjnego dostępne są 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 możliwość instalacji pakietów RPM przygotowanych dla innych dystrybucji, jednak nie skorzystamy wtedy z dobrodziejstwa zależności dotyczących danego pakietu. Wymagane dodatkowe pakiety należy wtedy zainstalować samodzielnie.

Menadżery pakietów

Do zarządzania pakietami (instalacja, deinstalacja, uzyskiwanie informacji) używa się specjalnych programów zwanych menadżerami pakietów:

  • Poldek

    Poldek to domyślny menadżer pakietów dla PLD. Jest nakładką na RPM-a o ogromnych możliwościach, pozwalającym na znaczną automatyzację procesu zarządzania dużymi ilościami pakietów. Jest "wołem roboczym" odciążającym administratora w jego żmudnym zajęciu. Konfigurację i opis Poldka przedstawiono w „Poldek”.

  • PackageKit

    Prosty zarządca pakietów, dla środowiska X-Window. Został stworzony pierwotnie dla Gnome, ma także wersję dla Qt. Jest to wygodne narzędzie, dobrze sprawujące się przy zrządzaniu niewielkimi ilościami pakietów. PackageKit wyświetla na tacce systemowej dostępność aktualizacji. PackageKit jest świetnym wyborem dla zupełnie niezaawansowanych użytkowników.

  • RPM

    Niskopoziomowy zarzdca pakietów, używany zwykle w nietypowych i awaryjnych sytuacjach. Opis posługiwania się tym programem zamieszczono w „RPM”.

Pobieranie pakietów

Jedną z najczęściej używanych form instalacji jest instalacja z sieci, dlatego jeśli nie zostanie podane inaczej to właśnie taka instalacja jest traktowana jako domyślna. Używamy tej metody nawet jeśli system był instalowany z lokalnego źródła (np. z dysku), choćby w celu aktualizacji systemu.

Menadżery pakietów są wstępnie skonfigurowane, Aby jednak instalować niestandardowe pakiety lub użyć innego źródła, musimy podać odpowiednie parametry. Konfiguracja w tym zakresie jest opisana w „Serwery z pakietami”.

Cechy pakietów w PLD

Zależności między pakietami

Istotną cechą pakietów RPM jest mechanizm tzw. zależności, dzięki nim w trakcie instalacji pakietu instalowane są automatycznie dodatkowe wymagane pakiety. Niekiedy w ramach zależności wymagana jest funkcjonalność dostarczana przez więcej niż jeden pakiet. W takim wypadku zostaniemy zapytani o to który pakiet ma być zainstalowany. Wynika to z filozofii PLD, która dopuszcza bogaty wybór oprogramowania spełniającego tą samą rolę.

Istnieją zależności wymagające wzajemnego wykluczania się pakietów, tak aby w systemie była zainstalowany był tylko jeden program z pośród kilku dostępnych. Jako przykład można wskazać serwery usług tego samego rodzaju lub pakiety zawierające w nazwie słowa "inetd" oraz "standalone".

Dodatkowo system pakietów pilnuje, aby nie można było mieć zainstalowanych dwóch wersji tego samego pakietu. Próba instalacji pakietu starszego niż ten, który mamy w systemie zakończy się niepowodzeniem, zaś przy instalacji nowszego nastąpi jego aktualizacja.

Menadżery pakietów pozwalają na ignorowanie powyższych zależności, jest to jednak operacja nie zalecana, gdyż powoduje później trudny do ogarnięcia bałagan. Wyjątki od tej zasady powinny być robione jedynie w razie uzasadnionej konieczności, takim przypadkiem jest np. aktualizacja kernela, operacja ta została opisana w „Jądro systemu”.

Dawniej zależności były budowane na podstawie nazw pakietów, w tej chwili stopniowo wprowadzane są zależności na podstawie plików (programów, bibliotek itd.). Zyskujemy w ten sposób elastyczność kosztem wygody w niektórych, rzadko spotykanych sytuacjach. W przypadku codziennej pracy z pakietami, nie odczujemy większych różnic i nie musimy się tym martwić.

Wymagania (requires) i własności (provides)

Ważnymi elementami mechanizmu zależności są tzw. wymagania i własności. Pierwsza z cech wskazuje listę wymaganych dodatkowo elementów (pakietów, plików) do działania instalowanej aplikacji, druga zaś informuje, które z elementów są dostarczane wraz z pakietem. Aby poznać wymagania pakietu posłużymy się 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
RPMReqs:        rpmlib(CompressedFileNames) <= 3.0.4-1,
    rpmlib(PayloadFilesHavePrefix) <= 4.0-1,
    rpmlib(PayloadIsBzip2) <= 3.0.5-1

Powyższe polecenie ma zadanie czysto informacyjne, gdyż jak już wspomniano zależnościami zajmie sie menedżer pakietów.

Sprawa nieco komplikuje się w przypadku własności, ponieważ w PLD nierzadko mamy dostępnych wiele pakietów spełniających podobne wymagania. Aby sprawdzić dostarczaną funkcjonalność ponownie uż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)

Analizując powyższe przykłady można dopatrzyć się informacji o dostarczaniu własności crondaemon przez vixie-cron, która z kolei jest wymagana przez logrotate.

Własność crondaemon jest dostarczana przez większą ilość pakietów, możemy samodzielnie wybierać, który z pakietów ma być instalowany lub ustawić automatyczny wybór. O tym decyduje ustawienie opcji choose equivalents manually w konfiguracji Poldka. Jeśli ustawimy opcję na yes (zalecane) to instalacja programu może wyglądać następująco:

poldek:/all-avail> install logrotate
Przetwarzanie zależności...
Więcej niż jeden pakiet udostępnia właściwość "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 powyższym przykładzie widać listę pakietów mogących pełnić funkcję demona zegarowego (crondaemon), dodatkowo podana jest domyślna wartość wyboru, nie zawsze jest to najlepszy wybór dla konkretnej instalacji, dlatego powinniśmy się upewnić, że wybieramy najwłaściwszy pakiet. Więcej informacji o obsłudze i konfiguracji Poldka odnajdziemy w „Poldek”.

Zawartość pakietów

Pakiety mogą zawierać wiele małych programów i/lub bibliotek albo jeden duży program może być podzielony na kilka pakietów. W PLD najczęściej stosowane jest to drugie rozwiązanie: osobno przechowywane są pliki uruchomieniowe, osobno biblioteki, a jeszcze osobno moduły, wtyczki i dodatki. Ponadto jeśli tylko można to są umieszczane w pojedynczych pakietach, dzięki temu unikamy dużych, zbiorczych paczek. Pozwala to instalować tylko to co jest nam potrzebne. Przykładowo jeś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ędzać miejsce na dysku.

Nierzadko do osobnych pakietów trafiają elementy aplikacji, które zostały przewidziane przez jej twórców jako kompletna instalacja. Nie należy się tego obawiać, gdyż mechanizm zależności wymusi instalację wszystkich wymaganych dodatkowo pakietów.

Tak silne rozdrobnienie powoduje czasami, że do przy instalacji mechanizm zależności zaznacza sporą ilość dodatkowych pakietów. Potrafi to wprowadzić w konsternację, jednak nie należy się tego obawiać, gdyż są to zazwyczaj małe pakiety i po zainstalowaniu zajmują tyle samo lub mniej niż domyślna instalacja.

Aby ułatwić poruszanie się w tym gąszczu, możemy posłużyć się 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 znamy nazwę pliku, ale nie wiemy w jakim pakiecie się znajduje. Do odnalezienia pakietu posłużymy się poleceniem:

poldek:/all-avail> search -f */sendmail

Dodatkowo możemy korzystać z zamieszczonej dalej tabeli.

Konwencja nazw pakietów w PLD

Nazwy pakietów mają następującą budowę: {$nazwa}-{$wersja}.{$arch}.rpm np.: 0verkill-0.16-3.i686.rpm. Tak wyglądają nazwy pakietów w systemie plików lub na serwerze FTP. W menedżerach pakietów posługujemy się jedynie nazwą lub nazwą i wersją (nie licząc instalacji za pomocą rpm-a).

Tabela 8.1. Opis zawartości pakietów w zależności od ich nazwy

Nazwa pakietuZawartość
program, program-coregłówny pakiet programu, zawiera pliki wykonywalne, dokumentację, skrypty startowe w przypadku usług, niekiedy biblioteki
program-commonpodstawowe, wspólne pliki; zwykle samodzielny taki pakiet jest bezużyteczny i wymaga zainstalowania dodatkowych pakietów
program-libszestaw bibliotek stworzonych na potrzeby danego programu, są niekiedy wymagane przez inne programy
program-tools, program-utils, program-progs dodatkowe narzędzia, zwykle nie są konieczne do podstawowej pracy programu
program-extras dodatkowe, rzadziej używane elementy
program-mod, program-plugin, program-applets, program-addon różnej maści moduły, "wtyczki", applety i dodatki przeważnie nie są konieczne do podstawowej pracy programu
program-skin(s), program-theme(s) "skórki" i "tematy" modyfikujące wygląd programu
program-driversterowniki
program-backend specjalne interfejsy służące do rozszerzania możliwości programu, łączenia z innymi programami, sprzętem itp.
program-i18ndodatkowe wersje językowe
program-docdokumentacja programu
program-develpakiety potrzebne dla programistów i osób które zajmują się własnoręczną kompilacją programów, bądź budowaniem pakietów.
program-staticprogram skompilowany statycznie - nie wymaga bibliotek
program-debuginfo informacje dla debuggera - pliki użyteczne tylko dla osób badających problemy z działaniem programu
lib_nazwa_bibliotekizestaw uniwersalnych bibliotek, nie związanych z żadnym konkretnym programem.
usługa-inetd, usługa-standalone alternatywne pakiety służące do wyboru trybu pracy niektórych usług. Należy wybrać jeden z nich: uruchamianie przez Inetd™ lub praca w tle (standalone). Pakiety te wzajemnie się wykluczają na poziomie mechanizmu zależności.
usługa-initskrypty startowe programu
metapackage-programmetapakiet
program-legacystarsze wersje programów lub sterowniki do starszych urządzeń
kernelpakiety okołokernelowe, zostały omówione w „Jądro systemu”

Metapakiety

Wadą silnego rozdrobnienia pakietów jest pracochłonne zarządzanie, aby temu zaradzić stworzono tzw. metapakiety, zwane również pakietami wirtualnymi. Są to pakiety zawierający jedynie wymagania (requires), nie zawierają żadnych plików, ani własności (provides). Ich zadaniem jest zautomatyzowana instalacja większych grup pakietów oraz utrzymanie wstecznej zgodności w nazwach.

Część metapakietów łatwo odnajdziemy dzięki nazwie, która zawiera słowo metapackage, np. metapackage-gnome. Aby poznać listę wymagań takiego pakietu, użyjemy opisanego nieco wcześniej polecenia desc -r trybu interaktywnego Poldka.

Komunikaty

Prace przy zarządzaniu pakietami niekiedy kończą się komunikatami skierowanymi do administratora, są to dość ważne informacje, dlatego powinniśmy je uważnie czytać. Zazwyczaj dotyczą plików konfiguracji, zarządzania użytkownikami/grupami, modyfikacji systemu rc-skryptów oraz zalecenia dalszego postępowania po instalacji pakietu. Dla przykładu poniżej przedstawiono komunikaty wyś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.

Wpływ pakietów na pracę systemu

Pakiety, oprócz plików programu, zawierają dokumentację, przykładowe pliki konfiguracji, strony podręcznika systemowego (man, info) oraz automatykę. Owa automatyka jest uruchamiana w trakcie instalowania bądź odinstalowania pakietu i wykonuje konieczne prace w systemie, dzięki czemu zmniejsza się nakład pracy administratora do absolutnego minimum. Jest tak skonstruowana, aby nie zaskakiwać administratora w najmniej oczekiwanych momentach oraz zapewnić nieprzerwanie działanie systemu, poniżej przedstawiono kilka przykładów jej działania.

Jeśli instalujemy w systemie jakąś usługę to zostanie zapisana odpowiednia informacja do skryptów startowych i nowe oprogramowanie uruchomi się przy najbliższej zmianie trybu pracy lub restarcie systemu. Jeżeli jakaś usługa jest wyłączona z działania i nastąpi jej aktualizacja, to w dalszym ciągu nie będzie uruchamiana.

Jeśli działa usługa, a my ją zaktualizujemy lub doinstalujemy dodatkowy moduł, to zostanie ona automatycznie zrestartowana lub taka operacja zostanie zasugerowana przez pakiet. Będzie to zależało od ustawienia opcji RPM_SKIP_AUTO_RESTART w konfiguracji rc-skryptu lub globalnie w /etc/sysconfig/rpm - opcja przyjmuje wartość yes/no. Konfigurację rc-skryptów dokładniej omówiono w „Zarządzanie podsystemami i usługami”.

Wpływ pakietów na pliki konfiguracji

Po aktualizacji pakietu nie są naruszanie istniejące pliki konfiguracji, nowe wersje tych plików są zapisywane z rozszerzeniem ".rpmnew". Przykładowo po zaktualizowaniu pakietu sudo™ obok pliku /etc/sudoers pojawi się nowy plik o nazwie /etc/sudoers.rpmnew, tak więc zaktualizowany program będzie używał starego pliku konfiguracji. W większości wypadków nie będzie to stanowić problemu, jednak dla pewności należy skonfigurować plik dostarczony z nowszym pakietem na wzór poprzedniej konfiguracji i zmienić mu nazwę poprzez usunięcie omawianego rozszerzenia. Jest to pierwsza rzecz, którą należy sprawdzić w razie problemów z działaniem programu po aktualizacji.

Kiedy odnajdziemy plik *rpmnew to możemy łatwo sprawdzić czym różni się jego zawartość w stosunku do obecnie używanego pliku konfiguracji. Posłużymy się 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 są jego pliki konfiguracji, posiadają one rozszerzenie ".rpmsave", możemy je zachować lub skasować jeśli uznamy że są nam zbędne.

Osoby chcące trzymać porządek w systemie powinny zajmować się plikami .rpmnew i .rpmsave od razu po pracy z menadżerem pakietów. Pliki łatwo odnajdziemy, gdyż występują zwykle w katalogu /etc, odszukamy je następująco:

$ find /etc -name "*rpmnew"
$ find /etc -name "*rpmsave"

Architektury pakietów

W PLD programy są kompilowane dla wielu architektur sprzętowych, pozwala to na używanie systemu na bardziej różnorodnym sprzęcie oraz na lepsze dopasowanie do używanego procesora. Architekturę pakietu rozpoznamy po nazwie, jest to kilkuznakowe oznaczenie znajdujące się tuż przed rozszerzeniem pliku. W przypadku pakietu 0verkill-0.16-3.i686.rpm jego architektura to i686.

Aby sprawdzić architekturę komputera, używamy polecenia arch lub uname -m.

Wybór architektury

Pakiety zbudowane dla poszczególnych architektur są umieszczane w odpowiednich katalogach na serwerze. Ścieżka katalogów na serwerze wygląda następująco:

/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 wybraną architekturą "i686". Poldek instaluje pakiety z tej architektury, do której należał pakiet z Poldkiem, co w zasadzie jest jednoznaczne z architekturą, która została wybrana przy instalacji. Konfiguracja źródeł pakietów w Poldku została opisana w „Poldek”.

Procesory

Tabela 8.2. Lista nazw kodowych architektur i odpowiadających im rodzin procesorów:

Nazwa architekturyObsługiwana platformaDostępna wersja PLD
alphaDEC/Compaq/HP Alpha AXPRa, Ac
amd64 / x86_64AMD K8: Opteron, Athlon 64, Sempron (socket: 754, 939), Intel EM64TAc, Th
athlonAMD K7: Athlon, Duron, Sempron (socket A)Ac
i386wszystkie procesory zgodne z i386 firmy IntelRa, Ac
i486Intel 486, AMD K5 (socket 3) i nowszeTh
i586Intel 586 Pentium, Cyrix 5x86, Cyrix 6x86, AMD K5 (socket 7), AMD K6 i nowszeRa, Ac
i686Intel Pentrium II, Pentium PRO, AMD K7 i nowszeRa, Ac, Th
ppcPowerPCRa, Ac
sparcSun SPARC 32bitRa, Ac
sparc64Sun SPARC 64bitAc
noarchdowolna-


Należy pamiętać by instalować pakiety wyłącznie przeznaczone dla używanej architektury. Wyjątkiem są pakiety z oznaczeniem noarch oraz pakiety przeznaczone dla procesorów Intel x86 i zgodnych: i386, i486, itd.

Architektury z rodziny x86 są bardziej lub mniej wyspecjalizowanymi grupami, najbardziej ogólna jest 386, zaś każda następna w kolejności jest bardziej wyspecjalizowana. Im węższa specjalizacja grupy tym mniej modeli procesorów obsługuje. Przykładowo na maszynie z procesorem Pentium III™ (i686) możemy zainstalować system w wersji i386, ale na procesorze 386™ wersja i686 nie będzie działać. Jeśli mamy nowszy procesor, to będziemy mogli użyć bardziej wyspecjalizowanej architektury, a co za tym idzie lepiej wykorzystać jego potencjał.

Źródła pakietów

W PLD jest kilka grup pakietów (źródeł) w ramach tej samej wersji dystrybucji, różnią się one wersjami pakietów i zastosowaniem. Ich listę uzyskamy za pomocą Poldka:

$ poldek -l

W większości wypadków, będziemy korzystać z głównego źródła (main), jednak od czasu do czasu potrzeba zaktualizować system lub pobrać niestandardowe wersje pakietów, właśnie wtedy z nich skorzystamy. Źródła są oznaczane za pomocą etykiet:

  • main (np. th): główne źródło pakietów (domyślne), zawiera stabilne wersje, od chwili wydania danej wersji dystrybucji, nie są tu dokonywane żadne zmiany

  • obsolete (np. th-obsolete): stare pakiety, usunięte z main w wyniku aktualizacji. Dzięki temu źródłu, możemy wrócić do starszej wersji pakietu, jeśli zajdzie taka konieczność. Źródło wprowadzone w Th.

  • test (np. th-test): trafiają tu pakiety prostu z builderów, bez sprawdzenia czy w ogóle działają i czy są spełnione zależności. Używanie pakietów z tego źródła jest dosyć ryzykownym krokiem, dlatego należy go wykonywać wyłącznie w ostateczności

  • ready (np. th-ready): następny krok w życiu pakietu, jeśli pakiety działają bez zarzutu, to są przenoszone razem z zależnościami do main. Pakiety te są już wstępnie przetestowane, nadal jednak powinniśmy zachować ostrożność instalując pakiety z tego katalogu

  • debuginfo (np. th-debuginfo, th-ready-debuginfo): pakiety zawierające wyłącznie symbole potrzebne przy debugowaniu. Pakiety te są pomocne dla programistów i deweloperów.

  • home: źródło lokalne, pozwala łatwo instalować pakiety z katalogu ~/rpm/RPMS - miejsca domyślnego umieszczania własnoręcznie zbudowanych pakietów.

Multilib

W środowisku x86_64 możemy używać także aplikacji 32 bitowych, aby wygodnie instalować pakiety zostały przygotowane źródła multilib /etc/poldek/repos.d/pld-multilib.conf. Domyślnie są przygotowane dla i686.

Źródła używane w starszych wersjach PLD:

  • updates (np. ac-updates) - aktualizacje, zaleca się regularne sprawdzanie czy nie pojawiają się tu nowe pakiety, źródło stało się zbędne w Th i nie jest używane. W Th w roli updates używa się źródła ready. W Ra™ istniały dwa niezależne źródła pakietów z aktualizacjami: {$wersja}-updates-security i {$wersja}-updates-general. W Ac™ nastąpiło ich połączenie i od tej pory źródło nazywa się {$wersja}-updates.

  • supported (np. ac-updates) - nietypowe pakiety, które nie powinny być trzymane w głównym źródle. Są tu umieszczane pakiety rzadko używane lub starsze wersje, podobnie jak updates przestało mieć rację bytu w Th.

Aby wybrać źródło inne niż domyślne należy użyć parametru -n np.:

$ poldek -n th -n th-ready

Należy pamiętać, że użycie każdego źródła będzie możliwe dopiero po pobraniu aktualnych indeksów:

$ poldek -n debuginfo --up

Ścieżki do podstawowych źródeł w konfiguracji Poldka

Poldek jest dostarczany z właściwie skonfigurowanymi etykietami, są one zdefiniowane w plikach /etc/poldek/source.conf i /etc/poldek/repos.d/pld.conf. Adresy oficjalnych serwerów i mirrorów znajdziemy w „Serwery z pakietami”. Etykieta źródła rozpoczyna się od przedrostka określającego wersję dystrybucji, zapisaną małymi literami, poniżej przedstawiono ją jako ciąg {$wersja}, który może mieć wartość np. ra, ac lub th. Ciąg {$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 życia pakietu

Zbudowany pakiet trafia do test gdzie oczekuje na zbudowanie zależności, następnie jest przenoszony przez RM-a do ready. kiedy wszytko jest w porządku trafia w końcu do main/updates. W przypadku bardziej krytycznych pakietów kiedy pojawia się aktualizacja to starsza wersja trafia do obsolete. Proces ten został szerzej opisany w podręczniku dewelopera.

Budowanie pakietów

Wstęp

W większości wypadków będziemy korzystali z gotowych pakietów, zdarza się jednak, że nie ma dostępnego jakiegoś pakietu lub nie odpowiadają nam opcje z jakimi został skompilowany. Co więcej może się zdarzyć, że będziemy potrzebować starszej, niedostępnej już wersji programu.

W takim wypadku nie powinniśmy pod żadnym pozorem kompilować samodzielnie programów, jeśli nie upewnimy się, że nie można go zbudować.

Budowanie

Budowanie jest operacją tworzenia pakietów na podstawie plików spec, do tego nie potrzeba umiejętności tworzenia speców ani wiedzy dewelopera. Wystarczy odpowiednio przygotować środowisko, zainstalować kilka pakietów i użyć odpowiedniego narzędzia. Tak utworzymy nasz własny, prywatny builder, który może nam wielokrotnie służyć.

Opis budowania pakietów odnajdziemy w przewodniku dla deweloperów PLD, wszystkie potrzebne informacje odnajdziemy pod adresem pld-linux.org/DevelopingPLD oraz w „Co jest potrzebne”.

Zarządzanie

Jeśli utworzymy środowisko wg. podanych wskazówek pakiety będą umieszczane w katalogu ~/rpm/RPMS. Ułatwi to ich instalację, gdyż Poldek ma ustawione lokalne źródło dla tego katalogu. Zbudowany pakiet będziemy mogli instalować dowolną ilość razy, warto więc przechowywać je uznamy że mogą nam się jeszcze przydać.

Jeśli wymagamy od programu nietypowej funkcjonalności i budujemy pakiet z niestandardowymi opcjami to może się zdarzyć, że przy aktualizacji zastąpimy naszą wersję programu tą z pakietu dystrybucyjnego. Dlatego musimy być czujni przy operacji aktualizacji lub dopisać nazwę tego pakietu do opcji hold w pliku konfiguracji Poldka.

Poldek

Wstęp

Poldek™ jest nakładką na program rpm™, zapewniającą wygodny interfejs obsługi oraz kilka dodatkowych funkcji. Poldek jest pośrednikiem w pobieraniu pakietów, indeksuje ich listy oraz ułatwia zarządzanie wieloma źródłami, może pobierać pakiety lokalnie (dyski twarde, napędy optyczne) lub z sieci (FTP, HTTP, HTTPS, SMB, RSYNC). Obsługuje ponadto zależności miedzy pakietami, wykrywa konflikty itp. Poldek nie obsługuje jednak wszystkich operacji możliwych na pakietach RPM, dlatego nie może całkowicie zastąpić programu rpm.

Poldek do wielu operacji (pobieranie pakietów i indeksów, wyszukiwanie informacji itp.) nie wymaga praw administratora, wymagane są jednak do operacji zapisu w systemie, np. instalowanie, odinstalowanie, itp. Poldek w tym celu automatycznie używa programu sudo™, z tego względu konieczne jest posiadanie skonfigurowanego sudo, w przeciwnym razie pozostaje nam uruchamianie programu z konta roota.

Konfiguracja Poldka jest dość złożona i wyjaśnienie wszystkich szczegółów zajęło by zbyt wiele miejsca, dlatego zajmiemy się jedynie najczęściej używanymi opcjami. Nie powinniśmy się jednak tym przejmować, program jest gotowy do działania od razu po zainstalowaniu i w większości wypadków nie ma potrzeby nic modyfikować. Musimy jednak się upewnić, że mamy dobrze skonfigurowane adresy serwerów i architekturę pakietów, co zostało omówione w dalszej części rozdziału.

Więcej informacji o poldku i jego konfiguracji odnajdziemy w podręczniku systemowym (man,info) oraz na witrynie projektu pod adresem http://poldek.pld-linux.org.

Pliki konfiguracji

Konfiguracja Poldka jest przechowywana w kilku plikach wewnątrz katalogu /etc/poldek, to czy dany plik konfiguracji jest używany określa opcja %include, umieszczona w głównym pliku konfiguracji.

  • poldek.conf - główny plik konfiguracji, jeśli nie zostało zaznaczone inaczej to właśnie ten plik ma na myśli autor

  • aliases.conf - zawiera zdefiniowane aliasy poleceń dla trybu interaktywnego

  • fetch.conf - zawiera konfigurację alternatywnych programów do pobierania pakietów, domyślnie konfiguracja z tego pliku nie jest wczytywana.

  • repos.d/pld.conf - ustawienia źródeł pakietów dla PLD

  • source.conf - plik przeznaczony dla lokalnych źródeł pakietów

  • .poldekrc - plik konfiguracji użytkownika, który umieszczamy w katalogu domowym.

Konfiguracja pobierania pakietów

W pliku repos.d/pld.conf mamy dwie ważne opcje wskazujące skąd mają być pobierane pakiety. Opcja _pld_arch wskazuje architekturę sprzętową pakietów, zaś _pld_prefix mówi skąd mają być pobierane pakiety i dla jakiej wersji dystrybucji. Więcej o architekturach pakietów znajdziemy w „Architektury pakietów”, adresy serwerów i oficjalnych mirrorów zawarto w „Serwery z pakietami”.

Poldek zacznie korzystać z proxy po ustawieniu właściwych zmiennych środowiskowych - zarówno w przypadku wbudowanego klienta jak i klientów zewnętrznych (np. wget). Możemy też użyć opcji proxy. Konfigurację proxy dla Linuksa szerzej opisano w „Proxy”.

Inne opcje

Poldek przechowuje indeksy pakietów w katalogu zdefiniowanym w opcji cachedir, domyślnie jest to $HOME/.poldek-cache. Jest to dobre rozwiązanie jeśli z Poldka korzysta jeden użytkownik, jeśli ma używać go więcej osób to lepiej ustawić wspólny katalog np. /var/cache/poldek-cache, w ten sposób unikniemy wielokrotnego pobierania indeksów.

use sudo - użycie sudo przy uruchomieniu z konta zwykłego użytkownika.

hold - blokuje aktualizację pakietów które znalazły się na jej liście.

ignore - opcja ukrywająca podane pakiety na liście dostępnych.

choose equivalents manually - pozwala wybierać użytkownikowi jeden z kilku pakietów oferujących tą samą funkcjonalność, domyślnie wyłączona przez co wybór następuje automatycznie. Pozwala bardzo precyzyjnie wybierać pakiety do zainstalowania.

Tryby pracy

Kolejną ważną jego cechą jest możliwość pracy zarówno w trybie wsadowym jak i interaktywnym. Pierwszy z nich nadaje do wszelkiej maści skryptów i automatyki, zaś drugi jest wygodniejszy do bezpośredniej obsługi przez użytkownika. Komfort pracy w trybie interaktywnym sprawia, że użytkownicy na co dzień korzystają niemal zawsze z niego. Stąd jeśli nie zostało to inaczej napisane to właśnie ten tryb autor ma na myśli.

Tryb interaktywny

Praca w trybie interaktywnym przypomina do złudzenia używanie powłoki systemowej (shella). Dostępne są: historia poleceń, pomoc, dopełnianie komend i nazw pakietów, aliasy, potoki itp. Na potrzeby tego rozdziału w przykładach taki tryb będziemy sygnalizować następującym znakiem zachęty:

poldek>

Jedną z największych zalet trybu interaktywnego jest dopełnianie nazw pakietów i poleceń za pomocą tabulatora. Przykładowo naciśnięcie klawisza tab po poleceniu:

poldek> upgrade

spowoduje wyświetlenie listy pakietów, dla których są dostępne aktualizacje.

W przypadku nazw pakietów możemy używać "gwiazdki" jako znaku zastępczego (wildcard), który zastępuje dowolny ciąg znaków. Przedstawiono to na poniższym przykładzie, który spowoduje zainstalowanie wszystkich pakietów o nazwach zaczynających się od "gnome-theme"

poldek> install gnome-theme*

Zazwyczaj nie ma potrzeby podawania wersji programu, jednak w pewnych przypadkach możemy mieć dostępnych kilka wersji tego samego pakietu (np. przy używaniu wielu źródeł na raz). Wtedy musimy podać jednoznacznie wersję pakietu.

Mamy do dyspozycji potoki:

poldek> ls perl* | grep curses

Możemy również wywoływać polecenia zewnętrzne:

poldek> ls perl* | !wc -l

W obsłudze źródeł i pakietów występuje wiele podobieństw do systemu plików. Źródła są traktowane jak katalogi zaś pakiety jak pliki, do poruszania się w tym środowisku używamy poleceń takich jak pwd, ls oraz cd.

Tryb wsadowy

Opis wszystkich parametrów trybu wsadowego uzyskamy dzięki poleceniu

$ poldek --help

Jest tam całe bogactwo opcji, dzięki którym będziemy mogli ułatwić sobie pracę. Na szczególną uwagę zasługuje parametr --shcmd pozwalający wydawać polecenia w trybie wsadowym jak w trybie powłoki np.:

$ poldek --shcmd="desc apache"

Możemy w tym celu użyć również polecenia ipoldek, np.:

$ ipoldek desc apache

Pierwsze kroki z Poldkiem

Poldek uruchomiony po raz pierwszy (bez podawania parametrów) sprawdza czy istnieją indeksy dla źródeł, które ma automatycznie obsługiwać. Jeśli ich nie ma, to zostaną automatycznie pobrane i zapisane w miejscu wskazanym przez omówioną powyżej opcję cachedir. Po tej operacji zostanie uruchomiony Poldek trybie interaktywnym i będzie gotowy do pracy. Przed każdą kolejną pracą z programem musimy uaktualnić indeksy pakietów, na wypadek gdyby w źródłach nastąpiły zmiany, w przeciwnym razie możemy otrzymywać komunikaty o braku pakietów. Aby uaktualnić indeksy domyślnych źródeł wywołujemy następująco program z powłoki systemowej:

$ poldek --up

Aby pobrać na nowo indeksy wywołujemy Poldka z parametrem --upa, dla pozostałych źródeł musimy podać ich nazwę po parametrze -n, źródła pakietów zostały omówione w dalszej części rozdziału.

Po uruchomieniu programu mamy od razu możliwość zarządzania pakietami, aby zobaczyć listę dostępnych poleceń wpisujemy help i naciskamy klawisz Enter. Większość poleceń ma składnię:

poldek> {$polecenie} {$pakiet} {$opcje}

Opis dodatkowych parametrów znajdziemy w pomocy danego polecenia, po napisaniu:

poldek> {$polecenie} -?

Aby opuścić program wpisujemy polecenie quit lub wciskamy ctrl+d

Zarządzanie pakietami

Mamy dostępne następujące polecenia zarządzania 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: wyświetlanie listy dostępnych (ls), wyświetlenia informacji (desc) oraz przeszukiwania bazy (search). W wielu przypadkach pomocna będzie opcja -t, która przeprowadzi symulację całej operacji, dzięki której dowiemy się jak duże i jak istotne zmiany zostaną dokonane w systemie po operacji. Najczęściej jest używana przy aktualizacji i usuwaniu pakietów.

Poniżej zamieszczono kilka przykładów zarządzania pakietami, na początek przykład wyświetlenia listy pakietów (wszystkich zaczynających się od zsh):

poldek> ls zsh*

wyświetlenie informacji o pakiecie:

poldek> desc zsh

instalacja pakietu:

poldek> install zsh

deinstalacja:

poldek> uninstall zsh

To jedynie podstawowe polecenia, więcej informacji znajdziemy w pomocy Poldka.

Źródła

Poldek ma kilka zdefiniowanych źródeł pakietów w plikach source.conf i repos.d/pld.conf, pierwszy z plików jest głównym plikiem konfiguracji źródeł, drugi zaś zawiera wpisy dla oficjalnych źródeł PLD. Aby wyświetlić listę skonfigurowanych źródeł, wraz użytymi opcjami uż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,type=pndir)
ac-updates-security ftp://ftp.ac.pld-linux.org/dists/ac/updates/security/athlon/  (type=pndir)
home         /home/users/qwiat/rpm/RPMS/  (noauto,noautoup,type=dir)

Nie wszystkie źródła są obsługiwane automatycznie, zależy to od ustawienia opcji noauto w konfiguracji danego źródła (zauważymy ją też na powyższym zrzucie ekranu). Aby tymczasowo użyć innego zestawu źródeł przy uruchomieniu musimy podać ich listę poprzedzonych parametrem -n np.:

$ poldek -n ac -n ac-ready

Teraz lista dostępnych pakietów będzie się składała z zawartości źródeł ac i ac-ready, jeśli chcemy, aby zawsze korzystał z niestandardowego zestawu źródeł wygodniej będzie zmodyfikować ustawienie opcji noauto. Oficjalne źródła PLD zostały wyczerpująco omówione w „Źródła pakietów”.

Istnieje możliwość instalacji pakietów Poldkiem z lokalnych źródeł, zamiast posługiwania się programem rpm. W pliku source.conf zdefiniowane jest źródło home, które służy do wygodnego instalowania pakietów z katalogu $HOME/rpm/RPMS, używanego powszechnie do umieszczania samodzielnie budowanych pakietów. Nie ma jednak potrzeby każdorazowego umieszczania tam pakietów jeśli to uznamy za konieczne. Możemy utworzyć tymczasowe źródło lokalne na podstawie zawartości katalogu za pomocą opcji -s:

poldek -s /jakis/katalog

Poldek po uruchomieniu tworzy dla wygody dodatkowe źródła wirtualne: all-avail i installed. Pierwsze zawiera sumę pakietów ze wszystkich wskazanych źródeł, drugie to lista zainstalowanych pakietów.

Przy pracy z samodzielnie podawanymi źródłami należy wskazywać też główne źródło pakietów (main), tak aby mogły zostać pobrane pakiety wymagane w ramach zależności. W przeciwnym razie możemy otrzymać błędy o nieistniejących pakietach.

Porady

Przy pracy z wieloma pakietami możemy utracić możliwość przewinięcia ekranu w celu odczytania najstarszych komunikatów. Aby temu zaradzić użyjemy opcji --log, dzięki której, wskażemy plik do którego trafią wszystkie komunikaty.

RPM

Instalowanie pakietów

Używając programu rpm posługujemy się następującym schematem: rpm [opcje] pakiet.rpm

Instalacja pakietu jest dosyć prosta. Załóżmy że pobraliśmy z sieci plik docbook-dtd31-sgml-1.0-12.noarch.rpm, teraz jedyną rzeczą jaką musimy wykonać jest wydanie polecenia rpm z opcją -i. Używając kombinacji -ivh dla procesu instalacji, -Uvh uzyskamy pasek postępu instalacji dla poszczególnych instalowanych pakietów.

# rpm -i docbook-dtd31-sgml-1.0-12.noarch.rpm

Brak ostrzeżeń lub błędów oznacza prawidłową instalację, teraz nieco skomplikujemy sytuację:

# 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ę nie powiodła, ponieważ pakiet libghttp-devel wymaga zainstalowanego pakietu libghttp. Aby instalacja pakietu się powiodła wykonujemy następujące polecenie:

# rpm -i libghttp-devel-1.0.9-4.i686.rpm libghttp-1.0.9-4.i686.rpm

Teraz wszystko jest w porządku, oba pakiety są zainstalowane. Możliwe jest instalowanie pakietu z opcją ignorowania zależności: --nodeps, opcję tą stosujemy jednak w ostateczności.

Aktualizowanie pakietów

Aktualizacja przebiega podobnie jak instalacja, tyle że używamy przełącznika -U np.:

# rpm -U docbook-dtd31-sgml-1.0-13.noarch.rpm

Należy pamiętać o tym, że aktualizacja nastąpi tylko wtedy gdy w systemie jest zainstalowana starsza wersja, w przeciwnym wypadku zostaniemy poinformowani, że pakiet jest już zainstalowany. Aby dokonać reinstalacji pakietu wykonujemy polecenie

# rpm -i docbook-dtd31-sgml-1.0-13.noarch.rpm --force

Odinstalowywanie pakietów

Zainstalowaliśmy kilka pakietów, teraz możemy spróbować je odinstalować - wykonujemy to przy uż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óż tu się stało? Podano nieprawidłową nazwę pakietu, należy pamiętać o tym, że przy odinstalowaniu pakietu nie podaje się rozszerzenia pakietu. Poprawne polecenie przedstawiono poniżej:

# 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ę w przypadku zainstalowania jednej wersji pakietu, drugi zaś używa się w przypadku kilku różnych (np. dwie różne wersje jądra).

Uwagi

Program rpm posiada o wiele bogatsze opcje, przedstawiono tu zaledwie kilka najważniejszych, więcej można znaleźć w podręczniku systemowym (man/info).

Bezpieczeństwo

Uruchamianie Poldka

Dobrym zwyczajem jest używanie Poldka z poziomu zwykłego użytkownika z włączoną obsługą sudo:

use sudo = yes

Jest to domyślne zachowanie Poldka, dzięki temu dla operacji wymagających uprawnień superużytkownika używany jest program sudo. Oczywiście w systemie musi być zainstalowany pakiet sudo, a dany użytkownik musi być uprawniony do jego używania.

Podpisy pakietów

W PLD mamy możliwość kontrolowania podpisów pakietów, dzięki czemu zyskujemy pewność, że instalujemy pakiety z zaufanego źródła. Importując klucz klucz publiczny GPG unikamy również zasypywania następującymi 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 żadnych komunikatów z ostrzeżeniami, warto dodatkowo zabezpieczyć się przed przypadkowym zainstalowaniem niepodpisanych pakietów. Wystarczy, że do każdego z podpisanych źródeł zdefiniowanych w pliku /etc/poldek/pld-source.conf dodajemy wiersz:

signed = yes

przykładowe źródło będzie wyglądało następująco:

[source]
type  = %{_ac_idxtype}
name  = ac
path  = %{_pld_prefix}/PLD/%{_pld_arch}/PLD/RPMS/
signed = yes

Teraz Poldek będzie ostrzegał przy instalacji niepodpisanego pakietu:

uwaga: rhythmbox-0.9.8-2.athlon.rpm: gpg/pgp nie znaleziono podpisu
błąd: rhythmbox-0.9.8-2: signature verification failed
Wystąpiły błędy weryfikacji podpisu. Kontynuować? [y/N]

Więcej informacji w dokumentacji programu rpm i Poldka.

Zaawansowane operacje

Lista ostatnio instalowanych pakietów

Jeśli chcemy utworzyć listę zainstalowanych pakietów w kolejności wg. daty instalacji to posłużymy się poleceniem

# rpm -qa --last

Odinstalowanie "opornych" pakietów

Bywa, że pakiet w wyniku błędów w skryptach nie pozwala się odinstalować, możemy go jednak łatwo usunąć wydając polecenie deinstalacji z parametrem --noscripts np.:

# rpm -e lockdev-1.0.2-1 --noscripts

Repackage - bezpieczna aktualizacja

Jeśli obawiamy się aktualizacji jakichś pakietów, możemy posłużyć się operacją repackage - ponownego umieszczenia plików w pakiecie rpm. Jeśli program po aktualizacji odmawia posłuszeństwa, wystarczy ponownie zainstalować pakiet w starszej wersji. Aby włączyć repakietację wystarczy, że ustawimy niezerową wartość dla makra %_repackage_all_erasures w pliku /etc/rpm/macros:

%_repackage_all_erasures    1

Od tej pory każda aktualizacja rozpocznie się od ponownego złożenia pakietu. Dla pojedynczych pakietów nie ma sensu modyfikować pliku z makrami, lepiej przekazać parametr do rpm-a:

poldek> upgrade geninitrd-10000.18-6.noarch --pmop=--repackage

W przypadku bezpośredniego użycia rpm-a:

# rpm -U --repackage geninitrd-10000.18-6.noarch

Tak zbudowane pakiety trafiają do katalogu /var/spool/repackage Repakietacja jest czasochłonna, ponadto dodatkowo zajmowane jest miejsce na dysku, dlatego najlepiej używać tej funkcji tylko dla wybranych programów.

Aby cofnąć wersję pakietu wykonujemy następującą operację:

rpm -U --oldpackage /var/spool/repackage/1189984560/geninitrd-10000.18-6.noarch

Kontrola integralności systemu

Zdarza się, że potrzebujemy sprawdzić czy nie nastąpiły w systemie uszkodzenia jakichś plików lub ich modyfikacje. Takie zdarzenia mogą się pojawić w wypadku uszkodzenia systemu plików, błędu człowieka lub ataku crackera. W obu przypadkach możemy posłużyć się weryfikacją pakietów RPM. Kontrola przyniesie oczekiwany skutek tylko wtedy, gdy jesteśmy pewni, że sama baza RPM nie została skompromitowana lub uszkodzona.

Aby uzyskać listę zmodyfikowanych plików uż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 oznaczeń znajdziemy w manualu programu rpm. Musimy pamiętać, że wiele plików konfiguracyjnych (oznaczanych literką "c") jest modyfikowanych po instalacji programu, dlatego ich obecność na liście jest naturalna.

Załóżmy, że poznaliśmy listę zmodyfikowanych plików i chcemy na jej podstawie stworzyć listę pakietów do reinstalacji. Zaczynamy od odfiltrowania wszystkiego prócz nazw plików:

# rpm --verify --all | sed 's/.*\ //' > pliki.txt

Taką listę możemy teraz sobie obejrzeć i ewentualnie zmodyfikować, kiedy lista już nam odpowiada sprawdzamy z jakich pakietów pochodzą pliki:

# cat pliki.txt | xargs rpm -qf --qf '%{NAME}\n' | sort -u  > pakiety.txt

Powyższy ciąg poleceń stworzy listę składającą się wyłącznie z nazw pakietów, by uniknąć problemów w przypadku różnic w wersjach pakietów: tych zainstalowanych z dostępnymi do instalacji. Mając listę unikalnych nazw pakietów, możemy wywołać polecenie ich reinstalacji:

# poldek --reinstall --pset pakiety.txt

Naprawa bazy RPM

System pakietów RPM opiera się na bazie w postaci plików przechowywanych w katalogu /var/lib/rpm. Nagłe przerwanie pracy programu, który na niej operował może zaowocować błędami w jej strukturze. Na początek należy się upewnić, że żaden z procesów nie operuje na bazie:

# lsof | grep /var/lib/rpm

jeśli nie wyświetlą nam się żadne informacje to możemy usunąć pliki blokad, łatwo je rozpoznamy, gdyż zaczynają się od __db

# rm -f /var/lib/rpm/__db*

Teraz możemy spróbować czy sytuacja się poprawiła, jeśli nie to musimy spróbować przebudować bazę. Zaczynamy od wykonania kopii bezpieczeństwa:

# tar -czf rpm.tar.gz /var/lib/rpm/

następnie wydajemy polecenia przebudowania:

# rpm --rebuilddb

W większości wypadków ta operacja pomoże nam odzyskać bazę, może się jednak zdarzyć, że odtworzy nam się tylko jej część. Do oszacowania strat konieczne będzie utworzenie listy pakietów w bazie:

# rpm -qa

Kiedy ustalimy listę brakujących pozycji, najłatwiejszym sposobem dodania brakujących wpisów będzie instalacja pakietów z opcją --justdb, powodującą jedynie modyfikowanie bazy RPM.

Reinstalacja wszystkich pakietów - zmiana architektury

Zdarza się, że potrzebujemy zainstalować na nowo wszystkie pakiety, np. w wypadku zainstalowania pakietów w niewłaściwej architekturze. Nie jest to pracochłonna operacja, wystarczy, że z powłoki Poldka wydamy polecenie:

poldek> install -F * --reinstall --nodeps --nofollow

Rozdział 9. Bootloader

Ten rozdział zawiera dostępnych w PLD bootloaderów

Wstęp

Podczas startu naszego komputera z naszego dysku uruchamiany jest bootloader. To właśnie on odpowiada za załadowanie prawidłowego jądra systemu, czy też przekazywanie do jądra 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 pozwalają na przekazywanie do jądra specjalnych parametrów, dzięki którym możemy wpływać na start lub pracę systemu jeszcze przed jego załadowaniem. Parametry przekazane przed startem systemu będą przesłaniać te użyte w konfiguracji bootloadera. W poniższej tabeli przedstawiono najczęściej używane opcje.

Przekazywanie parametrów jądra wygląda podobnie w obu wypadkach, po włączeniu specjalnego trybu w bootloaderze otrzymujemy wiersz, na końcu którego dopisujemy potrzebne nam parametry lub modyfikować istniejące. Poniż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 wciśnięcie klawisza e, w przypadku LILO wpisujemy etykietę obrazu, jeśli to jest graficzne LILO to użyjemy klawisza tab.

Tabela 9.1. Parametry jądra

ParametrZnaczeniePrzykład
{$nr}/single

Cyfra (1-5) wskazująca który poziom uruchomieniowy (run level), opcja single to tryb jednego użytkownika. Dzięki nim opcjom można przesłonić ustawienie opcji initdefault z pliku /etc/inittab.

Więcej o poziomach pracy w „Zmiana poziomu pracy systemu”, zaś o pliku /etc/inittab przeczytamy w „Kluczowe pliki”.

single lub 1
root={$urządzenie}

Wskazanie urządzenia (partycji) na którym znajduje się główny system plików. Wartością parametru może być ścieżka do urządzenia w katalogu /dev (np. /dev/hda1) lub wartość liczbowa powstała z połączenia szesnastkowej wartości liczb major i minor urządzenia. Major podajemy w postaci jednej cyfry, natomiast minor powinien być już rozwinięty do dwóch. Przykładowo urządzenie o wartościach major 3 i minor 1 będzie przedstawiane jako 301, 0301 lub 0x301 (wartości 3 i 1 są takie same w systemie dziesiętnym i szesnastkowym).

Urządzenia oraz liczby major i minor szerzej opisano w „Urządzenia”

root=/dev/hda1 lub root=0x301
init={$program} Wskazanie programu, który ma zostać użyty zamiast domyślnego programu Init™; opcja używana w krytycznych sytuacjach, np. gdy system nie może zostać uruchomiony nawet w trybie single. init=/bin/bash
vga={$tryb} Wskazanie trybu bufora ramki, więcej o buforze ramki w następnym rozdziale. vga=0x303

Opis wybranych parametrów jądra zamieszczono na stronie http://www.jtz.org.pl/Html/BootPrompt-HOWTO.pl.html, zaś pełną ich listę odnajdziemy w dokumentacji jądra, w pliku /usr/src/linux/Documentation/filesystems/devfs/boot-options

Są również specjalne parametry, które przekazuje się do jądra w trakcie pracy systemu, opisaliśmy je w „Parametry jądra”.

MBR czy bootsector?

Oba bootloadery mają możliwość instalacji zarówno w obszarze MBR dysku, jak i bootsectorze partycji. Instalacja w MBR jest dosyć wygodna i o wiele bardziej popularna, dlatego właśnie tam powinniśmy instalować bootloader. Instalacja w bootsectorze w wypadku niektórych systemów plików (np. XFS) jest niemożliwa, gdyż ich superblok jest umieszczany na samym początku partycji - w miejscu które powinno być zarezerwowane dla bootloadera.

Frame buffer (bufor ramki)

Frame Buffer (bufor ramki) to m.in. mechanizm pozwalający na pracę konsoli w wyższych rozdzielczościach. Aby go włączyć 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 dotyczących ich rozdziałach.

Wartość opcji vga to numer trybu graficznego dla danej rozdzielczości i głębi koloru, listę dostępnych trybów przedstawiono w poniższej tabeli. Kodowe oznaczenia trybów bufora ramki możemy podawać zarówno szesnastkowo jak i dziesiętnie, dlatego też w tabeli, obok wartości szesnastkowych umieszczono wartości w systemie dziesiętnym (w nawiasach).

Tabela 9.2. Tryby bufora ramki

Głębia koloru640x480800x6001024x7681280x1024
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 wskazywać konkretny tryb możemy opcji vga przypisać wartość ask, dzięki temu jądro pozwoli wyświetlić listę trybów i wybrać jeden z nich. Więcej o buforze ramki dowiemy się z dokumentacji kernela, jeśli zainstalowaliśmy pakiet z dokumentacją jądra to znajdziemy ją 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ępnie na wydaniu polecenia lilo w celu instalacji w MBR lub bootsektorze. Każda modyfikacja pliku konfiguracji, wygenerowanie nowego obrazu initrd lub instalacja nowego jądra pociąga za sobą konieczność ponownej instalacji obrazu.

O initrd poczytamy w „Initrd”.

Konfiguracja podstawowa

Poniżej, dla przykładu przedstawiony został bardzo prosty plik konfiguracji, ma on za zadanie umieścić lilo w MBR dysku twardego, umożliwiając w ten sposób uruchomienie naszej dystrybucji.

boot=/dev/hda
read-only
lba32

image=/boot/vmlinuz
	label=pld
	root=/dev/hda1
	initrd=/boot/initrd

Plik konfiguracji lilo dzieli się na dwie zasadnicze części: blok opcji głównych oraz opcje obrazu. W powyższym przykładzie opcje główne umieszczone są na samym początku (do pustego wiersza). Wartość zmiennej boot mówi gdzie ma zostać zainstalowany bootloader (bootsector/MBR), w tym wypadku jest o MBR dysku. Opcja read-only wymusza start systemu w trybie tylko do odczytu (później jest przemontowany na tryb do odczytu i zapisu), lba32 włącza wykorzystanie 32-bitowego adresowania (jest rozwiązaniem limitu cylindra 1024).

Następna sekcja (ustawienia obrazu) to konfiguracja dla konkretnego systemu operacyjnego (tutaj Linuksa). Każdy system, który mielibyśmy obsługiwać z poziomu lilo, musi mieć taką sekcję. Opcja image rozpoczyna sekcję i jednocześnie wskazuje ściekę do jądra, label to wyświetlana etykieta obrazu, root wskazuje urządzenie z głównym systemem plików, initrd to ścieżka do obrazu initrd (initial ramdisk).

Opcję root szerzej opisano w „Wstęp”. Z nazewnictwem urządzeń masowych zapoznamy się w „Nazewnictwo urządzeń masowych”.

Dzięki powyższej konfiguracji bootloader bezzwłocznie uruchomi nasze PLD zainstalowane na pierwszej partycji dysku hda bez zadawania jakichkolwiek pytań. W wielu przypadkach będziemy chcieli przekazać do kernela specjalne parametry lub mieć możliwość wyboru innego systemu operacyjnego (o ile dodaliśmy do lilo taką możliwość). Wtedy konieczne będzie zdefiniowanie dwóch dodatkowych opcji:

prompt
timeout=100

Pierwsza włącza tryb interaktywny, druga zaś ustawia czas oczekiwania na naszą reakcję, podawany w dziesiątych częściach sekundy. W tej chwili możemy wygenerować lilo i zrestartować maszynę aby sprawdzić czy dokonaliśmy prawidłowej konfiguracji.

Inne systemy operacyjne

Istnieje możliwość uruchamiania wielu systemów operacyjnych z poziomu lilo, w tym celu do pliku konfiguracji musimy dodać odpowiednie obrazy i opisane wcześniej opcje prompt i timeout. Poniżej została umieszczona sekcja pozwalająca uruchomić system DOS/Windows umieszczony na dysku hda3.

other=/dev/hda3
	label=windows

Domyślnym obrazem wybranym przez bootloader jest pierwszy w kolejności z pliku konfiguracji. Możemy to ustawienie bardzo prosto modyfikować za pomocą opcji default wskazującej etykietę domyślnego obrazu, np.:

default=pld

Opcję default umieszczamy w głównej części konfiguracji.

Frame Buffer

Frame Buffer (bufor ramki) to m.in. mechanizm pozwalający na pracę konsoli w wyższych rozdzielczościach. Aby go włączyć, do konfiguracji linuksowego obrazu lub do sekcji głównej dodajemy parametr jądra vga np.:

vga=0x303

Przykładowa konfiguracja obrazu będzie wyglądała następująco:

image=/boot/vmlinuz
	label=pld
	root=/dev/hda1
	initrd=/boot/initrd
	vga=0x303

Listę dostępnych trybów zamieszczono w „Wstęp”.

Graficzne menu

Jeśli zdecydowaliśmy się na wyświetlanie menu początkowego (za pomocą opcji prompt) to możemy się pokusić o ustawienie graficznego menu. Z pakietem lilo dostajemy odpowiednio przygotowane bitmapy, musimy tylko dodać kilka opcji do głównej sekcji pliku konfiguracji.

Wskazujemy interesujący nas obrazek:

bitmap = /boot/lilo-pldblue8.bmp

Określamy kolory i położ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ętać że powyższe dane są dobrane dla konkretnego obrazka i dla innego mogą nie być dobre.

Zakończenie

Kiedy już skonfigurujemy nasz bootloader wydajemy polecenie lilo:

# lilo
Added pld *

następnie restartujemy system.

GRUB

GRUB™ (GRand Unified Bootloader) jest bootloaderem zdobywającym sporą popularność, ze względu na swoją elastyczność i duże możliwości. Jest tak rozbudowany, że musi trzymać część swoich danych na dysku twardym, z tego też względu obsługuje kilka systemów plików i może wykonywać proste operacje dyskowe. GRUB normalnie "widzi" pliki na dysku, a więc widzi własny plik konfiguracji, kernel i obraz initrd. Dzięki 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 żadnej jasnej reguły. GRUB na każdym etapie konfiguracji (w trybie interaktywnym) wspiera nas wbudowaną pomocą oraz dopełnianiem nazw plików, urządzeń i partycji.

Do największych zalet GRUB-a można zaliczyć możliwość zmiany konfiguracji startowej z poziomu działającego bootloadera. Kiedy uruchomiony zostanie bootloader wybieramy obraz a następnie wciskamy klawisz e. Wyświetlą nam się wiersze konfiguracji, możemy je modyfikować za pomocą wbudowanego prostego edytora tekstów. Po skończonej edycji wciskamy klawisz b, aby uruchomić system z wprowadzonymi zmianami.

Kolejną ważną jego cechą jest możliwość używania klawiatury USB, w przeciwieństwie do LILO™, jedyną rzeczą jaką musimy zrobić w tym wypadku to włączyć obsługę klawiatury USB w BIOS-ie.

O initrd poczytamy w „Initrd”.

Nazewnictwo urządzeń

Nie używamy nazw dysków opierających się na urządzeniach widniejących w /dev (np. /dev/hda). GRUB przy pomocy BIOS-u sprawdza istniejące dyski i numeruje je począwszy od zera. Dla przykładu, jeżeli posiadamy dwa dyski twarde (np. hda i hdc), pierwszy z nich zostanie oznaczony jako hd0, drugi jako hd1. Sytuacja z partycjami wygląda podobnie, również numerowane są od zera, natomiast pierwsza partycja logiczna będzie oznaczona numerem 4.

Obszar MBR oznaczany jako /dev/hda będzie widziany jako (hd0), partycja /dev/hda1 będzie rozpoznawana jako (hd0,0). Podane nawiasy nie są przypadkowe, jest to cecha składni poleceń GRUB-a.

Urządzenia masowe opisano szerzej w „Nazewnictwo urządzeń masowych”.

Konfiguracja podstawowa

Konfiguracja polega na odpowiednim skonfigurowaniu pliku /boot/grub/menu.lst i instalacji bootloadera w MBR/bootsektorze dysku. W poniższych przykładach założyliśmy, że zarówno / (rootfs) jak i /boot leżą na tej samej partycji pierwszego dysku twardego. W przykładowej konfiguracji będzie to /dev/hda1. Poniżej przedstawiono przykładową konfigurację:

timeout 15

title  pld
root (hd0,0)
kernel /boot/vmlinuz root=/dev/hda1
initrd /boot/initrd

Konfiguracja GRUB-a podzielona jest na sekcję główną i sekcje obrazów, sekcja główna są to ustawienia globalne, zaś konfiguracja obrazów to opcje dla każdego z obsługiwanych systemów operacyjnych. Powyżej mamy sekcję główną oraz sekcję obrazu oddzieloną pustym wierszem.

Opcja timeout w sekcji głównej to czas w sekundach oczekiwania na reakcję użytkownika.

Opcja title w sekcji obrazu to jego etykieta, root(hd0,0) to partycja na której GRUB będzie szukał swoich plików (w PLD GRUB trzyma swoje pliki w /boot/grub). Parametry kernel i initrd to ścieżki do plików kernela i initrd, w powyższym przykładzie będą szukane na urządzeniu (hd0,0) gdyż podane do nich ścieżki są względne. Parametr root= jest parametrem jądra wskazującym położenie głównego systemu plików, opisanym szerzej w „Wstęp”. Może mieć zarówno postać liczbową jak i postać nazwy urządzenia z katalogu /dev np. /dev/hda1.

Kiedy plik konfiguracji jest gotowy możemy przejść do instalacji GRUB-a.

Instalacja

Przejdźmy teraz do instalacji GRUB-a w MBR, rozpoczynamy od uruchomienia programu grub, mamy teraz do dyspozycji interaktywną powłokę, oferującą liczne polecenia, dopełnianie oraz pomoc. Rozpoczynamy od polecenia root z parametrem wskazującym miejsce gdzie znajdują się pliki GRUB-a, konieczne do jego instalacji.

grub> root (hd0,0)
Filesystem type is xfs, partition type 0x83

Teraz uruchamiamy instalację 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 wskazują poprawność operacji, więc pozostaje nam tylko wyjście z powłoki programu.

grub> quit

W ten oto sposób staliśmy się posiadaczami GRUB-a w naszym systemie, możemy teraz zrestartować maszynę.

Inne systemy operacyjne

Zakładam, że chcemy dodać system Microsoftu zainstalowany na partycji /dev/hda2, oto sekcja jaką musimy dopisać do /boot/grub/menu.lst:

title Windows
rootnoverify (hd0,1)
chainloader +1

Domyślnym obrazem wybranym przez bootloader jest ten pierwszy w kolejności w pliku konfiguracji. Możemy to ustawienie bardzo prosto modyfikować za pomocą opcji default wskazującej numer obrazu. Obrazy są numerowane wg. kolejności począwszy od 0 np.:

default 2

Omawianą opcję wstawiamy do sekcji głównej pliku konfiguracji.

Frame Buffer

Frame Buffer (bufor ramki) to mechanizm pozwalający m.in. na pracę konsoli w wyższych rozdzielczościach. Aby go włączyć, do parametrów jądra w konfiguracji linuksowego obrazu dodajemy parametr vga np. vga=0x303. Przykładowa konfiguracja obrazu będzie wyglądała następująco:

title  pld
root (hd0,0)
kernel /boot/vmlinuz root=0301 vga=0x303
initrd /boot/initrd

Listę dostępnych trybów zamieszczono w „Wstęp”.

Graficzne menu

W pakiecie z GRUB-em dostępne są grafiki, co sugeruje możliwość wyświetlenia ich w menu, jednak GRUB w PLD domyślnie ich nie obsługuje. Aby włączyć taką możliwość musimy samemu zbudować pakiet z opcją --with splashimage.

Instalujemy zbudowany pakiet, a następnie do pliku konfiguracji, do sekcji głównej dodajemy opcję wskazującą bitmapę, która ma być wyświetlana np.:

splashimage=(hd0,0)/boot/grub/splash.xpm.gz

Aby napisy pozostały czytelne możemy ustalić ich kolor za pomocą opcji foreground i background np.:

foreground  = ffffff
background  = 000000

Pierwsza z opcji wskazuje główny kolor liter, druga zaś określa kolor ich cienia, oba parametry przyjmują szesnastkowe wartości. Teraz restartujemy komputer, aby sprawdzić czy wszystko działa poprawnie.

Grafiki możemy tworzyć samemu, GRUB wymaga indeksowanej bitmapy o 14 kolorach i rozdzielczości 640x480, typu .xpm, plik musi być dodatkowo skompresowany programem Gzip.

Bezpieczeństwo bootloadera

Jak już zostało wspomniane, GRUB trzyma część swoich danych w systemie plików, co przy poważnym uszkodzeniu systemu plików może uniemożliwić start systemu. Rozwiązaniem tego problemu, może być umieszczenie gałęzi /boot na osobnej partycji, tak jak to było dawniej robione dla ominięcia ograniczeń starych wersji LILO™. Więcej o podziale na partycje odnajdziemy w „Podział na partycje”.

Dla większego bezpieczeństwa partycję taką można montować w trybie tylko do odczytu, musimy jednak wtedy pamiętać o konieczności przemontowania jej do trybu rw, przed każdą aktualizacją jądra, lub bootloadera.

Uwagi

  • W przypadku nietypowych konfiguracji będziemy zmuszeni do podawania ścieżek bezwzględnych do plików. Podajemy je następująco: (hdX,Y)/katalog/plik np.: (hd0,0)/boot/vmlinuz

  • GRUB wymaga kompletnej listy urządzeń w katalogu /dev, stąd mogą pojawić się problemy przy próbie instalacji go z chroota opartego o udev. Należy w tym wypadku podmontować z głównego system katalog /dev z opcją -bind. Pliki urządzeń zostały dokładniej opisane w „Urządzenia”.

rc-boot

Wstęp

Osoby nie przepadające za konfiguracją powyższych bootloaderów, mogą skorzystać z narzędzia o nazwie rc-boot™. Jest to proste i wygodne w użyciu narzędzie, stworzone dla potrzeb PLD, które zapewnia uniwersalny interfejs do zarządzania bootloaderem. Został stworzony w celu automatycznego aktualizowania bootloadera po zaktualizowaniu jądra, jednak nie zdobył szerszej popularności wśród użytkowników. Dzięki rc-boot możemy używać dowolnego bootloadera (np. LiLo™, Grub™), nie znając zasad ich działania czy składni plików konfiguracji.

W gruncie rzeczy korzystanie z rc-boot ma sens wyłącznie przy używaniu LiLo. Bootloader GRUB nie wymaga przeładowania po aktualizacji jądra, dlatego użytkownicy używają właśnie jego zamiast rc-boot.

Aby utworzyć bootloader omawianym narzędziem należy się posłużyć poleceniem rc-boot, to jaki bootloader zostanie użyty i jakie opcje będą ustawione, definiujemy w jednym uniwersalnym pliku konfiguracji: /etc/sysconfig/rc-boot/config. Dodatkowo wymagane są specjalne pliki "obrazów" odpowiadające każdemu systemowi operacyjnemu, który chcemy obsługiwać z poziomu bootloadera. Są to proste pliki konfiguracyjne umieszczane w katalogu /etc/sysconfig/rc-boot/images. Po zainstalowaniu systemu powinien tam być przynajmniej jeden taki plik.

Podstawowa konfiguracja

Po zainstalowaniu pakietu rc-boot™ wymagane są poprawki w konfiguracji pliku /etc/sysconfig/rc-boot/config. Na początek odblokujemy działanie rc-boot™:

DOIT=yes

Kolejno wybieramy bootloader jaki chcemy używać, mamy do wyboru lilo™ oraz grub™:

LOADER=grub

Następnie ustalamy gdzie ma być zainstalowany bootloader np.: /dev/hda, /dev/hdb2 lub mbr. Wartość mbr oznacza że rc-boot™ stara się automatycznie wykryć gdzie jest twój MBR (Master Boot Record).

BOOT=mbr

Jeśli posiadamy więcej niż jeden obraz, możemy wskazać domyślny, poprzez podanie nazwy pliku obrazu z katalogu /etc/sysconfig/rc-boot/images. Definiowanie tej opcji nie jest konieczne, gdyż rc-boot™ próbuje samemu wykryć domyślny system operacyjny, jednak w naszym przykładzie ustawimy to "na sztywno":

DEFAULT=pld

Tworzenie "obrazów"

Teraz możemy przejść do utworzenia plików obrazów. Mają one bardzo prostą budowę - są to pliki tekstowe składające się z kilku wierszy. Poniższa treść pliku jest wystarczającą konfiguracją do uruchomienia Linuksa, plikowi temu nadamy nazwę "pld".

TYPE=Linux
ROOT=/dev/hda3
KERNEL=/boot/vmlinuz
INITRD=/boot/initrd

Opcja TYPE określa rodzaj systemu operacyjnego dla danego obrazu, mamy do wyboru następujące pozycje: Linux, DOS (DOS/Windows), BSD. Opcja ROOT wskazuje partycję na której znajduje się system, wartość podana powyżej jest tylko przykładem. Wartości KERNEL i INITRD są wskazaniami do pliku kernela i pliku initrd - muszą odnosić się do właściwych pozycji w katalogu /boot

Dla każdego kolejnego obsługiwanego systemu operacyjnego należy dodać kolejny plik obrazu. Jeśli chcemy używać systemu firmy Microsoft, należy utworzyć pusty plik o nazwie np. "windows" i umieścić w nim przykładową konfigurację:

TYPE=dos
ROOT=/dev/hda1

Na koniec generujemy bootloader używając 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ęc użyjemy tego narzędzia powinniśmy na wszelki wypadek zrobić kopię bezpieczeństwa właściwego pliku.

Więcej szczegółów można uzyskać z podręcznika systemowego.

Rozdział 10. Kernel i urządzenia

Jądro systemu

Abstrakt

Jak zapewne większości z was wiadomo jądro (kernel) jest najważniejszym elementem każdego systemu. W uproszczeniu można powiedzieć, że zajmuje się ono nadzorowaniem komunikacji wszystkich elementów systemu.

Koncepcja jądra w PLD

Jedną z silniejszych stron PLD™ są dobrze przygotowane jądra systemu, pozwala to szybko uruchomić system produkcyjny bez zbędnych przygotowań. Poniżej zamieszczono listę najistotniejszych cech jąder PLD:

  • funkcjonalność - nakładanych jest wiele łat rozszerzających możliwości domyślnego kernela.

  • modularność - jądro jest tak małe, jak to tylko możliwe; jeśli czegoś potrzebujemy to wystarczy załadować odpowiedni moduł. Konsekwencją takiego rozwiązania jest konieczność używania obrazu initrd, co zostało drobiazgowo omówione w „Initrd”.

  • elastyczność - mamy wybór kilku jąder, przygotowanych w postaci binarnych pakietów dla kilku najczęstszych zastosowań; dzięki temu unikamy czasochłonnej kompilacji. Dostępne jądra zostały opisane w dalszej części rozdziału.

  • bezpieczeństwo - domyślny kernel ma nakładaną łatę grsecurity™ (www.grsecurity.net), ponadto możemy mieć jądro z obsługą Linux VServers™ (linux-vserver.org).

Podsumowując można stwierdzić, że dla większości zastosowań jądra dystrybucyjne spełnią wszystkie stawiane przed nimi wymagania, bez konieczności rekompilacji.

Informacje o używanym jądrze

Używaną wersję jądra sprawdzimy za pomocą programu uname:

# uname -r
2.6.14.7-5

Jeśli interesuje nas konfiguracja danego jądra, to możemy ją odczytać z pliku /proc/config.gz (w Th plik jest dostępny po uprzednim załadowaniu modułu configs) np.:

# zcat /proc/config.gz

lub z pliku config-dist dostarczanego z właściwym pakietem kernel-headers np.:

# cat /usr/src/linux-2.6.27.13/config-dist

Rodzaje jąder systemowych

Z PLD dostarczanych jest kilka kerneli, przygotowanych do różnych zastosowań, jedyną rzeczą jaka nam pozostaje to wybór właściwego jądra dla naszej maszyny. W poniższej tabeli zamieszczono przykładowe zestawienie dostępnych kerneli. Nie wszystkie z wymienionych poniżej pakietów bezpośrednio dostępne na liście pakietów, jeśli tak nie jest to trzeba je zbudować samodzielnie ze speca.

Tabela 10.1. Kernele

NazwaCechy
kernel uniwersalny kernel z wieloma dodatkowymi funkcjami przydatnymi na serwerach, będzie dobry dla większości zastosowań (w PLD Th i w Ac z ac-updates obsługuje Linux VServers™).
kernel-grsecurity kernel z obsługą grsecurity™ (przyrostek "grsecurity" wprowadzono w PLD Ac) - przeznaczony raczej dla serwerów
kernel-desktopprzeznaczony dla stacji roboczych: obsługa m.in.: squashfs, bootsplash; pakiet jest budowany z kernel-desktop.spec
kernel-laptopodmiana kernel-desktop, przeznaczona przede wszystkim dla komputerów przenośnych
kernel-vanillaKernel bez jakichkolwiek modyfikacji (tzw. waniliowy), zwykle dostarcza najaktualniejszą wersję jądra. Brakuje mu wielu funkcji z głównego w PLD jądra, niekiedy jednak bywa od niego szybszy.
kernel-mosixjądro z obsługą klastrów openMOSIX
kernel24 rodzina kerneli z serii 2.4.x - obecnie przestarzała, ciągle jednak dostępna w Ac.

Powyższe zestawienie należy traktować orientacyjnie, gdyż kernel ciągle się zmienia. Aby poznać szczegóły, najlepiej jest sprawdzić plik spec dla konkretnego kernela. Ułatwieniem w poszukiwaniu właściwej rewizji, mogą być tagi zaczynające się od auto-, np.: auto-th-kernel-2_6_27_12-1. Tagi te są nadawane dla każdej wersji pakietu trafiającego na serwery FTP/HTTP.

W wersjach Ra™ i Ac™ istniał podział na kernel jednoprocesorowy (tzw. up) oraz wieloprocesorowy - SMP (symmetric multiprocessing). Dla odróżnienia te z obsługą wielu procesorów miały w nazwie pakietu przyrostek -smp. W Th™ i pakietach z ac-updates zaniechano takiego podziału i wszystkie jądra obsługują wiele procesorów i jednocześnie zrezygnowano z przyrostka -smp.

Należy zwrócić uwagę, na inne przyrostki po słowie kernel w nazwach pakietów, nie mówią one o rodzaju kernela ale o pakiecie z dodatkowymi modułami: kernel-net, kernel-sound, kernel-video, dokumentacją: kernel-doc i inną zawartością.

Aktualizacja

Kernel jest kluczową częścią systemu, dlatego zaleca się inaczej podejść do jego aktualizacji niż 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, użytkownicy LiLo muszą dodatkowo wydać polecenie lilo. W ten sposób mamy zainstalowane dwa jądra, przy czym po ponownym uruchomieniu użyta zostanie nowa wersja.

Gdyby nowy kernel okazał się niestabilny, to zawsze możemy powrócić do starej wersji. Aby ułatwić taką operację symlinki wskazujące na dotychczasowy kernel (/boot/vmlinuz) i initrd (/boot/initrd) automatycznie będą teraz dostępne pod nazwami /boot/vmlinuz.old i /boot/initrd.old. Dzięki temu, możemy w konfiguracji bootloadera mieć "obraz" konfiguracji dla starego kernela i użyć go w razie potrzeby.

Zależności

Istnieje kilka pakietów, bardziej lub mniej zależnych od konkretnej wersji kernela. Ścisłe zależności będą dotyczyły pakietów z modułami np. kernel-vanilla-sound-alsa oraz pakietów ściśle współpracujących z kernelem np. moduł kernel-video-nvidia ze sterownikiem X.Org: xorg-driver-video-nvidia. Nieco mniej oczywisty jest związek kernela z pakietami iproute2 czy iptables, w ich przypadku mamy nieco swobody.

W wielu sytuacjach nie będziemy musieli się o to martwić, gdyż ten problem załatwiają nam zależności. Mimo to, że mamy tu dostępną automatykę, przy tego rodzaju pakietach powinniśmy zachować zdwojoną czujność. Dla ważnych maszyn produkcyjnych warto dodać kernel i pakiety okołokernelowe do opcji hold w Poldku™, opcję tą omówiliśmy w „Poldek”. Więcej o zależnościach pomiędzy pakietami w „Cechy pakietów w PLD”.

Uwagi

Czasami zdarza się, że załamuje się praca systemu sygnalizowana za pomocą komunikatu Kernel Panic, jądro informuje nas, że nie wie co ma dalej zrobić i przerywa pracę. Warto ustawić system tak, by po takim zdarzeniu automatycznie następował restart, konfigurację takiego zachowania opisaliśmy w „Podstawowe ustawienia”.

Parametry jądra

Mamy możliwość wpływania na pracę systemu, dzięki modyfikowaniu specjalnych parametrów jądra, parametry te można podzielić na dwie grupy: podawane przed startem kernela oraz podawane po wystartowaniu. Pierwszy rodzaj został opisany w „Wstęp”, drugi to zestaw specjalnych wpisów do pseudo-systemu plików /proc/sys.

Czytać wartości możemy za pomocą programu cat np.:

# cat /proc/sys/net/ipv4/ip_forward

Parametry możemy wysłać za pomocą programu echo np.:

# echo "1" > /proc/sys/net/ipv4/ip_forward

Możemy do tego również użyć programu sysctl, który za nazwę węzła przyjmuje nazwy katalogów rozdzielone kropkami, z pominięciem "/proc/sys". Poniżej umieszczono przykład odczytania opcji:

# /sbin/sysctl net.ipv4.ip_forward

oraz przypisania:

# /sbin/sysctl net.ipv4.ip_forward=1

Wadą powyższego rozwiązania jest powrót do poprzednich ustawień po restarcie maszyny. Rozwiązaniem problemu jest korzystanie z pliku /etc/sysctl.conf, w nim przypisujemy wartości odpowiednim zmiennym. W celu wprowadzenia ustawień wywołujemy polecenie:

# /sbin/sysctl -p

Niektóre rc-skrypty wywołują automatycznie program sysctl, przykładowo robi to skrypt podsystemu sieci, gdyż plik /etc/sysctl.conf zawiera istotne opcje sieciowe.

Moduły jądra

Czym są?

Sterowniki mogą być wkompilowane do wnętrza jądra lub wydzielone jako osobne obiekty - moduły. Moduły jądra zostały stworzone po to by kernel zajmował mało pamięci operacyjnej i był zarazem uniwersalny. Ułatwiają one także prace ludziom zaangażowanym w rozwój jądra i dodatkowych modułów (nie potrzeba kompilować całego kernela by sprawdzić zmiany, wystarczy tylko sam moduł) Wyobraź sobie sytuację, w której masz wkompilowane do niego wszystko, a twój system nie posiada urządzeń, które kernel potrafi obsłużyć. Jest to duże marnotrawstwo, ponieważ w pamięci znajdą się nie potrzebne nam funkcje. Dodać należy fakt, ograniczenia wielkości jądra (można to zmienić odpowiednimi przeróbkami źródeł via Red Hat). Dlatego lubimy moduły. Dają nam one możliwość wyboru między tym co niezbędne, a brakiem wsparcia dla urządzeń. Podsumowując. Nie potrzebujesz to nie używasz.

By móc używać modułów potrzebujesz dwóch rzeczy. Kernela z wkompilowaną opcją Loadable module support oraz sterowników skompilowanych jako moduły. Ponieważ używasz PLD to nie masz co się głowić ponieważ wszystko to masz u siebie w systemie.

Załadowanie właściwego modułu dla urządzenia

Istnieją 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 urządzenie zostaje wykryte

Obydwie metody zostaną przedstawione w dalszych rozdziałach.

Konfiguracja modułów

Plik /etc/modprobe.conf jest przeznaczony do ustawiania opcji dla ładowanych modułów. Warto dodać iż we wcześniejszych wersjach kernela ( < 2.6.0) plik nazywał się /etc/modules.conf. W pliku mamy dostępnych wiele opcji, my omówimy tylko najczęściej używane: alias, option i blacklist.

Aliasy - są to dodatkowe nazwy dla modułów, pozwalają na wczytanie go odwołując się do aliasu. Z aliasów korzysta wiele programów, które nie mogą wiedzieć z jakiego modułu mają korzystać i używają ustalonych nazw (aliasów) np.:

alias eth0 8139too

Dzięki tej linijce wszelkie odwołania przy ładowaniu modułów załadują automatycznie moduł 8139too.

alias parport_lowlevel parport_pc

W tym fragmencie pliku /etc/modprobe.conf widzimy już znany alias z tym, że w trochę innej formie. Ponieważ występuje tu nazwa_jednego_modułu i nazwa_drugiego_modułu. Oznacza to, że jak będzie potrzeby moduł parport_lowlevel, to zostanie też automatycznie załadowany moduł parport_pc.

Opcje - często używa się możliwości przesłania do modułu ustawień. Przedstawię to na przykładzie drukarki podpiętej 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ęcej informacji o dostępnych opcjach modułu można uzyskać po wydaniu polecenia modinfo parport_pc.

Czarna lista - możemy zabronić ładowania jakiegoś modułu za pomocą słowa kluczowego blacklist np.:

blacklist rivafb

.

Statyczne zarządzanie modułami

Określenie modułu dla urządzenia

W zależności od naszych wymagań oraz zastosowania systemu operacyjnego, będzie się zmieniać liczba wymaganych sterowników, w większości wypadków będzie to wartość od kilku do kilkunastu modułów. Jeśli tych modułów jest mało to samodzielne ładowanie może być lepszym rozwiązaniem.

Aby wskazać odpowiedni moduł, musimy poznać dane urządzenia. Najbardziej interesującymi informacjami są: producent i model urządzenia lub użyty chipset. W większości wypadków te informacje znajdują się w dokumentacji urządzenia. Jeśli tak nie zdobędziemy szukanych informacji to możemy spróbować użyć którąś z poniższych metod:

  • Organoleptycznie - jeśli mamy dostęp do sprzętu to możemy obejrzeć urządzenie, opis może być umieszczony na płytce drukowanej lub na chipsecie (zwykle największy układ scalony).

  • lshw - zaawansowany program służący do wyświetlania szczegółowych danych o sprzęcie, jego zaletą jest duża ilość sprawdzanych podsystemów i wyświetlanie nazw używanych modułów przez konkretne urządzenie.

  • lspci - program ten wyświetla listę wykrytych urządzeń PCI/AGP wraz z dodatkowymi informacjami. Warto użyć tu dodatkowo opcji "-v" - "-vv" w celu zwiększenia ilości danych. Program ten znajdziemy w pakiecie pciutils.

  • Komunikaty jądra - są to dosyć cenne informacje, możemy je odczytać w dzienniku kernela: /var/log/kernel lub przejrzeć to co zwraca program dmesg:

    # dmesg | less

Kiedy uzyskaliśmy informacje o sprzęcie, pozostaje nam odnaleźć moduł:

  • pcidev - program z pakietu pci-database - stara się wykryć używany przez nas sprzęt oraz podaje nazwę sugerowanego modułu. Należy wywołać program z parametrem wskazującym o interesujące nas urządzenie np:

    # pcidev agp
    10de01e0 nvidia-agp nVidia Corporation|nForce2 AGP (different version?)

    drugi zwrócony łańcuch jest nazwą szukanego modułu. Aby otrzymać listę parametrów jakie przyjmuje program należy uruchomić go bez parametru. Uwaga: w celu określenia modułu kontrolera dysku nie należy używać parametru 'ide', tylko 'sata', gdyż linia sterowników IDE jest przestarzała. Zamiast niej należy używać tych opartych na libata.

  • Internet - można założyć, że ktoś się już spotkał z podobnym problemem. Mamy do dyspozycji sporą skarbnicę wiedzy: WWW, listy i grupy dyskusyjne.

  • Po nazwie modułu: modprobe -l {$słowo_kluczowe} - tak możemy próbować odnaleźć 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
    /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ę podajemy jako parametr. Program jest pomocny jeśli zawęziliśmy listę pasujących modułów do kilku pozycji.

Kiedy sądzimy że odnaleźliśmy właściwy moduł możemy go bez obaw wczytać i przetestować nasze urządzenie, jeśli próba zakończyła się sukcesem to możemy zapisać jego nazwę do odpowiedniego pliku aby został załadowany przy każdym starcie systemu. Opis tego znajduje się w dalszej części rozdziału.

Zarządzanie modułami

Moduły są ze sobą powiązane i załadowanie danego modułu załaduje moduły od niego zależne (jeśli takie są), podobnie jest z ich usuwaniem z pamięci. Do zarządzania modułami zaleca się używanie programu modprobe z odpowiednimi parametrami zamiast programów insmod i rmmod

Listę załadowanych modułów i zależności między nimi otrzymamy po wydaniu polecenia lsmod np:

# lsmod
Module                  Size  Used by
lp                      8644  0
parport                29896  1 lp
ext3                  119304  1
amd74xx                11676  0 [permanent]
psmouse                34840  0
ide_core              109560  2 ide_disk,amd74xx
ide_disk               14336  9

Wczytanie modułu do pamięci:

# modprobe ne2k-pci

Usuwanie modułu z pamięci (możliwe tylko jeśli nie jest używany):

# modprobe -r ne2k-pci

Wyświetlenie listy modułów zależ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

Wyświetlenie listy dostępnych modułów:

# modprobe -l

Po "ręcznym" załadowaniu modułu do pamięci będzie on dostępny do czasu ponownego uruchomienia komputera, aby moduł był automatycznie ładowany przy starcie systemu musimy użyć opisanych dalej plików: /etc/modules lub /etc/modprobe.conf.

/etc/modules

Plik ten zawiera listę modułów, które zostaną załadowane podczas startu systemu (przez rc-skrypty). Znając nazwę modułu możemy dodać ją do tego pliku np:

echo "via82cxxx_audio" >> /etc/modules

/etc/modprobe.conf

W „Moduły jądra” powiedzieliśmy, że plik /etc/modprobe.conf służy do konfiguracji modułów, jednak za pomocą pewnej sztuczki będziemy mogli wskazywać moduły do załadowania. Polega ona na utworzeniu aliasów o ustalonych nazwach i które będą ł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 żeby taki moduł został dopisany do /etc/modules, jednak metoda oparta na aliasach jest bardziej czytelna i elegancka (zwłaszcza przy większej ilości kart sieciowych). Poniżej została przedstawiona lista takich aliasów:

  • eth{$Nr} - opisany powyżej alias dla karty sieciowej typu Ethernet.

  • ide_hostadapter, scsi_hostadapter - aliasy do modułów kontrolerów pamięci masowych, używane są 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 eth0 8139too
alias scsi_hostadapter sata_sil
alias char-major-116 snd
alias snd-card-0 snd-intel8x0

Udev - dynamiczna obsługa sprzętu

Statyczne zarządzanie modułami kernela i urządzeniami w /dev było skomplikowane, uciążliwe i wymagało praw administratora, stąd narodziła się idea systemu, który zautomatyzuje te czynności. Tak oto powstał udev™, współczesne wersje udeva (następcy DevFS) mają wbudowaną obsługę hotpluga™ i coldpluga™. Dzięki temu mogą automatycznie ładować potrzebne moduły, ma to sens wyłącznie w przypadku modularnego kernela, jaki jest dostępny w PLD. Mimo włączenia hotpluga do udeva w PLD ciągle dostępne są pakiety z hotplugiem, są przechowywane jedynie dla wstecznej zgodności i nie będą nam już potrzebne.

Poza nielicznymi wypadkami nie będzie już konieczne dopisywanie nazw modułów do pliku /etc/modules, ani ich ręczne ładowanie za pomocą programu modprobe.

Więcej o plikach urządzeń znajdziemy w „Urządzenia”.

Instalacja

W systemie domyślnie instalowany jest pakiet dev™, jeśli zechcemy przejść na udev to wystarczy, że zainstalujemy pakiet udev a następnie odinstalujemy dev np.:

# poldek -i udev
# poldek -e dev

Osoby nie ufające do końca dynamicznemu tworzeniu urządzeń, nie usuwają z systemu statycznego deva tak jak to zrobiliśmy powyżej. Praktyka pokazuje jednak, że nie ma powodów do obaw i poza wyjątkowo ważnymi instalacjami systemu nie ma takiej potrzeby.

Konfiguracja

Udev w większości wypadków nie wymaga żadnych operacji konfiguracyjnych, czasami tylko konieczne jest poprawienie lub dodanie regułki do katalogu /etc/udev/rules.d/. Zanim się tym zajmiemy powinniśmy zapoznać się z dokumentacją.

W Ac™ do wyboru są dwa tryby pracy: udevstart (domyślny) i udevsynthesize. Ten drugi wykrywa większą liczbę urządzeń, stąd warto się pokusić o wybór właśnie jego. Aby go używać wystarczy, że ustawimy odpowiednią opcję w pliku /etc/udev/udev.conf:

UDEV_STARTER="udevsynthesize"

W Th™ powyższe opcje nie są już dostępne, ich miejsce zajął mechanizm udevtrigger.

Udev w praktyce

Liczba załadowanych modułów przez udev może przywrócić o zawrót głowy, udev ładuje moduły znalezionych urządzeń bez względu czy w ogóle z niego korzystamy. Jedyną wadą takiego działania jest większe zużycie pamięci przez nieużywane sterowniki. Nie powinno przekroczyć 2MiB pamięci, więc dla ogromnej większości współczesnych komputerów nie będzie to stanowić żadnego problemu.

Mamy wpływ na listę ładowanych modułów, aby zablokować ładowanie jakiegoś modułu wystarczy dodać do pliku /etc/modprobe.conf nazwę modułu poprzedzoną słowem blacklist np.:

blacklist rivafb
blacklist nvidiafb

Powyższa metoda ma sens jedynie jeśli chcemy zablokować pojedyncze moduły, jeśli mamy komputer o bardzo małej ilości pamięci lepszym pomysłem będzie pozostanie przy statycznej metodzie ładowania modułów.

Uwagi

Jeśli mamy kilka kontrolerów urządzeń masowych (IDE/SATA/SCSI) to mogą występować problemy z wykrywaniem ich na czas, tak by były gotowe do zamontowania systemów plików określonych w /etc/fstab. Jedynym pewnym sposobem poradzenia sobie z tym kłopotem jest dodanie modułów kontrolerów do initrd.

Więcej o udev możemy poczytać w FAQ

Udev nie zajmuje się montowaniem przenośnych nośników danych, musimy robić to ręcznie (co wymaga uprawnień administratora), lub użyć HAL-a, D-Busa oraz np. gnome-volume-manager w przypadku środowiska Gnome.

Initrd

Wstęp

W PLD wszystkie możliwe sterowniki są dostępne w postaci tzw. modułów, przez co nie są one "widoczne" dla jądra 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 urządzeń 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łoż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ęc dodatkowo musimy właściwie skonfigurować bootloader - wskazać położenie obrazu. Obraz przechowywany jest w katalogu /boot i ma nazwę initrd-{$wersja_jądra}.gz, do niego zaś prowadzi łącze o nazwie initrd.

Initrd jest tworzony przy każdej instalacji/aktualizacji kernela. Bywa jednak, że nasz obraz nie jest wygenerowany prawidłowo i jesteśmy zmuszeni do utworzenia go samodzielnie. Źle utworzony uniemożliwi uruchomienie systemu, ujrzymy wtedy następujący komunikat:

Kernel panic: VFS: Unable to mount root fs...

Jądro mówi nam, że nie może zamontować głównego systemu plików, gdyż brakuje mu jakiegoś komponentu. Może się to zdarzyć, że nasz sprzęt nie został prawidłowo wykryty lub próbujemy uruchomić PLD z naszego dysku na innym komputerze (o innym kontrolerze urządzeń masowych).

Systemu nie można uruchomić więc musimy skorzystać z operacji chroot-a, możemy w tym celu użyć dowolnej dystrybucji linuksa jednak chyba najwygodniejsze będzie użycie PLD-Live™ lub RescueCD™.

Przygotowanie

Poniżej przedstawiono trzy metody generowania initrd. W większości wypadków wystarczy nam pierwszy ze sposobów, pozostałe są trudniejsze gdyż musimy znać nasz sprzęt i system plików partycji "/". Jeśli obraz nie jest tworzony prawidłowo przez pierwszą metodę musimy się zadowolić dwoma pozostałymi. Druga i trzecia metoda mają jedną zasadniczą przewagę nad pierwszą - mogą być przeprowadzane na dowolnej maszynie.

W dwóch pierwszych metodach użyjemy skryptu /sbin/geninitrd z pakietu geninitrd. Jest to wygodny automat, który stara się wykryć sprzęt, system plików i czy główny system plików jest stworzony na LVM/soft RAID. Skrypt geninitrd wymaga prawidłowych wpisów w /etc/fstab i podmontowanego /proc. Tak więc jeśli generujemy initrd w systemie typu chroot to wydajemy polecenie (z chroota):

# mount /proc

Opis wykrywania sprzętu i dobierania właściwych modułów opisano w „Statyczne zarządzanie modułami”.

Automatyczne generowanie initrd

W razie potrzeby edytujemy plik /etc/sysconfig/geninitrd i ustawiamy jaki rodzaj urządzenia (SCSI, IDE, RAID) ma być 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_jądra} np.:

# geninitrd -v -f /boot/initrd-2.6.16.35-1.gz 2.6.16.35-1

Parametr -v odpowiada za "gadatliwość" programu, zaś -f wymusza nadpisanie istniejącego obrazu.

Ręczne generowanie initrd

Metoda ta wymaga precyzyjnej znajomości używanego sprzętu i systemu plików, gdyż sami musimy wskazać odpowiednie moduły. Jest jednak konieczna, w przypadku problemów z automatycznym wykryciem wymaganych sterowników lub jeśli chcemy operację wykonać na innej maszynie niż docelowa.

Możemy wpisać listę 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 zmodyfikować wywołanie geninitrd poprzez użycie parametru --with:

geninitrd [opcje] --with={$nazwa_modułu} {$initrd} {$wersja_jądra}

Dużym ułatwieniem zadania jest automatyczne dołączanie modułów zależnych od wskazanego (o ile takie są). Poniż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  /boot/initrd-2.6.16.35-1.gz 2.6.16.35-1

Gdy zawiedzie geninitrd

Możemy zmodyfikować zawartość obrazu wygenerowanego przez geninitrd, aby to zrobić 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 zawartości katalogu w inne miejsce:

# cp -a /tmp/initrd-src initrd-moje
cp: czytanie `initrd-src/bin/sh': Błąd wejścia/wyjścia

Pomimo tego błędu dobrze się skopiowało, warto jednak sprawdzić uprawnienia i atrybuty pliku (ewentualnie poprawić na takie jak w oryginale)

Aby dodać moduł, musimy go skopiować z naszego systemu do odpowiedniego katalogu w initrd-moje/lib/modules/*/, następnie do skryptu initrd-moje/linuxrc dodać wpis "insmod {$moduł}" na wzór już istniejących ({$moduł} musi zawierać pełną ścieżkę do pliku).

Przyszedł czas na wygenerowanie initrd:

# genromfs -d initrd-moje -f initrd-nowy

Kompresujemy nowy initrd:

# gzip -9 initrd-nowy

Teraz już pozostało tylko skopiowanie pliku initrd-nowy.gz do /boot i nadanie mu odpowiedniej nazwy.

Bootloader

Musimy się upewnić czy łącze symboliczne /boot/initrd wskazuje na prawidłowy obraz. Jeśli używamy LiLo™ wydajemy polecenie:

# lilo

W przypadku Grub-a™ nic nie musimy robić.

Na koniec restartujemy komputer i system powinien uruchomić się bez problemu. Konfigurację bootloaderów szerzej opisano w „Wstęp”.

Uwagi

Częste zmiany używanego obrazu initrd mogą być uciążliwe, można to obejść łącząc do jednego obrazu większą ilość modułów. Aby to zrobić możemy dopisać nazwy modułów do przedstawionych poniż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=""

możemy też użyć opcji --with programu geninitrd. Warto pamiętać żeby nie przesadzać z ich ilością, może to spowodować wolniejszy start systemu i niepotrzebne zużycie pamięci operacyjnej przez nieużywane sterowniki.

Urządzenia

Podobnie jak w innych systemach uniksowych obowiązuje tutaj zasada "everything is a file", czyli wszystko jest plikiem. Dzięki takiemu podejściu uproszczono sposób komunikacji z urządzeniami, poprzez odwoływanie się do specjalnych plików, odpowiadających konkretnym urządzeniom. Pliki te są przechowywane w katalogu /dev, zwykły użytkownik nie musi się martwić o jego zawartość, wystarczy że będzie znał powiązania między fizycznymi urządzeniami a nazwami tych plików.

Z nazw urządzeń najczęściej korzysta się w przypadku operacji dyskowych, warto zatem znać zasadę ich określania, więcej szczegółów na ten temat podano w „Nazewnictwo urządzeń masowych”.

Podstawowe informacje o urządzeniu

Nazwy urządzeń nadawane są tak, aby ułatwiać życie użytkownikom, dla jądra są właściwie obojętne. Jądro rozróżnia urządzenia za pomocą pary liczb: major (głównej) i minor (pobocznej). To jakie są wartości tych liczb odczytamy następująco:

ls -l /dev/hda2
	brw-rw----  1 root disk 3, 2 2005-11-11 15:08 /dev/hda2

Na powyższym przykładzie major jest równa 3, zaś minor jest równa 2. Pierwsza literka w łańcuchu opisującego uprawnienia określa rodzaj pliku, znak "b" (jak na powyższym przykładzie) oznacza urządzenie blokowe, zaś "c" urządzenie znakowe.

Jeśli potrzebujemy samodzielnie utworzyć plik urządzenia, to użyjemy do tego programu mknod np.:

# /bin/mknod  /dev/zero c 1 5

Numery major i minor oraz inne informacje odnajdziemy w dokumentacji kernela, jeśli zainstalujemy pakiet kernel-doc to powinniśmy zapoznać się z zawartością pliku /usr/src/linux/Documentation/devices.txt

Systemy plików-urządzeń

Są dwa sposoby dostarczania plików urządzeń dla systemu: dev™ - statyczny i udev™ - dynamiczny. Każdy z nich ma wsparcie w PLD, jednak domyślnie instalowany jest pakiet udev. Jeśli chcemy użyć innego mechanizmu, wystarczy że odinstalujemy udev a zainstalujemy dev w jego miejsce, dla pewności tą operację lepiej przeprowadzać przy pomocy operacji chroot-a.

Najstarszym z rozwiązań jest pakiet dev™, dzięki niemu w katalogu /dev zostanie utworzona spora ilość węzłów (nawet jeśli nie mamy danego rodzaju urządzenia), wystarczająca dla większości zastosowań. Jeśli jednak mamy jakieś egzotyczne urządzenie to będziemy musieli samemu utworzyć wymagane pliki. Pliki urządzeń tworzymy za pomocą opisanego wcześniej programu mknod.

W odróżnieniu od statycznej bazy plików urządzeń w ostatnim czasie popularność zdobywają systemy automatycznego tworzenia węzłów w katalogu /dev. W chwili podłączenia urządzenia lub startu systemu automatycznie tworzone są wymagane pliki. Jest to ogromne ułatwienie dla użytkowników, gdyż nie wymaga od nich wiedzy na ten temat.

UDEV

Udev™ automatycznie tworzy pliki urządzeń, jednak sam potrzebuje kilku z nich, aby mógł zacząć działać, są to: /dev/console, /dev/null, /dev/zero. Pliki te są dostarczane razem z pakietem, a więc nie musimy się to martwić.

System udev jest wart uwagi dlatego, że nie tylko tworzy wymagane węzły urządzeń lecz dodatkowo ładuje wymagane moduły jądra dla danego urządzenia. Więcej informacji o udev znajdziemy w „Udev - dynamiczna obsługa sprzętu”

Należy pamiętać o tym, że udev jest wywoływany z rc-skryptów, i nie wystartuje przy użycia parametru jądra init lub przy próbie wykonania operacji chroota z innego systemu. Wtedy wymagane pliki nie zostaną utworzone, co może spowodować nieoczekiwane problemy z działaniem programów. W przypadku wykonania operacji chroota problem ten rozwiązujemy poprzez wcześniejsze podmontowanie katalogu /dev z systemu głównego. W pozostałych przypadkach uruchamiamy skrypt /etc/rc.d/rc.sysinit, w ostateczności tworzymy wymagane urządzenia za pomocą programu mknod lub skądś je kopiujemy. Operacja chroota została szerzej opisana w „Ratowanie systemu”. Parametr jądra init jak i wiele innych szerzej opisano w „Wstęp”.

Jaki system wybrać?

Na stacji roboczej bez zastanowienia można polecić udev, gdyż pozwoli na znaczne podniesienie komfortu pracy. W przypadku serwerów będzie to głównie zależało od preferencji administratora i wybór nie będzie miał tu większego znaczenia.

Zupełnie inaczej to wygląda w przypadku systemów zamkniętych typu chroot, zarówno plikami urządzeń jak i modułami zajmuje się system gospodarz, ponadto udev może stać się poważnym wyłomem w bezpieczeństwie klatki. W takim wypadku powinniśmy użyć statycznych plików (dev), których lista powinna zostać poważnie ograniczona do kilku niezbędnych.

Rozdział 11. Konfiguracja systemu

Ten rozdział prezentuje metody konfiguracji parametrów systemu.

Podstawowe ustawienia

Plik /etc/sysconfig/system przechowuje zaawansowaną konfigurację systemu, w rozdziale tym opisano część z zawartych w nim opcji.

Konfiguracja skryptów startowych

Zmienna określa czy skrypty startowe mają używać kolorów:

COLOR_INIT=yes

Numer kolumny wyświetlania wyniku działania skryptu startowego:

INIT_COL=75

Szybsze uruchomienie systemu z pominięciem niektórych skryptów, startowych - m.in. skryptu od obsługi języków:

FASTRC=no

Zezwolenie na interaktywny start rc-skryptów (pytanie o uruchomienie każdego z podsystemów) po wciśnięciu klawisza I:

RC_PROMPT=yes

Opcje związane z jądrem

"Gadatliwość" kernela dla komunikatów wysyłanych na konsolę tekstową. Opcja jest jednoznaczna z wywołaniem polecenia dmesg -n {$nr} (domyślnie 1):

CONSOLE_LOGLEVEL=1

Czas w sekundach, po którym nastąpi restart maszyny jeśli wystąpił krytyczny błąd jądra (kernel panic). Ważna opcja w przypadku komputerów, do których nie mamy fizycznego dostępu:

PANIC_REBOOT_TIME=60

Opcje uruchamiania systemu

Uruchomienie programu sulogin™ (pytanie o hasło root-a) zamiast powłoki jeśli wystąpią problemy w trakcie uruchomienia:

RUN_SULOGIN_ON_ERR=yes

Wartość "yes" poniższej zmiennej pozwala na zalogowanie się użytkowników dopiero po zakończeniu procesu ładowania systemu. Dzięki unikniemy potencjalnych problemów wynikających z przedwczesnym uzyskaniem dostępu, z drugiej jednak strony tracimy możliwość zalogowania się (np. przez SSH) jeśli pojawią się problemy przed końcem ładowania systemu. Może to być istotne dla systemów obsługiwanych na odległość.

DELAY_LOGIN=yes

Opcja określa czy w czasie startu ma być usuwana zawartość katalogu /tmp:

CLEAN_TMP=yes

Wskazuje czy ma być zamontowany podsystem devfs™:

MOUNT_DEVFS=no

Usługi

Domyś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 przechowujących systemy typu chroot, które mają być zarządzane przez skrypt /etc/init.d/sys-chroots:

SYSTEM_CHROOTS=/jakis_katalog

Ustawienia konsoli

Dzięki plikowi /etc/sysconfig/console możemy ustawić takie parametry jak czcionka konsoli, mapa klawiatury, kodowanie fontów oraz zarządzanie energią.

Aby zmienić czcionkę, edytujemy parametr:

CONSOLEFONT=lat2u-16

Do wyboru mamy czcionki zamieszczone w katalogu /usr/share/consolefonts.

Aby zmienić kodowanie znaków, edytujemy parametr:

CONSOLEMAP=8859-2

Aby zmienić mapowanie klawiatury edytujemy parametr:

KEYTABLE=pl2

Aby ustawić numery konsol dla których aplikowane są parametry, zmieniamy:

SET_FONT_TERMINALS="1 2 3 4 5 6 7 8"

Przedstawiony parametr deklaruje zmianę ustawień dla konsol tty1-tty8.

Aby zmienić opcje zarządzania energią, edytujemy parametry:

POWER_SAVE=on
BLANK_TIME=10
POWERDOWN_TIME=60

Parametr BLANK_TIME określa liczbę minut nieaktywności do wygaszenia ekranu, POWERDOWN_TIME - do wyłączenia monitora.

Aby zmienić 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 zmienić domyślny tryb NUM Locka, edytujemy parametr:

NUM_LOCK=on

Do wyboru posiadamy atrybut "on" lub "off".

Aby uaktywnić zmiany wykonujemy:

/sbin/service console start

Internacjonalizacja

Wstęp

Częstym problemem początkującego użytkownika Linuksa jest ustawienie wyświetlania znaków diakrytycznych, walut oraz odpowiedniego języka. Ponieważ PLD jest dystrybucją dla zaawansowanych użytkowników, możemy w niej przystosować środowisko pracy do naszych indywidualnych potrzeb.

Internacjonalizacja konsoli i programów

Zanim przystąpimy do instalowania poszczególnych paczek, musimy w pliku /etc/sysconfig/i18n ustawić odpowiednie zmiennie środowiskowe odpowiadające za język czcionkę systemową oraz kodowanie. W naszym przypadku wpis ten wygląda następująco:

SUPPORTED_LOCALES=pl_PL
LANG=pl_PL
LC_ALL=pl_PL
LINGUAS=pl_PL
SYSFONT=lat2u-16
UNIMAP=lat2u
SYSFONTACM=iso02

Następnie instalujemy pakiety odpowiedzialne za ustawienia lokalne i klawiaturę:

# poldek -i localedb-src kbd

Locale generujemy poleceniem localedb-gen, które domyślne ustawienia pobiera ze zmiennej SUPPORTED_LOCALES wiec jeśli chcielibyśmy mieć obsługę również innego języka, to trzeba to zaznaczyć właśnie przy tej zmiennej.

Przykładowy zapis dla kilku języków w pliku /etc/sysconfig/i18n może wyglądać 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"

Można też zainstalować pakiet zawierający bazę danych locale dla wszystkich lokalizacji obsługiwanych przez glibc.

# poldek -i glibc-localedb-all

Aby sprawdzić czy wszystko przebiegło pomyś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ę zgadzają.

Jeśli chcemy aby ustawienia dopasowane były do naszych upodobań do dyspozycji mamy następujące zmienne LC_*:

Dostępne zmienne LC_*:
* LC_CTYPE: Konwersja czcionki i wielkości liter.                               
* LC_COLLATE: Porządek sortowania.                                              
* LC_TIME: Format wyświetlania daty i godziny.                           
* LC_NUMERIC: Wyświetlanie liczb nie związanych z walutą
* LC_MONETARY: Formaty walutowe.
* LC_MESSAGES: Format wiadomości informacyjnych, diagnostycznych \
    oraz określających interakcje programu.
* LC_PAPER: Rozmiar papieru.
* LC_NAME: Format nazw.
* LC_ADDRESS: Format wyświetlania adresu i lokalizacji.
* LC_TELEPHONE: Format wyświetlania numeru telefonu.
* LC_MEASUREMENT: Jednostki miary (metryczna lub inna)
* LC_IDENTIFICATION: Metadata o ustawieniach locale.

Przykładowo jako domyślnego języka, możemy używać 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

Myszka pod konsolą

Wstęp

Niniejszy rozdział dotyczy uruchomienia obsługi myszy dla terminala znakowego, konfigurację myszy dla środowiska graficznego (X-Window™) opisano w „X-Server”. Proces konfiguracji rozpoczynamy od instalacji demona gpm™:

# poldek -i gpm

Dalsza część konfiguracji polega na załadowaniu właściwego modułu jądra i ustawieniu przynajmniej dwóch parametrów w pliku /etc/sysconfig/mouse: nazwy urządzenia (DEVICE) i typu myszy (MOUSETYPE).

Poniższy opis dotyczy kernela 2.6.x, w tej wersji jako urządzenia dla myszy PS2 i USB stosuje się /dev/input/mouse0, /dev/input/mouse1, ... lub urządzenie zbiorcze /dev/input/mice. Jednak dla wstecznej zgodności działa dalej /dev/psaux

Szeregowa

Obsługa portu szeregowego RS-232 jest częścią jądra PLD, więc nie ładujemy żadnego modułu - urządzenia działają od razu po podłączeniu. W zależności od tego, na którym porcie mamy podpiętą mysz, ustawiamy odpowiednio parametr DEVICE, pamiętając, że /dev/ttyS0 to COM1, /dev/ttyS1 to COM2 ...

Typ myszy będzie zależał od modelu posiadanego urządzenia, w większości wypadków powinna zadziałać dla wartości "ms", "msc", lub "ms3". Szczegółowe informacje na ten temat znajdziemy w pomocy demona, którą wyświetlimy w sposób opisany na końcu rozdziału.

DEVICE=/dev/ttyS0
MOUSETYPE=ms3

PS/2, TouchPad, TrackPoint

W laptopach urządzenia wskazujące są zgodne z myszkami typu PS/2, stąd ich konfiguracja przebiega tak samo. Rozpoczynamy od załadowania modułu jądra:

# modprobe psmouse

Podajemy urządzenie myszy i jej typ, który dla większości urządzeń ustawimy na "ps2" lub "imps2":

DEVICE=/dev/input/mice
MOUSETYPE=ps2

USB

Ładowanie modułów dla tego rodzaju urządzeń może być wykonane automatycznie przez mechanizm udev™ lub ręcznie. W drugim wypadku wydajemy następujące polecenia (zakładam że są już załadowane moduły dla kontrolera USB):

# modprobe usbhid
# modprobe usbmouse

Podajemy urządzenie myszy i jej typ, który dla większości urządzeń ustawimy na ps2 lub imps2:

DEVICE=/dev/input/mice
MOUSETYPE=ps2

Zakończenie

Teraz wystarczy tylko uruchomić usługę gpm™:

# /etc/init.d/gpm start

Wcześniej załadowane moduły można jeszcze wpisać do /etc/modules, aby ładowały się przy starcie systemu.

Porady

  • Większość dostępnych na rynku myszek powinna zadziałać z przedstawioną powyżej konfiguracją. Możliwe jednak, że nasza mysz używa nietypowego protokołu i należy ustawić inny typ urządzenia (MOUSETYPE). W takim wypadku pomocna może się okazać lista urządzeń i odpowiadających im typów wyświetlana w wyniku poniższego polecenia:

    # gpm -m /dev/input/mice -t help
  • Pożyteczną opcją jest BUTTON_COUNT, która definiuje liczbę przycisków myszy.

  • Zamiast wskazania pliku urządzenia, możemy użyć łącza symbolicznego o nazwie /dev/mouse wskazującego na właściwe urządzenie.

Strefa czasowa

Strefy czasowe to specjalne ustawienia, pozwalające systemowi na łatwe przeliczanie czasu uniwersalnego (UTC) na lokalny i na odwrót. Zaczynamy od instalacji koniecznego pakietu:

$ poldek -i tzdata

Aby wskazać strefę czasową modyfikujemy plik /etc/sysconfig/timezone, jego ustawienia wskazują na odpowiednie pliki i katalogi w /usr/share/zoneinfo, które z kolei odpowiadają strefom czasowym. Nazwy plików odpowiadają pewnym punktom geograficznym tak aby łatwiej było określić właściwą strefę.

W Ac™ ustawiamy zmienne ZONE_INFO_AREA i TIME_ZONE. Opcje wskazują na katalog i plik opisujący strefę, jak zapewne czytelnik zauważy, część z nich nie jest przechowywania w podkatalogach, wtedy tą zmienną należy ustawić pustą. Dla Polski wybieramy podajemy następujące wartości:

ZONE_INFO_AREA="Europe"
TIME_ZONE="Warsaw"

W Th™ powyższe opcje zostały zastąpione przez TIMEZONE, tutaj wartości oddzielamy slashem:

TIMEZONE="Europe/Warsaw"

Aby zmiany odniosły skutek musimy zrestartować odpowiedni skrypt startowy:

# service timezone restart

Więcej informacji o strefach czasowych znajdziemy na witrynie www.timeanddate.com

Zegar

Standardowo BIOS powinien używać czasu uniwersalnego (UTC), zegar systemowy powinien wtedy działać zgodnie z czasem lokalnym, określonym w pliku /etc/sysconfig/timezone. W ten sposób zmiany czasu letni/zimowy będą następowały automatycznie, bez modyfikowania ustawień zegara sprzętowego.

Wyjątkiem od tej reguły jest używanie na tym samym komputerze PLD i któregoś z produktów Microsoftu. Te ostatnie używają zgodnego czasu dla BIOS-u i systemu, co spowoduje różnice we wskazaniach zegarów. Jedynym rozwiązaniem tego problemu jest zmuszenie naszego PLD, by używał czasu BIOS-u jako czasu lokalnego. W tym wypadku zmianą czasu letni/zimowy może zająć się system Microsoftu lub możemy wykonać to samodzielnie.

Aby skorzystać z pierwszego rozwiązania synchronizujemy zegar sprzętowy z czasem uniwersalnym, a w pliku /etc/sysconfig/clock ustawiamy:

UTC="true"

W przeciwnym wypadku ustawiamy czas lokalny i wybieramy wartość

UTC="false"

Zmienne środowiskowe

Przeglądanie

Zmienne środowiskowe to prosty sposób modyfikowania konfiguracji środowiska użytkownika. Listę zmiennych i przypisanych im wartości uzyskamy za pomocą polecenia powłoki set, na poniż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 może ustawić globalnie wszystkim użytkownikom zmienne środowiskowe. Do tego wykorzystuje się mechanizm env.d. Jest to katalog umieszczony w /etc, zawierający pliki tekstowe o nazwach takich samych jak nazwy zmiennych, wewnątrz każdego z nich podana nazwa zmiennej i jej wartość. Przykładowo zmienna EDITOR zostanie zainicjowana jeśli utworzymy plik /etc/env.d/EDITOR, jego treść może wyglądać następująco:

EDITOR=vim

Zmiany w /etc/env.d są aktualizowane po ponownym zalogowaniu danego użytkownika.

Konfiguracja lokalna

Każdy użytkownik może zarówno tworzyć takie zmienne jak i nadpisywać te ustawione globalnie.

Zmienne możemy powoływać na czas sesji, dokonujemy tego przy pomocy powłoki (shell). W większości z nich (sh, zsh, bash, ksh) istnieje polecenie export które pozwala ustawić dowolna zmienną np.:

# export EDITOR=mcedit

Tak ustawiona zmienna będzie funkcjonować do czasu wylogowania użytkownika

Aby ustawić na stałe zmienną użyjemy pliku konfiguracyjnego powłoki. Musimy jedynie wstawić do takiego pliku podane wyżej polecenie export. Każda z powłok posiada swoje własne pliki startowe, przykładowo powłoka BASH używa pliku ~/.bash_profile i ~/.bashrc, zaś ZSH ~/.zshenv. Więcej informacji na ten temat zawarto w manualu każdej z powłok.

Jeśli chcemy ustawić zmienną środowiskową tylko dla jednego uruchamianego programu, to podajemy jej definicję przed nazwą programu np.:

$ http_proxy=62.87.244.34:8080 wget http://foobar.com/plik.foo

PLDconf - Narzędzie do konfiguracji systemu

Pldconf jest narzędziem tworzonym z myślą o początkujących użytkownikach. Wiele opcji jest konfigurowanych automatycznie. Pldconf ma małe wymagania i jest niewielkim pakietem (ok. 150 kB) Jego instalacja sprowadza się do wydania polecenia:

# poldek -i pldconf

Program zadaje minimalną ilość pytań i w podstawowej wersji (dla PLD RA 1.0) konfiguruje:

  1. Serwer X: karta (auto), rozdzielczość, kolory, itd;

  2. Sieć: bramka, DNS, karty sieciowe (auto), otoczenie sieciowe, SDI, NEO (ethernet);

  3. Desktop: menedżer okien, kolory, czcionki i więcej;

  4. Menedżer startu: menu z linuksem i windows, dyskietka startowa i więcej;

  5. Dostęp do partycji windows;

tyle z podstawowych możliwości - pldconf potrafi więcej.

Obecnie pldconf rozwijany jest dla nadchodzącego PLD 2.0 (AC/DC/NEST). W nowej wersji dodano między innymi:

  1. Konfiguracje karty dźwiękowej (alsa);

  2. Konfiguracje drukarki (cups);

  3. Optymalizacje dysku twardego (hdparm);

  4. Konfiguracje fetchmail;

  5. Konfiguracje tunera telewizyjnego

  6. Zarządzanie kontami użytkowników

Wersja pldconf dla PLD 2.0 nieznacznie różni się od wersji dla PLD 1.0. Różnice dotyczą przede wszystkim zmiany ścież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ównież w systemie PLD 1.0. W szczególności najnowszy pldconf potrafi przeprowadzić sieciową instalację PLD 2.0 - moduł instalacji zadziała poprawnie w systemie PLD 1.0. Innymi słowy, aby zainstalować PLD 2.0 spod uruchomionego PLD 1.0 należy zainstalować najnowszą wersję pldconf.

Uwaga: W przypadku instalacji nowego pldconf w systemie PLD 1.0 wymagana jest również instalacja pakietu perl-modules.

Strona domowa projektu

Kluczowe pliki

W tym rozdziale przedstawione są informacje o kluczowych plikach systemu operacyjnego. Zostały tu opisane jedynie podstawowe dane na ich temat, więcej można znaleźć w podręczniku systemowym man, oraz info

/etc/inittab

Plik /etc/inittab przechowuje konfigurację programu init, uruchamianego w trakcie startu systemu i działającego bez przerwy do chwili jego zamknięcia. Głównym zadaniem procesu init jest kontrola zachowania systemu w zależności od osiągniętego poziomu pracy systemu oraz w wypadku wystąpienia specjalnych zdarzeń. Poziomy pracy szczegółowo opisano w „Zmiana poziomu pracy systemu”.

Oto najważniejsze opcje zawarte w pliku /etc/inittab:

  • Domyślny poziom uruchomienia - wskazuje programowi init jaki poziom uruchomienia ma być wybrany jeśli wywołano go bez parametrów lub w trakcie startu systemu. Wiersz określający tę opcję wygląda następująco: id:{$poziom}:initdefault: ($poziom to cyfra odpowiadająca poprawnemu poziomowi uruchomienia), ustawienie domyślnie trzeciego poziomu uruchomienia przedstawiono na poniższym przykładzie:

    id:3:initdefault:
  • Instrukcje uruchomienia programu mingetty™ na pierwszym terminalu wirtualnym (/dev/tty1), wywołania dla kolejnych będą bardzo podobne:

    1:12345:respawn:/sbin/mingetty --noclear tty1

  • Poniższy wiersz uruchomi program agetty™, łączący się z portem szeregowym /dev/ttyS0, w celu podłączenia terminala szeregowego:

    0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100

    Jeśli nie używamy tego rodzaju urządzeń to powyższe wywołania są dla nas zbyteczne.

  • Wywołania skryptów startowych - opcje te bardzo rzadko wymagają ingerencji użytkownika:

    si::sysinit:/etc/rc.d/rc.sysinit
    l0:0:wait:/etc/rc.d/rc 0
  • Obsługa specjalnych zdarzeń np. wciśnięcia kombinacji klawiszy ctrl+alt+del:

    ca::ctrlaltdel:/sbin/shutdown -t3 -r now

    Mamy sporą dowolność w zarządzaniu tym zdarzeniem, w powyższym przykładzie po naciśnięciu kombinacji ctrl+alt+del nastąpi przeładowanie systemu, aby nastąpiło zamkniecie powinniśmy użyć polecenia shutdown -h.

/etc/fstab

Plik ten przechowuje szczegółowe informacje o systemach plików, które mają być montowane do odpowiednich katalogów. Informacje w nim zawarte są odczytywane w trakcie startu systemu, dzięki temu automatycznie są montowane wszystkie woluminy (partycje) nie oznaczone opcją "noauto". Plik ten jest zazwyczaj tworzony przez instalator, jednak administrator ma możliwość, a nawet obowiązek dokonywać w nim zmian. Dla lepszego zrozumienia tematu przyjrzyjmy się przykładowemu plikowi i przeanalizujmy funkcje jakie spełniają 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 każdy odpowiada jednemu obsługiwanemu woluminowi. Poszczególne pola oddzielone są od siebie spacją lub tabulatorem. Dane odpowiedniego rekordu wczytywane są przez skrypty startowe oraz programy takie jak: fsck, mount czy umount przez co muszą one być zapisane w uporządkowany sposób.

Pole (fs_spec) - określa urządzenie blokowe lub zasób sieciowy przeznaczony do zamontowania, na przykład partycję dysku, CDROM czy udział NFS. Opis urządzeń masowych przedstawiono w „Nazewnictwo urządzeń masowych”, montowanie udziałów NFS przedstawiono w „NFS - Network File System”.

Pole (fs_file) - wskazuje na miejsce, w którym ma być zamontowany dany system plików, na przykład dla partycji wymiany (ang. "swap partition") to pole powinno zawierać wartość "none", a dla CDROM-u "/media/cdrom".

Pole (fs_vfstype) - określa typ systemu plików jaki znajduje się na danym urządzeniu. Najbardziej powszechne obecnie i obsługiwane systemy plików to:

  • ext2 - podstawowy system plików w Linuksie

  • ext3 - j.w. tyle że z księgowaniem

  • reiserfs - zaawansowany system plików z księgowaniem

  • xfs - zaawansowany system plików z księgowaniem

  • vfat - używany w starszych systemach Microsoftu, znany również jako FAT32

  • ntfs - system plików współczesnych wersji systemów Microsoftu

  • iso9660 - używany na płytach CD-ROM

  • nfs - sieciowe udziały dyskowe NFS

  • swap - obszar wymiany

Pole (fs_mntops) udostępnia szereg znaczników systemowych, które mogą mieć kluczowe znaczenie dla bezpieczeństwa i wydajności naszego systemu. Przykładowo następujące znaczniki oznaczają:

  • defaults - domyślny zestaw opcji, użyteczny w większości wypadków.

  • nodev - zapobiega rozpoznawaniu przez jądro dowolnych plików urządzeń, znajdujących się w systemie plików

  • noexec - zapobiega wykonywaniu plików wykonywalnych w danym systemie plików

  • nosuid - zapobiega uwzględnianiu bitów set-UID oraz set-GID w przypadku dowolnego pliku wykonywalnego

  • ro - powoduje zamontowanie systemu plików w trybie tylko do odczytu, powstrzymując wszelkie modyfikacje informacji dotyczących plików, włączając w to na przykład czas dostępu do pliku

Pole (fs_freq) jest używane przez program dump do wykrywania, który system plików ma mieć wykonywaną kopię bezpieczeństwa. Jeżeli nie ma informacji o tym polu, zwracana jest wartość 0 i dump przyjmuje, że dany system plików nie musi być mieć robionych kopii danych. Jeśli nie korzystamy z tego programu możemy wszędzie ustawić wartość 0.

Pole (fs_passno) jest używane przez program fsck aby zadecydować, jaka powinna być kolejność sprawdzania systemów plików podczas ładowania systemu. Główny system plików powinien mieć (fs_passno) równą 1, zaś inne systemy plików powinny mieć (fs_passno) równe 2. Jeżeli to pole nie posiada żadnej wartości lub jest ona równa 0 to wtedy dany system plików nie jest sprawdzany. Sprawdzania nie wymagają właściwie systemy plików z księgowaniem, gdyż są bardzo odporne na awarie.

Uwaga! Najważniejszym woluminem w systemie jest ten przypisywany do korzenia drzewa katalogów (katalog "/"), dlatego należy bardzo ostrożnie dokonywać zmian jego konfiguracji. Błąd może spowodować problemy z uruchomieniem systemu operacyjnego.

/etc/passwd

Jeden z najważniejszych plików w systemie - przechowuje informacje o kontach wszystkich użytkowników. Jeden wiersz w tym pliku zawiera informacje o jednym użytkowniku. Każdy składa się 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 że jest przechowywane w osobnym pliku (/etc/shadow). UID to unikalny identyfikator użytkownika, zaś GID to unikalny numer grupy głównej użytkownika - zdefiniowany w pliku /etc/group. Powłoka (shell) musi być zdefiniowana w pliku /etc/shells. Oznaczenie powłoki jako /bin/false oznacza że jest to konto użytkownika systemowego. Jest to specjalny rodzaj kont na które zwykli użytkownicy nie mogą się zalogować

Plik ten jak i opisany poniżej /etc/shadow mają kluczowe znaczenie dla systemu, dlatego nie należy ich edytować ręcznie. Narzędzia, służce do tego, opisano w „Konta użytkowników”.

/etc/shadow

Plik zawierający zakodowane hasła i dodatkowe informacje dla systemu uwierzytelniania użytkowników np.:

marek:$1$qb/waABk$F3Y6dKw/6ekZPfcoTpzks/:12575:0:99999:5:::

/etc/group

Plik zawierający nazwy utworzonych grup i przypisanych do nich uż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 już zastosowania, GID to niepowtarzalny identyfikator grupy, trzecie pole zawiera listę identyfikatorów użytkowników zapisanych do tej grupy.

Podobnie jak dwa powyższe, ten plik też powinien być modyfikowany przez przeznaczone do tego programy, ich opis zawarto w „Grupy”

/etc/shells

Zawiera listę dostępnych dla użytkowników powłok np.:

/bin/ksh
/bin/sh
/bin/bash

Aby użytkownik miał możliwość korzystania z danej powłoki musi być ona zdefiniowana w tym pliku

/etc/motd

Wiadomość dnia (ang. Message of the day) - Powitanie użytkownika: treść tego pliku wyświetlana po uwierzytelnieniu się w systemie.

/etc/nologin

Plik tworzony przez administratora - blokuje możliwość logowania się użytkowników do systemu. Przy próbie logowania wyświetlana jest jego treść.

Rozdział 12. Pamięci masowe

Ten rozdział opisuje operacje dyskowe takie jak podział na partycje, tworzenie systemów plików i inne zaawansowane zagadnienia

Wstęp

Uwaga! Wszelkie operacje dyskowe narażają nas na nieodwracalną utratę danych, dlatego zaleca się stworzenie kopii zapasowej danych i zachowanie szczególnej ostrożności.

Nazewnictwo urządzeń masowych

Numerowanie partycji

W Linuksie mogą być obsłużone cztery partycje podstawowe lub trzy podstawowe i jedna rozszerzona. Takie partycje są numerowane od 1 do 4, zaś dyski logiczne kolejnymi numerami począwszy od 5. Podawanie numeru partycji ma sens wyłącznie w wypadku dysków twardych, nie podajemy ich dla urządzeń takich jak napędy optyczne (CD/DVD), dyskietki czy też woluminy logiczne. Nie podajemy go również w przypadku odwołania do urządzenia fizycznego np. używając programu fdisk™ lub hdparm™.

Aby zorientować się w układzie partycji urządzenia możemy użyć programu fdisk™ np.:

# fdisk -l /dev/hda

Urządenia ATA (IDE)

Urządzenia ATA nazywane są wg. schematu: /dev/hd{$x}{$Nr} np. /dev/hda1.

Parametr {$x} jest małą literą identyfikującą fizyczne urządzenie, zaś {$Nr} to omówiony powyżej numer partycji dyskowej. W odróżnieniu od urządzeń SATA i SCSI w interfejsie IDE litery te mają swoje specjalne znaczenie - wskazują sposób podłączenia urządzenia:

  • "a" -dysk nadrzędny (primary) podłączony do pierwszego kanału IDE

  • "b" -dysk podrzędny (slave) podłączony do pierwszego kanału IDE

  • "c" -dysk nadrzędny (primary) podłączony do drugiego kanału IDE

  • "d" -dysk podrzędny (slave) podłączony do drugiego kanału IDE

Urządenia SCSI/SATA/USB Storage

Dyski twarde i pamięci flash mają oznaczenia /dev/sd{$x}{$Nr} np. /dev/sda1. Symbol {$x} to oznaczenie fizycznego urządzenia, którym przypisywane są kolejne litery zaczynając od "a", zaś {$Nr} to opisany na początku numer partycji. Napędy optyczne (CD/DVD) są oznaczane jako /dev/sr{$Nr} np.: /dev/sr0.

Dyskietki elastyczne

Do stacji dyskietek odwołujemy się za pomocą urządzenia /dev/fd0 lub /dev/fd1.

LVM

Woluminy logiczne mają dowolne nazwy - nadawane przez administratora w trakcie ich zakładania. Jeśli pliki urządzeń nie są utworzone statycznie, to mogą być wykrywane automatycznie (przy starcie systemu) i wtedy nadawane są im nazwy w konwencji /dev/mapper/$VG-$LV np. /dev/mapper/sys-home.

RAID programowy

Urządzenia mają nazwy wg. schematu: /dev/md{$nr}, np. /dev/md0, które z kolei jest symlinkiem do /dev/md/0.

Urządzenia w GRUB-ie

GRUB ze względu na swoja wieloplatformowość używa własnego schematu nazewnictwa. Dyski fizyczne są widoczne jako (hd{$NR}), np. (hd1) zaś partycje jako (hd{$NR1},{$NR2}) np. (hd1,2). Urządzenia te nie są bezpośrednio powiązane z plikami urządzeń w katalogu katalogu /dev i programy poza GRUB-em nie mogą z nich korzystać. Więcej w opisie bootloadera, w „GRUB”.

Podział na partycje

Partycje

Na dysku twardym możemy utworzyć do czterech partycji podstawowych (primary partition) lub do trzech partycji podstawowych i jednej rozszerzonej (extended partition). Partycję rozszerzoną możemy podzielić na liczne dyski logiczne (logical partitions).

Partycje szerzej opisano m.in. w Wikipedii, zaś sposób ich oznaczania przedstawiono w „Nazewnictwo urządzeń masowych”. Opis systemu plików-urządzeń z katalogu /dev odnajdziemy w „Urządzenia”.

Zanim zaczniemy

Operacje na partycjach mogą skończyć się utratą danych, dlatego warto najpierw zrobić zrzut tablicy partycji do pliku:

# sfdisk -d /dev/hda > hda.out

Jeśli zechcemy powrócić do poprzedniego układu partycji wystarczy, że wydamy polecenie:

# sfdisk /dev/hda < hda.out

Wymagane miejsce na system

Wymagania dyskowe w PLD (nie licząc danych, logów i obszaru wymiany):

  • instalacja minimalna - poniżej 150MB

  • serwer - dużo zależy od zainstalowanych usług, należy założyć, że zajmie co najmniej 250MB; dla większej elastyczności i stabilności warto przeznaczyć większy zapas miejsca, niż w przypadku maszyn domowych.

  • stacja robocza z XWindow - należy przeznaczyć przynajmniej 1GB miejsca

Logi i dane mogą zajmować bardzo duże ilości miejsca, dlatego musimy podejść do tego indywidualnie.

Osobnym zagadnieniem jest wielkość obszaru wymiany, stara zasada mówiąca, aby swap był dwukrotnie większy niż pamięć operacyjna, sprawdza się większości wypadków. Należy jednak podejść do tego elastycznie i dobrać objętość obszaru wymiany odpowiednio do charakterystyki pracy maszyny.

Plan podziału dysku

Dla stacji roboczych zazwyczaj wystarczy podział na dwie partycje, które będą użyte dla: "/" (głównego drzewa) i obszaru wymiany (swap). W przypadku serwerów dużo będzie zależało od zastosowania maszyny i preferencji administratora, lecz jako minimum należy dodatkowo przydzielić partycję dla gałęzi /var.

W obu zastosowaniach dla wygody i bezpieczeństwa nierzadko tworzy się dodatkową partycję dla katalogu /home, pozwala to na łatwiejsze zarządzanie uprawnieniami i ułatwia wiele operacji. Partycję na katalogi domowe należy traktować jako obowiązkową jeśli na maszynie będą dostępne konta z dostępem do powłoki (shella). Jej wielkość bezpośrednio zależy od planowanej ilości przechowywanych danych.

Jeśli od maszyny wymagamy zwiększonej niezawodności można utworzyć małą partycję dla katalogu /boot, w którym są trzymane ważne pliki systemowe. Dane w katalogu /boot zaraz po zainstalowaniu nie powinny przekroczyć ok. 7MB, aby więc mieć możliwość instalacji kilku kerneli, musimy przeznaczyć na taką partycję co najmniej 25MB miejsca. Dzięki temu zwiększymy szanse na uruchomienie systemu z uszkodzonym głównym systemem plików. Jest to szczególnie zalecane w przypadku użycia bootloadera GRUB, ze względu na jego specyficzną konstrukcję, więcej na temat GRUB-a znajdziemy w „GRUB”.

Programy do zarządzania partycjami

fdisk™ - interaktywny program do zarządzania partycjami, wydane polecenia zostaną wykonane na samym końcu - po operacji zapisu zmian. Właśnie ten program zostanie użyty w naszych przykładach, wywołujemy go z parametrem określającym urządzenie z katalogu /dev.

cfdisk™ - wygodne narzędzie, wyposażone w semigraficzny interfejs użytkownika. Twórcy ułatwili życie początkującym, poprzez ukrywanie partycji rozszerzonych, tworzeniem i ich usuwaniem zajmuje się program bez naszego udziału. Podobnie jak fdisk™ zapisuje zmiany do tablicy partycji na samym końcu. Wywołujemy go z parametrem określającym urządzenie z katalogu /dev.

parted™ - jest potężnym narzędziem, umożliwiającym wiele operacji niedostępnych dla obu poprzednich programów. Oprócz podstawowych operacji na partycjach umożliwia takie operacje jak zmianę wielkości partycji, tworzenie obrazów partycji i inne. Istotną różnicą w działaniu w porównaniu dla powyższych narzędzi jest natychmiastowe wprowadzanie zmian, stąd zaleca się zachowanie dużej ostrożności przy korzystaniu z niego.

GParted™/QtParted™ - programy dla X-Window oparte o parted™. Mają interfejs wzorowany na programie Partion Magic z systemu MS Windows.

sfdisk™ - program obsługiwany za pomocą argumentów i danych przesyłanych na wejście standardowe. Jest dosyć trudny w obsłudze ale za to może być używany w skryptach.

Podział

Poniższe przykłady będą dotyczyć programu fdisk™, cfdisk™ jest bardzo prosty w obsłudze i nikt nie powinien mieć nim problemów, zaś opis parted™ wykracza poza ramy tego rozdziału.

Aby sprawdzić czy na dysku /dev/sda są jakieś partycje użyjemy następującego polecenia:

# fdisk -l /dev/sda

Założyłem, że na dysku nie ma innych partycji, jeśli w naszym wypadku takie są to musimy je najpierw usunąć. Kiedy dysk jest gotowy uruchamiamy program fdisk:

# fdisk /dev/sda
Command (m for help):

wybieramy opcję n (nowa partycja)

Command action
   e   extended
   p   primary partition (1-4)

Program pyta o rodzaj rodzaj partycji, którą ma utworzyć. Tu wybór zależy od nas ale jeśli dysk ma mieć nie więcej niż cztery partycje, to śmiało możemy zostać przy partycjach podstawowych - w naszym przykładzie wybieramy opcję p (podstawowa partycja). Dalej program zapyta nas o numer partycji, pierwszy i rozmiar partycji. Rozmiar możemy podać w cylindrach, KiB, MiB lub GiB.

Dla kolejnych partycji powtarzamy cały proces, aż uzyskamy to co zaplanowaliśmy. Opcją p) wyświetlamy planowany układ partycji. Po zakończeniu podziału przypisujemy typy partycji opcją t) podając kolejno: numer partycji, Jeśli wybrany podział nam odpowiada to zapisujemy zmiany na dysk (do tablicy partycji) przez wybór opcji w.

Zakończenie

Jeśli żadna z partycji nie była używana w trakcie podziału na partycje (np. zamontowana) to tablica partycji jest ponownie odczytywana i od razu możemy wykonywać dalsze prace. W przeciwnym wypadku musimy jeszcze przeładować system. Po zakończeniu dzielenia dysku pozostało nam utworzenie systemów plików, które zostało opisane w „Systemy plików”.

Systemy plików

W tym rozdziale omówimy tworzenie jednej z dwóch możliwych struktur na partycji lub urządzeniu - systemu plików lub obszaru wymiany (swap).

Wybór systemu plików

Rodzaj użytego systemu plików zależy od planowanego zastosowania. W Linuksie najbardziej uniwersalnym i popularnym systemem plików jest ext2. Swoją pozycję uzyskał dzięki temu, że jest prostym i stosunkowo wydajnym systemem plików. Ponadto jako jeden z niewielu systemów plików nadaje się do użytku na dyskietkach i bardzo małych partycjach.

W pozostałych zastosowaniach możemy śmiało użyć systemów plików z tzw. księgowaniem (journaling) np.: ext3, ReiserFS, XFS, JFS ze względu na duże bezpieczeństwo przechowywania danych. Dla zastosowań wymagających wysokiej niezawodności najlepszy będzie ext3, pozostałe z wymienionych można polecić w systemach wymagających dużej wydajności i wszędzie tam gdzie występują duże ilości plików.

Aby z partycji mogły również korzystać systemy Microsoftu musimy utworzyć 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óżnią się nazwami, łatwo je rozpoznamy gdyż ich nazwy zaczynają się od "mkfs." np.:

/sbin/mkfs.ext2
/sbin/mkfs.ext3
/sbin/mkfs.reiserfs
/sbin/mkfs.msdos
/sbin/mkfs.vfat
/sbin/mkfs.xfs

Aby utworzyć system plików wywołujemy odpowiedni program z nazwą urządzenia jako parametrem, na poniższym przykładzie przedstawiono tworzenie systemu plików ext2 na drugiej partycji podstawowej:

# /sbin/mkfs.ext2 /dev/sda2

Więcej o nazewnictwie urządzeń masowych w „Nazewnictwo urządzeń masowych”.

Powyżej przedstawiono jedynie skróconą listę wszystkich dostępnych programów, programy te są dostępne w odpowiednich pakietach, przykładowo narzędzia dla systemu plików xfs odnajdziemy w pakiecie xfsprogs.

Tworzenie obszaru wymiany

Do tworzenia obszaru wymiany używamy programu mkswap np.:

# mkswap /dev/hda5

Podmontowanie partycji / aktywacja swapu

Partycje i obszary wymiany są montowane/włączane 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

System plików zostanie automatycznie wykryty a opcje zostaną ustawione na wartość "defaults". Więcej na ten temat odnajdziemy w podręczniku systemowym.

Obszary wymiany aktywujemy następująco:

# /sbin/swapon /dev/hda5

Szczegółowy opis pliku /etc/fstab oraz rc-skryptów przedstawiono w „Kluczowe pliki”.

Poznanie typu systemu plików

Aby dowiedzieć się jaki typ systemu plików jest na danej partycji, użyjemy programu file™ z opcją -s:

# file -s /dev/hda2
/dev/hda1: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)

Listę urządzeń z utworzonymi do tej pory systemami plików uzyskamy za pomocą 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 zobaczyć systemy plików podmontowanych urządzeń możemy użyć 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ę dysków twardych, można to robić jedynie z dyskietkami elastycznymi za pomocą narzędzia fdformat™. Robi się to wyłącznie dla uzyskania jakiejś nietypowej pojemności nośnika, w pozostałych wypadkach operacja ta jest zbędna, gdyż dyskietki podobnie jak dyski twarde są formatowane fabrycznie. Takie formatowanie nazywane jest także tzw. formatowaniem niskopoziomowym.

To co obecnie potocznie określa się jako "formatowanie" jest złożeniem dwóch operacji: podziału na partycje a następnie utworzeniem systemów plików.

RAID programowy

W systemie Linux istnieje możliwość tworzenia na dyskach programowych macierzy RAID poziomów 0, 1, 4, 5, 6, 10, 01. Służy do tego celu usługa mdadm™. W przeciwieństwie do macierzy RAID sprzętowych które wymagają specjalnego kontrolera dysków (dość drogiego), macierze RAID programowe zakłada się na dyskach podłączonych do zwykłego kontrolera IDE, SATA lub SCSI i całą obsługę przekazuje do odpowiedniego oprogramowania (np: mdadm™).

Macierze możemy zakładać zarówno na całych dyskach, jak i na odpowiednio przygotowanych partycjach, przy czym zakładanie na partycjach daje więcej możliwości konfiguracji. Zarówno korzystając z całych dysków jak i partycji należy pamiętać o tym że najmniejsza partycja lub dysk decyduje o wielkości zakładanej macierzy (miejsce ponad jest tracone), dlatego też należy raczej korzystać z takich samych rozmiarów dysków lub partycji.

Poniżej zamieszczono listę i opis dostępnych rodzajów macierzy dla mdadm™, w nawiasach podano nazwy parametrów programu:

  • RAID 0 (raid0, 0, stripe) - striping czyli połączenie dwóch dysków (partycji) z przeplotem danych, zwiększa się wydajność w porównaniu z pojedynczym dyskiem, obniża odporność na awarie dysków - awaria jednego dysku to utrata wszystkich danych.

  • RAID 1 (raid1, 1, mirror) - kopie lustrzane, dyski są w dwóch jednakowych kopiach, w przypadku awarii jednego drugi przejmuje role pierwszego. Wydajność tak jak pojedynczy dysk, duże bezpieczeństwo, wadą jest duża strata pojemności (n/2 - n-liczba dysków w macierzy)

  • RAID 4 (raid4, 4) - dane są rozpraszane na kolejnych dyskach a na ostatnim zapisywane są dane parzystości, zwiększone bezpieczeństwo danych przy zachowaniu dużej pojemności (n-1). Wymaga przynajmniej trzech dysków, wydajność ograniczona przez dysk parzystości

  • RAID 5 (raid5, 5) - rozpraszane są zarówno dane jak i informacje o parzystości na wszystkich dyskach, dzięki czemu wydajność jest wyższa niż w RAID 4; pojemność n-1, wymaga przynajmniej trzech dysków.

  • RAID 6 (raid6, 6) - jest to rzadko stosowana, rozbudowana macierz typu 5. Jedyną różnicą jest dwukrotne zapisanie sum kontrolnych. Dzięki temu macierz może bez utraty danych przetrwać awarię dwóch dysków. Wymaga minimum czterech dysków, jej pojemność to n-2.

  • Tryb liniowy (linear) - czyli połączenie dwóch dysków w jeden w ten sposób że koniec pierwszego jest początkiem drugiego, nie zapewnia absolutnie żadnego bezpieczeństwa a wręcz obniża odporność na awarie dysków.

Najczęściej stosuje się macierze RAID1 i RAID5, do specyficznych zastosowań używa się RAID0, pozostałe są rzadziej spotykane.

Instalacja

Instalujemy następujące pakiety:

# poldek -i mdadm

A jeśli zaplanowaliśmy umieszczenie głównego systemu plików (/) na macierzy, musimy dodatkowo zainstalować pakiet mdadm-initrd:

# poldek -i mdadm-initrd

oraz możemy opcjonalnie dla dysków ATA przy korzystaniu z device-mapera zainstalować dodatkowo:

# poldek -i dmraid

Planowanie macierzy

Dosyć popularnym rozwiązaniem jest utworzenie identycznego zestawu partycji na każdym z dysków, a następnie spięcie odpowiednich partycji w macierze. Aby ułatwić sobie zadanie możemy najpierw podzielić jeden z dysków, a na następne urządzenia skopiować układ tablicy partycji np.:

# sfdisk -d /dev/sdc | sfdisk /dev/sdd

jak się łatwo domyśleć w powyższym przykładzie kopiujemy z dysku /dev/sdc na /dev/sdd.

Garść porad:

  • Kernel może być ładowany wyłącznie z macierzy RAID 1, jeśli więc będziemy chcieli używać np. RAID5 na głównym systemie plików to musimy umieścić gałąź /boot na osobnej, niewielkiej macierzy RAID1. Opis konfiguracji bootloadera do obsługi macierzy znajduje się w dalszej części artykułu.

  • Należy oprzeć się pokusie umieszczenia obszaru wymiany (swap) na RAID0, gdyż awaria jednego z dysków może doprowadzić do załamania systemu.

  • Urządzenia, z których składamy macierz powinny być równej wielkości, w przeciwnym razie wielkość macierzy będzie wyznaczana przez najmniejszą partycję.

Więcej informacji o podziale na partycje i planowaniu miejsca na dysku zdobędziemy w „Podział na partycje”.

Tworzenie macierzy RAID

Przystępujemy do zakładania macierzy na partycjach za pomocą polecenia mdadm:

mdadm -C {$dev_RAID} --level={$rodzaj} --raid-devices={$ilość_urzadzen} {$urzadzenia}

  • -C, --create - utwórz nową macierz.

  • -l, --level - ustaw poziom RAID np: linear, raid0, 0, stripe, raid1, 1, mirror, raid4, 4, raid5, 5, raid6, 6; Jak możemy zauważyć niektóre opcje są synonimami. Przy opcji Building pierwsze mogą być użyte: raid0, raid1, raid4, raid5.

  • -n, --raid-devices - liczba aktywnych urządzeń (dysków) w macierzy

  • -x, --spare-devices - liczba zapasowych (eXtra) urządzeń w tworzonej macierzy. Zapasowe dyski można dodawać i usuwać także później.

  • -v --verbose - tryb "gadatliwy"

  • --auto=yes - automatyczne tworzenie urządzeń w /dev/ przez mdadm (stosowane zwykle przy użyciu UDEVa), więcej w Poradach na końcu rozdziału.

Przykłady tworzenia macierzy róż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), jeśli nie podasz ile ma być zapasowych partycji domyślnie 1 zostanie zarezerwowana na zapasową

    # mdadm -C -v /dev/md2 --level=5 -n 4 --spare-devices=1 \
    /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3

Konfiguracja

Po utworzeniu macierzy postępujemy z nią dalej jak z partycją, czyli zakładamy system plików i odwołujemy się do niej np: jako /dev/md0 np.:

# mkfs.xfs /dev/md0

Teraz możemy dokonać odpowiednich wpisów w pliku /etc/fstab.

Aby macierz była automatycznie składana przy starcie systemu musimy dodać odpowiednie wpisy do pliku /etc/mdadm.conf. Na początek dodajemy wiersz, w którym wymieniamy listę urządzeń z których budowane są macierze (można używać wyrażeń regularnych):

DEVICE /dev/sd[abcd][123]

Następnie dodajemy definicje macierzy, możemy to zrobić automatem:

# mdadm --detail --scan >> /etc/mdadm.conf:

lub samodzielnie, poprzez dodanie następujących 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 niż rootfs) są składane przez rc-skrypt /etc/rc.d/rc.sysinit, na podstawie powyższych wpisów konfiguracyjnych, zatem po restarcie maszyny będziemy już z nich korzystać. Jeśli mamy macierz z głównym systemem plików, to musimy jeszcze przygotować initrd i bootloader (poniżej).

Przy ręcznym składaniu macierzy przydane może być polecenie skanujące urządzenia blokowe w poszukiwaniu istniejących macierzy:

# mdadm --examine --scan -v

Initrd

Jeśli główny system plików ma być na macierzy to musimy wygenerować obraz initrd z modułami, które pozwolą na złożenie macierzy. Na początek musimy mieć zainstalowany pakiet mdadm-initrd. Generowanie takiego initrd przebiega dokładnie tak samo jak dla zwykłego urządzenia blokowego, musimy się tylko upewnić, ż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 „Initrd”.

Bootloader

Jeśli na raidzie ma się znaleźć główny system plików (bez /boot), to konfiguracja jest identyczna jak w przypadku klasycznych urządzeń blokowych.

Jeśli gałąź /boot ma się znaleźć na macierzy (wyłącznie RAID1) to powinniśmy zainstalować bootloader na każdym z dysków wchodzących w skład macierzy, dzięki czemu będziemy mogli uruchomić system mimo awarii jednego z dysków. RAID0 i RAID2-5 nie są obsługiwane przez LILO\GRUB

W LILO™ w pliku /etc/lilo.conf należy podać odpowiednie urządzenie dla opcji root i boot:

boot=/dev/md0
 raid-extra-boot=mbr-only
 
 image=/boot/vmlinuz
     label=pld
     root=/dev/md0
     initrd=/boot/initrd

Opcja w opcji raid-extra-boot wskazuje urządzenia na których ma zostać zainstalowany bootloader (urządzenia wchodzące w skład /dev/md0). Po zmodyfikowaniu konfiguracji musimy zaktualizować bootloader poleceniem lilo.

Jeśli używamy Grub-a™ wywołujemy z powłoki:

# grub
grub>

następnie szukamy gdzie znajdują sie pliki bootloadera,

grub>find /boot/grub/stage1

jeśli /boot jest oddzielną partycją 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 opisaliśmy w „Wstęp”.

Diagnostyka

Skrócone informacje o macierzy:

# mdadm --query /dev/md0

Poniżej podałem przykłady dwóch poleceń, które pozwalają odczytać dokładne dane macierzy i jej stan:

# mdadm --detail /dev/md0

# cat /proc/mdstat

Porady

  • Mając dwie macierze RAID1 np: /dev/md0 i /dev/md1, możemy utworzyć 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 mając dwie macierze RAID0.

  • Aby samemu złożyć macierz (z np: PLD Live CD™) wydajemy polecenie, które może wyglądać następująco:

    # mdadm -A /dev/md0 /dev/hda /dev/hdb

  • Jeśli macierz jest składana w trakcie startu systemu to automatycznie tworzony jest plik urządzenia /dev/mdX. W trakcie tworzenia macierzy, lub gdy macierz nie startuje wraz z systemem, możemy skorzystać z gotowych urządzeń w /dev (pakiet dev) lub samemu je utworzyć (pakiet udev). Udev nie tworzy urządzeń /dev/md0, więc musimy w tym celu użyć parametru --auto=yes w wywołaniach programu mdadm, lub utworzyć je poleceniem mknod. Urządzeniu nadajemy major o wartości 9 i kolejny, niepowtarzalny numer minor. Nie musimy się martwić o moduły, są on ładowane automatycznie przez mdadm lub initrd. Więcej o UDEV w „Udev - dynamiczna obsługa sprzętu”.

  • Wraz z pakietem mdadm dostarczany jest rc-skrypt uruchamiający mdadm w trybie monitorowania (jako demona). Więcej szczegółów w dokumentacji programu mdadm.

  • Migracja z pojedynczego dysku na RAID1

    Instalacja linuksa na raid1

    Naprawa zdegradowanej macierzy

LVM

LVM™ (Logical Volume Management) to system zaawansowanego zarządzania przestrzenią dyskową, który jest o wiele bardziej elastyczny, niż klasyczne partycje dyskowe. To wiąże się z bardziej złożoną konstrukcją, która składa się z następujących struktur:

  • PV (physical volumes) - fizyczne woluminy: są bezpośrednio związane z partycjami dyskowymi (np. /dev/hda1, /dev/sdb3).

  • VG (volume groups) - grupy woluminów: składają się z co najmniej jednego PV, ich wielkość to suma objętości wszystkich PV należących do danej grupy. Uzyskane miejsce dyskowe może być dowolnie dysponowane pomiędzy kolejne LV.

  • LV (logical volumes) - woluminy logiczne: są obszarami użytecznymi dla systemu (podobnie jak partycje dyskowe). LV są obszarami wydzielonymi z VG, zatem suma wielkości woluminów nie może zatem przekraczać objętości VG, do którego należą.

Schemat LVM-u, który zostanie użyty jako przykład w tym rozdziale:

 PV1   PV2
   \  /
    VG
   / | \
LV1 LV2 LV3

Planowanie woluminów

Musimy wyznaczyć urządzenia blokowe których chcemy użyć do stworzenia struktur PV. Jeśli główny system plików ma być umieszczony na woluminie logicznym to musimy przeznaczyć małą partycję dla gałęzi /boot, gdyż bootloadery lilo™ i grub™ nie potrafią czytać danych z woluminów. Szczegółowy opis dzielenia dysków na partycje zamieściliśmy w „Podział na partycje”.

Załóżmy, że mamy dwa dyski twarde po 250GB (/dev/sda i /dev/sdb), których powierzchnię chcemy połączyć i rozdysponować pod system operacyjny. Jako, że rootfs także będzie na woluminie to rozplanowanie miejsca może wyglądać następująco:

  • /dev/sda1: mała partycja na /boot o pojemności 50MB

  • /dev/sda2: druga partycja dla woluminów (reszta dysku)

  • /dev/sdb: cały dysk dla woluminów

VG będzie miało rozmiar ~500GB miejsca, z czego 400GB przydzielimy do użytku, a resztę pozostawimy dla przyszłych, nieokreślonych na razie zastosowań. Miejsce na VG rozdysponujemy następująco:

  • swap: 5GB

  • / (rootFS): 25GB

  • /home: 370GB

Instalacja

Omawiamy implementację LVM2™, zatem instalujemy pakiet lvm2, jeśli LVM ma być uż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 powyżej partycje, a następnie wskazujemy urządzenia Physical Volumes:

# pvcreate /dev/sda2 /dev/sdb

tworzymy Volume Group o nazwie "vgsys" z wskazanych powyżej PV:

# vgcreate vgsys /dev/sda2 /dev/sdb

W powstałej VG tworzymy woluminy o podanych pojemnoś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 możemy rozdysponować w przyszłości (przykład dalszej części rozdziału). Rzucającą się w oczy cechą woluminów logicznych jest możliwość swobodnego nadawania im nazw, co znacznie ułatwia utrzymanie porządku. Do utworzonych powyżej woluminów odwołujemy się za pomocą utworzonych przed chwilą urządzeń: /dev/vgsys/swap, /dev/vgsys/rootfs i /dev/vgsys/home. Woluminy są już gotowe do pracy, musimy jeszcze tylko utworzyć 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łęzi /boot:

# mkfs.ext2 /dev/sda1

Teraz montujemy woluminy w klasyczny sposób i jeśli wszystko przebiegło bez błędów dokonujemy odpowiednich modyfikacji w /etc/fstab.

Konfiguracja startowa

Woluminy są automatycznie aktywowane przez rc-skrypt /etc/rc.d/rc.sysinit lub initrd. Moduł device mappera również jest ładowany automatycznie. Jeśli chcemy umieścić główny system plików na LV, to musimy jeszcze wygenerować nowy obraz initrd, z obsługą LVM. Zostało to szczegółowo przedstawione w „Initrd”. W konfiguracji bootloadera ustawiamy opcję 'root=' na /dev/vgsys/rootfs. Teraz instalujemy system, instalujemy bootloader i możemy zrestartować maszynę.

Gdy zajdzie potrzeba "ręcznego" aktywowania woluminów (np. spod RescueCD), to na początek musimy się upewnić, że jest załadowany moduł dm-mod. Kernel nie zgłasza komunikatów o odnalezieniu woluminów, tak jak ma to miejsce z partycjami, należy je odszukać za pomocą odpowiednich narzędzi: lvmdiskscan i lvscan. Jeśli odnaleźliśmy żądane struktury, to możemy je aktywować:

# vgchange -a y

Narzędzia diagnostyczne

Skrócone informacje o każdym z rodzaju komponentów (PV/VG/LV) wyświetlimy za pomocą programów pvs, vgs, lvs. Więcej informacji uzyskamy za pomocą programów: pvdisplay, vgdisplay, lvdisplay.

Do niektórych operacji z woluminami będziemy musieli je odmontować i deaktywować. Aby deaktywować wszystkie woluminy użyjemy polecenia

# vgchange -a n

aby wszystkie aktywować wywołujemy:

# vgchange -a y

Zarządzanie: powiększanie woluminu

Teraz przedstawimy potęgę LVM-a: pokażemy jak powiększyć wolumin, gdy dochodzimy do wniosku, że przeznaczonego miejsca jest za mało. Załóżmy, że mamy woluminy utworzone zgodnie z wcześniejszymi przykładami i chcemy przeznaczyć całą dostępną wolną przestrzeń na naszym VG (100GB) dla /dev/vgsys/homes:

# lvextend  -l 100%VG  /dev/vgsys/home

Teraz, kiedy wolumin jest powiększony, musimy rozszerzyć system plików, w naszych przykładach jest to XFS, zatem musimy podmontować wolumin, a następnie:

# xfs_growfs /home

Operacja trwa krótko i nie powoduje utraty danych, jednak jak przypadku każdych operacji dyskowych, powinniśmy wcześniej wykonać kopię zapasową. Każdy system plików posiada własne narzędzia do zmiany rozmiaru systemu plików, szczegóły w ich dokumentacji.

Porady

Woluminy LVM powodują zwiększone ryzyko uszkodzenia danych, gdyż awaria jednego dysku może spowodować utratę wszystkich danych. Z tego powodu zaleca się tworzenie woluminów na macierzach RAID.

Naprawa

Awarie dysków często są bolesne, a nierzadko dosyć kosztowne. Istnieje wiele narzędzi do odzyskiwania danych, jednak nigdy nie gwarantują sukcesu. Dlatego warto dokonywać regularnie kopie zapasowe danych.

Uszkodzenia fizyczne

Uszkodzenia fizyczne sprawdzamy programem badblocks z pakietu e2fsprogs, uruchamiamy go poleceniem:

# badblocks -s /dev/sda

Program wypisze listę uszkodzonych bloków

Naprawa systemu plików

Nazwy programów, podobnie jak programy do tworzenia systemów plików, są ujednolicone (poza XFS). Zaczynają się od "fsck.":

fsck.ext2
fsck.reiserfs
fsck.vfat
fsck.jfs

do naprawy XFS-a użyjemy programu xfs_repair. Programy te różnią się nieco obsługą, dlatego przed użyciem każdego z nich należy zapoznać się z podręcznikiem systemowym (man/info), tak wygląda przykładowe wywołanie testu systemu plików XFS:

# xfs_repair /dev/sda2

Programy te nie pozwolą na sprawdzanie na systemie plików podmontowanym w trybie do odczytu i zapisu. Powinniśmy w ogóle nie montować takiego systemu plików, a przynajmniej podmontować w trybie tylko do odczytu.

Nieco bardziej złożone jest sprawdzanie głównego systemu plików jeśli uruchomiliśmy system w trybie jednego użytkownika. Problemem jest konieczność przemontowania systemu plików w tryb ro. Niektóre programy mogą sprawdzać w pliku /etc/mtab czy system plików jest w trybie tylko do odczytu. Może to dać nieprawidłowe wyniki, gdyż zazwyczaj gałąź /etc leży na głównym systemie plików i w pliku tym nie nastąpią żadne zmiany po takim przemontowaniu. Można to obejść wcześniej modyfikując wpis w /etc/mtab, kiedy już to zrobimy wykonujemy polecenie:

# mount / -o ro,remount

Naprawienie systemu plików nie gwarantuje, że nie zostały uszkodzone żadne pliki. Jeśli na naprawianym systemie plików były jakieś dane systemowe, to powinniśmy wykonać kontrolę ich integralności, opisaną dokładnie w „Zaawansowane operacje”.

Rozdział 13. Administracja

W tym rozdziale znajdziesz informacje dotyczące administracji systemem PLD

Ratowanie systemu

Wstęp

W tym rozdziale pokażemy co można zrobić w wypadku, jeśli nastąpiła awaria systemu, uniemożliwiająca normalne uruchomienie. Musimy uzyskać dostęp do urządzeń lub plików na dysku twardym, możemy w tym celu spróbować uruchomić system na niskim poziomie pracy, a jeśli to się nie powiedzie, to użyć operacji chroota z innego systemu np. dystrybucji typu live.

Uruchomienie na niskim poziomie pracy

Możemy uruchomić system z pominięciem wielu czynności wykonywanych przez skrypty startowe. Operacja polega na przekazaniu do kernela odpowiednich parametrów, które wymuszą użycie przez proces init specjalnie przygotowanego zestawu rc-skryptów.

Interesuje nas poziom 1 lub single (tryb jednego użytkownika), tak też nazywają się parametry, które musimy przekazać do kernela. Parametry przekazujemy do jądra za pośrednictwem bootloadera, w trakcie uruchomienia systemu np.:

grub append> root=/dev/sda2 single

Szczegółowy opis bootloadera i przekazywanie parametrów kernela opisano w „Wstęp”. Poziomy pracy zostały szerzej omówione w „Zmiana poziomu pracy systemu”

Uruchomienie RescueCD

Jako dystrybucję Live najlepiej wybrać RescueCD lub PLD Live. Oba projekty są dobrze przygotowane do pracy z naszą dystrybucją, gdyż zawierają program rpm™ i poldek™.

Na początek musimy zadbać o to, aby system mógł się uruchomić z płyty CD, uzyskamy to modyfikując odpowiednią opcję BIOS-u komputera. Teraz uruchamiamy komputer z RescueCD umieszczonym w napędzie CD-ROM i czekamy aż system się uruchomi.

Aby dokonać napraw musi zostać załadowany moduł kontrolera masowego. Większość współczesnych dystrybucji typu live sama wykrywa sprzęt, jeśli jednak to się nie powiedzie lub używamy starej wersji RescueCD to musimy sami załadować moduł. Jeśli potrzebujemy obsłużyć kontroler typu IDE musimy załadować moduł ide-disk

# modprobe ide-disk

Jeżeli naprawiany system jest oparty na macierzach programowych to musimy je najpierw złożyć np.:

# mdadm -A --auto=yes /dev/md0 /dev/hda /dev/hdb

Więcej szczegółów dotyczących programowych macierzy znajdziemy w „RAID programowy”.

Teraz kiedy mamy załadowane odpowiednie moduły i dostęp do plików urządzeń (w katalogu /dev) możemy wykonać liczne operacje diagnostyczne i naprawcze (opisane dalej).

Naprawa systemu plików

Do naprawy systemu plików konieczny jest tylko dostęp do plików urządzeń z katalogu /dev. Aby sprawdzić i naprawić system plików XFS wydajemy polecenie:

# xfs_repair /dev/sda2

Naprawy systemów plików została szczegółowo omówiona w „Naprawa”.

Naprawa konfiguracji

W przypadku podniesienia systemu w trybie single mamy swobodny dostęp do plików konfiguracji, w przeciwnym wypadku musimy najpierw podmontować odpowiednią partycję aby uzyskać dostęp do plików. W tym celu tworzymy nowy katalog, a następnie montujemy do niego właściwe urządzenie np.:

# mkdir -p /mnt/rootfs
# mount /dev/hda3 /mnt/rootfs

Jeżeli masz więcej partycji, na których znajdują się pliki systemowe (np. /boot), także je podmontuj w odpowiednich katalogach np.:

# mount /dev/hda1 /mnt/rootfs/boot 

mamy teraz nieograniczony dostęp do plików uszkodzonego systemu.

Operacja chroota

Jeśli uruchomiliśmy system z RescueCD i mamy podmontowane systemy plików to wielu wypadkach wygodniejsze, a czasami nawet konieczne będzie wykonanie tzw. chroot-a.. Polega to na podmianie głównego systemu plików używanego przez dany program na główny system plików ratowanego systemu operacyjnego. Będzie to konieczne przy problemach z jądrem, bootloaderem czy initrd. Aby wykonać tą operację należy wykonać komendę:

# chroot /mnt/rootfs

To polecenie uruchomi powłokę /bin/sh w taki sposób, że wszystkie działania z jej poziomu będą odbywały się przeźroczyście na podmontowanym systemie plików. Zanim jednak zabierzemy się do pracy proszę o zapoznanie się z uwagami na końcu rozdziału. Jeśli używamy powłoki korzystającej z chroot-a, wystarczy że zakończymy jej pracę wydając polecenie exit lub skrótem klawiszowym ctrl+d. Na koniec odmontowujemy systemy plików jeśli takie są i restartujemy komputer.

Uwagi

  • Niektóre operacje w środowisku chroot wymagają (np. tworzenie initrd) podmontowania pseudo systemu plików /proc:

    # mount /proc /mnt/rootfs/proc -o bind

  • Użytkownicy udeva powinni pamiętać, że wiele operacji w podmontowanym środowisku wymagają istnienia kompletu plików urządzeń:

    # mount /dev /mnt/rootfs/dev -o bind

    Udev dokładniej opisano w „Udev - dynamiczna obsługa sprzętu”.

  • Może się zdarzyć, że poldek się nie uruchamia w chroocie. Sposobem na obejście tego jest uruchomienie go z flagą -r , np:

    # poldek -r /mnt/rootfs

  • Dużą zaletą RescueCD jest to, że automatycznie "podnosi" interfejs sieciowy z obsługą DHCP oraz serwer SSH. Pozwala to na zdalną naprawę, wystarczy, że ktoś umieści płytę z dystrybucją w napędzie i uruchomi komputer. My zalogujemy się na odpowiedni adres za pośrednictwem SSH; login: root, hasło: pld.

Zarządzanie podsystemami i usługami

W systemie dostępne są specjalne skrypty, napisane w języku powłoki, zwane "skryptami startowymi" lub "rc-skryptami". W PLD™ zastosowano skrypty startowe typu System-V, dzięki temu praca administratora jest znacząco zautomatyzowana.

Za pomocą rc-skryptów pomocą możemy uruchamiać lub zatrzymywać podsystemy i usługi, kontrolować ich działanie oraz wiele innych. Można je podzielić na dwie zasadnicze grupy:

  • Skrypty podsystemów - specjalnych zadań mających za zadanie dokonać konfiguracji systemu operacyjnego. Do tego typu zadań należą: konfigurowanie sieci, ładowanie modułów, prace porządkowe i wiele innych. Te skrypty są integralną częścią systemu (pakiet rc-scripts) i zapewne są już u nas zainstalowane.

  • Skrypty zarządzania usługami - zarządzają programami działające w tle (demonami) np.: serwerem WWW, serwerem NFS. Skrypty te są instalowane automatycznie razem z pakietami usług. Wyjątek stanowią usługi z wydzielonymi w tym celu pakietami, rozpoznamy je po nazwie *-init i *-standalone. Więcej o nazewnictwie pakietów przedstawiono w „Cechy pakietów w PLD”.

Budowa systemu rc-skryptów

Katalog /etc/rc.d przechowuje konfigurację uruchamiania usług i podsystemów, poniżej pokrótce omówiono składniki systemu rc-skryptów:

  • /etc/rc.d/init.d - katalog z skryptami startowymi usług

  • /etc/rc.d/rc{$NR}.d - katalogi tak oznaczone zawierają łącza symboliczne do skryptów zawartych w katalogu init.d. Wartość {$NR} jest liczbą wskazującą poziom pracy (run level), dla którego uruchamiana jest zawartość danego katalogu.

  • /etc/rc.d/rc - skrypt uruchamiający i zatrzymujący usługi

  • /etc/rc.d/rc.init - skrypt ustawiający opcje narodowe (język, waluta) pobiera konfigurację z pliku /etc/sysconfig/i18n

  • /etc/rc.d/rc.local - uruchamiany na samym końcu wszystkich skryptów, użytkownicy mogą dodawać tu swoje wpisy jeśli nie chcą używać init.d i rc{$NR}.d

  • /etc/rc.d/rc.serial - konfiguracja portów szeregowych

  • 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 systemu lub restarcie.

  • /etc/profile - plik startowy przy pomocy którego są ustawiane głównie zmienne systemowe

Zarzadzanie podsystememi/usługami

Usługami/podsystemami zarządzamy ręcznie, wykonujemy to za pomocą uruchomienia odpowiedniego skryptu z katalogu /etc/rc.d/init.d/. Dodatkowo podajemy odpowiednim parametr określający akcję, którą skrypt ma wykonać. Uruchomienie bez parametru podaje listę możliwych dla niego akcji, dla przykładu wyświetlimy listę dostępnych parametrów podsystemu sieci:

# /etc/rc.d/init.d/network
Usage: /etc/rc.d/init.d/network {start|stop|restart|status}

Poniżej przedstawiono wyłączenie obsługi sieci, oraz ponowne jej uruchomienie. W ten sposób zmusza się usługę lub podsystem do ponownego odczytania swojej konfiguracji. W tym wypadku nastąpi skonfigurowanie na nowo interfejsów, zaktualizowanie ustawień, 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ępnych parametrów będzie się zmieniać w zależności od usługi, w poniższej tabeli przedstawiono znacznie tych najczęściej spotykanych:

Tabela 13.1. Popularne akcje skryptów startowych

ParametrAkcja
startUruchamia podsystem/usługę
stopZatrzymuje podsystem/usługę
reload, force-reload Przeładowanie usługi poprzez wysłanie sygnału (zwykle HUP) do demona, często oba podane parametry mają takie same działanie. Operacja uż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 używana do ponownego odczytania konfiguracji demona.
status Wyświetla stan podsystemu/usługi, dzięki temu możemy łatwo określić czy czy jest uruchomiony. W niektórych wypadkach podawane są dodatkowe informacje.

Niektóre usługi posiadają inne, użyteczne tylko dla nich parametry. Przykładem może być argument init, który zazwyczaj musi być użyty przed pierwszym uruchomieniem usługi.

Nieco wygodniej zarządza się skryptami przy pomocy programu service. Aby wykonać za jego pomocą taki sam efekt jak powyżej musimy go wywołać z dwoma parametrami, pierwszy to nazwa skryptu, drugi zaś to wybrana akcja:

# service network stop
# service network start

Domyślnie po zainstalowaniu nowego podsystemu lub usługi, dodawane są potrzebne skrypty startowe. Dzięki temu nowo zainstalowane oprogramowanie uruchamia się automatycznie w trakcie startu systemu lub przy zmianie poziomu pracy. Aby uruchomić dopiero co zainstalowany podsystem lub usługę musimy wykonać to "ręcznie".

  • Zarządzanie skryptami startowymi w trakcie instalacji/aktualizacji pakietów opisano w „Cechy pakietów w PLD”

  • Jeśli zechcemy utworzyć własny rc-skrypt to z pomocą 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 bezpośrednio, w PLD służ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ększość tych plików jest bezpośrednio załączana do kodu rc-skryptów, zatem ich składnia musi odpowiadać składni powłoki wskazanej w skrypcie (w PLD jest to /bin/sh). Dotyczy to także plików konfiguracji interfejsów sieciowych w katalogu /etc/sysconfig/interfaces. W plikach tych występują jedynie konstrukcje przypisania zamiennych oraz ewentualne komentarze. Możemy co prawda umieszczać tam dowolne komendy wiersza poleceń, jednak należy być przy tym niezwykle ostrożnym i robić to tylko w uzasadnionych przypadkach. Jest jednak kilka plików konfiguracji, które są traktowane inaczej - mają własną składnię, przykładem tego rozwiązania są np. pliki /etc/sysconfig/static-*, nimi jednak nie będziemy się zajmować w tym rozdziale.

Opcje w plikach konfiguracji można podzielić na dwie grupy: ogólnego stosowania i specyficzne dla rc-skryptu. Pierwsza z nich to uniwersalne opcje, z którymi możemy się zetknąć w wielu w innych plikach konfiguracji np.:

  • SERVICE_RUN_NICE_LEVEL - priorytet procesów usługi (liczba nice)

  • RPM_SKIP_AUTO_RESTART - mówi programowi rpm czy usługa ma być automatycznie restartowana po aktualizacji, więcej o tej opcji w „Cechy pakietów w PLD”

Druga grupa to opcje występujące tylko w pliku konfiguracji konkretnego rc-skryptu - zwykle są związane z argumentami pliku wykonywalnego usługi, dlatego należy uważnie czytać komentarze plików konfiguracji i w razie potrzeby podręczniki systemowe usług.

Zależności

Pomiędzy niektórymi demonami i podsystemami istnieją ścisłe powiązania, jako przykład można wymienić usługi sieciowe i podsystem sieci. Usługa jest zależna od działania sieci i próba wyłączenia najpierw tej drugiej może niekiedy zaowocować problemami, gdyż PLD nie dba o to za nas. Musimy samemu się zatroszczyć o wyłączanie usług we właściwej kolejności.

Pewną wskazówką będą numery przy nazwach łączy symbolicznych w katalogach /etc/rc.d/rc{$nr}.d (przy literze S). Numery te określają kolejność ł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 pracują usługi można zarządzać ręcznie, jest to jednak niezalecany sposób, lepszym pomysłem jest użycie programu chkconfig. Aby wyświetlić listę usług uruchamianych przy w danych poziomach pracy wydajemy polecenie:

# chkconfig --list
crond           0:wył.  1:wył.  2:wł.   3:wł.   4:wł.   5:wł.   6:wył.
cups            0:wył.  1:wył.  2:wł.   3:wł.   4:wł.   5:wł.   6:wył.
sshd            0:wył.  1:wył.  2:wył.  3:wł.   4:wł.   5:wł.   6:wył.
gdm             0:wył.  1:wył.  2:wył.  3:wył.  4:wył.  5:wł.   6:wył.
network         0:wył.  1:wył.  2:wł.   3:wł.   4:wł.   5:wł.   6:wył.
sshd            0:nie   1:nie   2:nie   3:nie   4:tak   5:nie   6:nie

W PLD najczęściej korzysta się z trybów 3 i 5 rzadziej z: 1, 2 i 4, nigdy nie ustawiamy trybu 0 (restart) i 6 (wyłączenie). Na powyższym przykładzie podsystem network jest uruchamiana dla poziomów: 2,3,4,5, zaś gdm tylko dla trybu 5. Aby włączyć/wyłączyć uruchamianie jakiejś usługi wywołujemy program następująco: chkconfig {$usługa} on/off. Wyłączenie usługi sshd™ (domyślnie jest włączona):

# chkconfig sshd off

Włączenie analogicznie:

# chkconfig sshd on

Poziomy dla których usługa ma być włączona/wyłączona jest wskazywane przez specjalny wpis w rc-skrypcie, możemy go odczytać następująco:

$ grep chkconfig /etc/init.d/sshd
# chkconfig:    345 55 45

pierwszy ciąg cyfr w wierszu to lista poziomów, których dotyczy operacja włączenia/wyłączenia rc-skryptu. W razie potrzeby możemy wymusić operację 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 zrobić musimy wykonać to ręcznie lub zmienić tryb pracy. Poziomy pracy zostały szerzej omówione w „Zmiana poziomu pracy systemu”.

Zmiana poziomu pracy systemu

PLD jest systemem uniksowym, a więc obsługuje tzw. poziomy pracy (ang. run levels). Poziom pracy jest to specjalna konfiguracja systemu, która pozwala zaistnieć tylko wytypowanym usługom bądź podsystemom. Mamy sporo swobody w wyborze usług pracujących bądź wyłączonych w danym poziomie pracy, opis jak nimi zarządzać znajdziemy w „Zarządzanie podsystemami i usługami”.

Tabela 13.2. Dostępne poziomy pracy

PoziomOpis
1 Konfiguracja z minimalną ilością uruchamianych podsystemów. Nie ma obsługi sieci i nie zezwala na logowanie się innym użytkownikom.
2 Rzadko używany tryb wielu użytkowników. Uruchamiana jest obsługa sieci i większości usług oprócz NFS.
3 Popularny tryb prac z dostępem wielu użytkowników i uruchomieniem wszystkich usług. Jest to typowy tryb dla maszyn obsługiwanych z konsoli tekstowej - np.: serwerów.
4 Rzadko używany tryb wielu użytkowników. - praca w konsoli tekstowej
5 Typowy tryb z dostępem wielu użytkowników uruchamiający system X-Window™ (uruchamia demon GDM lub KDM). Poziom używany na stacjach roboczych z GUI. Więcej o sposobach uruchamiania X-Window w „X-Server”.
single Tryb jednego użytkownika (ang. Single user mode) - używany przez administratorów w sytuacjach awaryjnych. Uruchamia mniej skryptów startowych niż pierwszy poziom. Jego włączanie ma sens tylko przez przekazanie do jądra parametru single z poziomu bootloadera.


Są jeszcze dwa tryby: tryb 0 i 6. Pierwszy jest używany w celu zatrzymania wszystkich usług i podsystemów przed zamknięciem systemu, drugi zaś przed ponownym uruchomieniem systemu. Z pośród wymienionych poziomów pracy najczęściej używa się poziomu 3 lub 5.

Poziomem pracy zarządza proces init. W celu określenia domyślnego poziomu pracy, init odczytuje swój plik konfiguracji (/etc/inittab) podczas uruchomienia systemu. Po uruchomieniu administrator może wymusić zmianę poziomu za pośrednictwem programu telinit (link symboliczny do programu init). Należy pamiętać o tym, że telinit nie dokonuje zmian w pliku /etc/inittab, tak więc przy ponownym uruchomieniu systemu wybrany zostanie ustawiony w nim poziom pracy. Więcej informacji o pliku /etc/inittab znajdziemy w „Kluczowe pliki”.

Za domyślny poziom pracy odpowiada opcja "initdefault", może ona przyjąć wartość od 1 do 5 np.:

id:3:initdefault:

Powyższy przykład włączy system na trzecim poziomie pracy, jest domyślna wartość w PLD.

W wyniku zmiany poziomu zostaną zatrzymane wszystkie wszystkie podsystemy wyłączone z pracy na tym poziomie, zaś te które mają działać zostaną uruchomione. Przykładowo jeśli chcemy przejść do trybu 2 użyjemy polecenia:

# telinit 2

Jeśli system do tej pory pracował w trybie 3 to wyłączona zostanie usługa NFS.

Możemy również określić poziom uruchomienia przed startem systemu, dokonujemy tego za pomocą parametrów przekazywanych za pośrednictwem bootloadera. Więcej szczegółów na ten temat znajdziemy w „Wstęp”.

Konta użytkowników

W PLD zastosowano klasyczny dla systemów uniksowych system kont użytkowników, tak więc istnieje podział na dwa rodzaje kont: konta systemowe i konta użytkowników. Zarządzanie kontami systemowymi następuje automatycznie w trakcie instalowania bądż usuwania programów, które ich wymagają. Z tego powodu nie musimy się nimi zajmować, zajmiemy się więc tylko kontami zwykłych użytkowników.

W PLD domyślnie instalowanym pakietem do zarządzania kontami jest pakiet shadow. Możemy do jednak zastąpić zbiorem pwdutils, który zawiera narzędzia o większych możliwościach. Dzięki nim nie będzie już konieczności "ręcznego" edytowania plików systemowych, z tego względu opisane zostaną wyłączne narzędzia pwdutils.

Dodanie

Konto użytkownika dodajemy poleceniem useradd -m {$nazwa_użytkownika} np.:

# useradd -m jkowalski

Powyższe polecenie doda konto o identyfikatorze 'jkowalski' i utworzy katalog domowy (parametr "-m"). Dodatkowo do stworzonego katalogu skopiowana zostaje zawartość katalogu /etc/skel. Domyślna konfiguracja konta jest tworzona na podstawie opcji z plików: /etc/default/useradd i /etc/login.defs. Najważniejsze opcje pierwszego z nich to:

  • GROUP - identyfikator grupy głównej - domyślnie: 1000 (users)

  • HOME - miejsce przechowywania katalogów domowych - domyślnie: /home/users

  • SHELL - powłoka - domyślnie: /bin/bash

Drugi określa bardziej zaawansowane opcje, najważniejsze z nich to:

  • PASS_MAX_DAYS - liczba dni do wygaśnięcia hasła -domyślnie: 99999

  • PASS_MIN_DAYS - minimalna liczba dni do między zmianami hasła -domyślnie: 0

  • PASS_WARN_AGE - ilość dni przez które będzie pokazywane ostrzeżenie o wygaśnięciu hasła - domyślnie: 7

Wiele opcji kont zawartych w tych plikach można łatwo modyfikować, poprzez przekazanie odpowiednich parametrów do programu useradd oraz passwd, więcej informacji na ten temat uzyskamy w podręczniku systemowym. Jeśli chcemy utworzyć większa ilość kont o zmodyfikowanych parametrach to wygodniejsze będzie ustawienie interesujących nas wartości w podanych powyżej plikach.

Jeśli użytkownik ma konto na wielu maszynach dobrym zwyczajem jest nadawanie takiego samego numeru użytkownika (UID) dla każdego z kont. W przypadku programu useradd należy użyć opcji "-u".

Na koniec administrator musi ustawić hasło dla danego użytkownika.

Usunięcie

Aby usunąć konto użyjemy programu userdel:

# userdel jkowalski

Warto wspomnieć tu o opcjach "-r" i "-f", pierwsza usuwa katalog domowy, druga wymusza usunięcie również plików z katalogu domowego nawet jeśli do niego nie należą.

Ze względów bezpieczeństwa można polecić blokowanie kont użytkowników w miejsce ich usuwania, w ten sposób możemy się ochronić przed sytuacją powrotu do użytku numeru UID usuniętego użytkownika.

Modyfikacja

Dane użytkownika modyfikujemy poleceniem usermod, dokładny opis tego programu znajdziemy w manualu.

Hasło

Pierwsze hasło dla użytkownika jest nadawane przez administratora, każdą następną jego modyfikację użytkownik może wykonywać samodzielnie.

Ustawienie hasła przez administratora: passwd {$nazwa_użytkownika}

# passwd jkowalski
Changing password for jkowalski.
New UNIX password:  
Retype new UNIX password:

Zwykły użytkownik zmienia swoje hasło również poleceniem passwd, tyle że bez podawania parametru. Administrator może zmusić użytkownika do zmiany hasła tuż po zalogowaniu:

# passwd -e jkowalski

Zarządzanie kontami

Hasło blokujemy poleceniem: passwd -l {$nazwa_użytkownika} np.:

# passwd -l jkowalski

Aby odblokować użyjemy parametru parametru "-u" np.:

# passwd -u jkowalski

Musimy pamiętać, że powyższe polecenia nie blokują dostępu opartego o inną metodę autoryzacji niż hasło, np. o klucz SSH. W takim wypadku dodatkowo powinniśmy zmienić powłokę użytkownikowi na nie figurującą w /etc/shells np.:

# usermod -s /bin/false jkowalski

Grupy

W PLD zastosowano klasyczny dla systemów uniksowych system grup, tak więc istnieje podział na dwa rodzaje grup: grupy systemowe i grupy użytkowników. Grupy te rozróżniamy na podstawie identyfikatorów grupowych (GID), dla grup użytkowników przeznaczone są wartości 1000 i więcej. Ponadto grupy systemowe często przyjmują nazwy podobne jak nazwy usług np: ftp, named, itp.

Zarządzanie grupami systemowymi następuje automatycznie w trakcie instalowania bądź usuwania pakietów, z tego powodu nie należy w nie ingerować. W naszej dystrybucji zarządzanie grupami zazwyczaj sprowadza się do dodawania/usuwania własnych grup oraz zarządzania uczestnictwem w istniejących grupach.

W PLD domyślnie instalowanym pakietem do zarządzania grupami jest pakiet shadow. Możemy do jednak zastąpić zbiorem pwdutils, który zawiera narzędzia o większych możliwościach. Dzięki nim nie będzie już konieczności "ręcznego" edytowania plików systemowych, z tego względu opisane zostaną wyłączne narzędzia pwdutils.

Dodanie grupy

Używamy polecenia groupadd {$nazwa_grupy} np.:

# groupadd kadry

Jeśli tworzymy takie same grupy na wielu maszynach, to dobrym zwyczajem jest nadawanie takiego samego numeru grupy (GID) dla każdej z grup. Dowolny GID narzucamy w trakcie tworzenia grupy programem groupadd z użyciem opcji "-g".

Zapisanie do grup

Dzięki poleceniu id {$nazwa_użytkownika} sprawdzimy do jakich grup zapisany jest użytkownik, jeśli nie podamy nazwy konta to zostanie wyświetlona informacja o aktualnie używanym koncie np.

$id jkowalski
uid=500(jkowalski) gid=1000(users) grupy=1000(users),10(wheel),19(floppy),23(audio)

Program zwrócił wartości: UID, GID i listę grup do których zapisany jest użytkownik jkowalski: users, wheel, floppy, audio

Zapisanie do grupy następuje po wykonaniu polecenia groupmod -A {$konto_użytkownika} {$grupa} np.

groupmod -A jkowalski kadry

Aby wyrejestrować użytkownika z grupy musimy użyć parametru "-R" np.

groupmod -R jkowalski kadry

Usunięcie grupy

Używamy polecenia groupdel {$nazwa_grupy}:

# groupdel kadry

Uwagi

  • Po każdej modyfikacji uczestnictwa w grupach, użytkownik musi się ponownie zalogować, aby wprowadzone zmiany zaczęły obowiązywać.

  • Zapisanie użytkownika do grupy służy podniesieniu jego uprawnień, listę przywilejów jakie uzyska zamieszczono w „Zarządzanie uprawnieniami”.

Zarządzanie uprawnieniami

W PLD zastosowano restrykcyjny poziom bezpieczeństwa, zwykły użytkownik domyślnie ma minimalne możliwe uprawnienia. Aby je zwiększyć administrator musi zapisać użytkownika do odpowiednich grup, poniżej została przedstawiona skrócona ich lista i odpowiadające im "przywileje" lub funkcje.

Tabela 13.3.

GIDNazwaWłaściciel/Uprawnienia
0rootgrupa administracyjna - wysokie uprawnienia w całym systemie
3sysodczyt niektórych plików systemowych np. konfiguracji i logów systemu druku CUPS
4admmożliwość korzystania z narzędzi takich jak: tarcerouote, ping, arping, clockdiff
6diskbezpośredni dostęp do urządzeń masowych np. naprawy i tworzenie systemów plików, odtwarzanie i nagrywanie CD
7lpdostęp do portu drukarki: równoległego, USB
9kmemodczyt z urządzeń /dev/mem, /dev/kmem
10wheelmożliwość korzystania z programu su
17procdostęp do pseudosystemu plików /proc (np. wgląd do procesów innych użytkowników)
19floppymożliwość niskopoziomowego formatowania dyskietek i tworzenia na nich systemu plików
22utmpzapis do plików /var/run/utmpx, /var/log/wtmp, /var/log/lastlog
23audiodostęp do karty dźwiękowej
27cdwritedostęp do narzędzi nagrywania płyt CD
28fsctrlgrupa której można używać do nadawania praw dla plików na montowanych urządzeniach
50ftpgrupa systemowa serwera FTP: odczyt plików konfiguracji
51httpgrupa systemowa serwera WWW
117crontabodczytywanie konfiguracji demona CRON
123statsgrupa używana do potrzeb automatycznie generowanych statystyk (mrtg, calamaris, itd.)
124logsgrupa odczytu niektórych logów
138filesharemożliwość udostępniania zasobów NFS i SMB (zapis do /etc/exports, /etc/samba/smb.conf)
1000usersdomyślna grupa główna dla zwykłych użytkowników

Dużo więcej informacji o grupach i użytkownikach znajdziemy w dokumencie uid_gid.db.txt trzymanym w CVS-ie. Zapisywanie do grup opisano w „Grupy”.

Bezpieczeństwo

Bezpieczeństwo systemów i danych to rozległy temat dlatego głównie skupimy się na aspektach dotyczących PLD.

Dostępne narzędzia

PLD jako dystrybucja "robiona przez administratorów dla administratorów" ma duże zasoby programów użytecznych w zakresie bezpieczeństwa, poczynając od NetCata™ (nc), a na wiresharku™ i nessusie™ kończąc.

Dostęp do konta root

Nasza polityka bezpieczeństwa wymaga, aby użytkownik należał do grupy wheel, jeśli chce zwiększyć swoje uprawnienia za pomocą su i sudo. W ten sposób atakujący musi zgadnąć trzy parametry zamiast jednego (nazwa użytkownika, hasło i hasło administratora zamiast samego hasła administratora). Nie ma też możliwości zdalnego zalogowania się bezpośrednio na konto roota (z tych samych powodów). Dodatkowo root nie może zdalnie używać innych usług (ftp, imap, pop3, smtp) m.in z powodu niedostatecznie silnego szyfrowania transmisji.

SUID

Domyślnie zwykli użytkownicy nie mają prawa wykonania programów z ustawionym bitem SUID. Aby takie prawo uzyskać muszą być zapisani do odpowiedniej grupy. Przykładowo program ping wymaga zapisania do grupy adm. Poglądowe zestawienie grup zamieściliśmy w „Zarządzanie uprawnieniami”.

/proc

Domyślnie użytkownicy nie widzą żadnych procesów poza swoimi. Jest to nie tylko krok w stronę bezpieczeństwa, ale i w wygody, użytkownik nie głowi się 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 użytkownik widział wszystkie procesy należy go zapisać do grupy /proc.

chroot i vserver

PLD oferuje system sys-chroot, wbudowany w rc-skrypty, służący do wygodnego zarządzania środowiskami typu chroot. Usługi, które wspierają natywnie chrooty (np. Bind™) działają w izolowanym środowisku od razu po instalacji.

PLD wspiera także mechanizm Linux VServers, zwany potocznie "chrootem na sterydach". Wymaga on zainstalowania odpowiedniej wersji kernela i odpowiedniego zestawu narzędzi.

Statyczny VIM

Najważniejszym narzędziem administracyjnym jest edytor tekstu, dlatego nie powinniśmy pozostać bez takiego programu, co może mieć miejsce np. przy uszkodzeniu systemu plików. Tu z pomocą 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 związane z bezpieczeństwem zostały omówione w „Bezpieczeństwo”.

Rozdział 14. Interfejsy sieciowe

W tym rozdziale znajdziesz informacje dotyczące konfiguracji sieci

Wstęp

Pierwszą rzeczą jaką musimy zrobić to ustalić wszystkie konieczne parametry połączenia sieciowego. W razie wątpliwości należy skontaktować się z naszym dostawcą usług internetowych. Ten rozdział opisuje konfigurację interfejsów sieciowych, testowanie połączenia oraz inne prace diagnostyczne przeprowadzimy za pomocą narzędzi opisanych w „Narzędzia sieciowe”.

Zarządzanie całym podsystemem sieci (włączanie, wyłączanie, restart) dokonujemy za pomocą rc-skryptu network, więcej informacji o zarządzaniu rc-skryptami znajdziemy w „Zarządzanie podsystemami i usługami”. Jest on integralną częścią PLD i startuje automatycznie w trakcie uruchomienia systemu. Aby skonfigurować sieć potrzebujemy jedynie ustawić podstawowe parametry sieci (opisane w następnym rozdziale) oraz prawidłowo skonfigurować interfejs(y).

Konfigurację proxy opisano szczegółowo w „Proxy”.

Jeśli mamy zamiar modyfikować konfigurację sieci na zdalnej maszynie (np. przez ssh), to zalecane jest użycie programu screen, aby mieć pewność, że cała procedura zakończy się poprawnie i nie utracimy kontaktu z hostem. Jeśli mamy program screen wystarczy że wydamy polecenie:

# screen service network restart

Podstawowa konfiguracja sieci

W większości wypadków konfiguracja sieci (oprócz ustawień interfejsu sieciowego) będzie się składała ze wskazania domyślnej bramy i serwerów DNS dla resolvera. Wiele zaawansowanych opcji sieci (np. przekazywanie pakietów) ustawianych jest w pliku konfiguracji jądra: /etc/sysctl.conf, parametry te zostały omówione w „Parametry jądra”.

Brama domyślna

Jeśli nie korzystamy z serwera DHCP ustawiamy statyczną trasę routingu do domyślnej bramy, w tym celu edytujemy plik /etc/sysconfig/static-routes - wpis może wyglądać następująco:

eth0 default via 192.168.0.1

Odwzorowanie nazw - serwery DNS

Wskazanie serwerów DNS jest obowiązkową pozycją konfiguracji resolvera nazw. Operacja ta następuje automatycznie, o ile korzystamy z serwera DHCP, w przeciwnym wypadku musimy podać ich adresy samodzielnie. Serwery nazw ustawiamy edytując plik /etc/resolv.conf. Jeśli go nie ma, to możemy go utworzyć za pomocą dowolnego edytora lub poleceniem touch. Podajemy przynajmniej jeden (zazwyczaj nie więcej niż dwa) serwer nazw za pomocą słowa kluczowego nameserver np.:

nameserver 192.168.0.12

Nazwa hosta

Możemy ustawić nazwę, za pomocą której nasza maszyna będzie się przedstawiała zalogowanym użytkownikom, i niektórym programom. W pliku /etc/sysconfig/network ustawiamy:

HOSTNAME=pldmachine

Dla porządku warto by była zgodna z adresem FQDN (o ile jest nadany). Niekiedy podaną tu nazwę należy dopisać do pliku /etc/hosts opisanego w dalszej części rozdziału.

Odwzorowanie nazw - konfiguracja zaawansowana

Plik /etc/host.conf zawiera podstawowe opcje resolvera nazw, w większości wypadków wystarczy domyślna konfiguracja:

order hosts,bind
multi on

Pierwsza pozycja wskazuje kolejność używania metod szukania adresów hostów, w podanym przykładzie najpierw będzie przeszukiwany plik /etc/hosts, w drugiej kolejności będą odpytywane serwery DNS. Drugi wiersz zezwala na zwracanie więcej niż jednego adresu IP z pliku /etc/hosts (o ile przypisano większą liczbę adresów do nazwy).

W pliku /etc/hosts można dodawać odwzorowania hostów, które są uzupełnieniem dla usługi DNS, jedyny wymagany wpis to wskazanie adresu IP pętli zwrotnej dla nazwy localhost:

127.0.0.1       localhost

Oprócz nielicznych wyjątków, inne wpisy nie są tu konieczne, Dla potrzeb niektórych programów trzeba dopisać do powyższego wiersza nazwę hosta ustawionego za pomocą opisanej powyżej opcji HOSTNAME:

127.0.0.1       localhost styx

przykład wpisu dla programu wymagającego przypisania pełnej nazwy domenowej:

213.25.115.88 platinum.elsat.net.pl

Rozwiązanie to służy do szybszej identyfikacji komputerów w sieci lub prac diagnostycznych. Aby w ogóle z tego skorzystać musimy ustawić odpowiednią kolejność przeszukiwania w pliku /etc/host.conf

Jeśli często odwołujemy się do maszyn w naszej domenie to możemy ułatwić sobie życie i ustawić domenę domyślną w pliku /etc/resolv.conf. Od tej pory podanie samej nazwy hosta (bez części domenowej), będzie uważane za podanie pełnego adresu. Przykładowe ustawienie domyślnej domeny (np. jakasdomena.cos) podano poniżej:

domain jakasdomena.cos

Inne opcje

Edytujemy plik /etc/sysconfig/network, domyślne wartości opcji z tego pliku w zupełności wystarczają do typowego korzystania z sieci i nie ma potrzeby nic modyfikować w nim.

NETWORKING=yes

Ustawiamy na "yes" jeżeli w ogóle chcemy komunikować się z siecią.

IPV4_NETWORKING=yes

Ustawiamy na "yes" jeżeli będziemy korzystać z protokołu IPv4 (wymagany do korzystania z Internetu).

NISDOMAIN=

Domena NIS, jeśli nie korzystasz z tej usługi sieciowej, lub nie jesteś pewien pozostaw to pole puste.

GATEWAY=192.168.0.254
GATEWAYDEV=eth0

Opcje za pomocą których możemy ustawić trasę routingu do domyślnej bramy. Opcje te zostały uznane za przestarzałe, obecnie należy korzystać z pliku /etc/sysconfig/static-routes.

Ethernet

Urządzenie

Większość dostępnych na rynku kart sieciowych jest oparta na układach Realteka, 3Com bądź Intela, dzięki temu nie będzie problemów z uruchomieniem urządzenia. Karty sieciowe są automatycznie wykrywane przez jądro i nadawane są im nazwy kolejno: eth0, eth1, eth2, itd. Jedyną rzeczą jaka pozostaje to załadowanie odpowiedniego modułu dla danego urządzenia, proces ten dokładnie opisano tutaj: „Moduły jądra”.

Pliki konfiguracyjne interfejsów są przechowywane w katalogu /etc/sysconfig/interfaces, nazwy tych plików będą miały kolejno nazwy ifcfg-eth0, ifcfg-eth1, ifcfg-eth2, itd. W tym rozdziale założono, że konfigurujemy pierwszy interfejs (eth0). Pliki te modyfikujemy za pomocą dowolnego edytora tekstu np.

# vim /etc/sysconfig/interfaces/ifcfg-eth0

Statyczna konfiguracja karty sieciowej

Zaczynamy od zmodyfikowania lub utworzenia pliku /etc/sysconfig/interfaces/ifcfg-eth0, aby karta działała poprawnie powinieneś mieć tam podobne ustawienia:

DEVICE="eth0"

Powyższa opcja ta określa nazwę urządzenia.

IPADDR="192.168.0.2/24"

Ta opcja określa adres karty sieciowej oraz maskę podsieci. Maskę podsieci podajemy w notacji CIDR - "/24" odpowiada masce 255.255.255.0.

ONBOOT="yes"

Ustaw na "yes" jeśli chcesz aby interfejs automatycznie podnosił się razem z podsystemem sieci.

BOOTPROTO="none"

Ta opcja pozwala dokonać wyboru, w jaki sposób karta sieciowa ma otrzymywać konfigurację. Powyższy wpis sprawia, że system pobiera wszystkie ustawienia z posiadanych plików konfiguracyjnych.

Na końcu aktywujemy sieć.

Dynamiczna konfiguracja karty sieciowej (DHCP)

Na początek wybieramy jeden z programów klienckich: dhcpcd lub pump:

# poldek -i dhcpcd

Nasze zadanie ogranicza się do zmiany jednego parametru w pliku /etc/sysconfig/interfaces/ifcfg-eth0. Odszukujemy w nim opcję BOOTPROTO i wskazujemy klienta DHCP, który ma być użyty:

BOOTPROTO="dhcp"

Na koniec dokonujemy aktywacji interfejsu.

Mała uwaga: przy użyciu DHCP statyczne opcje sieciowe (adres IP, maska podsieci, brama) umieszczone w plikach konfiguracyjnych będą ignorowane, zaś zawartość pliku /etc/resolv.conf będzie nadpisywana informacjami przyznanymi przez serwer DHCP.

Aktywacja sieci

Ostatnią czynnością jest uruchomienie lub restart podsystemu sieci:

# /etc/rc.d/init.d/network start
Ustawianie parametrów sieci....................[ ZROBIONE ]
Podnoszenie interfejsu eth0....................[ ZROBIONE ]

WiFi

Wstęp

W przypadku laptopa dobrym pomysłem jest użycie jakiejś aplikacji X-Window do konfiguracji WiFi, z możliwością łatwego przełączania pomiędzy sieciami oraz automatycznym wykrywanie podłączenia kabla do karty Ethernet. Takie możliwości zapewnia np. NetworkManager™ (korzysta z aplikacji wpa_supplicant™), przeznaczony dla środowiska Gnome. W przypadku stacjonarnych maszyn konfiguracja rc-skryptów powinna być wystarczająca w większości wypadków.

W naszych przykładach przedstawimy konfigurację dla sieci bezprzewodowej działającej w trybie trybie infrastruktury (managed), o określonym identyfikatorze SSID i zabezpieczonej kluczem WEP oraz WPA2-PSK (WPA2 Personal). WEP zawiera zbyt dużo słabych punktów i jest podatny na szybkie złamanie, dlatego o ile nie jesteśmy ograniczeni sprzętem to należy używać właśnie WPA2.

Niektóre karty sieciowe WiFi mają dedykowane sterowniki i ich konfiguracja nie sprawia większych kłopotów, w pozostałych wypadkach posłużymy się sterownikami dla systemu Microsoft Windows, uruchomionymi dzięki aplikacji NdisWrapper™. Jest to możliwe dzięki temu, że większość 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ługujących sterowniki kart WLAN, sterowniki rozwijane niezależnie są dostępne w osobnych pakietach kernel-net-* Przykładowo zainstalujemy moduł dla kart Atheros:

$ poldek -i kernel-net-madwifi-ng

musimy załadować moduł:

# modprobe ath_pci

Jeśli nie UDEV ładuje nam moduł kernela, to musimy dodać jego nazwę do pliku /etc/modules lub /etc/modprobe.conf, co zostało szczegółowo opisano w „Moduły jądra”. Teraz możemy przejść do konfiguracji interfejsu.

Sterowniki z NdisWrapperem

Instalujemy pakiety kernel-net-ndiswrapper oraz ndiswrapper:

$ poldek -i ndiswrapper kernel-net-ndiswrapper

Potrzebne nam będą teraz sterowniki windowsowe naszej karty sieciowej. Konkretnie chodzi o pliki z rozszerzeniami *.inf oraz *.sys. Możesz je skopiować 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 zainstalować te sterowniki przy użyciu NdisWrappera.

# ndiswrapper -i /lib/windrivers/sterownik.inf

Jeśli chcemy aby stworzył się alias w pliku /etc/modprobe.conf wykonujemy polecenie:

# ndiswrapper -m

Sieć WEP

Domyślnie rc-skrypty do obsługi WLAN używają pakietu wireless-tools:

$ poldek -i wireless-tools

Kiedy poradziliśmy sobie ze sterownikiem, musimy utworzyć odpowiedni plik konfiguracji, który umieścimy w katalogu /etc/sysconfig/interfaces/. Nazwiemy go ifcfg-wlan0, zaś w przypadku kart z chipsetem Atheros użyjemy nazwy ifcfg-ath0. Przykładową treść takiego pliku zamieszczono poniżej:

DEVICE=wlan0
IPADDR=192.168.0.2/24
ONBOOT=yes
BOOTPROTO=dhcp

WLAN_ESSID=nasza_nazwa_sieci
WLAN_KEY=A638FED41027EA086ECD6825B0

Opcje sieci bezprzewodowej rozpoczynają się się od przedrostka WLAN_, pozostałe parametry (w tym opcje protokołu IP) są takie same jak dla zwykłej karty typu Ethernet, której konfigurację szczegółowo omówiono w „Ethernet”.

Jako urządzenie w opcji DEVICE wskazujemy nadaną przez kernel nazwę. Kartom nadawane są zwykle nazwy wlan0, wlan1, itd. Wyjątkiem od tej reguły są niektóre sterowniki, rozwijane niezależ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 urządzeniu możemy odczytać z komunikatów jądra.

Poniżej przedstawione zostaną parametry sieci WLAN:

WLAN_ESSID=moja_siec

Powyższa opcja to identyfikator ESSID naszej sieci

WLAN_KEY=A638FED41027EA086ECD6825B0

Przy pomocy kolejnej zmiennej podajemy klucz WEP, na przykładzie użyto klucza szesnastkowego, aby podać klucz w postaci ASCII musimy ma jego początku dodać: "s:"

Dodatkowo możemy ustawić szybkość interfejsu:

WLAN_BITRATE=auto

Tą opcję możemy ustawić również na sztywno, przez podanie obsługiwanej wartości np.: 11MB, 24MB, 54MB.

Sieć WPA2-PSK

Opisane powyżej wireless-tools nie potrafią używać szyfrowania WPA/WPA2, dlatego konieczny nam będzie 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
}

Hasło do naszej sieci w linijce psk może być jawne lub kodowane za pomocą polecenia wpa_passphrase

Testujemy połączenie z WiFi:

# ifconfig wlan0 up
# wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf -dd

Opcja -dd włącza tryb debugowania i jeżeli nie otrzymamy jakichś błędów, to przerywamy działanie wpa_supplicant™ skrótem ctr-c Pozostała nam jeszcze edycja /etc/sysconfig/interfaces/ifcfg-wlan0, w celu wskazania, że chcemy korzystać z wpa_supplicant:

DEVICE=wlan0
IPADDR=192.168.0.2/24
ONBOOT=yes
BOOTPROTO=dhcp

WLAN_WPA=yes
WLAN_WPA_DRIVER=wext

Restartujemy ponownie naszą sieć:

# /etc/init.d/network restart

i nasza sieć WiFi powinna już działać.

Aktywacja i diagnostyka

Na wszelki wypadek powinniśmy się upewnić, że nasza maszyna jest w zasięgu sieci radiowej:

# iwlist wlan0 scan

Jeśli sieć jest na liście, to próbujemy podnieść interfejs (oczywiście, jeżeli tego nie zrobiliśmy już wcześniej):

# /etc/rc.d/init.d/network start
Ustawianie parametrów sieci....................[ ZROBIONE ]
Podnoszenie interfejsu wlan0...................[ ZROBIONE ]

Aby sprawdzić czy wszystko jest OK możemy użyć polecenia iwconfig, które powinno wyświetlić coś 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

w wyświetlonych danych interfejsu odszukujemy wartość jakości połączenia: Link Quality Niezerowa wartość oznacza, że konfiguracja zakończyła się sukcesem.

W przypadku użycia pakietu wpa_supplicant możemy użyć 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

Wartość COMPLETED parametru wpa_state oznacza prawidłowe połączenie z WiFi.

Jeżeli mamy kartę obsługującą tryb "n" może nam się przydać polecenie iwpriv z pakietu wireless-tools™. Możemy przełączyć wtedy kartę wifi w szybszy tryb, ponieważ często z automatu włączony jest wolniejszy np. "g". Uruchamiamy więc:

# iwpriv wlan0 network_type n

i powinniśmy wykorzystywać już naszą kartę maksymalnie - co możemy sprawdzić 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 początku musimy włączyć w biosie komputera port USB oraz zainstalować takie pakiety jak eagle™ oraz kernel-usb-eagle™. Dodatkowo musimy jeszcze zainstalować pakiet ppp™. Jeżeli zainstalowałeś system z płytki MINI-iso, powinieneś je tam znaleźć. W przypadku, kiedy instalowałeś system z dyskietki, znajdziesz je na jednej lub kilku dyskietek "addons" czyli dyskietek zawierających dodatkowe pakiety.

Instalacja

Przystępujemy do instalacji. Należy przejść do do lokalizacji w której znajdują się owe pakiety a następnie wydać następujące polecenie.

# rpm -Uvh kernel-usb-eagle* eagle-usb* ppp*

Kiedy już upewniliśmy się, że mamy włączony port USB w biosie, musimy go zainicjować w systemie. Możemy to zrobić za pomocą pliku /etc/modules.conf w którym umieszczamy przykładową linijkę

alias usb-controller usb-uhci

Jeżeli posiadasz zainstalowany kernel z serii 2.6.x powinieneś umieścić następujący wpis w pliku /etc/modprobe.conf

alias usb-controller uhci-hcd

Po ponownym uruchomieniu komputera powinniśmy posiadać w systemie obecny moduł usb-uhci (uhci-hcd dla jądra 2.6.x). W przypadku, kiedy ten moduł po prostu nie zadziała spróbuj załadować usb-ohci (ohci-hcd dla jądra 2.6.x). Jeżeli podłączyłeś modem do portu USB 2.0 powinieneś użyć modułu usb-ehci (ehci-hcd dla jądra 2.6.x).

Możemy teraz podłączyć modem do komputera. Nasze urządzenie zostanie od razu wykryte i zainicjowane w systemie. Poprawna inicjalizacja powinna zakończyć się załadowaniem do pamięci modułu adiusbadsl. UWAGA! Jeżeli posiadasz kernel 2.6.x powinieneś załadować moduł eagle-usb.

Konfiguracja

Możemy zacząć od pliku /etc/resolv.conf. Opis znajdziecie w rozdziale poświęconym konfiguracji sieci. Przystępujemy teraz do konfiguracji pliku /etc/eagle-usb/eagle-usb.conf. Należy w nim zmienić wartość opcji VPI na taką jaką widzicie poniżej.

VPI=00000000

Skonfigurujemy teraz demona PPP. Utworzonemu w wyniku instalacji plikowi /etc/ppp/options zmieniamy nazwę na options.old. Tworzymy nowy plik options z zawartością taką jaka została przedstawiona na poniższym listingu. Najważniejszą rzeczą jest podanie w nim nazwy użytkownika, która jest konieczna do ustanowienia połączenia. Możemy również dopisać opcję debug, jeśli chcemy być informowani o tym co się dzieje.

# cat /etc/ppp/options
user "user@neostrada.pl"
mru 1492
mtu 1492
noipdefault
defaultroute
usepeerdns
noauth
#ipcp-accept-remote
#ipcp-accept-loacal
nobsdcomp
nodeflate
nopcomp
novj
novjccomp
#novaccomp -am
noaccomp -am
#włączam debug.
debug

Musimy jeszcze wpisać hasło. Aby tego dokonać wyedytujmy plik /etc/ppp/chap-secrets. UWAGA! Jeżeli się pomylisz i wpiszesz hasło do /etc/ppp/pap-secrets, hasło nie zadziała.

# cat /etc/ppp/chap-secrets
user@neostrada.pl	*	haslo	*

Na tym zakończymy konfigurację połączenia z Neostradą. Jesteśmy już gotowi aby wszystko uruchomić.

Uruchomienie i post konfiguracja

Najbardziej wygodnym sposobem będzie wykorzystanie mechanizmu rc-scripts do uruchamiania usługi. Do tego potrzebny będzie odpowiedni plik konfiguracji, przykładowy taki plik umieszczono w katalogu /usr/share/doc/rc-scipts/ oraz na poniższym wydruku:

DEVICE=ppp0
ONBOOT=yes
PPPOA_EAGLE=yes
AUTH=no
MTU=1452
PERSIST=yes
DEFROUTE=yes
USEPEERDNS=yes
PAPNAME=XXX@neostrada.pl
# 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ęki opcji ONBOOT=yes połączenie będzie nawiązywane wraz z uruchamianiem systemu.

Możemy sprawdzić np. pingiem łączność z jakimś zewnętrznym serwerem, np. ping www.pld-linux.org. Jeżeli posiadasz jakąś sieć LAN, lub kilka komputerów w mieszkaniu, powinieneś przeczytać rozdział poświęcony maskaradzie.

Neostrada+ z modemem USB firmy Alcatel - Thompson

Przygotowanie do instalacji

Oto krótka lista tego, co będzie nam potrzebne do uruchomienia modemu.

  • Port USB w komputerze

  • Jądro z serii 2.4 lub 2.6

  • Programy: modem_run™ oraz pppoa3

  • Pakiet: ppp-plugin-pppoatm

  • Firmware do modemu.

Firmware dla modemu można ściągnąć z stąd: http://speedtouch.sourceforge.net/files/firmware.bin.

Jeżeli już upewniłeś się, że masz wszystkie wymagane rzeczy, możemy przystąpić do instalacji.

Konfiguracja

W pierwszej kolejności musimy zainicjować w systemie USB, oraz kilka modułów do obsługi ppp. Możemy to zrobić wykonując następujące 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. Jeżeli nie załaduje się poprawnie (zostaniesz o tym poinformowany) powinieneś wybrać jeden z następujących: usb-uhci, usb-ohci lub dla USB 2.0 usb-ehci. Posiadacze jąder z serii 2.6 mają do wyboru następujący zestaw modułów: uhci-hcd, ohci-hcd lub ehci-hcd. Ta różnorodność jest uwarunkowana sprzętowo, w zależności od rodzaju chipsetu obsługującego porty USB. Ważną rolę tutaj odgrywa moduł acm, gdyż bez niego nie będzie moż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 mogą użyć poniższej pętli która załaduje wszystkie potrzebne moduły. Oczywiście należy zwrócić uwagę aby załadować odpowiedni dla Twojego sprzętu moduł obsługujący kontroler USB na płycie głównej.

# for i in usbcore uhci-hcd cdc-acm ppp_generic ppp_synctty;do modprobe $i;done

Następnym krokiem jest podmontowanie systemu plików w proc.

# mount none /proc/bus/usb -t usbfs

W tym momencie możemy sprawdzić, czy SpeedTouch rzeczywiście jest widziany przez system. Aby tego dokonać wykonaj poniższe polecenie

# cat /proc/bus/usb/devices
[...]
S:  Manufacturer=ALCATEL
S:  Product=Speed Touch 330
[...]

Musisz teraz zainstalować oprogramowanie do modemu. Robimy to wydając następujące polecenie:

# poldek -U speedtouch

Podłącz modem do komputera. Będzie on potrzebował do działania specjalnego pliku, tak zwanego firmware. Program modem_run potrafi odczytywać firmware w formatach przygotowanych dla Linuksa, Windowsa oraz MacOS. Jakie są możliwości pobrania pliku firmware? Możemy pobrać go z adresu podanego na początku rozdziału. Jest to firmware przygotowany dla systemu MacOS. Linuksowy firmware możemy pobrać ze strony Alcatela: www.speedtouchdsl.com/dvrreg_lx.htm. Wymagana jest rejestracja. Możemy również go wziąć z płytki dostarczonej przez TPSA. Powinien on znajdować się w archiwum Linux/ThomsonST330/pliki.tar.gz. Po jego rozpakowaniu powinniśmy mieć coś takiego jak: drivers/speedmgmt.tar.gz. Posiadając już plik speedmgmt.tar.gz możemy sobie zbudować pakiet rpm z firmwarem przy użyciu speedtouch-firmware.spec. Musimy tylko skopiować archiwum do katalogu ~/rpm/SOURCES. Dalsze instrukcje dotyczące budowania pakietów znajdziesz w tej dokumentacji w rozdziale: Tworzenie PLD. Po zainstalowaniu zbudowanego pakietu z firmwarem, możemy go załadować wydając poniższe polecenie:

# modem_run -v 1 -m -f /ścieżka/do/firmware

Ładowanie firmware do modemu może trochę potrwać. Jeżeli chcesz widzieć co się dzieje wpisz następujące polecenie

# tail -f /var/log/messages

W trakcie ładowania pliku firmware, zaczną migać diody urządzenia. Będzie to oznaczać synchronizację linii. Po kilkunastu sekundach modem się ustabilizuje. Diody powrócą do zielonego koloru.

Jeżeli masz zainstalowany kernel z serii 2.6 lub 2.4.22+ wykonaj poniższe polecenia:

# modprobe speedtch
# modem_run -k -m -v 1 -f /usr/share/speedtouch/mgmt.o
# modprobe pppoatm

Moduł speedtch jest potrzebny do użycia opcji -k (może być ładowany automatycznie przez hotplug. Z kolei pppoatm będzie potrzebny do uruchomienia pppd. Nie ładuje się on automatycznie, dlatego należy go dopisać np. do /etc/modules.

W porządku. Po zakończonej operacji ładowania firmware jesteśmy gotowi aby skonfigurować nasze ppp do neostrady. Zanim to zrobimy będziemy musieli zainstalować pakiet ppp-plugin-pppoatm.

# poldek -U ppp-plugin-pppoatm

W zależności od wersji zainstalowanego kernela (2.6 lub 2.4) konfiguracja demona pppd będzie się różniła kilkoma szczegółami. Poniżej przedstawiam przykłady dla obu serii jąder.

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 "user@neostrada.pl"
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

Ważną rolę odgrywa tu parametr -e 1, gdyż bez niego nie uzyskamy połączenia.

Oczywiście musimy jeszcze odpowiednio skonfigurować pap-secrets oraz chap-secrets

# cat /etc/ppp/chap-secrets
user@neostrada.pl     *       haslo        *

Uruchomienie i zakończenie

W celu nawiązania połączenia, które uprzednio skonfigurowaliśmy, wydajemy takie oto polecenie

pppd call neostrada

Jeżeli nie chcemy, bądź z jakichś powodów nie możemy korzystać z programu hotplug™ nie musimy tego robić. Nie jest on tak naprawdę niezbędny. W takim przypadku za każdym razem będziemy musieli ładować firmware modemu programem modem_run™.

xDSL z interfejsem Ethernet

Wprowadzenie

Coraz więcej dostawców usług internetowych oferuje dzierżawę linii xDSL z portem LAN typu Ethernet, takie usługi oferują np. Telekomunikacja Polska (Internet DSL) oraz Dialog (DIALNET DSL).

Konfiguracja

W celu uruchomienia usługi, wystarczy jedynie skonfigurować interfejs sieciowy Ethernet w naszym komputerze, zgodnie z informacjami uzyskanymi od dostawcy łącza (konfiguracja statyczna). Poniżej przedstawiono skrócony opis konfiguracji tego typu interfejsu, szczegółowy opis znajdziemy tutaj: „Ethernet”

Podniesienie interfejsu eth0 możemy osiągnąć tworząc lub edytując (jeśli istnieje) plik /etc/sysconfig/interfaces/ifcfg-eth0 i wpisując dane otrzymane od dostawcy:

DEVICE="eth0"
IPADDR="80.55.203.222/30"
ONBOOT="yes"
BOOTPROTO="none"

Istotną kwestią 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). Należy pamiętać że 3 adresy IP są zarezerwowane do obsługi połączenia (adres sieci,brama,broadcast)

Ostatnią zmianą potrzebną do prawidłowego działania sieci jest wyedytowanie pliku /etc/sysconfig/network. Należy tam podać adres bramy (IP modemu DSL).

GATEWAY="80.55.203.221"
GATEWAYDEV="eth0"

Na koniec pozostaje nam uruchomienie podsystemu sieci:

# service network start

Uwagi

Jeśli przy łączu Internet DSL 1 zdarzają się przypadki zerwania połączenia, należy przywiązać 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 pozwalającym na automatyczne konfigurwanie systemu po podłączeniu określonego urządzenia. W przypadku urządzeń sieciowych PCMCIA i USB możliwe jest automatyczne aktywowanie interfejsu od razu po podłączeniu urządzenia.

Aby uruchomić ten mechanizm musimy najpierw zainstalować odpowiednie oprogramowanie:

# poldek -i hotplug*

Kolejnym krokiem będzie umieszczenie odpowiedniego wpisu w pliku konfiguracji interfejsu sieciowego. Dodajemy opcję:

HOTPLUG=yes

Narzędzia

Narzędzia do zarządzania i diagnostyki interfejsów sieciowych opisano w „Narzędzia sieciowe”.

Inne opcje

Zaawansowane opcje sieciowe interfejsów nie są 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 dokumentacją do rc-skryptów: /usr/share/doc/rc-scripts. Są to pliki tekstowe zarchiwizowane programem Gzip™.

Rozdział 15. Zastosowania sieciowe

W tym rozdziale znajdziesz informacje dotyczące konfiguracji sieci

Routing statyczny

Podstawowe trasy do podsieci są automatycznie tworzone przy konfiguracji interfejsów sieciowych na podstawie podanego adresu IP i maski podsieci. Trasa domyślna jest konfigurowana na podstawie ustawień w pliku /etc/sysconfig/network. Operacje te zostały opisane w poprzednim rozdziale, w przypadku bardziej zaawansowanych zastosowań musimy samodzielnie skonfigurować trasy pakietów.

Wstępna konfiguracja

Konfigurację routingu obowiązkowo rozpoczynamy od włączenia przekazywania pakietów między interfejsami sieciowymi, opcję tą możemy ustawić tymczasowo wykonując polecenie

# echo "1" > /proc/sys/net/ipv4/ip_forward

Możemy też w pliku /etc/sysctl.conf ustawić następująca opcję:

net.ipv4.ip_forward = 1

Następnie restartujemy podsystem sieci

# service network restart

Więcej o parametrach jądra znajdziemy w „Parametry jądra”

Tablica routingu

Aby wyświetlić tablicę routingu posłużymy się poleceniem ip route:

# ip route
10.0.0.4/32 dev eth0  proto kernel  scope link  src 10.0.0.4
10.0.0.0/24 dev eth1  proto kernel  scope link  src 10.0.0.1
default via 10.0.0.100 dev eth0 onlink

Zarządzanie trasami

Zarządzenia 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 domyślnej:

# ip route add 0/0 via 10.0.0.100 dev eth0

dodatkowe opcje:

  • src {$adres_IP} - adres ź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 ważna w przypadku łączenia trasowania statycznego z dynamicznym. Najczęściej stykamy się z protokołami: redirect, kernel, boot, ra. Ich pełną listę wraz z odpowiadającym 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 użyć opcji "del" zamiast "add".

Zakończenie

  • Dodane przez nas regułki możemy zapisac na stałe, w ten sposób zostaną 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

  • Jądro używa specjalnego cache do wydajniejszego trasowania pakietów, ma to jednak pewną wadę: zmiany w nim nie następują od razu po zmodyfikowaniu tablicy routingu. Aby wymusić natychmiastowe wyczyszczenie cache należy użyć poniższego polecenia:

    # ip route flush cache

NAT

NAT (Network Address Translation) w Linuksie można zrobić na dwa sposoby:

  • wykorzystując infrastrukturę netfilter™ jądra 2.4 i 2.6.

  • korzystając z narzędzi do kontrolowania sieci z pakietu iproute2™.

Oryginalna dokumentacja Netfilter w języku angielskim

Najlepszym sposobem jest wykorzystanie możliwości netfilter™, gdyż wykonuje on nat przed (PREROUTING) lub po (POSTROUTING) routingu, co daje nam możliwość tak skonfigurowania firewalla, jak by nie było wykonywane NAT. NAT w iptables™ tworzymy dodając regułki do tabeli "nat". Żeby sprawdzić jakie są dostępne "Chains" w tabeli nat, należy wykonać takie polecenie:

# iptables -t nat -L

W poniższych przykładach założyliśmy, że 1.2.3.4 jest adresem IP podniesionym na interfejsie zewnętrznym ($if_wan) zaś 192.168.1.0/16 to adresy na interfejsie sieci lokalnej ($if_lan).

DNAT

W PREROUTING są regułki do wykonania DNAT (Destination NAT). Zamienia to adres hosta docelowego na nasz prywatny, w ten sposób możemy przekierować ruch na dowolny host w sieci prywatnej:

# iptables -t nat -A PREROUTING -d 1.2.3.4 -j DNAT --to 192.168.1.2

Można określić na jakim interfejsie będzie wykonany NAT poprzez opcję -i $inteface. Opcja -o w PREROUTING nie jest dostępna.

Możemy też dokonać 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  -j DNAT --to 192.168.1.11:80

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 łącza".

# iptables -t nat -A POSTROUTING -s 192.168.1.2 -j SNAT --to 1.2.3.4

Jeśli podamy maskę podsieci, zostanie wykorzystana większa ilość adresów.

MASQUERADE wykonuje to samo co SNAT z tym, że na adres interfejsu jakim wychodzi pakiet. Używać go należy tylko kiedy nasz adres publiczny zmienia się. (np. w połączeniach ze zmiennym IP publicznym)

Zakończenie.

Po ustawieniu DNAT na adres wewnętrzny zauważymy, że jest problem z dostępem do ip 1.2.3.4 z wewnątrz sieci. Dzieje się tak dlatego, że adres source zostaje bez zmian, dlatego też pakiet nie wraca do bramy. Musimy więc zmusić, aby host wysyłał odpowiedź do bramy. Możemy wykonać to w następujący 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ł łącza w zależności od serwisów

Wstęp

Administratorzy sieci osiedlowych często natrafiają na problemy z programami p2p. Potrafią one skutecznie zapychać łącza. Jednym z możliwych rozwiązań jest zablokowanie takiego ruchu, a drugim opisanym w tym dokumencie, jest przekierowanie go na jedno z łącz - odciążając tym samym drugie.

Jednym z możliwych problemów może być "zatykanie" modemu, więc należy się dowiedzieć ile modem może obsłużyć aktywnych połączeń i ograniczyć wyjście przez iptables do tej wartości.

Podstawy

Ograniczenie można wykonać 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 użytkownikom do 300 wychodzących połączeń TCP. Wyeliminuje to problem, kiedy pakiety nie są w stanie wyjść w świat gdyż za dużo jest aktywnych połączeń i modem się zawiesza.

Drugim sposobem jest ograniczenie pasma wychodzącego w taki sposób, żeby router pilnował, aby na modemie nie było zbyt duż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łączeń podobnych

Trzecim sposobem jest zakupienie drugiego, taniego łącza i puszczenie nim niechcianego ruchu np tak:

Cały niezidentyfikowany ruch przekierowywany jest na łącze dodatkowe, a zidentyfikowany na łącze drugie (szybsze).

Na początek ustawimy w tabeli mangle takie regułki, służąc do oznaczania odpowiednich pakietów:

// przywrócenie wartości mark dla nawiązanych już połączeń
# iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark

// jeśli się okaże, że jakieś p2p działa na portach preferowanych to
// zaznaczy je i wtedy nie przepuś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 \
    -j MARK --set-mark 0x1214
// zachowanie dla potomności
# iptables -t mangle -A PREROUTING -p tcp -m mark --mark 0x1214 \
    -j CONNMARK --save-mark

// jeśli jakiś pakiet jest już 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  -s 192.168.0.0/16 \
    -j MARK --set-mark 0x1
# iptables -t mangle -A PREROUTING -p udp   -s 192.168.0.0/16 \
    -j MARK --set-mark 0x1
// porty 1:1024
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    --dport 1:1024 -j MARK --set-mark 0x1
// mysql
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    --dport 3306 -j MARK --set-mark 0x1
// gg
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    --dport 8074 -j MARK --set-mark 0x1
// cache
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    --dport 8080 -j MARK --set-mark 0x1
// gra americans army
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    --dport 1716:1718 -j MARK --set-mark 0x1
// irc
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 
    --dport 6665:6667 -j MARK --set-mark 0x1
// gra enemy terrytory
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    --dport 27960 -j MARK --set-mark 0x1
// gra MU Online
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    --dport 55201 -j MARK --set-mark 0x1
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    --dport 44405 -j MARK --set-mark 0x1

// wszystkie porty dobrze znanych serwerów
// www.wp.pl
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    -d 212.77.100.101 -j MARK --set-mark 0x1
// czat.wp.pl
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    -d 212.77.100.113 -j MARK --set-mark 0x1
// www.onet.pl
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    -d 213.180.130.200 -j MARK --set-mark 0x1
//strona z grami Online  www.miniclip.com
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    -d 69.0.241.20 -j MARK --set-mark 0x1
// www.kurnik.pl
# iptables -t mangle -A PREROUTING -p tcp   -s 192.168.0.0/16 \
    -d 217.17.45.25 -j MARK --set-mark 0x1

// no i jeszcze zachować dla potomności
# iptables -t mangle -A PREROUTING -p tcp -m mark --mark 0x1 \
    -j CONNMARK --save-mark

Jeśli już mamy oznaczone pakiety należy je odpowiednio przekierować. Możemy skorzystać z dobrodziejstwa iproute2™ i dodać następujące 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 łącze śmieci
// potrzebne jeśli domyślne jest inne łącze
# ip route add from 192.168.0.0/18 lookup TABLE_SMIECI

Oczywiście trzeba dodać do tabeli odpowiednie wpisy default i informacje o sieciach obsługiwanych przez ten router. Należy jeszcze wykonać te polecenia dla interfejsu z wyjściem w świat:

# echo 0 >  /proc/sys/net/ipv4/conf/eth1/rp_filter

Po takich zabiegach użytkownicy powinni odczuć znaczny wzrost wydajności łącza PRIORYTET

Niestety łącze SMIECI jest maksymalnie zapchane, więc należy przygotować się na narzekania użytkowników którzy są przekierowani na to łącze.

Przy takim rozwiązaniu należy mieć stałą kontrolę nad usługami, które mają działać na łączu PRIORYTET i stale uaktualniać tabelę mangle o odpowiednie wpisy.

Nie udało się niestety przekierować samego ruchu p2p gdyż podczas nawiązywania połączenia nie wiemy jeszcze czy jest to pakiet należący do p2p. Dzisiejsze programy p2p potrafią działać na portach poniżej 1024 np 80 (http) więc rozróżnienie ich po portach nic nie da

Innym rozwiązaniem może być wydzielenie portów dla programów p2p i ogłoszenie ich użytkownikom sieci. Należy wtedy zablokować ruch p2p na wszystkie porty oprócz tych wydzielonych i jeśli ktoś się nie dostosuje to nie będzie miał transferu. To rozwiązanie ma jednak wadę: będzie generowało dużo połączeń nawiązywanych (pakiety SYN) na obu łączach, gdyż iptables™ nie pozwoli na transfer dopiero po nawiązaniu połączenia i rozpoznaniu połączania jako należącego do p2p.

PPP over SSH - Tunel IPv4

Wstęp

Zaletą tego rodzaju tunelu jest to, że jego działanie opiera się na jednych z bardziej popularnych protokołach PPP™ oraz SSH™. Komunikacja odbywa się na porcie 22. Dzięki temu nie zachodzi potrzeba otwierania dodatkowych portów komunikacyjnych w konfiguracji zapory ogniowej. Interfejsy tunelu uruchamiane są przez demona pppd. Posłużą nam one do zestawienia trasy między dwoma hostami lub sieciami w zależności od potrzeb. Do naszych celów będzie potrzebny demon pppd będący implementacją protokołu ppp oraz klient i serwer ssh implementujący protokół ssh.

Konfiguracja

Zanim przystąpimy do konfiguracji musimy zdecydować który komputer będzie serwerem a który klientem. Klient będzie inicjował połączenie z serwerem uruchamiając demona pppd.

Serwer

Zanim przystąpimy do konfiguracji należy sprawdzić czy system wyposażony jest w demona ppp oraz serwer ssh. Pakiety które to udostępniają to odpowiednio ppp™ oraz openssh-server™. Przydatnym może się okazać pakiet openssh-clients™ zawierający jak sama nazwa wskazuje klienta ssh.

Po zainstalowaniu wyżej wymienionych pakietów przechodzimy do konfiguracji systemu. W pierwszej kolejności zakładamy konto użytkownika oraz przydzielamy mu grupę.

# 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 poleceń możesz zobaczyć na listingu poniżej

# grep vpn /etc/passwd
vpn:x:506:1005::/home/users/vpn:/usr/sbin/pppd

#grep vpn-users /etc/group
vpn-users:x:1005:

Wynik tych poleceń powinien odpowiadać temu co tutaj widać. 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 użytkownika vpn jest katalog ~/.ssh. Możemy go stworzyć (o ile wcześniej zainstalowaliśmy) przy pomocy klienta ssh. Robimy to w dwóch krokach które obrazuje poniż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

Można też ręcznie utworzyć z poziomu konta vpn ten katalog poleceniem mkdir. Aby umożliwić użytkownikowi prawo do wykonania po zalogowaniu polecenia /usr/sbin/pppd należy nadać temu plikowi suida.

# chmod 4755 /usr/sbin/pppd

Konfigurację warstwy ssh mamy już za sobą. Możemy teraz przystąpić do konfiguracji demona pppd. Demon nie będzie wymagał autoryzacji, więc w pliku /etc/ppp/options wyszukujemy opcję auth i zmieniamy ją na noauth. Musimy teraz skonfigurować wierzchołek (tzw. peer) końca tunelu. Tworzymy więc plik /etc/ppp/peers/tunel określający wszystkie niezbędne parametry połączenia. Na listingu poniż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 są dwukropkiem adresy IP wierzchołków tunelu. Ten po lewej stronie zostanie ustawiony na interfejsie serwera, ten po prawej klienta. Przedstawioną konfigurację należy potraktować jako przykład i dostosować ją do rzeczywistej. Oczywiście, jeżeli spełnia ona Twoje wymagania możesz ją zastosować.

  • noauth - wyłączamy autoryzację ppp

  • lcp-echo-interval - wartość przy tej opcji określa interwał w sekundach z jakim wysyłana będzie do peera ramka żądania o echo LCP. Demon sprawdza w ten sposób czy połączenie nadal jest aktywne.

  • lcp-echo-failure - wartość podana przy tej opcji określa ile żądań o echo LCP ma zostać wysłanych jeżeli peer nie dał odpowiedzi. Po tylu próbach demon stwierdzi, że połączenie zostało utracone.

Klient

Konfiguracja po stronie klienta sprowadza się do wygenerowania kluczy rsa oraz odpowieniego ustawienia demona pppd. Klucze nam są potrzebne do autentykacji nie interaktywnej ssh. Inaczej nie uda nam się nawiązać połączenia z serwerem. Do zestawienia połączenia z serwerem po stronie klienta wymagana jest instalacja pakietów ppp™ oraz openssh-clients™. Jeżeli ich nie posiadasz musisz je niezwłocznie zainstalować.

Przystępujemy do dalszej konfiguracji usługi po stronie klienta. Zaczniemy od wspomnianego na wstępie generowania kluczy.

$ 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łuży znajdujące się w pakiecie openssh-clients™ polecenie ssh-keygen. Użyliśmy go z następującymi parametrami:

  • -b - długość klucza w bitach. Wartość podana na listingu jest minimalną długością klucza która jest akceptowana przez demona sshd™.

  • -f - nazwa pliku (można podać ścieżkę do niego) zawierającego klucz prywatny.

  • -t - typ klucza. Na listingu jest to RSA. RSA jest algorytmem służącym do generowania kluczy.

  • -P - hasło klucza. Na potrzeby tunelu hasło musi pozostać puste. Inaczej tunel nie zadziała. Demon sshd będzie czekał na potwierdzenie hasłem klucza co nigdy nie nastąpi, gdyż sesja ssh będzie inicjowana poprzez demona pppd uniemożliwiając nam w sposób interaktywny jej przejęcie.

Kolejnym krokiem jest skopiowanie zawartości pliku klucz.pub do pliku ~vpn/.ssh/authorized_keys na serwerze. Możemy tego dokonać w następujący sposób.

$ scp ~/.ssh/klucz.pub vpn@domena.pl:~/.ssh/authorized_keys

Polecenie to zadziała tylko wtedy, kiedy na koncie vpn znajdującym się na serwerze zmienimy tymczasowo powłokę z /usr/sbin/pppd na standardową /bin/bash. Na tym etapie kończy się cała konfiguracja dotycząca ssh po obu stronach. Możemy więc przywrócić na serwerze w pliku /etc/passwd dla użytkownika vpn powłokę na /usr/sbin/pppd. Przystępujemy teraz do skonfigurowania demona pppd, który będzie wywoływał podczas ustanawiania połączenia klienta ssh.

Podobnie jak po stronie serwera w pliku /etc/ppp/options musimy opcję auth zmienić na noauth. Kiedy już to zrobimy, przystąpimy do konfiguracji wierzchołka (tzw. peera) dla klienta, który będzie inicjował połączenie. Nazwa pliku może być taka sama jak na serwerze. Poniżej na listingu znajduje się 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 vpn@domena.pl"
connect-delay 5000

Pierwsza linijka w pliku to dwa adresy IP oddzielone znakiem dwukropka. Adres po lewej stronie jest adresem tego końca tunelu, który właśnie konfigurujemy. Pamiętamy, że adres 192.168.1.100 został już przydzielony jako adres wierzchołka serwera. Pozostałe opcje zostały objaśnione poniżej.

  • debug - włączamy raportowanie szczegółów połączenia ppp.

  • noauth - wyłączamy autoryzację.

  • pty - dzięki tej opcji możemy wykorzystać zewnętrzny skrypt jako ośrodek komunikacji zamiast konkretnego urządzenia terminalowego. Wykorzystujemy tutaj ssh.

  • connect-delay - określony w milisekundach czas oczekiwanie na prawidłowy pakiet PPP od peera. Jeżeli taki w tym czasie nadejdzie pppd rozpocznie negocjację wysyłając pierwszy pakiet LCP.

W przypadku problemów z połączeniem możemy zwiększyć wartość connect-delay nawet dziesięciokrotnie jeżeli łącza pomiędzy którymi zestawiamy tunel będą sporo obciążone. Również po stronie klienta musimy nadać bit suid plikowi /usr/sbin/pppd.

# chmod 4755 /usr/sbin/pppd

Na tym kończymy konfigurację tunelu. Możemy przejść do fazy jego uruchomienia.

Uruchomienie

Skonfigurowane połączenie należy teraz zainicjować wykonując polecenie:

$ /usr/sbin/pppd call tunel

Udana próba połączenia połączenia powinna zaowocować zapisami w logach takimi jak poniżej na listingu.

Sep  2 12:35:34 pldmachine pppd[6623]: pppd 2.4.2b3 started by foo, uid 501
Sep  2 12:35:34 pldmachine pppd[6623]: Using interface ppp0
Sep  2 12:35:34 pldmachine pppd[6623]: Connect: ppp0 <--> /dev/pts/0
Sep  2 12:35:37 pldmachine pppd[6623]: Deflate (15) compression enabled
Sep  2 12:35:37 pldmachine pppd[6623]: Cannot determine ethernet \
    address for proxy ARP
Sep  2 12:35:37 pldmachine pppd[6623]: local  IP address 192.168.1.101
Sep  2 12:35:37 pldmachine pppd[6623]: remote IP address 192.168.1.100

Wykonując po obu stronach polecenie ifconfig zauważysz, że utworzone zostały interfejsy ppp służące do komunikacji. Wykorzystamy je do zestawienia prostej trasy pomiędzy dwoma sieciami.

Zakładając, że jedna sieć po stronie serwera ma adresację 192.168.0.0/24 a po stronie klienta 192.168.2.0/24 routing będzie wyglądał w sposób następujący.

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ędą przechowywały w swoich tablicach routingu informacje o sieciach połączonych dzięki interfejsom tunelu.

VTun - Tunel IPv4

Wstęp

VTun umożliwia tworzenie tuneli poprzez sieci TCP/IP wraz z przydzielaniem pasma, kompresją, szyfrowaniem danych w tunelach. Wspierane typy tuneli to: PPP, IP, Ethernet i większość pozostałych protokołów szeregowych. VTun jest łatwy i elastyczny w konfiguracji. Może zostać wykorzystany do takich sieciowych zastosowań jak VPN, Mobil IP, łącza o określonym paśmie oraz innych. Działa w warstwie user space.

Opis procesu konfiguracji tunelu podzielony został na część klient oraz serwer. Adresacja użyta na listingach może zostać użyta o ile nie będzie się ona kłóciła z bieżącą konfiguracją Twojej sieci. Zaczynamy od instalacji pakietu vtun™ na obu maszynach będących końcami tunelu. Dodatkowo ładujemy moduł tun™ do pamięci.

# modprobe tun

Na tym kończy się wstępne przygotowanie systemu do konfiguracji tunelu.

Konfiguracja

Serwer

Po zainstalowaniu pakietu, opcja VTUND_MODE w pliku /etc/sysconfig/vtun powinna być ustawiona tak jak na listingu poniż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óżnego rodzaju tuneli po obu stronach (klient - serwer). Warto je sobie zostawić. W tym celu wystarczy jedynie zmienić nazwę pliku.

# mv /etc/vtund.conf /etc/vtund.conf.orig

Przy użyciu ulubionego edytora stwórzmy nowy plik /etc/vtund.conf. Możemy w nim wyodrębnić kilka sekcji: options, default, nazwa, up oraz down. Sekcje up oraz down są podsekcjami sekcji nazwa.

options - opcje dotyczące 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łuchiwać demon.

  • syslog - sposób logowania zdarzeń na interfejsie tunelu.

  • ppp ifconfig route firewall ip - zmienne, które zawierają ścieżki do wykorzystywanych przez VTun programów.

default - domyślne ustawienia transmisji danych.

default {
	compress yes;
	speed 0;           
}
  • compress - kompresja pakietów w trakcie transmisji.

  • speed - prędkość transmisji. Wartość 0 oznacza brak ograniczeń.

vpn1 - wymieniona wcześniej nazwa tunelu. W tym miejscu znajduje się właściwa konfiguracja parametrów połączenia.

vpn1 {
	passwd  tajne.haslo; 
	type  tun;          
	proto tcp;         
	compress  zlib:9;
	encrypt  yes;   
	keepalive yes; 
	up {
  		...
  	};
  	down {
  		...
  	};
}
  • passwd - hasło, które posłuży do szyfrowania połączenia.

  • type - typ tunelu (w przykładzie tunel IP)

  • proto - protokół warstwy transmisyjnej tunelu.

  • compress - metoda oraz stopień kompresji.

  • encrypt - włączenie szyfrowania transmisji.

  • keepalive - utrzymywanie połączenia

  • up, down - co ma się wykonać po nawiązaniu połączenia oraz jego zakończeniu. Szerzej o tym poniżej.

up - akcje wykonywane po nawiązaniu połączenia.

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 nawiązaniu połączenia należy uruchomić odpowiedni interfejs. Jego nazwa zostanie rozwiązana dzięki zmiennej %%. Określamy oczywiście typ interfejsu oraz jego MTU. Kolejną czynnością jest podanie trasy do drugiego końca tunelu. Adres IP po prawej stronie jest oczywiście adresem naszego (czyli serwera) końca i przez niego prowadzi droga na drugą stronę.

down - czynności następujące po wyłączeniu tunelu.

down {
        ifconfig "%% down";
        ifconfig "%% delete";
	route "delete -host 192.168.2.11"
};

Po zakończeniu działania połączenia powinniśmy wyłączyć oraz skasować interfejs który nam do niego służył. Usuwamy również zbędną trasę do drugiego końca tunelu z tablicy routingu. Zwróć uwagę na konstrukcję tych dwóch podsekcji. polecenie "argument". Polecenie zostało określone w sekcji options, natomiast argumentami są odpowiednie parametry danego polecenia.

Na tym kończy się konfiguracja serwera. Możemy przystąpić teraz do konfiguracji klienta.

Klient

Konfigurację klienta zaczniemy od edycji pliku /etc/sysconfig/vtun. Opcje w nim zawarte powinieneś ustawić 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órą ustawimy w pliku konfiguracyjnym

  • VTUND_SERVER_ADDR - publiczny adres IP serwera.

  • VTUND_SERVER_PORT - port na którym nasłuchuje serwer.

Również po stronie klienta musimy wyedytować plik /etc/vtund.conf. Także i tutaj możemy mu zmienić nazwę na vtund.conf.orig, aby zachować przykłady konfiguracji. Krok po kroku omówię 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ędą przez syslog.

  • timeout - timeout VTuna.

  • ppp, ifconfig, route, firewall, ip - ścieżki do programów wykorzystywanych w czasie konfiguracji.

Przystępujemy teraz do konfiguracji połączenia o nazwie vpn1. Jak pamiętasz nazwa została już wstępnie okreś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 {
  		...
	};
}
  • passwd - hasło które posłuży nam do szyfrowania połączenia.

  • type - typ tunelu, w przykładzie jest to tunel IP.

  • proto - protokół warstwy transmisyjnej tunelu.

  • compress - typ oraz stopień kompresji. Na listingu ustawiona została kompresja przy użyciu zlib dziewiątego stopnia.

  • encrypt - włączamy szyfrowanie połączenia.

  • keepalive - utrzymywanie połączenia w przypadku braku ruchu na interfejsie tunelu.

  • stat - statystyki pracy tunelu, które VTun będzie zapisywał do sysloga co pięć minut.

  • persist - opcja ustawiona tak jak na listingu sprawi, że w przypadku zerwania połączenia z serwerem klient będzie nawiązywał połączenie.

  • up, down - programy wykonywane po nawiązaniu połączenia 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ępnym krokiem jest wyznaczenie trasy do naszego serwera, czyli drugiego końca tunelu. Jak doskonale widać, ta część konfiguracji jest analogiczna do serwera. Należy tylko zwrócić uwagę na adresację. Adres następujący po parametrze gw okreś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ę wykonają po zamknięciu połączenia. Kolejno, wyłączamy oraz kasujemy interfejs tunelu. Następnie kasujemy z tablicy routingu trasę do serwera.

Na tym kończy się etap konfiguracji VTuna. Możemy przejść do jego uruchomienia.

Uruchomienie

Uruchomienie VTuna sprowadza się do wykonania jednego polecenia na serwerze oraz kliencie.

# /etc/rc.d/init.d/vtund start

Po jego wykonaniu na komputerach będących końcami tunelu za kilka chwil powinny się utworzyć interfejsy tun0. Numeracja zaczyna się od "0". Nazwy kolejnych interfejsów będą kończyć się następną w kolejności liczbą naturalną.

Narzędzia sieciowe

W PLD głównym pakietem narzędzi sieciowych jest iproute2™, oferuje on większe możliwości oraz bardziej ujednolicony interfejs obsługi w stosunku do narzędzi z pakietu net-tools™ (ifconfig, route, arp, ifup, ifdown). Sercem pakietu iproute2™ jest program ip zawierający funkcjonalność kilku starszych narzędzi w jednym. Z tego względu będzie naszym podstawowym narzędziem sieciowym.

Jako dodatek do niniejszego rozdziału, pragnę polecić lekturę opisu najprostszych narzędzi sieciowych (ping, traceroute), który można znaleźć w „Podstawowe narzędzia kontroli sieci TCP/IP” oraz opis zarządzania routingiem statycznym zamieszczony w „Routing statyczny”.

Konfiguracja interfejsow

Aby wyświetlić konfigurację interfejsów uż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 wyświetliło listę dostępnych interfejsów, każdy z nich oznaczony jest numerem porządkowym. W większości wypadków najbardziej interesujące są dla nas interfejsy fizyczne (eth0 na powyższym przykładzie). Interfejsy lo oraz sit0, są "wirtualnymi" interfejsami, pierwszy z nich to interfejs pętli zwrotnej (loopback), drugi służy do tunelowania protokołu IPv6 wewnątrz IPv4.

Tryb pracy urządzenia jest wyświetlany wewnątrz trójkątnych nawiasów, oto kilka oznaczeń:

  • UP - urządzenie działa

  • LOOPBACK - interfejs pętli zwrotnej

  • BROADCAST - urządzenie ma możliwość wysyłania komunikatów rozgłoszeniowych

  • MULTICAST - interfejs może być używany do transmisji typu multicast

  • PROMISC - tryb nasłuchiwania, używany przez monitory sieci i sniffery

  • NO-CARRIER - brak nośnej, komunikat spotykany zwykle w wypadku braku fizycznego połączenia z siecią

Poniżej omawianego wiersza wyświetlone zostały informacje o adresach związanych z urządzeniem (adresy IP i maski podsieci są przedstawione w notacji CIDR):

  • -link/ether - adres fizyczny karty sieciowej (MAC)

  • -inet - dane protokołu IPv4

  • -inet6 - dane protokołu IPv6

Zarządzanie interfejsami

Do najczęstszych operacji tego typu należy włączanie i wyłączanie interfejsów, w tym celu użyjemy następującego 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 sprzętowe (MAC)

Do odczytania adresu sprzętowego lokalnych kart sieciowych możemy użyć opisanego wcześniej polecenia ip addr. Aby odczytać MAC zdalnej maszyny uż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
Unicast reply from 10.0.0.100 [00:04:ED:07:25:F8]  0.976ms
Unicast reply from 10.0.0.100 [00:04:ED:07:25:F8]  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ętowy za każdym razem był ustawiany dla interfejsu, powinniśmy dokonać odpowiedniego wpisu w pliku konfiguracyjnym interfejsu. W przypadku urządzenia eth0 musimy zmodyfikować plik /etc/sysconfig/interfaces/ifcfg-eth0, i dodać zmienną MACADDR np.:

MACADDR="01:01:01:01:01:01"

ARP

Aby wyświetlić tablicę ARP należy użyć polecenia ip neighbour:

# ip neighbour
10.0.0.140               ether   00:E0:7D:A1:8B:E2   C                     eth0
10.0.0.2                 ether   4C:00:10:54:19:50   C                     eth0
10.0.0.100               ether   00:04:ED:07:25:F8   C                     eth0

Tablica ARP wypełnia się w miarę komunikowania się z innymi hostami, aby wymusić zbadanie działania protokołu ARP wystarczy zainicjować komunikację. Możemy użyć do tego programu ping.

Możemy stworzyć własną, statyczną tablicę ARP, posłuży nam do tego plik /etc/sysconfig/static-arp w którym umieszczamy wpisy zawierające 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, że wpis nigdy nie wygasa.

Serwery nazw (DNS)

Do odpytywania serwerów DNS możemy użyć programu host z pakietu bind-utils™. Pozwala na szybkie sprawdzenie poprawności konfiguracji domeny (strefy).

host {$nazwa/$IP} {$dns_nazwa/$dns_IP}

Pierwszy parametr to nazwa domeny lub IP maszyny, drugi parametr nie jest obowiązkowy - wskazuje na serwer nazw, który chcemy odpytać. Jeśli nie podamy drugiego parametru użyty zostanie serwer zdefiniowany w pliku /etc/resolv.conf.

Odpytanie serwera DNS o domenę, 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 odczytać konkretny rekord domeny użyjemy parametru "-t". Dla przykładu spróbujemy określić 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ługujące ją serwery nazw) możemy posłużyć się programem whois:

$ whois pld-linux.org

Wydajność sieci

Aby sprawdzić przepustowość sieci pomiędzy dwoma hostami możemy użyć programu iperf. Jest to program typu klient-serwer sprawdzający na kilka sposobów przepustowość połączenia. Rozpoczynamy od instalacji programu na obu interesujących nas maszynach, następnie 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

Nawiązane połączenia i otwarte porty protokołu TCP/IP możemy kontrolować za pomocą programu netstat np.:

# netstat -tua 

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 *:blackjack             *:*                     LISTEN      
tcp        0      0 *:ircs                  *:*                     LISTEN      
tcp        0      0 *:netbios-ssn           *:*                     LISTEN      
tcp        0      0 *:ipp                   *:*                     LISTEN      
tcp        0      0 *:microsoft-ds          *:*                     LISTEN      
tcp        0      0 gargamel:ircs           192.168.1.3:rapidmq-reg ESTABLISHED 
tcp        0      0 gargamel:imaps          192.168.1.6:ttc-etap-ds ESTABLISHED 
tcp        0      0 gargamel:td-postman     host-92.gadugadu.p:8074 ESTABLISHED 
tcp        0      0 gargamel:cma            chrome.pl:5223          ESTABLISHED 
tcp        0      0 *:1024                  *:*                     LISTEN      
udp        0      0 gargamel:netbios-ns     *:*                                 
udp        0      0 *:netbios-ns            *:*                                 
udp        0      0 *:ipp                   *:*

Na powyższym przykładzie zostały wyświetlone dane dotyczące protokołu TCP (opcja: -t) oraz UDP (-u). Dodatkowo zostały wyświetlone gniazda nasłuchujące (-a). Warte uwagi są jeszcze dwa parametry: -n i -p, pierwszy wyświetla porty i adresy w postaci liczb, drugi zaś wyświetla nazwy programów korzystających z danych gniazd.

Do analizowania wielkości ruchu sieciowego na interfejsie polecam program nload, jest to proste narzędzie rysujące wykresy pomocą znaków ASCII. Podstawowe statystyki możemy przeglądać dzięki programowi ip np. ip -s link, dokładniejsze dane otrzymamy dzięki programowi iptraf™.

Wygodnym sposobem śledzenia wybranego ruchu sieciowego jest użycie regułek linuksowego filtra pakietów. Do śledzenia ruchu służy cel "-j LOG" np.:

# iptables -A INPUT -p TCP --dport 80  -s 10.0.0.3 -j LOG

Powyższy wpis doda do łańcucha INPUT regułkę rejestrującą połączenia TCP z hosta 10.0.0.3 na port 80 danej maszyny. Aby te regułki działały z wpisami odrzucającymi pakiety (DROP/REJECT) muszą być analizowane wcześniej, w przeciwnym wypadku pakiet nigdy nie dotrze do regułki rejestrującej. W przypadku dopasowania pakietu do regułki następuje odnotowanie tego zdarzenia, wpisy te można odczytywać za pomocą programu dmesg, lub z plików syslog-a - zwykle z /var/log/kernel i /var/log/messages.

Dużo bardziej szczegółowe informacje o ruchu sieciowym otrzymamy dzięki programowi tcpdump, jest to rozbudowany sniffer i program do analizy pakietów.

Zakończenie

W przypadku modyfikacji plików konfiguracji w większości wypadków trzeba dokonać restartu podsystemu sieci.

W tym rozdziale opisano niewielki fragment możliwości dostępnych narzędzi sieciowych. Poniższa lista przedstawia miejsca gdzie można znaleźć szerszy opis niektórych zagadnień.

Rozdział 16. Usługi dostępne w PLD

Spis treści

Usługi - wstęp
ALSA - Dźwięk w Linuksie
Instalacja
Konfiguracja z użyciem systemu UDEV
Konfiguracja statyczna
Ustawienie miksera i testowanie
Zaawansowana obsługa miksera
Uwagi
Apache - Serwer stron internetowych
Wstęp
Instalacja
Pliki konfiguracji
Podstawowa konfiguracja
Strony użytkowników
Virtual Hosts
Ograniczanie dostępu na podstawie adresu
Ograniczenie dostępu za pomocą loginu i hasła
Obsługa skryptów PHP
CGI
Security Socket Layer (SSL)
Indeksowana zawartość katalogu
Uwagi
BIND - Serwer Nazw
DNS - Domain Name System
Wstęp
Podstawowa konfiguracja
Przykładowa konfiguracja strefy typu primary
Przykładowa konfiguracja strefy typu secondary
Obsługa protokołu IPv6
Rejestracja
Diagnostyka
Zakończenie
CRON - Cykliczne wykonywanie zadań
Instalacja
Budowa tabel
Format daty i czasu
Tabele systemowe
Tabele użytkowników
Komunikaty cron-a
CUPS - Popularny system druku dla Uniksa
Wstęp
Instalacja
Zarządzanie drukarkami
Dodanie drukarki
Szczegóły dodawania drukarki lokalnej
Szczegóły dodawania drukarki zdalnej
Konfiguracja serwera
Zarządzanie kolejką druku
Test drukarki i rozwiązywanie problemów
DHCPD - Dynamic Host Configuration Protocol Daemon
Instalacja
Podstawowa konfiguracja
Statyczne przypisanie konfiguracji
Inne opcje
Uruchomienie
Konfiguracja klienta
Uwagi
Exim - Transport poczty elektronicznej (MTA)
Instalacja
Budowa pliku konfiguracji
Podstawowa konfiguracja
Skrzynki pocztowe
Różne opcje
Autoryzacja SMTP
Syfrowanie SSL
Quota
Dodanie skanerów antywirusowych
Walka ze spamem
Obsługa wielu domen w Eximie
Automatyczna odpowiedź - Vacations
Heimdal - Implementacja protokołu Kerberos
Instalacja i konfiguracja KDC
Logowanie do systemu
Konfiguracja poszczególnych usług
Jabber 2 - Serwer typu Instant Messaging
Wstęp
Instalacja
Konfiguracja DNS i rekordów SRV
Konfiguracja portów (jeżeli korzystamy z firewall-a)
Podstawowa konfiguracja Jabberd2
Konfiguracja dla SQL (Postgresql)
Szyfrowanie
Zakończenie
MySQL - System Zarządzania Relacyjnymi Bazami Danych (ang. RDBMS)
Co to jest MySQL?
Ogólne cechy MySQL
Instalacja
Konfiguracja MySQL
Demon MySQL
mysqladmin
mysqldump
phpMyAdmin
NFS - Network File System
Serwer
Udostępnianie
Klient
Bezpieczeństwo serwera
Dostrajanie wydajności
PDNS (Power DNS) - Serwer Nazw
Wstęp
Instalacja
Konfiguracja Postgresql dla PDNS
Konfiguracja PDNS
Domeny
Postfix - Transport poczty elektronicznej (MTA)
Zaczynamy
Konfiguracja
Szyfrowanie
Domeny
Usprawnienia
Końcowa konfiguracja
tpop3d
amavis + mks
postifx.admin
PostgreSQL - Baza danych SQL
Co to jest PostgreSQL
Instalacja pakietów
Konfiguracja PostgreSQLa w PLD
Inicjalizacja
Konfiguracja PostgreSQLa
Uruchomienie PostgreSQLa
Dodanie użytkownika
Ostatni test
Dodatki
Odnośniki
ProFTPD - serwer FTP
Wstęp
Instalacja
Podstawowa konfiguracja demona
Konfiguracja dostępu
Zakończenie
Samba - współpraca z Windows
Samba jako Serwer domeny NT4 (PDC)
Serwer członkowski domeny NT4
Snort - Sieciowy System Wykrywania Włamań
Wymagania
Instalacja Snorta i ACID
Konfiguracja Snorta
Aktualizacja reguł
Instalacja Oinkmaster
Architektura Snorta
Tryby pracy
Preprocesory
Moduł sygnatur
Ciekawe projekty
Syslog-ng
Wstęp
Konfiguracja
Test konfiguracji
Uwagi
Dodatek

W rozdziale tym przedstawimy opis instalacji i konfiguracji ważniejszych usług dostępnych w PLD

Usługi - wstęp

Usługi w PLD są przygotowane do natychmiastowego uruchomienia, wystarczy wyedytować pliki konfiguracji i można korzystać z programu. Zanim jednak zaczniemy pracować z usługami warto zapoznać się z opisem zarządzania usługami zawartym w „Zarządzanie podsystemami i usługami”.

Z wieloma demonami dostarczane są przykładowe pliki konfiguracji, którymi możemy się sugerować przy konfigurowaniu aplikacji, przykłady te są umieszczane w dokumentacji programu, w katalogu /usr/share/doc. Ponadto, zanim uruchomimy usługę, powinniśmy przyjrzeć się 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 odpowiadają argumentom programu demona, są też opcje określające np. priorytet programu i inne właściwości.

W trakcie uruchamiania usługi zdarzają się trudne do odnalezienia problemy. Pierwszą rzeczą jaką powinniśmy w takim wypadku zrobić to przeczesać logi programu, w takich wypadkach niejednokrotnie pomaga włączenie większej "gadatliwości" demona. Wygodnym sposobem szukania błędów jest uruchomienie demona na pierwszym planie (bez przejścia w tło), w takich wypadkach często demony wysyłają komunikaty na standardowe wyjście. W trudniejszych przypadkach będziemy zmuszeni użycia programu strace w celu śledzenia wywołań systemowych aplikacji. W wypadku demonów powinniśmy użyć opcji -f, aby śledzić również procesy potomne lub uruchomić demona z wyłączonym forkowaniem procesów. Opisane tu czynności są specyficzne dla każdego z demonów, zatem musimy skorzystać z dokumentacji właściwej aplikacji.

Aktualizacja niektórych demonów wiąże się z pewnymi czynnościami przygotowawczymi i poprawkami, problem ten dotyczy szczególnie silników baz danych. Zanim bezmyślnie zaktualizujemy pakiet, należy dokładnie zapoznać się z dokumentacją produktu, aby uchronić się przed unieruchomieniem usługi na dobre.

W PLD usługi, podobnie jak inne oprogramowanie, kompilowane jest z najczęściej używanymi opcjami, jeśli program nie obsługuje jakichś funkcji, to powinniśmy sprawdzić czy uzyskamy je samodzielnie budując pakiet, więcej na ten temat odnajdziemy w „Budowanie pakietów”.

ALSA - Dźwięk w Linuksie

Obecnie w Linuksie do obsługi dźwięku stosuje się system ALSA™ (ang: Advanced Linux Sound Architecture), będący następcą systemu OSS™. ALSA to zestaw modułów jądra oraz kilku narzędzi pomocniczych, moduły możemy ładować za pomocą systemu UDEV™ lub statycznie, obydwie metody będą opisane w tym rozdziale. Druga z metod jest bardziej złożona, dlatego początkujących zachęcamy do korzystania z metody opartej o system UDEV.

Instalacja

Zaczynamy od pakietu zawierającego moduły kernela:

$ poldek -i kernel-sound-alsa

Potrzebujemy jeszcze kilku narzędzi, w tym programu do zarządzania mikserem:

$ poldek -i alsa-utils

W ogóle nie należy instalować pakietu kernel-sound-oss, ALSA potrafi emulować OSS.

Konfiguracja z użyciem systemu UDEV

Niezaawansowanym zalecamy użycie udeva zamiast statycznej konfiguracji (opisanej dalej), ze względu na łatwiejszą konfigurację. Zakładam, że w systemie mamy działający UDEV, instalujemy pakiet z rc-skryptem, koniecznym do zapisywania stanu miksera (inicjacja miksera jest wykonywana bezpośrednio przez UDEV):

$ poldek -i alsa-udev

i uruchamiamy go

# /etc/init.d/alsa-udev start

Nie należy sie martwić, że nic się nie wyświetla po jego uruchomieniu, parametr start nic nie robi. Najprawdopodobniej mamy już załadowane właściwe moduły i jedyne co pozostaje nam to w mikserze ustawić głośność i wyłączyć wyciszenie, co zostało opisane w dalszej części rozdziału. Więcej o systemie UDEV w „Udev - dynamiczna obsługa sprzętu”.

Konfiguracja statyczna

Konfiguracja statyczna jest alternatywną metodą w stosunku do powyższej. Zaczynamy od zainstalowania pakietu alsa-utils-init:

$ poldek -i alsa-utils-init

Teraz musimy postarać się o dodanie koniecznych aliasów do pliku /etc/modprobe.conf, które posłużą do załadowania koniecznych modułów, przez zainstalowany przed chwilą rc-skrypt. Możemy wykonać to na dwa sposoby:

  • samodzielnie - za pomocą dowolnego edytora tekstu; wpisy możemy skopiować z opisu Driver & Docs, urządzenia odnalezionego na liście obsługiwanego sprzętu

  • za pomocą programu alsaconf, który wykryje urządzenie i dokona koniecznych wpisów

Pierwsza z metod jest tak oczywista, że zajmiemy się tylko drugą z wymienionych. Na początek musimy się upewnić, że mamy pakiet pciutils™ i uruchamiamy program:

# /usr/sbin/alsaconf

Po ukazaniu się ekranu z napisem "Searching sound cards" czekamy ok. 10 sekund i wciskamy ctrl-c (konfigurator szybko znajduje naszą właściwą kartę - a ponieważ szuka również kart starego typu oraz różnych egzotycznych, co zajmuje mu bardzo dużo czasu dlatego przerywamy wyszukiwanie). Następne okno pokazuje nam listę znalezionych kart muzycznych (zwykle jedną). Zatwierdzamy wyświetloną kartę i na pytanie:

Do you want to modify /etc/modprobe.conf?

Odpowiadamy twierdząco, spowoduje to dopisanie odpowiednich aliasów modułów do pliku konfigurującego. Kiedy progam zakończy działanie, uruchamiamy rc-skrypt:

# /etc/init.d/alsasound start

Teraz pozostaje nam ustawić głośność w mikserze oraz wyłączyć wyciszenie.

Ustawienie miksera i testowanie

Domyślnie wszystkie "suwaki" miksera są ustawione na zero i dodatkowo włączone jest wyciszenie (mute), aby to zmienić musimy uruchomić program alsamixer lub amixer:

# /usr/bin/alsamixer

Wyłączmy mute (klawisz m) i przesuwamy "suwaki" (strzałkami) kanału Master i PCM. Teraz możemy przetestować ustawienia z poziomu root-a, możemy to zrobić odsłuchując 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 już praktycznie koniec instalacji. Pamiętać należy, że do niektórych programów należy doczytać odpowiednie wtyczki, które umożliwią prace z ALSA™-ą. Wtyczki te łatwo rozpoznać po dopisce "alsa" w nazwie pakietu.

Na koniec pozostaje nam nadać uprawnienia wybranym użytkownikom, do obsługi dźwięku. Musimy zapisać użytkowników do grupy audio np.:

# usermod -A jkowalski audio

Więcej o uprawnieniach w „Grupy”.

Zaawansowana obsługa miksera

W wielu przypadkach okazuje się, że posiadamy kartę muzyczną, która nie potrafi miksować dźwięku sprzętowo - co powoduje m.in., że jednocześnie może z karty korzystać jeden program lub proces. Zdarza się także, że niektóre programy na sztywno próbują połączyć się np. z OSS w celu obsługi dźwięku (np. Skype™). W takim przypadku możemy skorzystać z wtyczki ALSA™-y o nazwie dmix. Wbrew nazwie nie musimy niczego dogrywać - wszystko odbywa się w plikach tekstowych: /etc/asound (gdy chcemy ustawień globalnych) lub ~/.asoundrc (czyli indywidualnych ustawień dla każdego użytkownika). Przykładowy wpis przedstawimy poniżej - po więcej szczegółów odsyłamy na strony projektu ALSA (www.alsa-project.org):

# definiujemy urządzenie wirtualne nazwane przez nas demixer
# do którego później będziemy się odwoływać:
pcm.demixer	
	{
	type dmix 		# typ urządzenia, tutaj "dmix"
	ipc_key 1024 		# numer musi być 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"
	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 że tylko dwa pierwsze kanały bedą używane 
# przez demixer (czyli tutaj dmix)

	bindings	{
	0 0	# from 0 => to 0
	1 1	# from 1 => to 1
			}
	} # koniec konfiguracji wirtualnego urządzenia demixer
	
# następnie ustawiamy przekierowanie z wybranych
# urządzeń do wirtualnego urządzenia demixer:
# możemy przekierowywać z następujących urządzeń 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 korzystające z urządzenia
# default ALSA-y przekierowujemy do miksera 
# czyli wszystko przechodzi przez dmix

pcm.!default	{
	type plug
	slave.pcm "demixer"
		}
		
# OSS device /dev/mixer0 use hardware
# Urządzenie OSS /dev/mixer0 bez zmian
# obsługuje pierwszą (0) kartę audio bezpośrednio

ctl.mixer0	{
	type hw
	card 0
	}

Jeśli chcemy jedynie przekierować dźwięk z programów obsługujących tylko OSS™ do ALSA™, bez programowego miksowania (czyli bez używania dmix) wystarczy że wpiszemy tylko:

# from /dev/dsp0 to ALSA 
pcm.dsp0 {
	type plug
	slave.pcm "hw:0"
	}
# lub: 
#  pcm.dsp0 pcm.default
# jeśli "default" nie było redefiniowane

ctl.mixer0 {
	type hw
	card 0
	}

Natomiast najprostsze przekierowanie z /dev/dsp0 do dmix wygląda tak:

pcm.dsp0 {
    type plug
    slave.pcm "dmix"
    }

Dla chipsetów nvidia nforce(2) (intel8x0) oraz C-media konfiguracja powinna wyglądać 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ępnie możemy przetestować nasz "dmix" czyli urządzenie demixer

alsaplayer -o alsa -d demixer test.mp3

ponieważ wcześniej zdefiniowaliśmy urządzenie "default", ALSA™ kieruje wszystko na urządzenie "demixer" - co jest równoważne:

alsaplayer -o alsa test.mp3

To tylko podstawowe przykłady działania jakie daje nam ALSA™, a dzięki olbrzymim możliwościom definiowania dowolnych urządzeń wirtualnych i przekierowywania dźwięku, możemy uzyskać ciekawe i różnorodne efekty. Więcej o konfiguracji urządzeń PCM znajdziemy tutaj: www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html.

Przy pracy z pluginem "dmix" nie należy zapomnieć o wyłączeniu demonów ARTs i ESD gdyż w przeciwnym razie mogą pojawić się opóźnienie w odtwarzaniu dźwięków i zakłócenia w niektórych programach, gdyż wiele z nich próbuje najpierw korzystać z w/w demonów dźwięku.

Uwagi

Więcej o dźwięku pod Linuksem na stronie linux-muzyka.ixion.pl/.

Apache - Serwer stron internetowych

Wstęp

Każdy, nawet początkujący użytkownik sieci internet zetknął się z apaczem świadomie lub nie. Apache jest oprogramowaniem, które można powiedzieć zdominowało w pewnym stopniu rynek aplikacji serwerowych. Do działania wykorzystuje on protokół HTTP (RFC2616). Jak sama nazwa wskazuje Apache (a patche server) składa się z wielu modułów. Można to zauważyć już na pierwszy rzut oka. W tym rozdziale zostanie opisana autoryzacja, obsługa języka PHP, CGI, virtualhosts oraz ogólna jego konfiguracja. Przedstawiona poniżej oparta została o apache z serii 2.x.

Instalacja

Apache w PLD jest podzielony na wiele małych pakietów, możemy dzięki instalować tylko potrzebne moduły. Jeśli nie możemy się połapać w tym gąszczu to możemy posłużyć się metapakietem apache, który za pośrednictwem mechanizmu zależności zainstaluje najważniejsze pakiety.

# poldek -i apache

Kiedy będziemy mieli zainstalowane wymagane pakiety, będziemy mogli wstępnie przetestować serwer, zatem uruchomimy usługę:

# service httpd start

W katalogu /home/services/httpd umieszczamy jakąś testową stronę WWW którą nazwiemy np. test.html i sprawdzamy za pomocą przeglądarki czy się prawidłowo wyświetla:

$ elinks localhost/test.html

Jeśli wszystko jest w porządku, to możemy przejść do właściwej konfiguracji serwera.

Pliki konfiguracji

Tytułem wstępu pragnę powiedzieć, że niniejszy dokument nie może być traktowany jako dokumentacja do Apache. Ma on na celu ułatwienie użytkownikowi zapoznania się z usługą oraz kilkoma jej możliwościami. Po bardziej szczegółowe informacje odsyłam do stron podręcznika systemowego (man) oraz dokumentacji on-line

  • /etc/httpd/httpd.conf - w tym katalogu przechowywane są pliki konfiguracyjne demona. Po instalacji poszczególnych składników Apache, właśnie w tym miejscu należy szukać plików konfiguracyjnych od nich.

  • /home/services/httpd - pliki domyślnej strony Apache, katalog z komunikatami o błędach oraz katalog przeznaczony dla skryptów cgi.

  • /usr/lib/apache - moduły potrzebne do działania Apache oraz poszczególnych jego składników. Warto o tym pamiętać w przypadku problemów z uruchomieniem usługi.

  • /usr/sbin - jest to katalog należący stricte do Apache, jednak warto o nim wspomnieć ze względu na to iż przechowywane są w nim jego binaria. Aby się dowiedzieć które należą do niego wydaj następujące polecenie

    # rpm -ql apache |grep ^\/usr\/sbin

Aby nasz serwer obsługiwał dodatkowe funkcje musimy zainstalować odpowiednie moduły, wraz z modułami dostarczane, są pliki konfiguracji z dyrektywami konfiguracyjnymi dla tego modułu.

Apache domyślnie działa z uprawnieniami zwykłego użytkownika (http), dlatego trzeba zadbać o to by demon miał prawo do odczytu plików ze stronami WWW.

Bardzo pożyteczną cechą Apache jest możliwość tworzenia lokalnych plików konfiguracji, dzięki którym możemy modyfikować niektóre opcje konfiguracji. Pliki te mają nazwę .htaccess i może ich używać każdy, kto ma tylko dostęp do katalogu ze stroną WWW. Wygoda w ich używaniu polega na tym, że nie ma potrzeby restartowania demona po każdorazowej ich modyfikacji.

Podstawowa konfiguracja

Głównym plikiem konfiguracyjnym jest /etc/httpd/apache.conf. Spośród wielu opcji w tym pliku zajmiemy się dwiema podstawowymi:

ServerAdmin root@example.net

Powinieneś tutaj wpisać kontaktowy adres e-mail do siebie jako administratora tego serwera.

Poniżej znajduje się opcja ServerName. Powinna ona wyglądać tak jak w poniższym przykładzie.

ServerName example.net:80

Dosłownie jest to nazwa tego serwera. A dokładniej nazwa domenowa skonfigurowana na serwerze nazw opiekującym się Twoją domeną. Jeżeli nie posiadasz zarejestrowanej domeny, powinieneś wpisać tutaj adres IP.

Teraz zajmiemy się opcją DocumentRoot, którą odnajdziemy w /etc/httpd/conf.d/10_common.conf Określa ona domyślny katalog w którym będzie przechowywana strona internetowa. Wpisując nazwę lub adres IP określony przez ServerName właśnie z tego katalogu zostaną pobrane i wczytane przez przeglądarkę pliki strony.

DocumentRoot "/home/services/httpd/html"

Domyślnie wszystkie żądania są tutaj skierowane. Ta lokalizacja nie jest obligatoryjna, więc nie musisz się jej trzymać. Może zostać zmieniona przy użyciu dowiązań symbolicznych lub aliasów wskazujących w inne miejsca.

Zgodnie z obecnym standardem tworzenia stron internetowych, domyślnym plikiem który jest automatycznie wczytywany po wpisaniu w przeglądarce adresu jest index, który w zależności od konstrukcji strony może mieć różne rozszerzenia. A więc skąd Apache wie, co ma zostać wczytane jako pierwsze? Do tego właśnie służy pakiet apache-mod_dir. Jego plikiem konfiguracyjnym jest /etc/httpd/httpd.conf/59_mod_dir.conf

Poprzez dyrektywę DirectoryIndex określa się czego i w jakiej kolejności ma szukać przeglądarka.

DirectoryIndex index.html index.html.var index.htm index.shtml \
    index.cgi index.php

Oczywiście możemy podawać tutaj różne nazwy plików startowych stron w zależności od naszych potrzeb.

Strony użytkowników

Swobodne publikowanie stron internetowych przez użytkowników jest możliwe dzięki pakietowi apache-mod_userdir. Opcja UserDir w pliku 16_mod_userdir.conf definiuje nazwę katalogu przechowującego strony użytkowników wewnątrz ich katalogów domowych.

UserDir public_html

Przykład: Użytkownik Jan Kowalski posiada konto o nazwie: jan. W /home/users/jan jest jego katalog domowy. Swoją stronę internetową umieszcza w katalogu /home/users/jan/public_html, zaś dostęp do nie uzyskuje za pomocą adresu http://example.net/~jan.

Aby strona się wyświetliła należy ustawić odpowiednie prawa dostępu - tak by Apache (domyślnie z prawami użytkownika http) miał prawo do odczytu. Katalog domowy jan powinien mieć ustawione prawa 711. Katalog przechowujący jego stronę czyli public_html powinien mieć 755. Każdy katalog zawierający elementy strony powinien mieć również uprawnienia 755. Pliki strony natomiast 644.

Virtual Hosts

Mechanizm hostów wirtualnych pozwala obsługiwać strony o róż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 każdego wirtualnego hosta, drugi zaś korzysta z jednego. Z oczywistych względów dużo bardziej popularna jest druga z metod i właśnie ją będziemy opisywać.

Obsługa hostów wirtualnych jest związana z odpowiednią konfiguracją domen w systemie DNS - wymaga wpisów typu IN A wskazujących na nasz serwer WWW. Konfigurację serwera DNS opisano w „BIND - Serwer Nazw” i będzie docelowo konieczna, jednak dla potrzeb testowych wystarczą nam wpisy w pliku /etc/hosts, który z kolei został opisany w „Podstawowa konfiguracja sieci”.

W naszym przykładzie dodamy obsługę domeny moja-strona.com, na początku należy stworzyć dodatkowy plik konfiguracji (dla porządku) o nazwie np. vhosts.conf, który umieścimy w katalogu /etc/httpd/httpd.conf/. Zakładamy, że wszystkie vhosty będziemy trzymać w katalogu /home/services/httpd/vhosts/. Plik będzie się zaczynał od następującego 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 mają być używane do obsługi hostów witrualnych, w tym wypadku wszystkie, co jest najczęściej spotykaną konfiguracją. Sekcja Directory zezwala na dostęp do plików ze wskazanego katalogu. Pierwszy zdefiniowany virtualhost (_default_) ma za zadanie wskazanie serwerowi domyślnej strony, wyświetlanej w wypadku jeśli jakiś vhost nie jest skonfigurowany na naszym serwerze, w przeciwnym razie wyświetli się strona pierwszego w kolejności vhosta. Teraz możemy dodawać vhosty, wg. przykładu:

<VirtualHost *>
        ServerName moja-strona.com
        DocumentRoot /home/services/httpd/vhosts/moja_strona
</VirtualHost>

Wewnątrz sekcji VirtualHost znajduje się opcja ServerName, mówiąca o nazwie domenowej vhosta, a poniżej wskazanie są ścieżki do katalogu z plikami strony. Po uruchomieniu mechanizmu hostów wirtualnych całkowicie bezużyteczne staną się globalne opcje ServerName czy DocumentRoot, od tej pory konfiguracja w całości opiera się o vhosty. W konfiguracji hostów wirtualnych możemy umieszczać wiele opcji używanych w głównym serwerze (np.: ServerAdmin, ErrorLog), tak zdefiniowane opcje przesłonią globalne wartości.

Istnieje możliwość masowego konfigurowania vhostów, bez konieczności tworzenia wpisów dla każdego po kolei, służy do tego moduł vhost-alias dostarczany wraz z pakietem apache-mod_vhost_alias. Jego opis wykracza poza ramy tego rozdziału, więcej na jego temat odnajdziemy w dokumentacji serwera.

Ograniczanie dostępu na podstawie adresu

Czasami chcemy ograniczyć możliwość przeglądania stron dla konkretnych adresów lub klas adresowych. W tym celu użyjemy modułu apache-mod_authz_host, dzięki niemu będziemy mogli chronić przed dostępem do wskazanych katalogów. Jeżeli potrzebujesz chronić jedynie jeden lub kilka plików, stwórz w obrębie strony katalog o dowolnej nazwie i umieść je w nim. Oczywiście musisz pamiętać o przekonstruowaniu linków na stronie.

Do konfiguracji Apache dodajemy podobną konstrukcję konstrukcję:

<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ęp do katalogu intra mają wszystkie komputery z określonej w przykładzie sieci oraz jeden komputer (bądź urządzenie udostępniające NAT) o wymienionym adresie. Wszystkie połączenia nie pasujące do tych kryteriów traktowane są jako deny, zgodnie z porządkiem wyznaczonym przez dyrektywę Order.

Ograniczenie dostępu za pomocą loginu i hasła

Apache udostępnia mechanizm autoryzacji, który używany jest do wyodrębnienia z serwisu pewnej części przeznaczonej dla upoważnionych użytkowników. Ograniczenie działa na poziomie katalogów i podobnie jak w ograniczeniu dla adresu (opisanego powyżej) nie można w ten sposób chronić poszczególnych plików.

Apache wspiera wiele rodzajów źródeł uwierzytelniających: pliki tekstowe, konta systemowe, bazy LDAP i inne. My będziemy zajmować się autoryzacją za pomocą plików tekstowych, ze względu na popularność i prostotę tego rozwiązania. Istnieją 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 przeglądarki WWW, tak więc pozostaje nam używanie metody Basic.

Zaczynamy od instalacji metapakietu apache-mod_auth oraz pakietu htpasswd-apache. Teraz dodajemy do któregoś z plików konfiguracji regułkę chroniącą 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 użytkowników, jak widać ścieżka ta jest inna niż chroniony katalog ze względów bezpieczeństwa. Opcja Require określa jacy użytkownicy są akceptowani - tutaj każ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łasność, aby dostęp do niego miał wyłącznie użytkownik http:

# chmod 600 /home/services/httpd/.htpasswd
# chown http.http /home/services/httpd/.htpasswd

Po restarcie każde odwołanie do katalogu będzie wymagało podania loginu jan i hasła. Istnieje także możliwość dodania obsługi grup - mechanizmu zbliżonego działaniem do uniksowych grup systemowych.

W wielu wypadkach będziemy chcieli dać możliwość użytkownikom tworzenia plików z hasłami z wraz z plikami .htaccess w katalogu określonym przez DocumentRoot. Stanowi to zagrożenie bezpieczeństwa, ze względu na możliwość wyświetlenia zawartości tych plików. Możemy się zabezpieczyć przed tym instalując pakiet apache-mod_authz_host, dzięki któremu m.in. nie zostaną wysłane do przeglądarki pliki .ht*

Obsługa skryptów PHP

Ze względu na dużą funkcjonalność język PHP stał się już w zasadzie pewnym standardem w tworzeniu interaktywnych stron internetowych. Współczesne serwisy wykorzystują m. in. bazy danych, dlatego zostanie również opisane jak taką obsługę zapewnić. Przeglądając listę dostępnych do zainstalowania pakietów z PHP na pierwszy rzut oka widać nacisk twórców dystrybucji jaki został nałożony na modularność. Daje to niesamowitą wolność w wyborze tego co jest Ci dokładnie potrzebne.

Zaczynamy od instalacji pakietu apache-mod_php, w ten sposób otrzymamy podstawową wersję PHP, dodatkowe pakiety instalujemy wtedy gdy potrzebna nam jest jakaś funkcjonalność. Najlepszą metodą sprawdzenia czy PHP działa jest użycie funkcji phpinfo(), aby z niej skorzystać stwórz plik z zawartością taką jak poniżej:

<? phpinfo(); ?>

następnie należy go umieść w katalogu /home/services/httpd/html, pod nazwą np. info.php. Teraz wpisujemy w przeglądarce adres http://example.net/info.php, powinieneś uzyskać informacje m. in. na temat wersji PHP, konfiguracji serwera oraz obsługiwanych modułów.

Obsługa różnego typu systemów bazodanowych rozbita jest na osobne pakiety zawierające definicje funkcji PHP które ją zapewniają. Poniżej w tabeli znajduje się lista która to odzwierciedla.

Tabela 16.1. Obsługa baz danych

Nazwa pakietuBaza Danych
php-dbaModuł dla PHP dodający obsługę dla baz danych opartych na plikach (DBA).
php-dbaseModuł PHP ze wsparciem dla DBase.
php-fileproModuł PHP dodający możliwość dostępu (tylko do odczytu) do baz danych filePro.
php-interbaseModuł PHP umożliwiający dostęp do baz danych InterBase i Firebird.
php-mssqlModuł PHP dodający obsługę baz danych MS SQL poprzez bibliotekę FreeTDS.
php-mysqlModuł PHP umożliwiający dostęp do bazy danych MySQL.
php-odbcModuł PHP ze wsparciem dla ODBC.
php-pgsqlModuł PHP umożliwiający dostęp do bazy danych PostgreSQL.
php-sybaseModuł PHP dodający obsługę baz danych Sybase oraz MS SQL poprzez bibliotekę SYBDB.
php-sybase-ctModuł PHP dodający obsługę baz danych Sybase oraz MS SQL poprzez CT-lib.

Aby skorzystać z którego kolwiek modułu wystarczy go po prostu zainstalować. Przeprowadzając instalację w trybie wsadowym pamiętaj o zrestartowaniu usługi apache, o czym zostaniesz przez poldka poinformowany. Dystrybucja nie posiada niestety pakietów do obsługi bazy danych Oracle. Jeżeli jest Ci ona potrzebna musisz zbudować PHP włączając obsługę oracla z serwera CVS, instalując uprzednio Oracla którego posiadasz.

Warto jeszcze wspomnieć o narzędziach wspomagających zarządzanie bazami danych. Do obsługi bazy MySQL służ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 zainstalować pakiet apache-mod_cgi. Po przeładowaniu demona programy CGI obsługiwane będa w katalogu /home/services/httpd/cgi-bin, zgodnie z ustawieniami w pliku /etc/httpd/apache.conf.

Żeby przetestować CGI wystarczy że utworzymy plik o następującej treści:

#!/bin/sh
echo "Content-type: text/html\n\n"
echo "Hello, World."

a następnie umieścimy go w odpowiednim katalogu z nazwą np. cgi.sh, nadamy mu prawo wykonywalności i w przeglądarce podamy adres http://example.net/cgi-bin/cgi.sh. Możemy do tego użyć również testowych skryptów przychodzących z pakietem apache-cgi_test.

Jeśli zechcemy wskazać więcej katalogów w których pozwolimy uruchamiać aplikacje CGI (np. dla hostów wirtualnych) wystarczy, że do któregoś z plików konfiguracji dodamy odpowiednio skonfigurowaną opcję ScriptAlias np.:

ScriptAlias /cgi-bin/ "/home/users/jan/cgi-bin/"

Ze względów bezpieczeństwa autorzy Apache zalecają by taki katalog leżał poza ścieżką wskazaną w opcji DocumentRoot.

Security Socket Layer (SSL)

Mechanizm ten wykorzystuje się w serwisach wymagających od użytkownika autoryzacji. Najbardziej typowymi aplikacjami tego typu są różnego rodzaju klienci poczty. SSL zapewnia szyfrowany kanał dla informacji przepływającej od użytkownika do serwera. Dzięki temu niemożliwe jest podsłuchanie hasła. UWAGA! Jeden certyfikat SSL może zostać przypisany tylko dla jednego adresu IP.

Konfigurację zaczynamy od zainstalowania pakietu apache-mod_ssl. W wyniku instalacji utworzony zostanie plik /etc/httpd/httpd.conf/40_mod_ssl.conf. Zanim zaczniemy go konfigurować należy wygenerować certyfikaty. Służy do tego polecenie openssl. Program ten znajduje się 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łuży do tworzenia certyfikatu. Robimy to w następujacy sposób.

# openssl req -new -x509 -days 365 -key /etc/httpd/ssl/apache.key \
     -out /etc/httpd/ssl/apache.crt

Proces tworzenia certyfikatu będzie 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 []:root@example.net

Pola, które widzisz w powyższym przykładzie należy wypełnić zgodnie z tym jak zostało to przedstawione. W przypadku kiedy serwer jest prywatną własnością i nie należy do żadnej firmy, w polu Organization Name możesz wpisać imię i nazwisko. Para plików: klucz oraz certyfikat powinny mieć takie uprawnienia, aby użytkownik http mógł je odczytywać.

Możemy teraz wyedytować plik /etc/httpd/httpd.conf/40_mod_ssl.conf. Pośród szeregu opcji interesuje nas w zasadzie tylko konfiguracja katalogu, do którego połączenie będzie szyfrowane oraz ścieżki do plików z kluczem oraz certyfikatem. Musimy odnaleźć początek sekcji o nazwie VirtualHost.

<VirtualHost _default_:443>
	DocumentRoot "/home/services/httpd/html/webmail"
	ServerName mail.example.net:443
	ServerAdmin root@example.net
	ErrorLog /var/log/httpd/error_log
	TransferLog /var/log/httpd/access_log

Jak widać jej początek nie różni się niczym od konfiguracji VirtualHosts. Zwróć uwagę na opcję ServerName. Powinna ona kończyć się ciągiem :443 który oznacza port na którym ma nasłuchiwać 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 ścieżki do plików które wygenerowaliśmy w poprzednim etapie.

Po zapisaniu i zakończeniu edycji pliku restartujemy Apache, aby nasze zmiany odniosły skutek. Aby nawiązać połączenie szyfrowane z webmailem należy w przeglądarce wpisać adres https://example.net/webmail. Aby ustanowić połączenie szyfrowane i za każdym razem nie wpisywać https://, powinieneś użyć 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 już się dowiedziałeś, robisz wpis w pliku strefy domeny oraz konfigurujesz apache. Natomiast w katalogu /home/services/httpd/html/mail tworzysz plik o nazwie index.php z zawartością taką 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();
                                                                                                     
?>

Oczywiście domena, która jest podana na listingu musi odnosić się do vhosta z opcją DocumentRoot ustawioną na /home/services/httpd/html/mail.

Indeksowana zawartość katalogu

Jest to bardzo przydatna funkcja, pozwalająca w łatwy sposób udostępnić zawartość katalogu na serwerze. Aby umożliwić indeksowanie musimy zainstalować moduł apache-mod_autoindex.

poldek -i apache-mod_autoindex

Aby uruchomić indeksy musimy włączyć opcję Indexes. W domyślnej konfiguracji, Apache ma włączone indeksy dla wszystkich podkatalogów wewnątrz /home/services/httpd/html (w pliku 10_common.conf). Jeśli ustawiliśmy inaczej to musimy włączać tą opcję dla każdego z katalogów osobno np.:

<Directory /home/services/httpd/html/katalog>
	Options Indexes
</Directory>

Opcja nie zadziała wtedy, kiedy zainstalowaliśmy moduł apache-mod_dir i w katalogu znajduje się plik określony przez DirectoryIndex.

Uwagi

Po każdej zmianie konfiguracji w katalogu /etc/httpd/httpd.conf konieczne jest przeładowanie demona, aby na nowo odczytał swoje pliki konfiguracji. Możemy użyć w tym celu odpowiedniego wywołania rc-skryptu:

# service httpd restart

Jeśli będziemy modyfikować konfigurację działającego serwera produkcyjnego, to dobrą praktyką jest wcześniejsze użycie programu apachectl z pakietu apache-tools do sprawdzenia poprawności składni plików konfiguracji:

# apachectl configtest
Syntax OK

Na szczególną uwagę zasługują parametry rc-skryptu: reload|force-reload|graceful np.:

# service httpd reload

Użycie któregoś z nich wywołuje "łagodny" restart serwera (graceful restart), który pozwala dokończyć wykonywane prace przez procesy. Dzięki temu restart nie jest odczuwalny przez klientów. Parametry te mają jeszcze jedną ważną zaletę, wywołanie ich powoduje sprawdzenie konfiguracji serwera przed rozpoczęciem restartu, dzięki czemu nie musimy do tego używać programu apachectl.

BIND - Serwer Nazw

DNS - Domain Name System

DNS jest systemem hierarchicznym. Na samym szczycie owej hierarchii stoją tzw. TLD (Top Level Domains), czyli domeny najwyższego rzędu. Zaliczają się do nich takie domeny jak .com (komercyjne), .pl (krajowe), .net (sieci) i inne. Są to domeny powstałe na podstawie odpowiednich postanowień, opisane w specjalnych dokumentach. Każda z wymienionych (lub też nie wymienionych) tutaj TLD's posiada swoje subdomeny, np. pld-linux.org. Z kolei każda powstała w wyniku rejestracji danej nazwy domena może mieć swoje poddomeny, np. www.pld-linux.org. W ten sposób można tworzyć bardzo zagęszczone hierarchie w obrębie danej domeny. Niniejszy rozdział dotyczy implementacji Bind™ określanego czasem jako named™ - jednego z najpopularniejszych serwerów DNS.

Każda domena (zwana również strefą) musi mieć co najmniej dwa serwery DNS, jest to wymóg registrarów, czyli instytucji oferujących możliwość rejestracji domen. Jeden z serwerów określa się jako podstawowy (również master lub primary) a drugi jako zapasowy (slave lub secondary).

Wstęp

Bind w PLD dziala w środowisku chroot, w katalogu /var/lib/named, musimy o tym pamiętać, 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 wygląda następująco:

dev/
etc/
M/
S/
named.pid
root.hint

Podobnie jak w normalnym środowisku, jest obecny tutaj katalog /dev, w którym znajdują się urządzenia konieczne do działania demona: /dev/null oraz /dev/urandom. Katalog /etc jak zapewne się domyślasz, przechowuje pliki konfiguracyjne. U nas znajduje się 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 liś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 żądanych 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.

Podstawowa konfiguracja

Głównym plikiem konfiguracyjnym serwera Bind jest /etc/named.conf. Znajdują się w nim podstawowe opcje usługi oraz informacje na temat obsługiwanych stref. Poniżej zamieszczono domyślne wpisy, które znajdują się 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 początku pliku konfiguracyjnego znajduje się sekcja options. Najbardziej istotną opcją jest tutaj directory. Wskazuje ona na główny katalog przechowywania plików stref. Być może zdziwi Cię nieco parametr powyższej opcji. Jak już wcześniej wspominałem Bind w PLD posiada własne chrootowane środowisko, dlatego można taki zapis zastosować.

Zanim przejdę do omawiania pozostałych wpisów, należy się jeszcze słowo wyjaśnienia na temat konstrukcji samego pliku. Na pierwszy rzut oka poszczególne wpisy są podzielone na sekcje. Te z kolei ograniczone są klamrami. Znak ; również pełni tutaj rolę ogranicznika dla poszczególnych opcji jak i całych sekcji ujętych w klamry. Warto o tym wiedzieć ze względu na ewentualne szukanie błędów powstałych na skutek edycji tego pliku.

Poniżej mamy zdefiniowane trzy sekcje stref zaczynających się słowem kluczowym zone. W powyższym przykładzie przedstawione są wpisy określające localhosta. Są one typu master. Plik strefy w każdej z nich wskazany jest opcją file. Strefa nie musi być aktualizowana, ani synchronizowana z serwerem slave, więc dwie pozostałe opcje mają parametr none oraz any. Ostatnia strefa służy do komunikacji naszego binda z Root serwerami o których była mowa we wstępie. Bez tej strefy nie mógłby on wyszukiwać nazw w internecie. Mówiąc w przenośni byłby ślepy.

Każdorazowe odpytywanie Root Servers może się okazać mało wydajne, ze względu na duże czasy odpowiedzi. Dlatego, jeżeli chcemy przyspieszyć ten proces powinniśmy sekcję option zmodyfikować o wpis taki jak poniżej

options {
forwarders { 194.204.159.1; 194.204.152.34; };
}

Oczywiście nie musimy posługiwać się takimi adresami jak w przykładzie. Możemy sobie wybrać takie serwery DNS, które będą nam odpowiadały najszybciej np. serwery naszego ISP.

W PLD zaleca się, aby wszystkie pliki stref w zależności od typu domeny były przechowywane w katalogach /var/lib/named/M oraz /var/lib/named/S. Tak naprawdę o ścieżce do tych katalogów decydują 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 wyjaśniona w poprzedniej części tego rozdziału. Poniż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 już na początku tego rozdziału. Podsumujmy więc dostępne informacje skupiając się na powyższym przykładzie:

  • zone "example.net" - nazwa strefy

  • type master - rodzaj serwera

  • file "M/example.net" - nazwa pliku z konfiguracją strefy

  • allow-transfer { 123.45.67.89; } - adres serwera, który ma możliwość transferu całej strefy, Jeżeli posiadasz więcej niż jeden taki DNS, możesz je wpisać pomiędzy klamry pamiętając o tym, aby rozdzielić poszczególne adresy IP, znakiem ';'.

  • notify yes - opcja ta włącza powiadamianie zapasowego serwera DNS o zmianach w naszej domenie.

Musimy teraz utworzyć plik strefy dla domeny example.net wskazany przez opcję file. Poniżej zamieszczam treść 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
        )
@               IN      NS      ns1.example.net.
@               IN      NS      ns2.example.net.
@               IN      MX      10    mail.example.net.
@               IN      A       123.45.67.8
ns1             IN      A       123.45.67.8
ns2             IN      A       90.12.34.237
mail            IN      A       123.45.67.8
www             IN      A       34.5.6.78
ftp             IN      CNAME   www

Plik strefy można podzielić na trzy odrębne sekcje. Pierwsza określa nazwę domeny oraz okres ważności wpisów. Druga, kto tą domeną zarządza. W trzeciej znajduje się cała jej zawartość. Bardziej szczegółowy opis znajduje się w poniższym wykazie. Kilka zdań o wyrażeniach stosowanych w plikach stref. Warto o nich pamiętać. Wszystkie wpisy poprzedzone ;; będą ignorowane i traktowane jak komentarz. Kolejnym ważnym znakiem jest znak kropki. Jego znaczenie omówię poniżej w przykładzie.

@               IN      NS      ns1.example.net.

Jeżeli w powyższym wpisie pominęlibyśmy końcowy znak kropki, wówczas Bind dokleiłby na końcu nazwę domeny. Wówczas z ns1.example.net zrobiłby się wpis ns1.example.net.example.net, co oczywiście nie jest pożądane. następnym znakiem specjalnym na który warto zwrócić uwagę jest @. Otóż można go potraktować jako pewnego rodzaju zmienną, która przechowuje nazwę example.net. Jednym słowem, example.net i @ to to samo.

  • $TTL 86400 - czas ważności rekordów w domenie wyrażony w sekundach; 86400 s. to jedna doba

  • $ORIGIN example.net. - domena jaką będzie opisywał bieżący plik strefy.

  • @ IN SOA ns1.example.net. root.example.net. - Rekord typu SOA czyli Start Of Authority. Możemy się z niego dowiedzieć, kto zarządza domeną (root@example.net), jaki jest adres serwera primary DNS. Zwróć uwagę, że w adresie root@example.net zamiast znaku @ użyta została kropka. Rekord SOA posiada swoją własną strukturę o której poniżej. Zawarta jest ona pomiędzy znakami ( ).

  • 2004022300 ;; serial - numer seryjny domeny. Powinien on być zwiększany wraz z każdą jej modyfikacją. W dobrym tonie jest utrzymywanie go w formacie YYYYMMDDnn czyli rok, miesiąc, dzień oraz numer modyfikacji w danym dniu.

  • 1200 ;; refresh - To pole rekordu SOA definiuje jak często serwery slave mają sprawdzać czy dane o domenie nie zmieniły się na masterze. Według RFC 1035 wartość ta powinna się zawierać pomiędzy 1200 a 43200 (czyli od dwudziestu minut do dwunastu godzin). W praktyce najlepsza wartość zawiera się między 3600 a 7200 sekund.

  • 1200 ;; retry - Czas po jakim secondary ma ponowić próbę kontaktu z masterem, gdy taka się nie powiedzie. Zalecana wartość pomiędzy 120 a 7200 sekund.

  • 2419200 ;; expire - Ta wartość określa czas po jakim dane domeny mają zostać uznane za nieaktualne gdy serwer secondary nie będzie mógł się skontaktować z primary. Zalecana wartość zawiera się pomiędzy 1209600 a 2419200 sekund, czyli od dwóch do czterech tygodni.

  • 86400 ;; TTL - Time To Live. Określa ile czasu informacja o danym rekordzie ma być ważna. Jest to okres przez jaki informacja o naszej domenie będzie przechowywana przez serwer DNS, który ją pobrał. Zalecana wartość zawiera się między 86400 a 432000 sekund, czyli przez okres od jednego do pięciu dni.

Bezpośrednio pod rekordem SOA definiujemy, które serwery DNS będą obsługiwały naszą domenę. Jeszcze raz przypominam aby właściwie zamknąć ten rekord. Bez tego nasza domena nie będzie działać. Do definiowania serwerów DNS służą wpisy typu IN NS.

@               IN      NS      ns1.example.net.
@               IN      NS      ns2.example.net.

Powyższy wpis mówi, że domenę example.net obsługuje serwer DNS ns1.example.net oraz ns2.example.net. Jeżeli obie nazwy dotyczą komputerów, które wcześniej nie pełniły roli serwerów DNS, powienieś dodać wpisy takie jak poniżej.

ns1             IN      A       123.45.67.8
ns2             IN      A       90.12.34.237

ns1 oczywiście może wskazywać na adres serwera DNS który zapewne konfigurujesz; ns2 powinien wskazywać na Twojego secondary. Zrobiliśmy to posługując się wpisami typu IN A. Jak zapewne pamiętasz, brak końcowej kropki powoduje doklejenie do wpisanej nazwy tego co znajduje się w zmiennej $ORIGIN. Możemy więc uznać to co widzisz w powyższym przykładzie za postać skróconą poniższego wpisu.

ns1.example.net.             IN      A       123.45.67.8
ns2.example.net.             IN      A       90.12.34.237

Wpisy typu IN A służą do określania, że właśnie ten adres IP ma przypisaną taką a nie inną nazwę. Oczywiście do jednego adresu IP możesz stworzyć kilka takich wpisów. Jeżeli posiadasz serwer poczty, powinieneś zrobić wpis mówiący o tym, że będzie on obsługiwał pocztę dla domeny example.net.

@               IN      MX      10    mail.example.net

Dokładnie tak jak wcześ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łuży właśnie do definiowania w DNS serwera poczty. Priorytet przydaje się wtedy, kiedy posiadasz kilka serwerów poczty w swojej domenie. Służy on do ustalenia porządku; do którego serwera poczta ma trafić w pierwszej kolejności. Mniejszy priorytet zapewnia pierwszeństwo.

Pozostałe wpisy dotyczą takich standardowych usług jak www czy ftp. Umieszczanie ich w pliku strefy nie jest obowiązkowe. Jednak domenę rejestruje się zazwyczaj na potrzeby www, ftp czy poczty, dlatego zostały one wymienione w przykładzie.

ftp             IN      CNAME   www

Powyżej umieszczono przykład rekordu typu IN CNAME, tworzy on dodatkową subdomenę dla hosta przypisanego już do innej nazwy. Specjaliści radzą by tego rodzaju rekordy wskazywały wyłącznie na rekordy typu IN A.

Po zakończeniu konfiguracji musimy jeszcze uruchomić usługę.

# /etc/rc.d/init.d/named start

Przykładowa konfiguracja strefy typu secondary

Konfiguracja serwera secondary sprowadza się do dokonania poniższego wpisu w pliku /etc/named.conf.

zone "example.net" IN {
	type slave;
	file "S/example.net";
	masters { 123.45.67.8; };
};

Jak widać wpis wygląda podobnie jak w przypadku serwera primary. Opcja type tym razem ma wartość slave. Musimy też wskazać serwer primary. Robimy to używając opcji masters, której wartość zawiera adres serwera primary DNS.

Obsługa protokołu IPv6

Podobnie jak większość usług w dystrybucji BIND posiada wsparcie dla protokołu IPv6 (IPng). Oczywiście wcześniej komputer musi być podłączony do tej sieci. W tej części rozdziału zostanie omówiona konfiguracja dla stref IN A oraz strefy odwrotnej. Narzędziem wspomagającym konfigurację będzie ipv6calc znajdujący się 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. Każda z dotychczasowych stref stworzona do tej pory dla protokołu IPv4 może mieć swój odpowiednik w sieci IPv6. Możemy również stworzyć zupełnie nowe wpisy, które będą widoczne jedynie w tej sieci.

    moja		IN  AAAA	3ffe:1a:2b:3c::1

    Umieszczenie powyż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 zaczął obowiązywać należy zrestartować usługę.

  • IN PTR

    Konfigurację strefy odwrotnej zaczniemy od stworzenia odpowiedniego wpisu w pliku /etc/named.conf. Jak sama nazwa wskazuje będzie on przypominał lustrzane odbicie adresu w zwykłej postaci. Aby mieć pewność, że nasza strefa będzie poprawnie zapisana posłużymy się wspomnianym we wstępie narzędziem 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.

    Uzyskaliśmy w ten sposób informacje, że dla sieci o adresie 3ffe:1a:2b:3c::/64, strefa odwrotna posiada postać taką jak na powyższym listingu. Wystarczy teraz to zapisać 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 widać na pierwszy rzut oka, konfiguracja niczym się praktycznie nie różni od konfiguracji strefy dla IPv4. Jako nazwę strefy podaliśmy to co nam zwrócił ipv6calc. Przyjrzyjmy się teraz jak powinien wyglądać plik dla tej strefy wskazany dyrektywą 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 już wcześniej okres ważności rekordów. Jak widać na listingu wynosi on jeden dzień. Drugi z nich to de facto nazwa tej strefy. Sama opcja $ORIGIN to swojego rodzaju zmienna, której wartość jest podstawiana w miejsce @ oraz doklejana do tych nazw które nie posiadają na końcu specjalnego znaku kropki.

    @               IN      SOA ns1.example.net. root.example.net. (
    	        2004050600
                    3H
                    15M
    		1W
    		1D )

    Jak widać rekord IN SOA nie różni się niczym od tego dla domeny IPv4.

    @                               IN      NS      ns1.example.net.
    @                               IN      NS      ns2.example.net.

    Określamy które serwery przechowują naszą domenę odwrotną. Również tutaj wszystko wygląda identycznie jak dla protokołu IPv4. Możemy teraz przystąpić 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? Odpowiedź na to znajdziesz obliczając przy użyciu programu ipv6calc adres odwrotny dla 3ffe:1a:2b:3c::1. Robimy to w sposób identyczny do poprzedniego przykładu jego użycia. W wyniku obliczeń będzie on wyglądał 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 zauważyć, po ostatnim zerze w listingu nie postawiliśmy kropki, a więc zostanie doklejona po nim zawartość $ORIGIN.

    Narzędziem pomocnym w odpytywaniu serwerów DNS, jest program host. Można nim również odpytywać o nazwy skonfigurowane dla protokołu IPv6. Jak by wyglądało zapytanie o nazwę 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łącznik -n oznacza, że będziemy odpytywali strefę odwrotną, natomiast -i, że jest to adres typu int. Domyślnie host szuka nazw typu arpa.

Rejestracja

Zanim zarejestrujemy domenę musimy mieć skonfigurowany podstawowy i zapasowy serwer nazw. Mamy możliwość zarejestrowania własnej domeny, bądź skorzystać z usług darmowego oddelegowania nam subdomeny zarejestrowanej już domeny. Ceny rejestracji domen spadły w ostatnich latach tak bardzo, że używanie "obcej" domeny stało się mało profesjonalne i warto zarejestrować własną.

Jeżeli nie posiadasz serwera secondary, możesz poszukać firmy lub organizacji, która za darmo utrzymuje zapasowe DNS-y. Możemy też umówić się z administratorem innej firmy na wzajemne prowadzenie serwerów secondary.

Diagnostyka

Jeśli chcemy przetestować poprawność składni pliku strefy, powinniśmy skorzystać z narzędzia named-checkzone. Program sprawdzi poprawność pliku strefy i poda w której linii wystąpił błąd np.:

# /usr/sbin/named-checkzone example.net /var/lib/named/M/example.net

Named™ generuje logi typu daemon, domyślnie syslogd umieszcza takie wpisy w pliku /var/log/daemon. Jeśli jednak nastąpił problem z uruchomieniem demona, uniemożliwiający mu pisanie do logów, to możemy sprawdzić co się dzieje uruchamiając go bez przejścia w tło i z wypisaniem komunikatów na standardowe wyjście:

/usr/sbin/named -g -t /var/lib/named

Aby ostatecznie sprawdzić poprawność konfiguracji możemy odpytać nasz serwer za pomocą protokołu DNS. Użyjemy do tego programu host™ z pakietu bind-utils np.:

# /usr/sbin/host -t mx example.net

Zakończenie

Uwaga! Named™ nie powinien być resolwerem nazw dla maszyny na której pracuje, powinien nim być inny serwer DNS aby nie powstawały zapętlenia zapytań. Wyjątek stanowią usługi pracujące w osobnych środowiskach chroot/vserver. Więcej o konfiguracji resolwera nazw znajdziemy w „Podstawowa konfiguracja sieci”.

CRON - Cykliczne wykonywanie zadań

CRON™ jest ważnym demonem systemowym, którego zadaniem jest uruchamianie programów cyklicznie lub o określonej porze. Omówiona zostanie instalacja vixie-cron™, który oprócz standardowych usług posiada dodatkowe opcje konfiguracyjne i zwiększone bezpieczeństwo

Instalacja

Program instalujemy za pomocą poldka:

# poldek -i vixie-cron

Po zainstalowaniu program jest praktycznie gotowy do użycia. Można więc od razu uruchomić demona korzystając z polecenia:

# /etc/rc.d/init.d/crond start

Od tej pory demon może działać nieprzerwane - nie wymaga restartów po rekonfiguracji.

Budowa tabel

W cronie istnieje podział na zadania systemowe i zadania użytkowników. Pierwszych zwykle używa się do prac administracyjnych, z drugich korzystają użytkownicy wedle własnych potrzeb (o ile mają do tego prawo). Główna konfiguracja demona (systemowa) umieszczona jest w pliku /etc/cron.d/crontab, konfiguracje lokalne użytkowników przechowywane są w plikach /var/spool/cron/{$login}. O ile /etc/cron.d/crontab może być swobodnie modyfikowany za pomocą edytora tekstu, o tyle użytkownicy powinni używać w tym celu odpowiedniego narzędzia (opisanego w dalszej części).

Pliki konfiguracji crona nazywane są tabelami, zarówno główny plik konfiguracji jak i konfiguracje użytkowników mają bardzo podobną budowę. Są to pliki tekstowe o ściśle ustalonej składni, w których jeden wiersz odpowiada jednemu zadaniu. Wiersz tabeli systemowej ma następującą składnię:

{$data-czas} {$użytkownik} {$zadanie}

Nieco prostszą budowę mają tabele użytkowników:

{$data-czas} {$zadanie}

Pierwsze pole określa jak często wykonywane jest zadanie, pole {$użytkownik} występuje jedynie w konfiguracji globalnej (w /etc/cron.d/crontab) i wskazuje z jakimi prawami uruchamiane ma być zadanie. Trzecie pole to operacja która ma być wykonywana. W tabelach użytkowników nie podaje się nazwy użytkownika, gdyż polecenia tam zawarte są automatycznie wykonywane z prawami ich właś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 użytkownika:

30 * * * *    backup.sh

W tabelach oprócz zadań możemy definiować zmienne środowiskowe np.:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=jakis_user
NICE=15

Pierwsza zmienna wskazuje powłokę (zamiast domyślnej /bin/sh), która ma być używana do wywoływania zadań, druga to ścieżka do plików wykonywalnych. Trzecie pole to konto użytkownika do którego będą wysyłane powiadomienia pocztą elektroniczną lub pełny adres e-mail, ostatnia zmienna to priorytet wykonywanych zadań (liczba nice).

Format daty i czasu

Sekcja {$użytkownik} i {$zadanie} nie wymagają komentarza więc opisane zostanie jedynie pole {$data-czas}. Pole to składa się z pięciu kolumn:

  • 1-sza kolumna (zakres 0-59) oznacza minuty.

  • 2-ga kolumna (zakres 0-23) oznacza godzinę.

  • 3-cia kolumna (zakres 0-31) oznacza dzień miesiąca.

  • 4-ta kolumna (zakres 0-12) oznacza miesiąc. (0 i 1 to styczeń)

  • 5-ta kolumna (zakres 0-7) oznacza dzień tygodnia (0 i 7 to niedziela)

  • 6-ta kolumna określa komendę jaka powinna zostać wykonana dla danego wiersza.

Gwiazdka "*" oznacza cały zakres z możliwego przedziału. Same zakresy w pierwszych pięciu kolumnach mogą być reprezentowane w różny sposób. Więcej szczegółów na ten temat dowiemy się wywołując polecenie man 5 crontab

Program vixie-cron™ posiada także mało udokumentowany format wykonywania poleceń

Nazwa          Działanie
------         -------
@reboot        Uruchom jeden raz przy starcie systemu
@yearly        Uruchom jeden raz w roku, "0 0 1 1 *"
@annually      To samo co @yearly
@monthly       Uruchom jeden raz w miesiącu, "0 0 1 * *"
@weekly        Uruchom jeden raz w tygodniu, "0 0 * * 0"
@daily         Uruchom jeden raz dziennie, "0 0 * * *"
@midnight      To samo co @daily
@hourly        Uruchom raz na godzinę, "0 * * * *"

Przykład:

@reboot        /usr/bin/rdate -s ntp.task.gda.pl

Tabele systemowe

Główną konfigurację systemu tworzymy za pomocą naszego ulubionego edytora tekstu, poprzez modyfikację pliku /etc/cron.d/crontab. Jego zawartość będzie podobna do poniżej przedstawionego przykładu:

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=admin@foobar.foo
NICE=15

# run-parts
01 * * * *       root  /bin/run-parts /etc/cron.hourly
02 1 * * *       root  /bin/run-parts /etc/cron.daily
02 2 * * 0       root  /bin/run-parts /etc/cron.weekly
02 3 1 * *       root  /bin/run-parts /etc/cron.monthly
0-59/10 * * * *  root  /bin/run-parts /etc/cron.10min		
15 18 * * 1-5    root  /bin/run-parts /etc/cron.gielda

Poniżej napisu # run-parts umieszczone są konfiguracje zadań, pierwsze cztery linijki stanowią domyślną konfigurację demona. Program run-parts służy do uruchamiania o jednej porze wszystkich programów we wskazanym katalogu. Dzięki takim opcjom możemy dodawać programy lub skrypty do odpowiednich katalogów bez konieczności pisania regułek cron-a. Poniżej umieszczono opisy powyższych przykładów:

Wykonanie poleceń zawartych w pliku (plikach) katalogu /etc/cron.hourly codziennie, co godzinę - zaczynając od pełnej pierwszej minuty (np. 02:01, 03:01 itd.):

01 * * * *      /bin/run-parts /etc/cron.hourly

Wykonanie poleceń zawartch w pliku (plikach) katalogu /etc/cron.daily raz dzienie (o godz. 01:02):

02 1 * * *      /bin/run-parts /etc/cron.daily

Wykonanie poleceń 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 poleceń zawartych w pliku (plikach) katalogu /etc/cron.monthly raz na miesiąc (w pierwszy dzień miesiąca o godz. 03:02):

02 3 1 * *      /bin/run-parts /etc/cron.monthly

Wykonanie poleceń zawartych w pliku (plikach) katalogu /etc/cron.gielda raz dziennie w dni robocze (od poniedziałku do piątku o godz. 18:15):

15 18 * * 1-5   /bin/run-parts /etc/cron.gielda

Wykonanie poleceń zawartych w pliku (plikach) katalogu /etc/cron.10min co 10 minut (każdego dnia, zaczynając od pełnej godziny - czyli np. 01:00, 01:10, 01:20 itd.):

0-59/10 * * * * /bin/run-parts /etc/cron.10min

Tabele użytkowników

Domyślnie użytkownicy nie mogą tworzyć własnych zadań cron-a, aby im na to zezwolić każdy nich musi zostać dopisany do pliku /etc/cron/cron.allow.

Użytkownicy powinni używać narzędzia crontab, program ten pozwala na bardzo łatwe zarządzanie tabelą użytkownika. Przyjmuje parametry określające rodzaj działania, które ma być wykonane na tabeli. Polecenie crontab -l wyświetla listę zdefiniowanych zadań, wywołanie crontab -e otworzy plik konfiguracji do edycji, zaś crontab -r usunie całą zawartość konfiguracji użytkownika.

Wybranie opcji edycji tabeli spowoduje otworzenie edytora tekstu określonego zmienną środowiskową EDITOR, po skończonej edycji plik zostanie automatycznie poddany kontroli poprawności i zapisany jako /var/spool/cron/{$login}. Najczęściej popełniane błędy przez użytkowników to zły format daty/czasu lub brak znaku nowej linii po ostatnim wierszu.

Root ma dodatkowo do dyspozycji możliwość zarządzania zadaniami dowolnego użytkownika, w tym celu stosuje się opcję -u z podaną nazwą użytkownika.

Komunikaty cron-a

Cron rejestruje wszystkie swoje prace do pliku /var/log/cron za pośrednictwem demona syslogd™, dodatkowo można wskazać adres e-mail, na który mają docierać informacje o wystąpieniu błędów w wykonywaniu zadań. Jeśli nie zdefiniuje zmiennej MAILTO w tabeli to poczta zostanie wysłana na lokalne konto właściciela tej tabeli. Poczta elektroniczna jest jedyną formą informowania zwykłych użytkowników o ewentualnych błędach zadań, gdyż nie mają oni dostępu do logów.

Wysyłanie poczty elektronicznej zarówno do użytkowników lokalnych jak i zewnętrznych będzie wymagało instalacji lokalnego serwera poczty MTA. Może to być niemal dowolny demon pocztowy, np.: Exim (opis w „Exim - Transport poczty elektronicznej (MTA)”) lub Postfix (opis w „Postfix - Transport poczty elektronicznej (MTA)”).

Aby łatwiej było analizować problemy, do wiadomości wysyłanej przez demon, dodawane są nagłówki X-Cron-Env, zawierające dane środowiska np.:

X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin>
X-Cron-Env: <MAILTO=root>
X-Cron-Env: <NICE=15>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>

CUPS - Popularny system druku dla Uniksa

Wstęp

CUPS™ jest nowoczesnym i uniwersalnym systemem druku dla systemów uniksowych. Może być stosowany zarówno do drukowania lokalnego jak i do drukowania w sieci - obsługuje domyślnie protokół IPP. Po poprawnym skonfigurowaniu urządzenia będziemy mogli drukować z niemal każdego programu, CUPS akceptuje wywołania poleceń drukowania w stylu klasycznego systemu LPD.

System CUPS może być zarówno serwerem jak i klientem, o tym jaką funkcję będzie pełnić zainstalowane "urządzenie" decyduje wybór specjalnego sterownika interfejsu: backendu(poza IPP) i konfiguracji.

Instalacja

Podstawowa część CUPS:

$ poldek -i cups cups-clients

Następnie instalujemy jeden lub więcej kontrolerów interfejsów drukarki (protokół IPP nie wymaga backendu):

  • cups-backend-parallel - port równoległy (parallel port)

  • cups-backend-serial - 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ługujących PostScriptu konieczne będą dodatkowe pakiety:

$ poldek -i cups-filter-pstoraster ghostscript-esp

Do zdalnej administracji (za pomocą HTTPS), konieczny będzie program openssl:

$ poldek -i openssl-tools

Czas uruchomić demona:

$ /etc/rc.d/init.d/cups start

Zarządzanie drukarkami

Operacje takie jak dodawanie, czy konfigurowanie drukarek mogą być dokonywane na kilka sposobów:

  • HTTP

    Popularnym sposobem jest konfiguracja przy pomocy przeglądarki internetowej, CUPS posiada wbudowany niewielki serwer WWW, z którym łączymy się dowolną przeglądarką na adres serwera i port 631 np.:

    $ lynx localhost:631

    Z poziomu tej strony mamy dostęp do wielu opcji administracyjnych: konfiguracji drukarek, zarządzania klasami, zadaniami druku i innymi. Ten sposób zarządzania systemem CUPS w niniejszej publikacji jest traktowany jako domyślny.

  • lpadmin

    lpadmin jest programem administracyjnym dostarczanym z CUPS-em, obsługiwany jest całkowicie z linii wiersza poleceń. Jest to narzędzie zaawansowane, przez co stosunkowo trudne w obsłudze, jego dokładny opis zawarto w dokumentacji.

  • Inne

    Dla CUPS powstały wygodne programy zarządzające przeznaczone działające w środowiskach GNOME i KDE. Szczególnie pozytywnie przedstawia się system-config-printer™ - wygodna aplikacja, której układ opcji przypomina konfigurację przez WWW.

Dodanie drukarki

W tym rozdziale przedstawiono ogólny opis instalacji urządzenia, szczegółowe informacje umieszczono w rozdziałach: Szczegóły dodawania drukarki lokalnej i Szczegóły dodawania drukarki zdalnej.

Możemy użyć programu system-config-printer™ lub narzędzia dostępnego przez stronę WWW:

$ lynx localhost:631

następnie przechodzimy do opcji Managle Printers -> Add Printer.

Określamy nazwę drukarki oraz opcjonalnie komentarz i lokalizację, następnie wybieramy jeden z dostępnych na liście kontrolerów interfejsów drukarki (backend). Na koniec wybieramy producenta i model drukarki.

System CUPS jest dostarczany z niewielką ilością sterowników drukarek, jednak nie należy się jednak martwić jeśli na liście nie odnajdziemy szukanego urządzenia. Coraz więcej producentów dostarcza ze sprzętem pliki PPD (w CUPS są używane również dla drukarek niepostcriptowych), możemy także skorzystać z bazy Foomatic™ zawierającej ogromną liczbę sterowników.

Sterowniki Foomatic możemy zainstalować w postaci zbiorczego pakietu sterowników danego producenta. Przykładowo jeśli chcemy zainstalować sterowniki drukarek firmy Samsung to instalujemy pakiet cups-foomatic-db-Samsung. Możemy również pobrać pojedyncze pliki PPD z z witryny http://www.linuxprinting.org, po wyszukaniu modelu drukarki (Driver Listings) należy kliknąć 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 normalną instalację drukarki. Możemy ich wiele zainstalować, to do której będą trafiać dokumenty zależy od tego, którą z nich ustawimy jako domyślną.

Szczegóły dodawania drukarki lokalnej

Dodanie drukarki lokalnej dotyczy drukarek podłączonych bezpośrednio podłączonych do komputera, na którym zainstalowany jest CUPS, w tym wypadku interesują nas interfejsy: Parallel, Serial i USB. Zanim zaczniemy proces konfiguracji, musimy sie upewnić, że są załadowane odpowiednie moduły jądra (w przeciwnym wypadku dany backend może być nieaktywny).

Drukarka podłączona do portu równoległego będzie wymagała modułów lp, parport i parport_pc. Moduł lp dopisujemy do pliku /etc/modules, jeśli nie używamy udeva to pozostałe moduły także. Drukarki podłączane pod port LPT są dostępne za pomocą urządzeń /dev/lp*. W przypadku drukarek USB konieczny będzie moduł usblp oraz rzecz jasna moduł kontrolera USB, urządzenia te będą dostępne za pomocą /dev/usb/lp*. Więcej o modułach jądra i ich zarządzaniu odnajdziemy w „Moduły jądra”.

CUPS od wersji 1.3 wymaga zdefiniowania opcji Group w pliku /etc/cups/cupsd.conf, która wskazuje jaki użytkownik ma być używany dla uruchamiania zewnętrznych programów - w tym backendów. Jako że urządzenia w katalogu /dev mają grupę ustawioną na lp, taką też podamy jako wartość parametru:

Group lp

Dalszą instalację przeprowadzamy zgodnie z zaprezentowanym wcześniej opisem Dodanie drukarki.

Szczegóły dodawania drukarki zdalnej

  • IPP

    Aby CUPS było klientem IPP musimy dodać drukarkę z backendem IPP oraz podać prawidłowy URI zasobu, jako producenta wybieramy Raw, zaś jako model Raw Queue. URI powinno mieć następującą postać:

    ipp://{$serwer}/printers/{$drukarka}

    ($serwer to nazwa lub IP serwera druku, zaś $drukarka to nazwa drukarki). Adres taki może wyglądać następująco:

    ipp://10.0.0.3/printers/laserowa
  • SMB

    Jedyne co musimy zrobić to dodać drukarkę z użyciem odpowiedniego backendu - Windows Printer via SAMBA i podać prawidłowy URI, na koniec musimy wskazać sterownik danej drukarki. W przypadku systemów MS z serii 95/98/Me URI powinno mieć następującą postać:

    smb://{$serwer}/{$drukarka}

    ($serwer to nazwa lub IP serwera druku, zaś $drukarka to nazwa drukarki). Adres taki może wyglądać następująco:

    smb://wodzu/laserowa

    W przypadku systemów z serii NT (NT4, 2000, XP Professional) może być konieczne podanie konta użytkownika i hasła:

    smb://{$użytkownik}:{$hasło}@{$serwer}/{$drukarka}

    np.:

    smb://jasio:mojehasło@wodzu/laserowa

Konfiguracja serwera

Aby udostępnić w sieci zainstalowaną drukarkę, musimy odpowiednio skonfigurować demona cupsd, jego konfiguracja jest przechowywana w pliku /etc/cups/cupsd.conf.

Domyślnie CUPS pozwala jedynie na drukowanie lokalne, aby uzyskać dostęp z sieci musimy dokonać zmian w pliku konfiguracji. Należy odszukać sekcję oznaczoną znacznikami <Location /></Location>. Dostęp z innych maszyn konfigurujemy za pomocą opcji Allow From {$klient} ($klient to nazwa lub adres IP lub klasa adresów, którym udostępniamy drukarkę). Poniższy przykład przedstawia udostępnienie 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>

Jeśli chcemy mieć możliwość zdalnej administracji za pośrednictwem HTTP/HTTPS powinniśmy dodatkowo ustawić dostęp (zgodnie z powyższymi wskazówkami) dla sekcji: /admin, /admin/conf.

  • IPP

    Protokół IPP jest używany domyślnie przez CUPS i nie wymaga żadnych dodatkowych przygotowań.

  • SMB

    W systemie musi być zainstalowany i działający pakiet Samba™. Aby systemy Microsoftu mogły "widzieć" drukarki CUPS należy dokonać modyfikacji w głównym pliku konfiguracji Samby - /etc/samba/smb.conf. Należy usunąć z niego wszystkie opcje dotyczące druku z sekcji [global], zaś w ich miejsce wstawić poniższe linijki:

    printing = cups
    printcap name = cups

    Na koniec należy przygotować sekcję drukarek. Prosty przykład pliku konfiguracji pakietu Samba może wyglądać następująco:

    [global]
       netbios name = shilka
       workgroup = pod_cisami
       security = share
    
       printing = cups
       printcap name = cups
    
    [printers]
       comment = Drukarki
       printable = yes
       path = /var/spool/samba

    Jako, że Windows pre-formatuje dokumenty zanim wyśle je przez sieć do drukarki, musimy nauczyć CUPS'a odpowiednio takie pre-formatowane dokumenty obsługiwać. W tym celu musimy wyedytować plik /etc/cups/mime.convs i odkomentować w nim linijkę

    application/octet-stream        application/vnd.cups-raw        0       -
    

    w pliku /etc/cups/mime.types zaś, należy odkomentować linijkę

    application/octet-stream
    

    Po tych operacjach wymagany jest oczywiście restart usługi CUPS.

    # /etc/rc.d/init.d/cups restart

Przy tak skonfigurowanym serwerze drukarkę w MS Windows dodajemy standardowo, musimy jedynie samemu dostarczyć odpowiedni sterownik. Istnieje możliwość umieszczenia takiego sterownika na serwerze Samba™, wymaga to jednak dodatkowych operacji konfiguracyjnych. Więcej na ten temat odnajdziemy w dokumentacji Samby.

Zarządzanie kolejką druku

Zarządzanie wydrukami jest możliwe z poziomu przeglądarki internetowej, programów dla X-Window oraz z poziomu linii wiersza poleceń. Z pośród tych ostatnich mamy do dyspozycji: lpstat, lpmove, cancel, lpq oraz lprm. Programy te znajdują się w pakiecie cups-clients.

Test drukarki i rozwiązywanie problemów

Drukarka powinna działać od razu po zainstalowaniu, można to przetestować z poziomu panelu konfiguracji drukarki drukując stronę testową. W razie problemów pierwszą rzeczą jaką należy zrobić to przejrzeć plik rejestrowania błędów (log): /var/log/cups/error_log. Jeśli ciągle nie możemy odnaleźć źródła problemu możemy spróbować włączyć wysoki poziom raportowania błędów. Dokonujemy to przez edycję w pliku /etc/cups/cupsd.conf i przestawienie ustawienia opcji "LogLevel" z "info " na "debug" lub " debug2" np.:

LogLevel debug2

Kiedy rozwiążemy problem należy przywrócić poprzedni poziom raportowania ze względu na szybki przyrost objętości logów. Po każdej modyfikacji pliku konfiguracji należy przeładować demona:

# /etc/rc.d/init.d/cups restart

DHCPD - Dynamic Host Configuration Protocol Daemon

DHCP™ to protokół pozwalający urządzeniom pracującym w sieci LAN na pobieranie ich konfiguracji IP (adresu, maski podsieci, adresu rozgłoszeniowego itp.) z serwera. Ułatwia on administrację dużych i średnich sieci.

Instalacja

Aby uruchomić serwer DHCP musimy oczywiście zainstalować go. Instalacja w PLD jest prosta:

# poldek -i dhcp

Podstawowa konfiguracja

Konfiguracja usługi przechowywana jest w pliku /etc/dhcpd.conf , z pakietem dostarczona jest przykładowa konfiguracja, pozwalająca uruchomić usługę po zmianie zaledwie kilku wartości. Przedstawiona poniżej sekcja zawiera parametry dla określonej podsieci. Dla większej jasności w poniższym przykładzie użyto skróconej wersji konfiguracji.

ddns-update-style               ad-hoc;
# Sekcja konfiguracji hostów z podsieci o podanym adresie i masce
subnet 192.168.0.0 netmask 255.255.255.0 {
 
        # domyś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 dzierżawionych adresów IP (z włączoną obsługą protokołu BOOTP)
        range dynamic-bootp 192.168.0.128 192.168.0.255;
        
        # domyślny czas dzierżawy (w sekundach)
        default-lease-time 21600;
        
        # maksymalny czas dzierżawy (w sekundach)
        max-lease-time 43200;
}

Wewnątrz przedstawionej sekcji (ograniczonej nawiasami klamrowymi) umieszczane są opcje jakie zwykle podajemy przy statycznej konfiguracji interfejsu sieci. Powyższa konfiguracja będzie przydzielać komputerom dynamiczne adresy IP z zakresu 192.168.0.128 - 192.168.0.255 na okres 21600 sekund, jednak nie większy niż 43200 sekund.

I to już 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ędzie nasłuchiwał dhcpd (np. eth1). Po tej operacji wystarczy uruchomić lub zrestartować usługę.

Statyczne przypisanie konfiguracji

Aby komputery mogły za każdym razem uzyskać taką samą konfigurację, musimy dla każdego z nich dodać odpowiednie wpisy w pliku konfiguracji. Konfiguracje hostów umieszczamy wewnątrz przedstawionej powyż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 pomocą adresów sprzętowych kart sieciowych (MAC). Powyż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 pomocą programu ip, lub iconfig, szczegóły na ten temat odnajdziemy w „Narzędzia sieciowe”.

Inne opcje

Poniżej zamieszczono przykłady innych nieco rzadziej uż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ęzła NetBIOS
option netbios-node-type 2;

Adres serwera czasu NTP:

option ntp-servers              192.168.1.1;

Uruchomienie

Serwer uruchamiamy następująco:

# /etc/rc.d/init.d/dhcpd start

Konfiguracja klienta

Szczegółowy opis konfiguracji klienta DHCP umieszczono w „Ethernet”. Jeśli zechcemy sprawdzić poprawność konfiguracji przydzielonej hostowi to wystarczy użyć programu ip, lub iconfig, szczegóły odnajdziemy w „Narzędzia sieciowe”.

Uwagi

W większości wypadków najlepszym wyborem będzie przypisywanie niezmiennych adresów IP dla każdej z maszyn, pozwoli to zachować porządek i lepszą kontrolę nad siecią. Jest to absolutnie konieczne w wypadku serwerów oraz routerów, jednak przy tego typu maszynach zaleca się zrezygnowanie z DHCP na korzyść statycznej konfiguracji.

Domyślnie logi demona są rejestrowane przez syslog-a z ustawionym źródłem (facility) na "daemon". Tego rodzaju komunikaty zwykle są zapisywane do pliku /var/log/daemon , dlatego tam właśnie powinniśmy szukać informacji jeśli wystąpią jakieś problemy.

Exim - Transport poczty elektronicznej (MTA)

Usługa MTA (ang. message transfer agent) jest odpowiedzialna za przesył m.in. e-mail między serwerami. Najpopularniejszymi przedstawicielami tego typu usług są: Sendmail™, Postfix™ czy opisany przez nas Exim™. Oto zalety jakie przemawiają za wybraniem Exim™-a jako naszego MTA:

  • Ponieważ Sendmail™ nie posiada nawet połowy jego funkcji

  • Autoryzacja w Exim™-ie zaimplementowana jest domyślnie

  • Współpracuje z bazami MySQL™ i z Postgres™-em, a także ze zwykłymi plikami tekstowymi

  • Tom Kistner napisał do Exim™ użyteczna łatkę, rozbudowywującą Exim™ o obsługę programów antywirusowych, demona SpamAssasin™ (skanera antyspamowego) oraz wykrywania błędów MIME - dzięki temu nie potrzebujemy wielkich i zasobożernych programów w perlu

  • Za to Tomasz Kojm napisał bardzo dobry program antywirusowy: Clam AntiVirus™ - darmowy, w dodatku rewelacyjnie współpracujący z Exiscanem

Podsumowując - Exim™ jest rewelacyjnym MTA. Jego możliwości konfiguracji pozwoliły mi na zbudowanie dosyć rozbudowanego serwera poczty obsługującego zarówno konta lokalne jak i konta zapisane w bazie danych MySQL™. Dodatkowe możliwoś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 są spamem czy nie już nawet nie wspomnę. W dodatku Exim™ jest całkiem bezpiecznym MTA (wersja 4.x wg. securityfocus jak narazie dorobiła się jednego błędu - w końcu jakaś cena musi być za te wodotryski). Zresztą konstrukcja omawianego MTA na początku doprowadzała mnie do szału, gdyż Exim™ nie może sobie poradzić 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

Oczywiście zanim wykonamy zalecenie startu demona powinniśmy dokonać konfiguracji, którą opisuje następny rozdział.

Budowa pliku konfiguracji

Wszelkich zmian w konfiguracji dokonujemy w pliku /etc/mail/exim.conf. Na początek wyjaśnimy jak zorganizowany jest plik konfiguracyjny, wygląda to mniej więcej tak:

# główna sekcja ...

opcje i dyrektywy sekcji głównej

begin sekcja1

opcje i dyrektywy sekcji1

begin sekcja3

...

Tak więc plik ten jest zbudowany z sekcji, które rozpoczynają się słowem begin nazwa, z wyjątkiem sekcji głównej, która jest na samym początku pliku i nie posiada swojego begina. Sekcje również nie mają żadnych słów kluczowych, które by je zamykały - po prostu początek begin nowej sekcji oznacza zakończenie poprzedniej. I tak, standardowo mamy następujące sekcje:

  • główna - odpowiedzialna za podstawowe ustawienia Exim

  • acl - listy kontroli dostępu, filtrowania, odrzucania i akceptowania poczty

  • routers - hm, najprościej jest to przetłumaczyć jako routery, czyli reguły kierowania wiadomości do odpowiednich transporterów

  • transports - tutaj tworzymy sposoby doręczenia poczty

  • retry - ustawienia ponowień

  • rewrite - reguły do przepisywania nagłówków

  • authenticators - reguły do autoryzacji

Co to są te całe 'transportery' i 'routery'? Właściwie to serce Exima. Jeżeli Exim dostaje jakiegoś maila to najpierw puszcza go przez routery, które można porównać do reguł ipchains/iptables - jeżeli mail załapie się na jakąś regułę (router) to jest przekazywany do transportu określonego przez ten router. Inaczej mówiąc router w Eximie kieruje maila do odpowiedniego transportera. Transporter natomiast robi już z mailem co należy - doręcza go lokalnie, albo przekierowywuje gdzieś indziej albo odsyła do innego serwera. Wiem, że w tym momencie może wydawać się to skomplikowane, ale nie przejmujcie się, to tylko wiedza teoretyczna która na początku nie będzie wam potrzebna. Musiałem natomiast wam wytłumaczyć, że są sekcje i że musicie nauczyć się tego, iż jak napiszę 'dopisać w sekcji głównej' to należy coś dopisać na początku pliku.

Podstawowa konfiguracja

Zanim zaczniemy konfigurację demona SMTP, musimy koniecznie dodać rekord MX do każdej strefy DNS obsługiwanej przez nasz serwer. Informacje na ten temat zawarto w „BIND - Serwer Nazw”.

Domeny lokalne to takie, które Exim™ ma traktować 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łaśnie 'moja nazwa'. Aby dopisać kolejne domeny wystarczy dodać je do tej listy rozdzielając je dwukropkami:

domainlist local_domains = @ : domena.pl : baseciq.org : \
    /etc/mail/local_domains

Poza domena.pl, baseciq.org, Exim będzie teraz także akceptował domeny wypisane w pliku /etc/mail/local_domains. Domeny tam należy wpisywać w oddzielnych linijkach. Exim™ o tyle fajnie działa, że po dopisaniu ścieżki do pliku, wystarczy go raz zrestartować. Jakiekolwiek kombinacje w /etc/mail/local_domains nie będą wymagały restartu. Tak więc najwygodniej będzie dopisać do pliku konfiguracyjnego:

domainlist local_domains = @ : /etc/mail/local_domains

I po prostu powpisywać wszystkie domeny do /etc/mail/local_domains.

Domeny dla których mamy być zapasowym MX'em tworzy się bardzo łatwo. Linijkę 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ędzie akceptował każdą pocztę zaadresowaną do domen zawartych w pliku /etc/mail/relay_to_domains. A co z nią zrobi? Jak wiadomo, jeżeli domena ma kilka MX'ów, to Exim™ będzie starał się ją dostarczyć do serwera o najniższym priorytecie MX. Chyba że on ma najniższy, to wygeneruje błąd.

Relaying, czyli określenie kto może przez nasz serwer wysyłać pocztę. I tutaj, listę adresów i hostów buduje się w podobny sposób do local_domains i relay_to_domains. Wystarczy stworzyć listę o nazwie relay_from_hosts:

hostlist   relay_from_hosts = 127.0.0.1 : 192.168.0.0/16

Uwaga! Już w tym momencie możemy sprawdzić działania serwera. Wystarczy że przeładujemy demona i wyślemy e-mail do istniejącego konta użytkownika. Przy takiej konfiguracji poczta będzie docierała do skrzynek typu mbox.

Skrzynki pocztowe

Exim potrafi umieszczać pocztę 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 użytkownika). Ze względu na wsteczną zgodność Exim domyślnie używa tych pierwszych, aby używać Maildir-a wykonujemy następujące czynności:

W sekcji konfiguracji transporterów odszukujemy opcję "local_delivery", tam wstawiamy znak komentarza przed opcją "file =" i dodajemy linijki:

  maildir_format = true
  directory=${home}/Mail/Maildir

Jak się łatwo domyślić druga z opcji wskazuje miejsce przechowywanie skrzynek. Po modyfikacji omawiana sekcja może wyglądać następująco:

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łać e-mail na konto użytkownika.

Możemy przekazać dostarczanie poczty do skrzynek programowi Procmail™. Wystarczy, że w sekcji routerów usuniemy znaki komentarza z kolejnych wierszy zaczynających się od "procmail:", podobnie postępujemy w sekcji transporterów w miejscu zaczynającym się od wiersza "procmail_pipe:". Na koniec musimy jeszcze tylko umieścić plik konfiguracji Procmaila: .procmailrc w katalogu domowym użytkownika.

Różne opcje

Czasami (czytaj: gdy mamy sieczkę w /etc/hosts) Exim™ zgłasza się nie jako serwer.domena.pl a jako sam 'serwer'. Jeżeli zmiana wpisów w /etc/hosts nie pomaga, albo gdy chcemy aby nasze MTA przedstawiało się inaczej niż hostname maszyny na którym stoi wystarczy ustawić (bądź dodać gdy jej nie ma) opcję primary_hostname w głównej sekcji:

primary_hostname = serwer.domena.pl

W czasach zabawy z Sendmail™-em podawałem także sposób na ograniczenie bannera, który się pojawiał po telnecie na port 25. W Exim™-ie nie jest to skomplikowane i służy do tego opcja smtp_banner w sekcji głównej:

smtp_banner = $primary_hostname ESMTP $tod_full

Spowoduje to wyświetlanie następującego tekstu jako bannera:

220 serwer.domena.pl ESMTP Wed, 23 Jul 2003 15:18:04
			+0200

Chyba nie muszę tłumaczyć, że aby usunąć datę należy wywalić $tod_full?

Teraz zajmiemy się aliasami. Plik z aliasami powinien znajdować się w /etc/mail/aliases. Jest to czysty plik tekstowy, wprowadzone w nim zmiany wymagają wydania polecenia newaliases. Restart demona nie jest konieczny. Jeżeli jednak nie macie pewności czy tam powinien być plik z aliasami, w sekcji routers odszukajcie ciąg system_aliases: - jest to definicja routera odpowiedzialnego za rozwiązywanie aliasów. Tam też, w linijce data widać ścieżkę 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

Jeżeli z naszego SMTP korzystają użytkownicy spoza sieci lokalnej przyda nam się autoryzacja. Sprawa w Exim™-ie jest dosyć zawiła. Otóż Exim™ zbyt wcześnie zrzuca uprawnienia root, tak że opisywany na wielu stronach opis zrobienia autoryzacji via PAM najczęściej nie działa. Z pomocą przyjdzie nam pakiet cyrus-sasl™, a dokładniej pwcheck daemon™ (w PLD cyrus-sasl-saslauthd™). W sekcji AUTHENTICATORS wpisujemy następujące linijki (lub kasujemy komentarze #)

plain:
  driver = plaintext
  public_name = PLAIN
  server_prompts = :
  server_condition = ${if saslauthd{{$1}{$3}}{1}{0}}
  # powyższy wpis zadziała przy saslauthd -a shadow, jeż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}}
  # powyższy wpis zadziała przy saslauthd -a shadow, jeżeli
  # uruchomicie saslauthd -a pam (np. PLD) wpiszcie wtedy:
  # server_condition = ${if saslauthd{{$1}{$2}{smtp}}{1}{0}}
  server_set_id = $1

Ostatnią rzeczą przy saslauthd™ (uruchomionym z opcją -a pam) jaką trzeba stworzyć (lub sprawdzić 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
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 przypomnieć, że przed sprawdzaniem autoryzacji należy także uruchomić pwcheck saslauthd

# echo 'pwcheck_method:saslauthd' > /etc/sasl/smtpd.conf

Syfrowanie SSL

Exim™ sobie bardzo dobrze radzi z połączeniami szyfrowanymi przy użyciu protokołu SSL (wspiera metodę STARTTLS). Wystarczy wygenerować 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 []:baseciq@baseciq.org

Oczywiście na pytania odpowiadajcie podając swoje dane... Po takim zabiegu do sekcji głównej Exim™ należy dopisać:

tls_certificate = /etc/mail/exim.crt
tls_privatekey = /etc/mail/exim.key
tls_advertise_hosts = *

Po tym zabiegu i restarcie Exim™ powinien bez problemu komunikować się po SSL, co zresztą widać w logach:

2003-09-07 01:48:36 19vmnC-0006EG-27 <=	bensonzow@beer.com 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łuchiwać porcie 465 jedynie przy użyciu inetd, w nowszych wersjach wystraczy że ustawimy odpowiednie opcje:

daemon_smtp_ports = 25 : 465
tls_on_connect_ports = 465

Warto by było, żeby także pop3d™ obsługiwał SSL natywnie ssl (bez jakichś stunneli i innych wynalazków). Ja osobiście polecam demonik tpop3d™, którego konfiguracja jest bardzo prosta. Instalujemy tpop3d:

# poldek -i tpop3d

a następnie wystarczy ż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ędzie obsługiwał SSL po wykonaniu komendy STLS (np. TheBat™ potrafi tak zacząć sesję SSL) a na porcie 995 będzie od razu używał SSL (TheBat™, Outlook Express™).

Quota

Generalnie nie ma sensu męczyć kernela i filesystemu żeby pilnował quoty na pocztę. Szczególnie gdy MTA samo sobie może z tym poradzić. Służy do tego parametr quota w konfiguracji transportów. I tak, w najprostszy sposób można lokalną quotę per user ustawić 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ę w wysokości 20MB:
	quota = 20M

Proste, prawda? Tak naprawdę ma to zastosowanie w systemach poczty wirtualnej gdzie możemy w bazie danych przechowywać quotę użytkownika i można skonstruować zapytanie SQL do odpytania ile miejsca ma dany użytkownik. Ale jeżeli nie możecie sobie poradzić z quotą systemową, możecie zamiast quota = 20M dopisać coś takiego:

quota =	${lookup{$local_part}lsearch{/etc/mail/quota.conf}{$value}{0M}}

Od tego momentu w pliku /etc/mail/quota.conf możesz trzymać wielkości skrzynek dla poszczególnych użytkowników. Jeżeli ktoś nie zostanie tam wymieniony, to nie będzie miał żadnych limitów na swoją skrzynkę pocztową. Plik taki powinien wyglądać mniej więcej tak:

lukasz:	100M
kflis:	5M
ania:	20M

I tak oto ja mam 100mb na pocztę, kubuś tylko 5, a siostra 20 MB ;) Podobnym parametrem każdego transportera jest message_size_limit. Wystarczy wpisać:

message_size_limit = 10M

Podobnie jak powyżej, można zrobić to na bazie pliku - wystarczy zamiast /etc/mail/quota.conf użyć np. /etc/mail/size_limits.conf ;-) BTW. na końcu linijki z quotą, gdzie mamy '0M' możemy wstawić np. '20M'. Wtedy, osoby nie dopisane do /etc/mail/quota.conf będą miały 20MB limitu (limit domyślny).

Oczywiście jak na Exim™ przystało, od quoty jest więcej bajerków. Chyba najbardziej pożądanym będzie opcja quota_warn_message. Jest to nic innego jak mail ostrzegający usera o tym, że skrzynka jest zapchana po same brzegi. Zanim jednak polecisz to wdrażać, zainteresuj się jak to działa. Otóż po dostarczeniu każdego maila Exim™ będzie sprawdzał czy został przekroczony konkretny próg (podany w megabajtach lub w procentowo). Jeżeli tak, wygeneruje on odpowiednią wiadomość. I tak, dodajemy do molestowanego przez nas local_delivery następujące opcje:

quota_warn_message = "\
Content-Type: text/plain; charset=ISO-8859-2\n\
To: $local_part@$domain\n\
Reply-to: Administratorzy sieci <admins@twojadomena.pl>\n\
Subject: Informacja o Twoim koncie pocztowym\n\
\n\
*** Ta wiadomość została wygenerowana automatycznie ***\n\
\n\
Uprzejmie informujemy, iż skrzynka pocztowa została zapełniona w 90%\n\
swojej pojemności. W przypadku 100% nie będą dostarczane\n\
do Ciebie nowe wiadomości. Opróżnij skrzynkę pocztową ze starych\n\
wiadomości.\n"
	quota_warn_threshold = 90%

Dodanie skanerów antywirusowych

Aby Exim™ współpracował z jakimś antywirusem należy najpierw wybrać i zainstalować program antywirusowy. Doświadczenie uczy, że najlepszy jest program Clamav™.

Instalujemy więc Clamav

# poldek -i clamav clamav-database

Po zainstalowaniu Clamav™ musimy zmodyfikować plik konfiguracyjny /etc/mail/exim.conf w sekcji głównej ustawiamy typ antywirusa:

av_scanner = clamd:/var/lib/clamav/clamd.socket

Po dwukropku ustawiamy ścieżkę do socketu antywirusa (w przypadku clamav™ - zajrzyj do pliku /etc/clamav.conf). W miejscu gdzie wpisaliśmy clamd, możemy wpisać także i inny typ skanera. Niestety, żaden z innych obsługiwanych (sophie™, kavdaemon™, drweb™) skanerów nie jest darmowy. Jeżeli natomiast wolicie mks™, to możecie użyć 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 początku):

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 = *
	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 jeśli zostanie znaleziony wirus lub inna zawartość uznana za szkodliwą przez skaner antywirusowy to taki mail jest odrzucany oraz informacja o znalezionym wirusie zostaje wyświetlona z jednosekudnowym opóźnieniem. Te opóźnienie ma na celu unikniecia ewentualnego zapchania serwera poczty poprzez uciążliwego użytkownika co chwila próbujacego wysłać pocztę uznaną za szkodliwą. Kolejny warunek spowoduje iż maile z uszkodzonymi nagłówkami MIME zostaną odpowiednio oznaczone (czyli, także, duże maile podzielone na częś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 jakaś wiadomość, 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ł sprawdzać pocztę Exima musi zostać dodany do grupy exim. Dokonujemy tego poleceniem groupadd albo edytując po prostu plik /etc/group:

[...]
			
exim:x:79:clamav,mail

[...]

Kolejny feature jaki daje exiscan to odrzucanie plików z załącznikiem o określonym rozszerzeniu. W tym celu dopisujemy zaraz po exiscan: następujące 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.

Powyższa regółka ma na celu zablokowanie możliwości wysyłanie wiadomości, których załącznikami są pliki: *.exe, *.pif, *.bat, *.scr, *.lnk oraz *.vbs. Teraz, jeżeli nie chcemy aby skanowane były maile pochodzące od danych adresów ip dopisujemy (jeżeli chcemy aby Ci ludzie też nie mogli wysyłać plików *.com, to po poprzedniej regułce, jeżeli oni będą mogli, to przed):

accept	hosts = /etc/mail/dontscan

Teraz, w pliku /etc/mail/dontscan umieszczamy adresy IP bądź klasy adresowe z których poczta ma nie być skanowana.

Jeżeli natomiast chcecie, by poczta przeskanowana u was w przypadku gdy wróci w jakiś sposób z powrotem do naszego serwera (np. poprzez alias na innym serwerze) nie była ponownie skanowana, możecie zacząć oznaczać pocztę odpowiednimi znacznikami oraz przyjąć że poczta z tym znacznikiem nie była ponownie skanowana. Tak więc, przed końcowym accept dodajemy:

warn	message = X-Scan-Signature: ${hmac{md5}{atutajwpiszhaslo} \
		{$body_linecount}}

Exim™ spowoduje dodanie zaszyfrowanego ciągu znaków składającego się z hasła i wielkości maila. Dzięki temu ktoś kto nie pozna waszego hasła nie będzie mógł sfałszować informacji o tym że mail został już zeskanowany. Teraz, aby taka poczta przechodziła bez skanowania, na samym początku po exiscan: dopisujemy:

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 że gdy mail będzie przechodził przez kilka z nich, tylko jeden będzie musiał go przeskanować.

Walka ze spamem

Zjawisko spamu jest niezwykle uciążliwe. W niektórych Stanach w USA traktowane jest w kategoriach kryminalnych. Zapewne znasz jego definicję lub przynajmniej wiesz jak spam wygląda. W skrócie jest to wiadomość e-mail, której nie chciałeś otrzymać. Exim posiada wbudowaną obsługę filtra antyspamowego opartego na technice dnsbl, może wykorzystwać 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óźnianie procesu komunikacji pomiedzy klientem wysyłającym poczte a serwerem MTA. Nie tylko odcina to część robotów spamerskich ale także zmiejsza ryzyko przeciążenia serwera.

Przejdźmy do konfiguracji. Wszystkie te wpisy powinny znaleść się w sekcji ACL CONFIGURATION w obrębie 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. Jeśli nasz zestaw regół okazałby się zbyt restrycyjny możemy oznaczyć 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

HELO nie może być 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)?)$\N}{yes}{no}}
	delay = 5s
	log_message = Stupid localhost HELO.

HELO musi być nazwą domenową (hostname)

deny	message = HELO musi byc nazwa domenowa. \n\
	HELO must be hostname.
	hosts = !+relay_from_hosts
	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 być pełną nazwą domenową (Fully Qualifield Domain Name).

deny	message = HELO nie wyglada poprawnie. Zobacz RFC 821. \n\
	HELO must contain a Fully Qualifield Domain Name. See RFC821.
	hosts = !+relay_from_hosts
	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ę 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}}
	hosts = !+relay_from_hosts
	delay = 5s
	log_message = Fake HELO from host $sender_helo_name.

Kolejne dwa warunki są bardzo restrycyjnymi testami. Formalnie przez RFC nie jest wymagane aby domena miała zdefiniowany rekord MX. Lecz każdy szanujący się administrator poważnej domeny zawsze zadba aby odpowiednie serwery figurowaly jako MX. RFC zaleca aby jeśli już 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}{no}}
	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 wyjaśnienie wykorzystanych opcji

  • deny message

    Określamy jaka informacja zwrotna pojawi się u nadawcy.

  • delay

    Opóźnienie po jakim komunikat określnony jako message zostanie zwrócony nadawcy.

  • dnslist

    Lista systemów z bazami blokującymi serwery open relay. Wymienione tutaj powinny skutecznie powstrzymać spam. Jeżeli nadal dostajesz niechciane maile, wykonaj następujące czynności. Sprawdź w nagłówku wiadomości adres IP serwera, który przekazał Twojemu MTA pocztę. Wejdź na stronę: www.ordb.org/lookup/ i wpisz adres IP do sprawdzenia. Jeżeli wyszukiwanie w bazie ordb.org nie przyniesie rezultatów, wejdź 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ócić w odpowiedzi listę systemów RBL (Relay Black List). Można ją wykorzystać dopisując do naszej regułki. Uważaj na system block.blars.org figuruje w nim smtp.wp.pl.

  • hosts

    Podana lista serwerów. W powyższym przykładzie jest to !+relay_from_hosts co oznacza, że cała regółka dotyczy połączeń z wszystkich serwerów za wyjątkiem tych zdefiniowanych jako relay_from_hosts.

  • log_message

    Informacja jaka zostanie zapisana w dzienniku systemowym exima czyli /var/log/exim/main.log

Teraz należałoby włączyć wszystkie usługi jakie zainstalowaliś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=< jin@sina.com > \
    rejected RCPT < user@domena.pl >: \
    Serwer 218.79.119.92 figuruje na czarnej liście dnsbl.sorbs.net

Obsługa wielu domen w Eximie

Jeżeli czytasz tą część opisu konfiguracji exima stanąłeś przed problemem obsługi przez niego więcej niż jednej domeny. Exim jest jak najbardziej do tego przystosowany. Poniżej zamieszczam listing z pliku /etc/mail/exim.conf

virtusertable_alias:
   driver = redirect
   allow_fail
   allow_defer
   data = ${lookup{$local_part@$domain}lsearch{/etc/mail/virtusertable}}
   file_transport = address_file
   pipe_transport = address_pipe
virtusertable_defaultalias:
   driver = redirect
   allow_fail
   allow_defer
   data = ${lookup{@$domain}lsearch{/etc/mail/virtusertable}}
   file_transport = address_file
   pipe_transport = address_pipe

Powyższy przykład umieść umieść na początku sekcji routers. Dla przypomnienia dodam, że początek sekcji oznacza się słowem kluczowym begin.

Jak słusznie zauważyłeś, wpisy z virtusertable do złudzenia przypominają te z system_aliases. Działa to właściwie w ten sam sposób. Podczas odbierania przesyłki exim czyta linijkę data. Ma w niej zdefiniowane, że ma szukać na podstawie local_partczyli to co jest przed znakiem @ oraz domain czyli części domenowej adresu. Wartości które zostaną podstawione zamiast tych zmiennych zostaną porównane z plikiem /etc/mail/virtusertable. Jeżeli wynik porównania wypadnie pomyślnie poczta zostanie dostarczona do odpowiedniego użytkownika, jeżeli zaś nie, odpytane zostaną aliasy systemowe. Jeżeli i tam użytkownik nie zostanie odnaleziony, zostanie wysłana wiadomość z odpowiednią informacją do nadawcy z komunikatem błędu. Część defaultalias jest prawie identyczna. Różnica tkwi jedynie w opcji data. Sprawdzana jest jedynie część domenowa. Poniżej zamieszczam listing z pliku /etc/mail/virtusertable

user@domena.pl		user
mister@sample.com	user2
@jakasdomena.pl		user3

Jak widać budowa pliku jest prosta i czytelna. User3 będzie otrzymywał całą pocztę z domeny jakasdomena.pl. Po tych zabiegach exim powinien być już przygotowany do obsługi wielu domen. Musisz pamiętać aby go zrestartować po dokonaniu modyfikacji jego pliku konfiguracyjnego.

# /etc/rc.d/init.d/exim restart

Automatyczna odpowiedź - Vacations

W przypadku, gdy masz zamiar gdzieś wyjechać na dłużej i nie będziesz miał dostępu do poczty, dobrym pomysłem jest ustawienie automagicznej odpowiedzi dla ludzi, którzy do Ciebie piszą. Tu z pomocą przychodzi nam opcja w Eximie™.

Na początku edytujemy plik /etc/mail/exim.conf i w sekcji routers przed localuser router dodajemy następujące linijki:

user_vacation:
     driver = accept
     check_local_user
     # nie odpisujemy na błędy bądź listy dyskusyjne
     condition = "${if or {{match {$h_precedence:} {(?i)junk|bulk|list}} {eq {$sender_address} {}}} {no} {yes}}"
     no_expn
     require_files = /var/mail/vacation/${local_part}/vacation.msg  
     # nie odpisujemy na maile od list dyskusyjnych oraz na powiadomienia o błędach
     senders = " ! ^.*-request@.*:\
		 ! ^.*@list*.*:\ 
                 ! ^owner-.*@.*:\
                 ! ^postmaster@.*:\
                 ! ^listmaster@.*:\
                 ! ^mailer-daemon@.*\
                 ! ^root@.*"
     transport = vacation_reply
     unseen
     user = ${local_part}
     no_verify

Następnie tworzymy katalog /var/mail/vacation , w którym będą się znajdować katalogi zawierające nazwę użytkownika oraz pliki z informacjami o powodzie jego nieobecności. Powód taki wpisujemy do pliku vacation.msg znajdującego się w /var/mail/vacation/NAZWA_UŻYTKOWNIKA/. Gdy już mamy te ustawienia za sobą w sekcji transport dodajemy następujące 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:}}} (autoreply)} {Informacja} }
     text = "\
     Witaj $h_from\n\n\
     Ta wiadomość została wygenerowana automatycznie\n\
     Tekst poniżej zawiera informację od użytkownika:\n\
     ====================================================\n\n\
     "
     to = "$sender_address"

Ważną częścią tutaj jest opcja once_repeat, która sprawdza jak często nadawcy będą otrzymywać odpowiedzi. W tej konfiguracji jest to co 7dni.

To wszystko, teraz musimy jeszcze zrestartować Exima™ i możemy jechać na urlop.

# /etc/rc.d/init.d/exim restart

Heimdal - Implementacja protokołu Kerberos

Heimdal jest implementacją nowoczesnego sieciowego protokołu uwierzytelniania użytkowników Kerberos. Użytkownik po standardowym zalogowaniu za pomocą hasła na czas trwania sesji otrzymuje specjalny unikalny klucz (w terminologii kerberos'a nazywany biletem (ang. ticket)) za pomocą którego może uzyskać dostęp do innych usług w sieci już bez konieczności dodatkowego podawania hasła.

Każda sieć posiada wydzielony serwer Kerberos, zwany KDC (Key Distibution Center) którego zadaniem jest zarządzanie centralną bazą kluczy (m.in. wydawanie nowych kluczy oraz odpowiadanie na pytania dotyczące ich autentyczności).

Uwaga:Kerberos nie zapewnia dystrybucji bazy użytkowników w sieci - do tego celu najlepiej użyć usługi NIS.

Instalacja i konfiguracja KDC

Za pomocą poldka instalujemy serwer i narzędzia heimdal'a:

# poldek -i heimdal heimdal-server

Edytujemy plik konfiguracyjny /etc/heimdal/krb5.conf. Plik ten używany jest przez biblioteki heimdal'a i powinien być obecny na wszystkich maszynach, na których będziemy używali kerberos'a (na serwerze i klientach)

[libdefaults]
    default_realm = FOO.PL
    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 określa domyślną domenę kerberos'a. Zamiast FOO.PL wpisujemy wybraną nazwę domeny, typowo jest to pisana wielkimi literami nazwa naszej domeny dns. kdc.foo.pl zastępujemy adresem serwera, na którym uruchomiony jest serwer KDC heimdal'a.

clockskew określa maksymalną różnicę czasu (w sekundach) pomiędzy serwerem a klientami (jeżeli różnica czasu będzie większa niż podana, kerberos odmówi współpracy) dlatego dobrze w sieci uruchomić także usługę synchronizacji czasu ntp.

Sekcja [realms] definiuje domeny kerberosa. Można tu wymienić kilka niezależnych domen, określając dla nich lokalizację serwerów kerberosa. kdc.foo.pl zastępujemy oczywiście nazwą hosta na którym będzie uruchomiona usługa kdc.

Ostatnia sekcja [domain_realm]określa mapowanie nazw dns na domeny kerberosa. Na tej podstawie heimdal wie na podstawie nazwy dns hosta w jakiej domenie kerberos'a się znajduje. Nazwa dns zaczynająca się od kropki pasuje do dowolnej poddomeny podanej domeny.

uruchamiamy usługę dystrybucji kluczy KDC:

# service heimdal start

Do zarządzania domeną kerberos'a używamy narzędzia kadmin. Inicjalizujemy domenę i dodajemy użytkownika, w tym przypadku mrk (zostawiając domyślnie proponowane wartości):

# kadmin -l
kadmin>init FOO.PL
kadmin>add mrk

Opcja -l uruchamia kadmin w trybie lokalnym, program musi być uruchomiony z konta root. Możemy także dopisać do pliku /etc/heimdal/krb5.acl:

mrk@FOO.PL all

dając użytkownikowi mrk@FOO.PL prawo do administracji kerberosem - w tym przypadku kadmin wołamy z parametrem -p użytkownik

Logujemy się w systemie na koncie zwykłego użytkownika (w naszym przykładzie mrk) i próbujemy się zalogować do domeny kerberosa:

$ kinit

kinit domyślnie próbuje uzyskać bilet dla zalogowanego użytkownika, można to zmienić podając użytkownika jako parametr.

Sprawdzamy, czy kerberos wystawił nam bilet (ticket):

$ klist
Credentials cache: FILE:/tmp/krb5cc_1000_pSN1Vv
        Principal: mrk@FOO.PL

  Issued           Expires          Principal         
Apr 13 11:02:40  Apr 13 21:02:40  krbtgt/FOO.PL@FOO.PL

Logowanie do systemu

Instalujemy moduł pam-pam_krb5.

# poldek -i pam-pam_krb5

Zmieniamy wybrane pliki /etc/pam.d/*, dodając dodatkowo sprawdzanie hasła za pomocą nowego modułu:

Przykładowo /etc/pam.d/login wykorzystywany przez program login poprawiamy tak:

#zmieniamy linijkę

auth    required    pam_unix.so

na:

auth    sufficient  pam_unix.so
auth    required    pam_krb5.so use_first_pass

i dodajemy:

session optional pam_krb5.so

W ten sposób możemy się zalogować przy uż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 powinniśmy móc zalogować się już podając hasło kerberos'a. Po zalogowaniu możemy jeszcze za pomocą polecenia klist sprawdzić 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 użytkownika na podstawie wystawionego biletu kerberos'a. Zaprezentujemy to na przykładzie sshd, cyrus-imap'a oraz apache'a - opis postępowania w przypadku innych usług obsługujących uwierzytelnianie kerberos jest podobny, Każda skerberyzowana usługa musi mieć utworzone własne konto w domenie Kerberos'a (tzw. service account). Z kontem tym związany jest klucz, który musi być znany zarówno kdc i usłudze. Konto usługi przeważnie jest w postaci: nazwa_usługi/hostname, przy czym hostname musi być pełną nazwą hosta wraz z domeną, czyli tym, co zwraca hostname:

$ hostname --fqdn

Ponadto należy zadbać o poprawne odwzorowanie tej nazwy w DNS - opis jak właściwie ustawić hostname znajduje się podstawach konfiguracji sieci

SSH

Tworzymy konto dla daemona sshd. Konto musi miec nazwę w postaci: host/hostname

# kadmin -l
kadmin> add -r host/host.foo.pl

Parametr -r powoduje, że do konta zostanie przypisany losowy klucz (hasło). Klucz ten jest zapisany jako jeden z atrybutów użytkownika w bazie użytkowników domeny Kerberos'a (dokładnie w /var/lib/heimdal/heimdal.db). By sshd miał także dostęp do tego klucza robimy:

kadmin> ext_keytab host/host.foo.pl

Powyższe polecenie zapisuje klucz związany z kontem usługi do tzw. tablicy kluczy (keytab), z której to tablicy sshd może go pobrać. Klucz zostaje zapisany w domyślnej tablicy kluczy znajdującej się w pliku /etc/heimdal/krb5.keytab. Z tej tablicy kluczy domyślnie korzystają usługi używające kerberos'a.

By sshd uwierzytelniał użytkowników za pomocą 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 określa, czy bilet kerberosa ma być przekazany na maszynę, na którą się logujemy.

Po restarcie sshd, jeżeli mamy wystawiony bilet kerberosa powinniśmy móc zalogować się przez ssh na nasz serwer bez pytania o hasło.

Powyższy opis dotyczy sytuacji, gdy serwer sshd znajduje się na tej samej maszynie co kdc. Jeżeli sshd jest na innej maszynie w sieci, musimy wyeksportować klucz do innej tablicy kluczy:

kadmin> ext_keytab host/host.foo.pl sshd.keytab

a następnie przenieść plik sshd.keytab na maszynę na której mamy uruchomione sshd. Trzeba jeszcze poinformować sshd, że ma szukać klucza w innej lokalizacji niż 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 mieć nazwę w postaci imap/hostname:

kadmin> add -r imap/host.foo.pl

exportujemy klucz do tablicy kluczy:

kadmin> ext_keytab /etc/heimdal/cyrus.keytab

Wybieramy inną niż domyślna tablicę kluczy, ponieważ cyrus imap pracuje z uprawnieniami użytkownika 'cyrus' i jako taki nie ma prawa czytania domyślnej tablicy /etc/heimdal/krb5.keytab.

Dajemy dostęp do tablicy kluczy użytkownikowi cyrus:

chown cyrus.root /etc/heimdal/cyrus.keytab
chmod 660 /etc/heimdal/cyrus.keytab

Na koniec musimy jeszcze poinformować cyrus'a gdzie ma szukać klucza. W pliku /etc/sysconfig/cyrus-imapd dodajemy:

export KRB5_KTNAME=/etc/heimdal/cyrus.keytab

Przykładowe programy klienckie, które potrafią użyć protokołu kerberos do uwierzytelnienia użytkownika to evolution i mutt

Apache

Doinstalowujemy moduł apache'a obsługujący uwierzytelnianie za pomocą kerberos'a:

# poldek -i apache-mod_auth_kerb

Dodajemy konto usługi w domenie kerberos'a:

kadmin> add -r HTTP/hostname

hostname zastępując nazwą 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ę tablicy kluczy możemy tak jak wcześniej podać apache'owi globalnie przez zmienną środowiskową, dopisując do /etc/sysconfig/apache:

export KRB5_KTNAME=/etc/heimdal/httpd.keytab

Można to także zrobić za pomocą dyrektywy Krb5Keytab w pliku konfiguracyjnym apache'a

Przykładowa konfiguracja dostępu może wyglądać następująco:

<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 mrk@FOO.PL
</Directory>

Próba dostępu z prawdopodobnie zakończy się pytaniem o hasło. Naszym celem jest jednak dostęp do serwisu www'a za pomocą biletu kerberos'a, bez zbędnego podawania hasła. W firefox'ie wpisujemy url: about:config, i szukamy pozycji:

network.negotiate-auth.delegation-uris
network.negotiate-auth.trusted-uris

Określają one url'e, dla których przeglądarka ma zastosować rozszerzenie negotiate. Wpisujemy tam nazwy dns naszego serwisu www oddzielone przecinkami. Teraz, jeśli mamy aktualny bilet (sprawdzamy przez klist), powinniśmy zostać wpuszczeni bez pytania o hasło. Rozszerzenie negotiate oprócz firefox'a powinny obsługiwać także mozilla i epiphany - o innych mi nie wiadomo.

Jabber 2 - Serwer typu Instant Messaging

Wstęp

Protokół jabber służy głównie do przesyłania wiadomości typu Instant Messaging (czyli działa podobnie jak inne znane komunikatory np. icq, tlen, gadu-gadu itp.). Zaletą jabbera jest to, że jest otwarty, zapewnia darmową i pełną infrastrukturę (serwery, a także klienty) dla osób prywatnych i użytkowników komercyjnych. Charakteryzuje się także dużym bezpieczeństwem - rozmowy, a także komunikacja między serwerami może być szyfrowana.

W PLD jest kilka serwerów obsługujących komunikację protokołu XMPP, który jest fundamentem Jabbera - zatwierdzonym przez IETF w formie RFC (RFC od 3920 do 3923). Używany przez wielu ISP jabberd™ w wersji 1.4, zdobywający popularność ejaberd™ czy opisywany poniżej jabberd™ w wersji 2.0.

Opisana zostanie podstawowa konfiguracja, umożliwiająca połączenia szyfrowane, a do składowania danych przez jabberd2™ wykorzystamy silnik SQL Postgresql™.

Instalacja

Pakiet jabberd2™ instalujemy za pomocą poldka:

poldek> install jabber-common jabberd

Oczywiście, jeżeli do tej pory nie mamy zainstalowanego Postgresql™ należy zainstalować go także. Należy pamiętać, że jabberd2™ może współpracować także z MySQL™, sqlite3™, a także znacznie prostrzą wersją bazy db™.

Konfiguracja DNS i rekordów SRV

Zanim zaczniemy, musimy stworzyć domenę, która jednoznacznie będzie wskazywała na maszynę Jabbera. Dodamy także rekordy SRV, które służą do zapytań 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      A       10.1.1.1 ;Tu wpisujemy IP naszej domeny
_jabber._tcp.jabber             IN SRV 20 0 5269 domena.org.
_xmpp-server._tcp.jabber        IN SRV 20 0 5269 domena.org.
_xmpp-client._tcp.jabber        IN SRV 20 0 5222 domena.org.

Oczywiście nie możemy zapomnieć o zmianie rekordu serial w strefie domeny i restarcie demona named

Konfiguracja portów (jeżeli korzystamy z firewall-a)

W przypadku wykorzystwania zapór ogniowych w systemie powinniśmy otworzyć porty tcp dla następujących portów:

  • 5222 - Dla komunikacji klienckiej (połączenie nieszyfrowane)

  • 5223 - Dla komunikacji klienckiej (połączenie szyfrowane SSL)

  • 5269 - Dla komunikacji między serwerami Jabbera

  • 5347 - Dla komunikacji między serwerami Jabbera, wykorzystany przez dodatkowe transporty (np. transport GG)

Pamiętać należy, że powyższe porty są ustalone umownie i w plikach konfiguracyjnych demona Jabber, a także rekordach SRV możemy je zmienić (np. dla portu klienckiego ustalić port 80) - jednak zaleca się pozostawić proponowane wyżej porty.

Oczywiście, jeżeli nie chcemy aby nasz serwer był widoczny na zewnątrz naszej sieci (np. jest przeznaczony tylko dla wewnętrzej sieci intranetowej) nie otwieramy portu przeznaczonego do komunikacji między serwerami (u nas to porty 5269 i 5347).

Podstawowa konfiguracja Jabberd2

Możemy wreszcie skonfigurować wstępnie usługę jabberd2™. Wszystkie pliki konfiguracyjne znajdują się w katalogu /etc/jabber.

W pliku /etc/jabber/c2s.xml w okolicy tagu "local" dodajemy naszą domenę:

<!-- Local network configuration -->
  <local>
  <!-- Who we identify ourselves as. This should correspond
       to the ID (host) that the session manager thinks it is. You can
       specify more than one to support virtual hosts, as long as you
       have additional session manager instances on the network to
       handle those hosts. The realm attribute specifies the auth/reg
       or SASL authentication realm for the host. If the attribute is
       not specified, the realm will be selected by the SASL
       mechanism, or will be the same as the ID itself. Be aware that
       users are assigned to a realm, not a host, so two hosts in the
       same realm will have the same users.
       If no realm is specified, it will be set to be the same as the
       ID. -->
   <id>jabber.domena.org</id>

W pliku /etc/jabber/sm.xml w pierwszych linijkach także dodajemy naszą domenę:

<sm>
  <!-- Our ID on the network. Users will have this as the domain part of
       their JID. If you want your server to be accessible from other
       Jabber servers, this ID must be resolvable by DNS.s
       (default: localhost) -->
   <id>jabber.domena.org</id>

Jeżeli chcemy, aby nasz serwer komunikował się 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 już zrobiona. Domyślne ustawienie tzw. "storage" czyli sposobu trzymania przez jabbera informacji o użytkownikach jest zrobione w PLD w db™. Przy małej ilości użytkowników jest to wystarczający sposób. Jednak przy większej ich ilości, bardziej praktyczne jest trzymanie tych danych w bazie SQL.

Konfiguracja dla SQL (Postgresql)

Przy poprawnie działającym postgresie, z uprawnionego dla niego użytkownika tworzymy bazę jabberd2

$ createdb -U postgres jabberd2

Następnie przypisujemy do tej bazy użytkownika jabberd2 i ustalamy dla niego hasło i opcje dostępu do bazy:

$ createuser -P -U postgres jabberd2
Enter password for user "jabberd2":
Enter it again:
Shall the new user be allowed to create databases? (y/n) n
Shall the new user be allowed to create more new users? (y/n) n
CREATE USER

Teraz musimy wypełnić nowoutworzoną bazę odpowiednimi tabelami i polami. Z katalogu /usr/share/doc/jabberd-2* należy rozpakować (najlepiej do katalogu użytkownika, który może działać 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łączenie z bazą będzie odbywać się po localhost, tak więc musimy zadbać o to, żeby postgres umożliwiał takie połączenie

Została nam jeszcze konfiguracja w plikach jabbera.

W pliku /etc/jabber/sm.xml szukamy sekcji "storage" i zmieniamy na:

  <!-- Storage database configuration -->
  <storage>
  <!-- By default, we use the MySQL driver for all storage -->
  <driver>pgsql</driver>

Dla porządku dodamy, że zamiast pgsql, możemy także wykorzytać: mysql, ldap, sqlite (w zależności od mechanizmu jaki wybraliśmy).

W tym samym pliku szukamy następnie sekcji "pgsql" aby w odpowiednim miejscu wpisać hasło dostępu do bazy jabberd2. Możemy tam także zmienić sposób dostępu:

    <!-- PostgreSQL driver configuration -->
    <pgsql>
      <!-- Database server host and port -->
      <host>localhost</host>
      <port>5432</port>
     
      <!-- Database name -->
      <dbname>jabberd2</dbname>

      <!-- Database username and password -->
      <user>jabberd2</user>
      <pass>tu_wpisujemy_hasło_do_bazy</pass>

Podobne zmiany wykonujemy w pliku /etc/jabber/c2s.xml. Umożliwiają one autentykacje użytkowników jabbera:

  <!-- Authentication/registration database configuration -->
  <authreg>
   <!-- Backend module to use -->
   <module>pgsql</module>

I dalej w tym samym pliku (sekcja "pgsql")

    <!-- PostgreSQL module configuration -->
    <pgsql>
      <!-- Database server host and port -->
      <host>localhost</host>
      <port>5432</port>

      <!-- Database name -->
      <dbname>jabberd2</dbname>

      <!-- Database username and password -->
      <user>jabberd2</user>
      <pass>tu_wpisujemy_hasło_do_bazy</pass>
      </pgsql>

Po zrestartowaniu demona jabberd możemy się już cieszyć bardziej zaawansowaną funkcjonalnością naszego komunikatora.

Szyfrowanie

Przed konfiguracją samego jabbera, musimy sprawdzić czy mamy pakiet openssl™ i wygenerować klucz:

# openssl req -new -x509 -newkey rsa:1024 -days 3650 -keyout privkey.pem -out server.pem

sam parametr -days 3650 możemy ustawić na krótszy lub dłuższy (oznacza on długość ważności certyfikatu - w naszym przypadku 10 lat).

Po wykonaniu powyższego polecenia i wpisaniu odpowiedzi na zadane pytania (zwróćmy tylko uwagę, abyśmy w polu Common Name wpisali naszą domenę, obsługiwaną przez serwer jabbera) usuniemy hasło z klucza prywatnego:

# openssl rsa -in privkey.pem -out privkey.pem

Następnie połączymy oba klucze w jeden plik i skasujemy klucz prywatny:

# cat privkey.pem >> server.pem
# rm privkey.pem

Zmieniamy nazwę naszego certyfikatu (dla porządku), 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:

    <!-- Older versions of jabberd support encrypted client connections
    via an additional listening socket on port 5223. If you want
    this (required to allow pre-STARTTLS clients to do SSL),
    uncomment this -->
  <ssl-port>5223</ssl-port>
		 </local>

Zdejmujemy komentarz także z tagu "require-starttls" (kilka linijek wyżej):

    <!-- Require STARTTLS. If this is enabled, clients must do STARTTLS
    before they can authenticate. Until the stream is encrypted,
    all packets will be dropped. -->
  <require-starttls/>

Teraz w każdym z pięciu plików konfiguracyjnych znajdujących się w /etc/jabber tj. router.xml, sm.xml, resolver.xml, s2s.xml, c2s.xml znajdujemy zakomentowany ciąg wskazujący na nasz certyfikat:

<!--
<pemfile>/etc/jabber/server.pem</pemfile>
-->

Kasujemy komentarze (czyli <!-- i -->) i wpisujemy odpowiednią scieżkę do naszego certyfikatu:

<pemfile>/var/lib/openssl/certs/jabber.pem</pemfile>

Kolejny restart demona jabber i możemy cieszyć się połączeniami szyfrowanymi.

Zakończenie

Opisane powyżej sposoby konfiguracji nie wyczerpują oczywiście wszystkich aspektów. Zachęcamy do odwiedzenia strony z oryginalną dokumentacją jabbera. Mimo, że niektórym może sprawić problem język angielski, to podane przykłady w jasny sposób omawiają także zaawansowane zagadnienia.

MySQL - System Zarządzania Relacyjnymi Bazami Danych (ang. RDBMS)

Co to jest MySQL™?

MySQL™ jest Systemem Zarządzania Relacyjnymi Bazami Danych. Znany i ceniony jest przede wszystkim ze względu na swoją niebywałą wydajność i szybkość działania. Świetnie nadaje się do obsługi projektów internetowych, ale nie tylko - z powodzeniem używany jest również w wielkich projektach informatycznych organizacji, takich jak chociażby NASA. Przeciwnicy MySQL'a często mówią, jak to bardzo brakuje mu wielu ficzerów, które posiadają prawdziwe, duże systemy baz danych. Ze swojego doświadczenia wiem, że część z tych ludzi nawet nie rozróżnia wersji systemu, które oferuje nam firma MySQL AB (producent MySQL).

Ogólne cechy MySQL

  • Napisany w C i C++ (wydajność!).

  • API dla wielu języków programowania: C, C++, Eiffel, Java, Perl, PHP, Python, Ruby, Tcl.

  • Pełna wielowątkowość, korzystająca z wątków kernela. Oznacza to, że MySQL będzie pracował na maszynie wieloprocesorowej, jeśli tylko taką posiadasz.

  • Opcjonalna obsługa transakcji.

  • B-drzewa z kompresowanymi indeksami. To wam się przyda, jakbyście mieli wieeeelkie bazy ;) Wystarczy powiedzieć, że znacząco wpływa na czas wyszukiwania i pobierania danych (wierszy) z bazy.

  • Istnieje możliwość "osadzenia" (ang. embed) serwera MySQL w aplikacji, którą piszemy. Jeśli ktoś potrzebuje funkcjonalności systemu baz danych, a niekoniecznie chce się bawić w klient-serwer, to czemu nie?

  • Duża liczba typów danych w kolumnach. Liczby, ciągi znakowe, obiekty binarne (BLOB), data & czas, typy wyliczeniowe, zestawy. Na uwagę zasługuje fakt, że w MySQL możemy daną kolumnę dostosować do pewnej wielkości danych, które zamierzamy w niej przechowywać (np. TINYINT, a nie INT), tym samym uzyskujemy większą wydajność i mniejsze zużycie pamięci (również dyskowej). Istnieje możliwość definiowania niektórych typów danych jako narodowych (różne standardy kodowania chociażby).

  • Obsługa klauzul agregujących i grupujących SQL.

  • Złączenia zewnętrzne (LEFT & RIGHT).

  • Komenda SHOW pozwalająca przeglądać informacje na temat baz, tabel i indeksów. Komenda EXPLAIN opisująca pracę optymalizatora zapytań.

  • Bardzo prosty (z punktu widzenia administratora) system zabezpieczeń. Wszystkie hasła są szyfrowane.

  • Połączenia z serwerem przez: TCP/IP, ODBC, JDBC.

  • Lokalizacja (w sensie językowym) serwera. Komunikaty m.in. po polsku.

Instalacja

Instalację oprogramowania przeprowadzimy oczywiście z pomocą naszego poldka. Logujemy się jako root, bądź używamy polecenia sudo, jeżeli mieliśmy je skonfigurowane do tego celu. Pierwszą rzeczą, którą będziemy musieli zrobić, jest ściągnięcie i zainstalowanie odpowiednich pakietów z repozytorium PLD. Można zrobić to używając zarówno trybu wsadowego, jak i interaktywnego. Podam oba sposoby, wybierz sobie ten, który bardziej Ci odpowiada :) (osobiście wolę tryb interaktywny, ze względu na tab-completion).

Najpierw uruchamiamy poldka. Można podać mu flagę -n, która oznacza źródło, z którego zamierzamy ściągać pakiety. Jeśli nie podamy tej flagi, wówczas poldek skorzysta z pierwszego ź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 wygląda następująco:

# poldek -n bentel -i mysql mysql-client mysql-libs

Instalacja w trybie interaktywnym

W trybie interaktywnym poldka, instalacja wygląda tak:

# poldek -n bentel
Wczytywanie ftp://spirit.bentel.sk/mirrors/PLD/[...]/packages.dir.gz...
Przeczytano 5116 pakietów
Wczytywanie /root/.poldek-cache/packages.dir.dbcache.var.lib.rpm.gz...
Przeczytano 450 pakietów

Witaj w poldkowym trybie interaktywnym. Wpisz "help" aby otrzymać pomoc.

poldek>

Teraz przystępujemy do instalacji pakietów MySQL:

poldek> install mysql mysql-client mysql-libs

poldek sam zadba o spełnienie wymaganych zależności.

Konfiguracja MySQL

Żeby móc sprawnie (i bezpiecznie) używać naszego świeżo zainstalowanego serwera, musimy go odpowiedno skonfigurować.

Otworzymy naszym ulubionym edytorem tekstu plik konfiguracyjny demona MySQL. W przypadku użycia edytora Vim wydajemy następującą komendę:

# vim /etc/mysql/clusters.conf

Jeżeli nie zamierzamy zmieniać lokacji, w której będzie u nas pracował MySQL, to po prostu odkomentujmy linijkę z MYSQL_DB_CLUSTERS, a jeżeli zamierzamy umieścić serwer MySQL w innym miejscu, to należy tą linijkę odkomentować, ale dodatkowo zmienić ścieżkę.

# standard setting
MYSQL_DB_CLUSTERS="/var/lib/mysql"

Upewniamy się, że jesteśmy zalogowani na konsoli jako root i wydajemy polecenie:

# /etc/rc.d/init.d/mysql init

Polecenie to będzie nam potrzebne tylko przy pierwszym uruchomieniu serwera - służy ono zainicjalizowaniu klastra baz danych. Powiedzmy, że nasz katalog jest "formatowany", ok? ;) Jeżeli pojawiłby wam się błąd, mówiący o duplikacie wpisu localhost-mysql dla klucza 1 - możecie go zignorować.j

Teraz możemy przystąpić już do edycji właściwiego pliku konfiguracyjnego RDBMS. Używając naszego ulubionego edytora otwieramy plik /var/lib/mysql/mysqld.conf

# vim /var/lib/mysql/mysqld.conf

Teraz możemy przystąpić do jego edycji. Pierwszą grupą opcji, na jaką 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 oczywiście katalog, w którym składowane będą nasze bazy. Można zostawić tak jak jest.

user to użytkownik "pod którym" będzie działał nasz serwer, w sensie - uruchomienie serwera wygląda tak, jakby to ten użytkownik, reprezentowany przez zmienną user go uruchomił (proces należy do niego). Można zmienić, chociaż nie polecam. Nie zalecane jest wykorzystanie do tego użytkownika root!

To co nas natomiast bardzo interesuje, z dwóch względów, to opcja port. Chodzi o dwa przypadki:

  • Chcemy umożliwić dostęp do naszego serwera baz danych z zewnątrz, a admin naszej sieci "łaskawie" przekierował nam jakiś 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, żeby wskazywała na ten, który mamy dostępny.

  • Mamy maszynę z zewnętrznym IP (taką, do której można się podłączyć z Internetu), nie blokowaliśmy jednak dostępu do MySQL, ale chcielibyśmy podnieść choć troszeczkę poziom bezpieczeństwa i udostępnić serwer MySQL na innym porcie. Wybieramy i jakiś i wpisujemy go jako wartość opcji port.

# Don't allow connections over the network by default
skip-networking	

Jeżeli chcemy zablokować dostęp do serwera MySQL z zewnątrz (z sieci), to... nie robimy nic. A jeśli chcemy umożliwić innym komputerom łączenie się z naszym serwerem, to należy wykomentować (dodać #) linijkę z skip-networking.

Gdyby nam się kiedyś coś popsuło (zapomnieliśmy hasła, nie możemy dostać się do bazy), to przyda się odkomentowanie tej opcji:

# Emergency option. Use only if you really need this.
#skip-grant-tables

Przydatną rzeczą (ale w sumie tylko, jeśli zamierzamy udostępniać bazy na zewnątrz), będzie włączenie logowania połączeń i zapytań (zwalnia pracę serwera). Dodam, że można oczywiście zmienić standardową ścieżkę, do której zapisywane są 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ływają bezpośrednio na pracę i wydajność serwera, nie będę się więc w nie zagłębiał. To trochę trudniejszy temat. Jak ktoś chce bardzo zoptymalizować pracę swojego serwera, to polecam lekturę dokumentacji MySQL. Przydatna jest również znajomość zagadnień relacyjnych baz danych i SQL'a. Przykładowo zerkniemy na jedną zmienną:

#set-variable = max_connections=100

Odkomentowanie tej linijki pozwoli nam na ustawienie maksymalnej liczby połączeń, które nasz MySQL będzie mógł przyjąć i obsłużyć w danej chwili. Wszystko zależy od tego, w jakim celu używamy naszego RDBMS - należy postawić sobie pytanie - "ile osób może chcieć podłączyć się do mojego serwera w jednej chwili i ile takich połączeń przypada średnio na jedną osobę?". Odpowiedź wpisujemy w zmienną max_connections. Innym pytaniem mogłoby być "czy skrypty obsługujące moje strony www korzystają ze stałych (persistent) połączeń?"

Ponieważ "Polacy nie gęsi i swój język mają" odkomentujemy jeszcze jedną linijkę w pliku konfiguracyjnym, aby włączyć polskie komunikaty:

# Language
language   = polish

W tej chwili nasz serwer powinien być już skonfigurowany do pracy. Upewniamy się, że jesteś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ę jeszcze, że nasz serwer baz danych rzeczywiście "wstał":

# /etc/rc.d/init.d/mysql status
MySQL cluster /var/lib/mysql: running

Jak widać na załączonym obrazku serwer działa. Ponieważ w tej chwili jest zainstalowany w sposób domyślny i dlatego mało bezpieczny, należy ustawić jakieś hasło dla użytkownika mysql:

# mysqladmin -u mysql -S /var/lib/mysql/mysqldb/mysql.sock password 'naszehaslo'

Po opcji -S podajemy scieżkę do pliku mysql.sock, który powinien znajdować się w katalogu, w którym umieściliśmy MySQL.

Demon MySQL

Demon MySQL standardowo startuje wraz z systemem, ale przydaje się znać dwie komendy. Aby włączyć lub wyłączyć serwer, będąc zalogowanym jako root, bądź używając komendy sudo, wydajemy polecenie:

# /etc/rc.d/init.d/mysql start | stop

wstawiając oczywiście opcje start lub stop, w zależności od tego, co chcemy zrobić.

mysqladmin

mysqladmin jest narzędziem, za pomocą którego możemy tworzyć i usuwać bazy oraz przeładowywać konfigurację. Nie będziemy go używać do wyłączania serwera, bo od tego jest skrypt omówiony powyżej. Narzędzie wywołuje się poleceniem mysqladmin, a flagi i argumenty (opcje) polecenia służą do wykonywania określonych zadań. Ponieważ wcześniej zmieniliśmy hasło dla użytkownika mysql, winniśmy przy każdym poleceniu dodać -u mysql i -p na koń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 nową bazę danych o nazwie nazwabazy.

  • drop nazwabazy - usuwa bazę danych o nazwie nazwabazy

  • flush-privileges albo reload - obie opcje robią to samo - przeładowują tablice uprawnień. Powinniśmy wykonać przeładowanie zawsze, gdy dodamy np nowego użytkownika do jakiejś bazy, ponieważ do czasu przeładowania takie konto jest nieaktywne.

mysqldump

mysqldump to program, służący do "zrzucania" danych - czyli do robienia kopii zapasowych. Polecenie to jest przydatne w przypadku wykonywania kopii zapasowych podczas aktualizacji MySQL czy też przenoszenia danych na inny serwer.

Kilka przydatnych opcji:

  • --databases baza1 baza2... - zrzuca dane z baz, których nazwy podaliśmy w liście oddzielonymi spacjami.

  • --all-databases - to samo co wyżej ale dla wszystkich bazy.

  • --add-drop-table - dodaje DROP TABLE do skryptów tworzących tabele z backup-u (jak będziemy przywracać dane). Przydatne, kiedy np chcemy przywrócić już istniejącą tabelę. Spowoduje to najpierw jej usunięcie, a następnie utworzenie od nowa z danych, które mieliśmy w kopii zapasowej. Ogólnie, żeby uniknąć ewentualnych problemów z duplikatami wierszy, itp. warto tą opcję włączyć.

  • --no-create-info - w kopii nie zostanie zawarta informacja o tworzeniu tabel (nazwy tabel, typy pól, indeksy itp.). Przydatne, jeżeli chcemy zrobić kopię tylko danych, a nie całej struktury bazy.

  • --no-data - Ta opcja pozwala zapisać samą informację o strukturze bazy i tabel, nie zapisuje natomiast danych.

  • --opt nazwabazy - tworzy kopię bazy nazwabazy wraz z rozszerzonymi informacjami MySQL, blokowaniem tabel, itd. Chyba najczęściej stosowana opcja przy robieniu kopii zapasowych.

Należy pamiętać, że wynik polecenia mysqldump należy przekierować (>) do jakiegoś pliku. Podam może kilka przykładów użycia tego programu. Zrzucenie zawartoś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 przydatną opcją jest --opt omówiona wcześniej. Polecam jej stosowanie do wykonywania kopii całej bazy, włącznie ze strukturą tabel i samymi danymi. Aby stworzyć pełną kopię zapasową bazy baza1 i zapisać ją w pliku baza1_kopia.sql:

# mysqldump -u mysql --opt baza1 > baza1_kopia.sql -p

Przywracanie baz wykonanych poleceniem mysqldump wygląda tak:

# mysql -u mysql baza1 < baza1_kopia.sql -p

Inna metoda (w sumie różniąca się 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 pozwalająca udostępniać zasoby dyskowe komputerom w sieci. Serwer udostępnia katalog(i) klientom, którzy mogą je podmontować i działać jak na lokalnym systemie plików. Ponadto można z niego uruchamiać stacje bezdyskowe lub tworzyć rozproszone systemy plików.

Serwer

Najpierw instalujemy demona portmap (o ile nie jest już zainstalowany) oraz demona NFS poleceniem:

# poldek -i portmap nfs-utils

Serwer NFS jest gotowy do pracy od razu po zainstalowaniu, wystarczy jedynie uruchomić usługę portmap, a następnie nfs (dokładnie w tej kolejności). Teraz możemy przejść do konfiguracji udziałów sieciowych. Do podstawowej pracy serwera nie ma potrzeby konfigurowania czegokolwiek, w pozostałych wypadkach należy przyjrzeć się plikowi /etc/sysconfig/nfsd, który może wyglądać następująco:

SERVICE_RUN_NICE_LEVEL="+0"

#RPCMOUNTOPTIONS="--no-nfs-version 3"

RPCNFSDCOUNT=8

NFSDTYPE=K
  • SERVICE_RUN_NICE_LEVEL - ustala priorytet serwera

  • #RPCMOUNTOPTIONS="--no-nfs-version 3" - opcja dla jąder z serii 2.2, dla współczesnych kerneli powinna być zakomentowana

  • RPCNFSDCOUNT - podaje liczbę instancji serwera, czyli ilu klientów może obsłużyć jednocześnie

  • NFSDTYPE - podaje czy serwer ma pracować jako oddzielny demon (U), czy w trybie jądra (K). Zalecane jest to drugie z rozwiązań, gdyż zapewnia większą wydajność.

Modyfikacja pliku konfiguracji wymaga restartu uslugi.

Udostępnianie

Uruchomiliśmy serwer, teraz przyszedł czas na udostępnienie zasobów. W pliku /etc/exports definiuje się udostępniane katalogi, ich listę podajemy w postaci wierszy, które mają następującą składnię:

$katalog  $klient1($opcja1,$opcja2,...)  $klient2($opcja1,$opcja2,...)
  • $katalog - udostępniony katalog. Warto tutaj wspomnieć, że jeżeli udostępniamy dany katalog to nie możemy udostępnić w nowej regułce katalogu będącego jego ojcem jak i synem, jeżeli leżą na tym samym systemie plików. Udostępnianie partycji FAT, itp. też nie jest dobrym rozwiązaniem.

  • $klient - IP lub nazwa komputera, któremu udostępniamy katalog. Można podać także całą sieć, wtedy zezwolimy wszystkim komputerom w sieci na przeglądanie i/lub zapisywanie do katalogu.

  • $opcje - tutaj możemy ustalić m.in. czy zasób ma być udostępniony tylko do odczytu, czy także do zapisu, oraz nałożyć inne ograniczenia. Wszystkie opcje opisane są w manualu (man exports).

Oto przykładowe wpisy do /etc/exports:

/srv/pub   192.168.0.1(ro) 192.168.0.2(rw)
/home        192.168.0.0/255.255.255.0(rw)

Pomijając sensowność 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. Jeżeli modyfikujemy /etc/exports w trakcie pracy serwera to musimy poinformować demona, żeby ponownie odczytał plik konfiguracji. Przed tym możemy sprawdzić czy nasze wpisy są poprawne:

# exportfs -v

Polecenie to wyświetli listę katalogów gotowych do wyeksportowania, jeśli któryś z udziałów nie jest wyświetlony, to prawdopodobnie popełniliśmy jakiś błąd w składni. Gdy jesteśmy pewni, że chcemy udostępnić udziały NFS, to wydajemy polecenie:

# exportfs -rv

W PLD stworzono grupę systemową fileshare, która ma prawo do modyfikowania konfiguracji udziałów sieciowych (NFS i SMB), bez konieczności posiadania praw root-a. Aby nadać użytkownikowi takie prawo wystarczy zapisać go do tej grupy, opis zarządzania grupami użytkowników opisano w „Grupy”.

Klient

Konfigurację klienta rozpoczynamy od zainstalowania i uruchomienia usługi portmap. Jeśli chcemy, aby zasoby NFS były montowane w trakcie startu systemu, instalujemy pakiet nfs-utils-clients, dostarczający wymagany rc-skrypt: /etc/rc.d/init.d/nfsfs.

Teraz przyszedł czas na połączenie się z zasobem NFS, w tym celu musimy go zamontować np.:

# mount serwer.net:/srv/pub /mnt/net -t nfs

serwer.net to IP bądź nazwa naszego serwera, /srv/pub jest przykładowym udostępnionym katalogiem na serwerze (wpisaliśmy go wcześniej do /etc/exports). Katalog /mnt/net to przykładowe miejsce podmontowania zasobu. Można użyć dodatkowo flagi -o a po niej podać potrzebne nam opcje montowania. Pełną listę opcji znajdziemy w podręczniku systemowym: man 5 nfs.

Jeśli nic nie stoi na przeszkodzie abyśmy podłączali 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 wygląda znajomo, ale uwagę zwracają opcje hard i intr. Otóż hard oznacza, że programy korzystające z zasobów NFS w momencie awarii serwera zostaną zawieszone w oczekiwaniu na dostęp do danych i nie będzie możliwości ich odwieszenia w postaci polecenia kill, chyba, że dodamy opcję intr dzięki czemu będziemy mogli zabić dany proces. Zamiast hard możemy użyć opcji soft, jednak w przypadku awarii serwera NFS sygnalizuje błąd programom korzystającym z zasobów. Wadą tego rozwiązania jest to, że nie wszystkie programy potrafią poradzić sobie z takim komunikatem i może dojść do utraty danych.

Bezpieczeństwo serwera

Musimy zadbać o bezpieczeństwo naszego serwera, podstawowym sposobem zabezpieczania zasobu jest ograniczenie dostępu. Możemy go ograniczać za pomocą ustawień w pliku /etc/exports, za pomocą filtra pakietów lub plików /etc/tcpd/hosts.allow i /etc/tcpd/hosts.deny, co zostało przedstawione poniżej.

Najpierw blokujemy wszystkim dostęp do naszych usług wpisując do pliku pliku /etc/tcpd/hosts.deny:

portmap:ALL                                                                     
lockd:ALL                                                                       
mountd:ALL                                                                      
rquotad:ALL                                                                     
statd:ALL

Następnie w /etc/tcpd/hosts.allow wpisujemy komputery, którym zezwalamy na korzystanie z wymienionych usług. Możemy zarówno wpisać adresy IP komputerów jak i całą podsieć.

portmap: 192.168.0.0/255.255.255.0                                              
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 użytkownika, a jedynie na poziomie hosta. Z tego względu nie bardzo nadaje się do udostępniania w Internecie, jeśli to tylko możliwe lepiej użyć protokołu FTP lub WebDAV.

Dostrajanie wydajności

Wolne działanie protokołu NFS wskazuje przeważnie na brak odpowiedniego dostrojenia połączenia, wystarczy ustawić kilka opcji by uzyskać zaskakująco duży wzrost wydajności. Podane poniżej zalecenia dotyczą konfiguracji klienta.

Na początek zajmiemy się opcjami rsize i wsize. Dzięki nim możemy zwiększyć szybkość odczytu i zapisu plików na serwer. Manual systemowy radzi by ustawić im na wartości: rsize=8192 i wsize=8192. Linijka w pliku /etc/fstab będzie wyglądać teraz następująco:

192.168.0.1:/usr/local  /usr/local   nfs      rw,hard,intr,rsize=8192,wsize=8192  0     0

Domyślnie NFS działa w oparciu o protokół UDP, doświadczenie pokazuje jednak, że przełączenie w tryb TCP może w niektórych wypadkach zwiększyć szybkość przesyłu danych. Niestety nie każdy serwer NFS obsługuje połączenia TCP, więc nie wszędzie możemy użyć tej opcji. Na szczęście PLD zawiera demona pozwalającego na używanie TCP. Aby włączyć tą opcję 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 należy trochę eksperymentować z ustawieniami, na początek dobrym pomysłem może być użycie obu powyższych wskazówek. Więcej o dostrajaniu NFS-a można odnaleźć w podręczniku systemowym.

PDNS (Power DNS) - Serwer Nazw

Power DNS zwany w dalszej części tego dokumentu jako PDNS™ jest zaawansowanym i bardzo efektywnym serwerem nazw. Jego możliwości współpracy z LDAP lub bazami SQL (Mysql i Postgresql) dają szerokie możliwości tworzenia skryptów lub interface zarządzających. Sam PDNS jest uważany za zdecydowanie bezpieczniejszy niż Bind™, a także od niego szybszy - zwłaszcza przy większej ilości obsługiwanych domen.

Wstęp

W tym rozdziale zostanie omówiona podstawowa instalacja, konfiguracja z bazą Postgresql™, a także wstępna konfiguracja przykładowej domeny. Oczywiście więcej szczegółów możemy znaleźć w oryginalnej dokumentacji.

Instalacja

Instalacja przebiega standardowo za pomocą poldka.

poldek> install pdns

Do poprawnego działania naszej bazy potrzebujemy także postgresql™ (możemy także wykorzystać mysql lub ldap, a nawet pliki konfiguracyjne Bind-a). Tak więc jeżeli nie mamy Postgresql to instalujemy go i poprawnie konfigurujemy.

Konfiguracja Postgresql dla PDNS

Następnym krokiem będzie stworzenie bazy obsługiwanej przez PDNS w Postgresql. W tym celu możemy wykorzystać klienta dostarczanego razem z Postgresql - psql™. Możemy także do tego celu użyć innych wygodnych narzędzi np. phpPgAdmin

Najpierw z konta użytkownika uprawnionego do operacji na bazie tworzymy bazę:

$ createdb -U postgres powerdns

Tworzymy także użytkownika dla w/w bazy:

$ createuser -P -U postgres pdns
Enter password for user "pdns":
Enter it again:
Shall the new user be allowed to create databases?
(y/n) n
Shall the new user be allowed to create more new
users? (y/n) n
CREATE USER

Teraz za pomocą swojego ulubionego klienta Postgresql wykonujemy poniż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            VARCHAR(255) DEFAULT NULL,
type            VARCHAR(6) DEFAULT NULL,
content         VARCHAR(255) DEFAULT NULL,
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
);

GRANT SELECT ON supermasters TO pdns;
GRANT ALL ON domains TO pdns;
GRANT ALL ON domains_id_seq TO pdns;
GRANT ALL ON records TO pdns;
GRANT ALL ON records_id_seq TO pdns;

Konfiguracja PDNS

W /etc/pdns/pdns.conf konfigurujemy działanie programu PDNS. Przykładowa konfiguracja PDNSa współpracującego z bazą Postgresql może wyglądać następują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	   # Uż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. serwerów DNS np.
# 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łączenie usługi monitorowania pracy PDNS przez WWW
webserver-address=10.1.1.1 # Adres IP strony monitorującej pracę PDNS
webserver-password=hasło_do_strony_monitorującej
webserver-port=8088	   # port strony monitorującej

Krzyżyk "#" na początku oznacza komentarz bądź wyłączenie danej opcji. Oryginalne teksty komentarzy są na tyle czytelne, że tylko niektóre opcje skomentowalismy po polsku.

Domeny

Praktycznie PDNS jest gotowy do pracy. Musimy jeszcze wypełnić treścią bazę - czyli dodać domenę (domeny). Przykładową domenę zaprezentujemy w formie tzw. "dump-a" bazy. Jest to na tyle czytelne, że skomentowane zostaną 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;

--
-- 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 (1, 'foo.com', NULL,	NULL, 'NATIVE', NULL, NULL); 
INSERT INTO domains VALUES (2, '1.1.10.in-addr.arpa', NULL, NULL, 'NATIVE', NULL, NULL);
-- W pierwszym ID podajemy domenę 'foo.com'
-- W drugim ID definiujemy domenę odwrotną dla danego IP

--
-- Data for Name: records; Type: TABLE DATA; Schema: public; Owner: pdns
--
-- Poniżej zgodnie z określonymi ID definiowane są kolejno strefy

INSERT INTO records VALUES (2, 1, 'localhost.foo.com', 'A', '127.0.0.1', 120, NULL, NULL);
INSERT INTO records VALUES (3, 1, 'www.foo.com', 'A', '10.1.1.1', 120, NULL, NULL);
INSERT INTO records VALUES (5, 1, 'dns.foo.com', 'A', '10.1.1.1', 120, NULL, NULL);
INSERT INTO records VALUES (6, 1, 'ftp.foo.com', 'A', '10.1.1.1', 120, NULL, NULL);
INSERT INTO records VALUES (7, 1, 'poczta.foo.com', 'A', '10.1.1.1', 120, NULL, NULL);
INSERT INTO records VALUES (8, 1, 'pop3.foo.com', 'A', '10.1.1.1', 120, NULL, NULL);
INSERT INTO records VALUES (9, 1, 'smtp.foo.com', 'A', '10.1.1.1', 120, NULL, NULL);
INSERT INTO records VALUES (10, 1, 'ssh.foo.com', 'A', '10.1.1.1', 120, NULL, NULL);
INSERT INTO records VALUES (11, 1, 'jabber.foo.com', 'A', '10.1.1.1', 120, NULL, NULL);
INSERT INTO records VALUES (1, 1, 'foo.com', 'SOA', 'localhost user.foo.com 1', 86400, NULL, NULL);
INSERT INTO records VALUES (16, 1, 'foo.com', 'TXT', 'Serwer PDNS', 300, NULL, NULL);
INSERT INTO records VALUES (17, 1, 'foo.com', 'NS', 'ns.foo.com', 300, NULL, NULL);
INSERT INTO records VALUES (4, 1, 'mail.foo.com', 'A', '10.1.1.1', 120, NULL, NULL);
INSERT INTO records VALUES (18, 1, 'foo.com', 'MX', 'mail.foo.com', 300, 5, NULL);
INSERT INTO records VALUES (19, 1, 'foo.com', 'A', '10.1.1.1', 300, 0, NULL);

-- Poniżej definiujemy rekordy SRV dla serwera Jabber 
INSERT INTO records VALUES (12, 1, '_jabber._tcp.jabber.foo.com', 
	'SRV', '0 5269 foo.com', 300, 10, NULL);
INSERT INTO records VALUES (13, 1, '_xmpp-server._tcp.jabber.foo.com', 
	'SRV', '0 5269 foo.com', 300, 10, NULL);
INSERT INTO records VALUES (14, 1, '_xmpp-client._tcp.jabber.foo.com', 
	'SRV', '0 5222 foo.com', 300, 10, NULL);

-- Domena odwrotna
INSERT INTO records VALUES (15, 2, '1.1.1.10.in-addr.arpa', 'PTR', 'foo.com', 86400, NULL, NULL);
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, NULL, NULL);

--
-- Data for Name: supermasters; Type: TABLE DATA; Schema: public; Owner: pdns
--

--
-- PostgreSQL database dump complete
--

Wszelkie zmiany lub dodawanie nowych domen możemy wykonywać na bazie danych lub wykorzystując do tego odpowiednie skrypty. Teraz możemy uruchomić demona PDNS wykorzystując skrypt:

# /etc/init.d/pdns start

Należy pamiętać, że jeżeli wcześniej używalismy BINDa bądź innnego demona do obsługi nazw domenowych, należy go przed uruchomieniem PDNS wyłączyć.

Po uruchomieniu serwisu możemy za pomocą przeglądarki http wejść na stronę monitorującą pracę PDNS (odpowiednie opcje dotyczące 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 możemy odnaleźć wiele cennych informacji dotyczących 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 ściągamy poldkiem instalujemy i działa... działa ale chcemy coś więcej... chcemy by nasz smtpd był ładnie skonfigurowany.

Zaczynamy

Ściągamy to co nam będzie potrzebne. Wiadomo... postfix i dodatki, które mu są potrzebne:

poldek -i postfix cyrus-sasl cyrus-sasl-plain cyrus-sasl-saslauthd \
    cyrus-sasl-login

A tutaj coś co będzie nam potrzebne do tworzenia certyfikatów.

poldek -i openssl-tools

A tutaj coś żebyśmy mogli pobrać pocztę z serwera.

poldek -i tpop3d inetd rc-inetd

Konfiguracja

Przyszedł czas na konfigurację postfix™-a.

# echo 'pwcheck_method:saslauthd' > /etc/sasl/smtpd.conf

Należy jeszcze sprawdzić czy w /etc/pam.d/ znajduje się plik smtp, jeżeli nie to należy przegrać na to miejsce przykładowy konfig z /usr/share/doc/cyrus-sasl-saslauthd-*/cyrus.pam.gz , rozpakować i nazwać plik smtp.

Uruchom saslauthd™:

# /etc/rc.d/init.d/saslauthd start

Uruchom postfix™-a:

# /etc/rc.d/init.d/postfix start

Teraz chcemy, żeby postfix™ wymagał autentykacji:

# postconf -e smtpd_sasl_auth_enable=yes
# 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 wyglądać 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, \
    reject_sender_login_mismatch,permit_sasl_authenticated, \
    reject_unauth_destination
smtpd_sasl_auth_enable = yes

Szyfrowanie

Włączamy teraz szyfrowanie wysyłania poczty oraz transmisji między MX-ami dla różnych domen

Następnie generujemy certyfikat SSL. Podczas generowania certyfikatu będziesz musiał odpowiedzieć na kilka prostych pytań.

Robimy to w sposób następujący:

# 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 należy dodać 4 linijki, takie jak poniż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 należy zastąpić aktualną linijkę czyli tą z domyślnej instalacji:

#smtps inet  n  -  n  -    -    smtpd
na naszą aktualną:
 smtps inet  n  -  y  -    -    smtpd -o smtpd_tls_wrappermode=yes \
    -o smtpd_sasl_auth_enable=yes

Domeny

Jeżeli posiadamy więcej niż jedną domenę na serwerze to w /etc/mail/main.cf dopisujemy:

mydestination = $myhostname, jakas.domena.pl, \
    costam.gdziestam.pl, PLD.biz.pl

Jeżeli chcemy aby nasz postfix obsługiwał wirtualne domeny (przyznawał się 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 nastepujące wpisy:

# plik domains, w nim wpisane domeny dla których nasz serwer 
#pocztę będzie przyjmował.
pld-linux.org    		relay
81.0.225.27			relay

Do /etc/mail/virtual dopisujemy na przykład coś takiego:

# plik virtual, w nim wpisane są konta w domenach które obsługujemy
# schemat wpisu
# ktostam.nazwisko@domena.pl    konto_w_systemie
rafal.drozd@networking.ee           grifter
rafal.drozd@jakas.domena.pl         grifter
rafal.drozd@costam.gdziestam.pl	grifter
rafal.drozd@PLD.biz.pl		grifter
virusalert@networking.ee		grifter
# to ostatnie będzie nam później do amavisa potrzebne :)

Teraz musimy wklepać

# postmap /etc/mail/domains
# postmap /etc/mail/virtual

No i restart postfixa

# /etc/rc.d/init.d/postfix restart

Usprawnienia

Dodatkowe wpisy które poprawią pracę naszego postfix™-a Edytujemy /etc/mail/main.cf i dodajemy następujące 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] wielkość przesyłki, właściwie mając \
# dobre łącze można
# wpisać 10 mega [10000000]
message_size_limit = 2000000
# 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.

Koń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, \
    reject_sender_login_mismatch,permit_sasl_authenticated, \
    reject_unauth_destination
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

Zawartość master.cf

# grep -v ^# /etc/mail/master.cf
smtp      inet  n  -  n  -     -  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 coś dzięki czemu będziemy mogli pobrać pocztę z serwera.

No i włączamy tpop3d™-a

# /etc/rc.d/init.d/tpop3d start

amavis + mks

Przystępujemy do instalacji i konfiguracji amavisa™ + mks™ :)

Instalujemy poldkiem mks™, serwer mksd™, bazy, oraz skrypt aktualizujący bazy

poldek -i mks mksd mks-bases mks-updater mksd-clients

Teraz ściągamy jakiegoś 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

Jeśli dostaliście coś takiego, tzn. ż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

Jeśli dostałeś coś takiego, tzn. że wszystko jest okej. mksd przyśpiesza znacznie pracę na słabych maszynach... wtedy znacznie odczujesz.

Instalujemy teraz amavisa

poldek -i amavisd-new

No i teraz najgorsze ;)

Edytujemy /etc/amavisd.conf

Odkomentuj linię:

@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)

Możemy tutaj ustawić użytkownika amavis. Dodatkowo należy dopisać mksd do grupy amavis, dzięki czemu będzie on mógł korzystać z katalogów z częściami maili amavisa.

# grep amavis /etc/group
amavis:x:116:mksd

Zakomentuj linię:

#$unix_socketname = "$MYHOME/amavisd.sock"; # amavis helper protocol socket

Jeśli nie chcesz żeby amavis używał pewnych pakerów to zakomentuj odpowiednie linie, np.

#$unrar  =  'unrar';

Usuń wszystkie wpisy na temat antywirusów (@av_scanners = ) i zastąp to wpisem z pliku README z archiwum mksd:

['MkS_Vir daemon',
'mksscan', '-s -Q {}',
[0], [1..7],
qr/^... (\S+)/
 ],

Usuń wpisy z @av_scanners_backup =

W swoim systemie pocztowym (postfix) utwórz użytkownika (lub alias) "virusalert" lub pozmieniaj wpisy:

$mailfrom_notify_admin
$mailfrom_notify_recip
$virus_admin

My zrobiliśmy wcześniej aliasa dla virusalert ;)

Ja sobie jeszcze dopisałem:

$hdrfrom_notify_sender = $mailfrom_notify_admin;

Jeśli nie chcesz aby nadawcy listów oraz admini dostawali informacje o wirusach w domyślnym języku (English) to odkomentuj linie i zrób własne wpisy w /var/amavis/*.txt

# $notify_sender_templ      = 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 zmień 

#$bdy_encoding = 'iso-8859-1';  # (default: 'iso-8859-1')

na

$bdy_encoding = 'iso-8859-2';  # (default: 'iso-8859-1')

Według licencji powinieneś umieścić w notify_sender.txt reklamę http://www.mks.com.pl gdyż jest do warunek licencji na używanie mks™. Na końcu pliku /usr/sbin/amavisd znajdują się przykładowe szablony.

W pliku /etc/mail/master.cf dopisujemy nową linię:

localhost:10025 inet n  -       n       -       -       smtpd

No i restart postfix™-a, amavisd™-a i mks

# /etc/rc.d/init.d/postfix restart
# /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łeś 250? To znaczy, ze amavisd™ sprawdził przesyłkę :) nie wierzysz? tail -n 100 -f /var/log/maillog

A teraz sprawdzimy jak reaguje na przesyłkę 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

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ę:
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 -      -       n       -       2       smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes

Restart postfix™-a:

# /etc/rc.d/init.d/postfix restart

i powinno wszystko nam pięknie latać:)

Wyślij sobie eicar.com w załączniku a zobaczysz, ż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 zarządzania bazą danych na świecie typu OpenSource - w taki oto sposób grupa rozwijająca SZBD PostgreSQL reklamuje swój produkt. SZBD PostgreSQL jest implementacją języka SQL, która zawiera w sobie bardzo wiele jego elementów, a na dodatek wprowadza wiele własnych rozszerzeń. Porównywany z mySQL oddaje mu pola przy małych instalacjach, które w prosty, a szybki sposób mają obsługiwać bazę danych - typu małe portale internetowe, proste bazy, i tym podobne. Jednakże SZBD PostgreSQL dostaje skrzydeł w większych projektach, jest często porównywany do bardzo rozbudowanego SZBD Oracle. Cechy SZBD PostgreSQL to między innymi:

  • osadzane języki proceduralne wykonywane przez bazę danych (plperl, pl/perlu, plpgsql, plpython, pltcl, pl/tcl)

  • możliwość tworzenia funkcji w PostgreSQLu w języku C, kompilowanych do bibliotek dynamicznych

  • sterowniki dostępu do bazy z języków C, C++, python, perl, czy Java (poprzez JDBC), ODBC

  • wysoce zaawansowana implementacja standardu SQL, obejmująca SQL/92

  • obsługa BLOB (Binary Large OBjects) -- dużych obiektów binarnych, takich jak pliki graficzne, itp.

  • obsługa pól typu AUTOINCREMENT jako SERIAL lub SEQUENCE

  • licencję BSD, która umożliwia zamykanie kodu SZBD PostgreSQL przy dokonywaniu modyfikacji, co jest istotne w rozwiązaniach biznesowych

Instalacja pakietów

Uruchamiamy program poldek™:

# poldek

Wykonujemy:

poldek>ls -l postgresql-*

Przykładowy wynik to:

poldek> ls -l postgresql-*
package                                build date                 size
postgresql-7.4-0.8                     2003/12/16 20:45        8.8 MB
postgresql-backend-devel-7.4-0.8       2003/12/16 20:45        1.4 MB
postgresql-clients-7.4-0.8             2003/12/16 20:45        1.5 MB
postgresql-devel-7.4-0.8               2003/12/16 20:45       93.0 KB
postgresql-doc-7.4-0.8                 2003/12/16 20:45        5.3 MB
postgresql-ecpg-7.4-0.8                2003/12/16 20:45      479.0 KB
postgresql-ecpg-devel-7.4-0.8          2003/12/16 20:45       17.0 KB
postgresql-libs-7.4-0.8                2003/12/16 20:45      252.0 KB
postgresql-module-pgcrypto-7.4-0.8     2003/12/16 20:45       91.0 KB
postgresql-module-plperl-7.4-0.8       2003/12/16 20:45       30.0 KB
postgresql-module-plpgsql-7.4-0.8      2003/12/16 20:45      100.0 KB
postgresql-module-plpython-7.4-0.8     2003/12/16 20:45       35.0 KB
postgresql-module-pltcl-7.4-0.8        2003/12/16 20:45       44.0 KB
postgresql-static-7.4-0.8              2003/12/16 20:45      303.0 KB
postgresql-tcl-7.4-0.8                 2003/12/16 20:45       38.0 KB
postgresql-tcl-devel-7.4-0.8           2003/12/16 20:45        0.0 KB
postgresql-tcl-static-7.4-0.8          2003/12/16 20:45       36.0 KB
17 packages, 18.6 MB
poldek>

Do poprawnego działania SZBD PostgreSQL konieczne są następujące pakiety:

  • postgresql

  • postgresql-clients

  • postgresql-libs

Zatem można przystąpić do ich instalacji, wpisując następujące polecenie:

# poldek -i postgresql postgresql-clients postgresql-libs

Aby SZBD PostgreSQL skorzystał z wewnętrznych języków plpgsql czy też plphpython należy doinstalować pakiety postgresql-module-plpgsql

# poldek -i postgresql-module-plpgsql

oraz

root# poldek -i postgresql-module-plpython

Konfiguracja PostgreSQLa w PLD

Wstępna konfiguracja

Edytujemy plik /etc/sysconfig/postgresql:

# vim /etc/sysconfig/postgresql

I wybieramy odopowiednie podejście do bazy danych. Polecam standard setting. Po edycji wykonanie komendy

# grep PG_DB_CLUSTERS /etc/sysconfig/postgresql | egrep -v ^#

powinno dać 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 można dodawać bazy danych. Trzeba teraz odpowiednio skonfigurować tenże cluster. Przyda się edycja plików ${PG_DB_CLUSTERS}/{postgresql.conf,pg_hba.conf}:

# vim /var/lib/pgsql/{postgresql.conf,pg_hba.conf}

Przydatna opcja to tcpip_socket = true w pliku /var/lib/pgsql/postgresql.conf.

Uruchomienie PostgreSQLa

# service postgresql start

Dodanie użytkownika

# su - postgres -c 'psql template1'
template1=# CREATE USER uzytkownik WITH ENCRYPTED PASSWORD 'hasło' \
    CREATEUSER CREATEDB;
CREATE USER

Użytkownik `uzytkownik' będzie miał możliwość tworzenia baz danych (za pomocą createdb lub CREATE DATABASE z poziomu psql) jak i dodawania uż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łączyć obsługę PostgreSQLa w PHP™, instalując pakiet php-pgsql™, również 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++™ korzystających z PostgreSQLa. Dokumentacja do PostgreSQLa znajduje się, a jakże, w pakiecie postgresql-doc™.

# poldek -i php-pgsql
# poldek -i perl-DBD-Pg
# poldek -i perl-Pg
# poldek -i python-postgresql
# poldek -i postgresql-devel
# poldek -i postgresql-doc

Odnośniki

ProFTPD - serwer FTP

Wstęp

Dużą zaletą ProFTPD™ jest jego prostota. Plik konfiguracyjny demona do złudzenia przypomina ten od Apache™. Jego zrozumienie nie powinno sprawiać trudności.

Instalacja

Zanim przystąpisz do instalacji powinieneś zdecydować w jakim trybie ma pracować usługa. Jako demon, czy ma być uruchamiana poprzez superserwer inetd™. Tryb inetd polega na tym, że proces proftpd zostanie uruchomiony dopiero po odebraniu przez inetd żądania o tę usługę. Natomiast w trybie daemon ProFTPD jest uruchomiony cały czas i pracuje niezależnie od inetd. Tak więc, jeżeli Twój komputer, który przeznaczysz na serwer nie jest zbyt szybki, powinieneś wybrać ProFTPD uruchamianego poprzez inetd. Dystrybucja udostępnia obie te możliwości. Pakiet proftpd-inetd zapewnia uruchamianie poprzez inetd, natomiast po zainstalowaniu usługi z pakietu proftpd-standalone uruchamiana ona będzie w trybie daemon. W opisie posłużymy się wersją daemon. Instalujemy pakiet proftpd-standalone

Podstawowa konfiguracja demona

Jak już wspomniałem we wstępie, ProFTPD jest jednym z prostszych w konfiguracji programów serwerowych. Wszystkie pliki potrzebne do jego skonfigurowania znajdują się w katalogu /etc/ftpd.

# ls -1 /etc/ftpd
ftpusers
proftpd.conf

W pliku ftpusers znajduje się lista użytkowników, którym odebrana została możliwość logowania się do serwera ftp. Poszczególne pozycje z tej listy zakończone są znakiem nowej linii, tak więc każda pozycja jest rozmieszczona jedna pod drugą. Natomiast plik proftpd.conf zawiera właściwą konfigurację usługi.

ServerName                      "ProFTPD"
ServerIdent                     off
ServerType                      standalone
DeferWelcome                    off
DefaultServer                   on
DefaultRoot                     ~
  • ServerName określa nazwę serwera wyświetlaną łączącym się z nim użytkownikom.

  • ServerIdent pozwala na wyświetlenie wiadomości powitalnej podczas połączenia, np. zawartości pliku .message. Domyślnie wyłączona.

  • ServerType ustawia tryb pracy demona ProFTPD

  • DeferWelcome Nie pokazuje wiadomości powitalnej dopóki użytkownik się nie zautoryzuje.

  • DefaultServer Określamy konfigurację jako domyślną

  • DefaultRoot Wyznaczamy nadrzędny dla każdego użytkownika katalog spoza którego nie będzie mógł wyjść. W listingu powyżej będzie to katalog domowy.

Poniżej znajduje się szereg zakomentowanych opcji pozwalających na konfigurację połączeń bezpieczną metodą przy użyciu SSL. Jeżeli jesteś zainteresowany ich użyciem powinieneś zapoznać się z dokumentacją on line serwera ProFTPD. Przechodzimy teraz do dalszej konfiguracji.

Port                            21
Umask                           022
User                            ftp
Group                           ftp
AuthPAMAuthoritative            on
  • Port Definiujemy tutaj port na którym serwer będzie oczekiwał nadchodzących połączeń

  • Umask Tryb umask 022 jest typowym standardem dla ogolnie dostępnych plików i katalogów

  • User Konto użytkownika na którego uprawnieniach pracuje usługa

  • Group Grupa do której należy konto użytkownika usługi

  • AuthPAMAuthoritative Dajemy możliwość autoryzacji użytkowników poprzez moduł PAM jeśli jest to możliwe.

Przedstawione tutaj wartości poszczególnych opcji są domyślnie ustawiane w pliku konfiguracyjnym w trakcie instalacji pakietu. Jak najbardziej możesz z nich korzystać. Na pewno nie powinieneś zmieniać takich ustawień jak użytkownik czy grupa, port oraz sposób autoryzacji.

Konfiguracja dostępu

<Directory />
	AllowOverwrite          on
</Directory>

Zezwalamy na nadpisywanie plików w obrębie katalogu do którego użytkownik się zaloguje. Poniżej w pliku znajduje się przykładowa konfiguracja dla użytkownika anonimowego. Sekcja mieści się wewnątrz znacznika <Anonymous ~ftp></Anonymous>. Poniższy wykaz omawia najczęściej wykorzystywane dyrektywy w tej sekcji.

User			ftp
Group			ftp
AnonRequirePassword	off
RequireValidShell	off
  • User - konto użytkownika którego prawa będzie uzyskiwała osoba logująca się do serwera

  • Group - grupa do której należy powyższe konto.

  • AnonRequirePassword - w powyższym przykładzie wyłączona. Umożliwia użytkownikom anonimowym logowanie się bez hasła.

  • RequireValidShell - opcja ta powoduje, że ProFTPD nie sprawdza czy dany użytkownik, który się loguje posiada przypisaną w /etc/shells powłokę.

UserAlias		anonymous ftp
MaxClients		10
DisplayLogin		welcome.msg
DisplayFirstChdir	.message
AllowStoreRestart 	on
  • UserAlias - przyporządkowuje nazwę użytkownika do systemowego konta. W przykładzie anonymous został przypisany kontu ftp.

  • MaxClients - ilość jednoczesnych połączeń anonimowych które będą realizowane przez serwer.

  • DisplayLogin - określamy plik którego zawartość będzie wyświetlana po starcie.

  • DisplayFirstChdir - plik którego zawartość będzie wyświetlana po pierwszym wejściu do katalogu.

  • AllowStoreRestart - pozwala klientom wznawiać 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 określone prawa dostępu. W powyższym przykładzie każdy ma dostęp do zapisu w tym katalogu natomiast nikt nie posiada prawa do jego odczytywania.

Zakończenie

Dostęp do serwera ftp możemy ograniczać na kilka sposobów. Można limitować ilość jednoczesnych połączeń, stworzyć listę adresów IP, które będą miały prawo do zapisu czy odczytu określonych katalogów.

Na tym zakończymy podstawową konfigurację serwera ProFTPD. Więcej informacji na jego temat znajdziesz na stronach z jego dokumentacją.

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ędą pakiety: samba™ i samba-clients™. Znaczenie poszczególnych pakietów:

  • samba™ - pakiet ten zawiera serwer samby

  • samba-clients™ - zestaw narzędzi przydatnych w poruszaniu się w środowisku Microsoft Networks.

Proces instalacji pakietów przedstawiony został w dziale Zarządzanie pakietami.

Konfiguracja

Przy użyciu dowolnego edytora otwieramy plik /etc/samba/smb.conf. Całą konfigurację należy wykonać w sekcji [global]. Przyjęta w nim została następująca konwencja: <opcja> = <wartość>. Jeżeli dana opcja ma kilka wartości, oddziela się je znakiem spacji. Poszczególne opcje umieszczane są w osobnych liniach. Komentarze w pliku rozpoczynają się znakiem "#" lub ";". Poniżej znajduje się wykaz najważniejszych opcji które należy ustawić podczas realizacji zadania.

workgroup = DOM
server string = File Server
announce as = NT Server	

Ustawiamy nazwę domeny której członkiem będzie 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łówną przegladarką komputerów w sieci.

security = user

Określamy poziom bezpieczeństwa. Nasza konfiguracja wymaga ustawień zabezpieczeń na poziomie użytkownika.

nt acl support = yes
nt pipe support = yes

Ustawiamy

time server = yes

Ustawiamy bycie serwerem czasu (opcjonalnie).

Następnie restartujemy SAMBĘ i przystępujemy do dalszej konfiguracji. W bazie użytkowników Samby musi znaleźć się konto administratora. Będzie ono wymagane przy dołączaniu stacji klienckich do domeny.

# smbpasswd -a root
New SMB password:
Retype new SMB password:
Added user root.

Hasło roota Samby nie powinno być identyczne z hasłem administratora systemu! następnie tworzymy konta uż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ętajmy też o utworzeniu wpisu w bazie użytkowników Samby:

# smbpasswd -a jurek

następnie ustawiamy mapowanie grup w linux na odpowiednie grupy windows-a, poleceniem net groupmap. Domyślne ustawienia Samby (mapowanie na uniksową grupę -1) wymaga zmiany, którą wprowadzi polecenie net groupmap add:

# net groupmap add ntgroup="Domain Admins" unixgroup=domadmin type=d rid=512
Updated mapping entry for Domain Admins

Podobnie modyfikujemy wpisy dla grup Domain Users - decydując się na wybór grupy users oraz Domain Guests - nobody: net groupmap.

# net groupmap add ntgroup="Domain Users" unixgroup=users type=d rid=513
Updated mapping entry for Domain Users
# net groupmap add ntgroup="Domain Guests" unixgroup=nobody type=d rid=514
Updated mapping entry for Domain Guests
# net groupmap add ntgroup="Users" unixgroup=users type=d
Add mapping entry for Users

Sprawdźmy, czy zmiany będą 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łożenia mu konta - tzw. Machine Trust Account. Jest to specyficzne konto, gdyż jego hasło ustalane jest przy podłączaniu komputera do domeny i znane tylko parze klient-serwer. Dzięki temu istnieje możliwość sprawdzenia tożsamości próbującego się logować komputera - nawet gdy ktoś dołączy maszynę o tej samej nazwie, to nie powinien uzyskać możliwości dostępu do domeny. Nazwy kont odpowiadają nazwom NetBIOS komputerów, ale z dołączonym na końcu symbolem dolara. Dla stacji biuro będzie to więc biuro$. Konto to powinno być zablokowane, by niemożliwe było uzyskanie dostępu poprzez ssh, czy też inne usługi systemu operacyjnego. Nie jest także konieczny katalog domowy, w zamian za to zdecydujemy się na umieszczenie kont w grupie machines - pozwoli to w jakimś stopniu ogarnąć szybko zwiększającą się liczbę uż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 powinniśmy teraz utworzyć odpowiedni wpis w bazie haseł Samby - nie jest to jednak konieczne. Przy próbie podłączenia komputera do domeny czynność ta zostanie wykonana automatycznie. Gdy jednak zajdzie potrzeba ręcznego utworzenia wpisu, do wywołania smbpasswd dodać musimy parametr -m (machine):

# smbpasswd -a -m ksiegowosc

W tym przypadku nie podajemy symbolu $. Oczywiście cały proces dodawania kont maszyn można zautomatyzować w tym celu należy dodać do /etc/samba/smb.conf:

add machine script = /usr/sbin/useradd -d /var/lib/nobody -g machines -c 'Konto Maszyny %I' -s /bin/false %u 
passwd chat debug = no
passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passwd:*all*authentication*tokens*updated*successfully*
passwd program = /usr/bin/smbpasswd -L -a %u

i oczywiście utworzyć katalog /var/lib/nobody

# mkdir /var/lib/nobody
 

należy sie też upewnić czy nie mamy w smb.conf wpisu

# kto nie moze sie logowac do samby
invalid users = root
 

Aby dodać Windows XP Profesional lub Microsoft Windows NT Server 4.0 Standard Edition (wersja Home nie obsługuje modelu domenowego w żaden sposób) należy w rejestrze zmienić:

REGEDIT4

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\netlogon\parameters

"RequireSignOrSeal"=dword:00000000

lub z poziomu Local Group Policy wyłączając (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.html 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. Zaletą takiej konfiguracji jest możliwość budowania polityki praw dostępu do zasobów zgromadzonych na serwerze w oparciu o konta użytkowników lokalnego serwera PDC.

Instalacja

Do realizacji tego zadania potrzebne będą trzy pakiety: samba™, samba-clients™ oraz samba-winbindd™. Znaczenie poszczególnych pakietów:

  • samba™ - pakiet ten zawiera serwer samby

  • samba-clients™ - zestaw narzędzi przydatnych w poruszaniu się w środowisku Microsoft Networks.

  • samba-winbindd™ - demon pozwalający na pobieranie uprawnień z serwera PDC.

Proces instalacji pakietów przedstawiony został w dziale Zarządzanie pakietami.

Konfiguracja

Przy użyciu dowolnego edytora otwieramy plik /etc/samba/smb.conf. Całą konfigurację z której będzie również korzystał demon winbindd™ należy wykonać w sekcji [global]. Przyjęta w nim została następująca konwencja: <opcja> = <wartość>. Jeżeli dana opcja ma kilka wartości, oddziela się je znakiem spacji. Poszczególne opcje umieszczane są w osobnych liniach. Komentarze w pliku rozpoczynają się znakiem "#" lub ";". Poniżej znajduje się wykaz najważniejszych opcji które należy ustawić podczas realizacji zadania. Wykraczają one nieco poza czystą konfigurację winbindd™ ale są konieczne do jego prawidłowego działania.

workgroup = DOM
server string = File Server

Ustawiamy nazwę domeny której członkiem będzie nasz serwer oraz opcjonalnie komentarz (opis) komputera.

security = domain

Określamy poziom bezpieczeństwa. Nasza konfiguracja wymaga ustawień zabezpieczeń typu domenowego.

password server = PDC

Nazwa netbiosowa serwera PDC. To z tego właśnie serwera demon winbind będzie pobierał uprawnienia.

To tyle, jeżeli chodzi o ogólną konfigurację 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
  • winbind separator - znak, którym oddzielana będzie nazwa użytkownika bądź grupy od nazwy domeny. Np. "DOM+jan"

  • idmap uid - zakres uidów w systemie zarezerwowanych na użytkowników domenowych

  • idmap gid - zakres gidów w systemie przeznaczonych na grupy domenowe

Na tym możemy zakończyć edycję pliku konfiguracyjnego samby. Aby nasza konfiguracja stała się aktywna musimy przerestartować usługę.

/etc/rc.d/init.d/smb restart

W ślad za usługą smb™ zostaną przerestartowane także nmbd™ oraz interesujący nas winbindd™. Czynnością którą musimy bezwzględnie wykonać jest podłączenie naszego serwera do domeny. Aby to uczynić wykonujemy poniższe polecenie:

# net rpc join -S PDC -U Administrator%hasło
Joined the domain DOM

Jeżeli w tym momencie miałbyś problemy ze skomunikowaniem się z serwerem domeny możesz dodać do polecenia opcję -I a po niej adres IP serwera PDC. Po pomyślnej operacji podłączenia możemy sprawdzić działanie winbinda.

# wbinfo -g
DOM+Administrator
DOM+Basia
DOM+Darek
...
# wbinfo -g
DOM+Domain Admins
DOM+Domain Users
...

Opcja -u pokazuje listę użytkowników, natomiast -g listę grup.

Jeżeli wynik obu poleceń wygląda podobnie jak na listingu oznacza to, że winbind pracuje poprawnie.

Zakończenie

Jakie korzyści płyną z takiej konfiguracji samby? Otóż sprawdza się ona w środowisku sieciowym w którym zasoby udostępniają zarówno serwery pracujące pod kontrolą Windows jak i linuksa. Pozwala to na budowanie spójnej polityki bezpieczeństwa w oparciu o uwierzytelnianie użytkownika na poziomie domeny. Drugą z zalet jest prostota w implementacji. Dzięki winbindd™ dostęp do grup oraz użytkowników domenowych odbywa się w taki sam sposób jak do ich odpowiedników lokalnych.

# chown DOM+Administrator.DOM+Domain\ Users plik.txt

Snort - Sieciowy System Wykrywania Włamań

Snort to bardzo silny sieciowy system wykrywania ataków (ang. Network Intrusion Detection System, NIDS), który daje szeroki zakres mechanizmów detekcji, mogących w czasie rzeczywistym dokonywać analizy ruchu i rejestrowania pakietów w sieciach opartych na protokołach IP/TCP/UDP/ICMP. Potrafi przeprowadzać analizę strumieni pakietów, wyszukiwać i dopasowywać podejrzane treści, a także wykrywać 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 instalacją Snorta warto zaopatrzyć się w bazę danych (w opisie wykorzystano MySQL™) i serwer Apache™ z obsługą PHP™. W bazie będą składowane logi, a za wygodny interfejs do przeglądania alarmów posłuży ACID™ (ang. Analysis Console for Intrusion Databases).

Instalacja Snorta i ACID

Gdy mamy już bazę danych i serwer WWW z PHP, instalujemy następujące pakiety.

# poldek -i snort acid

Przed konfiguracja ś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 < \
    /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ępnie (najprościej przy użyciu popularnego narzędzia phpMyAdmin™) tworzymy użytkownika i nadajemy mu prawa dla stworzonych baz.

Przechodzimy do edycji pliku /etc/acid_conf.php, w którym dodajemy parametry dla połączenia się 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ępna pod adresem http://twoje_ip/acid. Oczywiście dla bezpieczeństwa zalecane jest zastosowanie protokołu SSL do komunikacji z zasobem i autoryzacji poprzez pakiet apache-mod_auth.

Snort zależnie od środowiska w jakim działa może generować dużą ilość zbędnych alertów, te bardziej istotne można przenosić do drugiej bazy za pomocą ACID, dla przejrzystości ogółu.

Konfiguracja Snorta

Do działania jako sieciowy system wykrywania włamań, Snort potrzebuję sprecyzowania zasad funkcjonowania całości w głównym pliku konfiguracyjnym snort.conf. W starszych wersjach systemu, wszystkie opcje, łącznie z regułami ataków znajdowały się w jednym pliku. Ciągła rozbudowa Snorta, rosnąca liczba sygnatur i ogólna funkcjonalność, wymusiła rozdzielenie niektórych części konfiguracyjnych, w tym reguł ataków. Przejrzystość i spójność snort.conf została przywrócona przy użyciu polecenia include, którym dołącza się odpowiednie zestawy sygnatur i inne części konfiguracyjne, np.:

include: ścieżka_do_pliku/nazwa

Bazy reguł charakteryzują się nazwą pliku z końcówką .rules, pierwszy człon nazwy zawiera rodzaj usługi lub typ ataku, którego dotyczy dany zestaw.

Pozostałymi plikami konfiguracyjnymi są:

  • classification.config - zawierający klasyfikatory rodzajów ataków z nadanym priorytetem zagrożenia, tak jak poniżej:

    config classification: web-application-attack,Web Application Attack,1
  • reference.config - posiadający skróty adresów do stron organizacji z bazą opisów ataków, np.:

    config reference: bugtraq http://www.securityfocus.com/bid/
  • threshold.conf - metody łagodzenia licznych, fałszywych alarmów,

  • unicode.map - zestaw kodowanych znaków unicode, na potrzeby preprocesora http_inspect.

Główny plik konfiguracyjny można podzielić na cztery sekcje. Pierwsza, odpowiedzialna jest za ustalanie zmiennych var, wykorzystywanych w składni reguł ataków.

Przyjmijmy że docelowo Snort ma monitorować dwie podsieci o adresach 192.168.1.0/24 i 192.168.2.0/24, jego pliki konfiguracyjne znajdują się bezpoś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,]
# Scieżka do katalogu z regulami atakow
var RULE_PATH /etc/snort/rules

W tej samej sekcji znajduje się zestaw parametrów uruchomieniowych, zaczynających się od wyrażenia config (pełna ich lista znajduję się w dokumentacji):

# wybor interfejsu do nasłuchu (jeden demon Snorta moze 
# obslugiwac tylko jeden interfejs sieciowy) 
config interface: eth0

Druga część głównego pliku konfiguracyjnego, zawiera ustawienia preprocesorów. Parametry domyślne nie będą przedstawione w poniższym opisie. Kompletną listę opcji, można znaleźć w dokumentacji Snorta. Oto przykłady ustawień 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.
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 }

Powyższy przykład przedstawia możliwość profilowania ustawień dla poszczególnych serwerów, które podlegają ochronie. Serwery IIS i Apache, pracują w odmienny sposób, a zarazem posiadają inne słabe punkty wykorzystywane podczas ataków. Operacja dostosowania ustawień skupia mechanizmy ochronne na odpowiednich metodach ataków dla danego typu serwera bądź ich grupy w danej sieci objętej ochroną.

RPC_decode, Back Orfice, Telnet_decode, Arpspoof, Performance Monito:

# alert_fragments . wlacza alarm, przy fragmentowaniu pakietow RPC,
# Domyś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 wyjściowych, czyli różnych sposobów logowania wyników i tzw. akcji reguł. Na potrzeby tego opisu wymieniony będzie tylko przykład logowania do bazy MySQL.

output database: alert, mysql, user=login password=haslo \ 
dbname=snort_log host=127.0.0.1

Za pomocą reguł akcji można tworzyć własne rodzaje reakcji na wykryte zdarzenie, np.:

ruletype czerwony_alarm
 {
	type log
	# 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ęść, głównego pliku konfiguracyjnego, zawiera odniesienia do zestawów reguł i wcześniej już opisanych plików, classification.config, reference.config, threshold.conf (przykład poniż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ł mają być brane pod uwagę (czyli jakie pliki z regułami mają być dołączane za pomocą polecenia include). W środowisku, w którym wszystkie serwery WWW to Apache, reguły chroniące serwer IIS będą generowały zupełnie niepotrzebne alarmy. Jeśli nie udostępniamy FTP, reguły opisujące ataki na tę usługę będą tylko spowalniały pracę całego systemu. To sprawy oczywiste, jednak właściwe dostosowanie NIDS do swoich potrzeb wymaga wiele pracy. Dobranie odpowiednich dla danego środowiska reguł jest kluczowe dla działania całego systemu, duża ilość fałszywych alarmów nie tylko zużywa zasoby (każda z reguł musi być przecież przeanalizowana), ale może również bardzo skutecznie "zaciemnić" obraz, sprawiając, że prawdziwy atak może przejść niezauważony w zalewie informacji mało istotnych. Obecna baza sygnatur liczy sobie około 2500 reguł i jest praktycznie każdego dnia wzbogacana o nowe opisy ataków. Dla przybliżenia występujących w bazie kategorii sygnatur, opiszę jakiego rodzaju ataki wykrywają:

  • attack-responses - odpowiedzi usług na próbę ataku;

  • backdoor - działalność tzw. tylnych drzwi, trojanów, rootkitów;

  • bad-traffic - nieprawidłowy ruch, np. na port 0;

  • chat - aktywność róż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ę Domain Name System;

  • experimental - zestaw eksperymentalnych reguł;

  • exploit - programy mające na celu wykorzystywanie błędów w oprogramowaniu;

  • icmp-info, icmp - komunikaty ICMP z różnych programów, testujących 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óżne, dotyczące usług CVS, MS Terminal, BOOT, UPnP itd.;

  • multimedia - strumienie audio, wideo;

  • mysql, sql, oracle - ataki na znane serwer baz danych;

  • netbios - anomalia związane z protokołem Netbios/SMB;

  • nntp - ataki na serwer grup dyskusyjnych;

  • other-ids - działalność innych systemów IDS;

  • p2p - aktywność programów Peer to Peer;

  • policy - próby ataków na usługi policy ftp itp.

  • porn - aktywność stron pornograficznych;

  • rpc - ataki na usługi Remote Procedure Call;

  • finger, rservices, telnet - ataki na dość słabo zabezpieczone usługi uniksowe: finger, rlogin, rsh, rexec, telnet;

  • scan - róż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 związane z przesyłaniem plików poprzez serwer ftp;

  • virus - transfer poczty z podejrzanym załącznikiem;

  • web-attacks, web-misc, web-client, web-cgi, web-php, web-coldfusion, web-frontpage, web-iis - ataki na różnego typu serwery WWW, przeważnie z wykorzystaniem błędów w skryptach cgi, php;

  • x11 - aktywności sesji serwera XFree86.

Aktualizacja reguł

Do aktualizacji sygnatur posłuży nam perlowy skrypt Oinkmaster. Ma on duże możliwości które pozwalają w prosty sposób zarządzać regułami Snorta. Wymagane pakiety do uruchomienia to: perl, perl-base, perl-modules i vixie-cron albo hc-cron .

Instalacja Oinkmaster

Ściągamy 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ę po następującej sekwencji komend:

# /usr/local/bin/oinkmaster.pl -o /etc/snort/rules/

Dodanie innego ź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ę automatycznie, w katalogu /etc/cron.daily tworzymy plik uprules.

# touch /etc/cron.daily/uprules
# chmod 700 /etc/cron.daily/uprules

I dodajemy do niego następującą zawartość, podając adres e-mail na który ma zostać wysłany raport z codziennej aktualizacji jeśli pojawia się coś 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 przyjżeć się bliżej ciekawym funkcjonalnościom oinkmastera. W pliku konfiguracyjnym mamy możliwość wyłączania poszczególnych regułek po nr sid, dodawania do nich własnych modyfikacji itp. Wtedy jest pewność że po aktualizacji, nasze zmiany w plikach reguł nie będą nadpisywane.

Architektura Snorta

Snort jest logicznie podzielony na kilka komponentów, które współpracują ze sobą by wykrywać ataki i generować wyniki w odpowiednim formacie. Głównymi składnikami systemu są: dekoder pakietów (sniffer), preprocesory, silnik detekcji i moduł wyjściowy.

W swej najprostszej formie Snort może działać jako sniffer. Przechwytuje pakiety z warstwy łącza danych za pomocą biblioteki pcap. Rozpoznaje różne protokoły modelu OSI - Ethernet, 802.11, Token Ring oraz wiele protokołów działających w wyższych warstwach jak: IP, TCP, UDP i ICMP. Surowe pakiety z warstwy łącza danych (np. ramki Ethernetowe) po zdekodowaniu wądrują do preprocesorów (warstwa transportowa), gdzie są testowane i w razie konieczności obrabiane na potrzeby silnika detekcji (warstwa sesji). Tam dokonywana jest analiza pakietów pod kątem zbioru zadanych reguł. Następnie po wykryciu próby ataku bądź anomalii sieciowych, system przekazuje odpowiednie dane do modułu wyjściowego, który to decyduje o zapisaniu wyniku wykrycia w logach lub wszczęciu alarmu.

Tryby pracy

Snort umożliwia dużą swobodę konfiguracji, za pomocą wielu parametrów, które pozwalają kontrolować trzy podstawowe tryby pracy programu: sniffer, packet logger i network intrusion detection.

  • Sniffer Mode - wychwytuje wszystkie pakiety w danym segmencie sieci i przedstawia ich zawartość na ekranie. Najprostszym sposobem użycia tego trybu jest uruchomienie programu z parametrem -v w wyniku, czego Snort będzie wyświetlać informacje o nagłówkach IP, TCP/UDP/ICMP. Do uzyskania bardziej szczegółowych danych o wychwyconych pakietach, służą parametry -d (aby monitorować ładunek pakietów) i -e (dodatkowe nagłówki warstwy łącza danych). Parametry można łączyć razem, bez znaczenia jest ich kolejność (np. snort -ved). Aby zakończyć pracę w tym trybie należy użyć sekwencji klawiszy CTRL+C.

  • Packet Logger Mode - logowanie pakietów poprzez zapis na dysku. Czynność ta odbywa się po użyciu opcji -l, którą wskazujemy katalog, gdzie Snort będzie zapisywać w odpowiednio nazwanych podkatalogach i plikach, zawartość zebranych pakietów. Program potrafi także zapisywać dane w formie binarnej tak jak robi to znany sniffer tcpdump™. Służy do tego opcja -b, po jej użyciu nie trzeba stosować dodatkowych kombinacji parametrów -ved, ponieważ format tcpdump, określa to, co ma być logowane (np. snort -b -l ./log). Uzyskane w ten sposób informacje, można wykorzystać do późniejszej analizy za pomocą programów rozpoznających format binarny tcpdump (np. Ethereal™). Oczywiście można tą samą czynność wykonać z wykorzystaniem Snorta, używając opcji -r, po czym przetworzyć sczytane pakiety dostępnymi trybami. Snort czytając swoje dzienniki (tak samo działając w trybie sniffera) przyjmuje parametry w formacie BPF (Berkeley Packet Filter), dzięki którym możemy sprecyzować (na podstawie nagłówków), jakie konkretnie pakiety chcemy obserwować (np. określić adres hosta, protokół, port). Jeśli np. interesuje nas tylko ruch na porcie 80 można uruchomić Snorta poleceniem: snort -r /var/log/snort/snort.log port www, jeśli chcemy wyświetlić tylko odpowiedzi serwera www: snort -vde src port www. Aby ignorować 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łączenie Snorta z filtrami BPF znacznie zwiększa wydajność całego systemu, gdyż filtrowanie BPF odbywa się w warstwie łącza danych (a więc na poziomie biblioteki pcap). Określając w ten sposób, jakie pakiety nas interesują (lub jakie chcemy zignorować) można dość dokładnie "zawęzić" obszar poszukiwań. Filtry BPF można również zapisać w oddzielnym pliku i załadować w trakcie uruchamiania Snorta parametrem -F: snort -r snort.log -F plik_z_bdf. Więcej na temat możliwości oferowanych przez BPF można poczytać na stronach podręcznika zarówno Snorta, jak i Tcpdump.

  • Network Intrusion Detection Mode - sieciowy system wykrywania włamań. Jest najbardziej skomplikowanym trybem działania programu. Za pomocą parametru -c, wskazujemy plik konfiguracyjny, w którym określane są zasady badania przechwyconego ruchu sieciowego, ustawienia preprocesorów, a także zestaw sygnatur ataków. Aby program działał w tle jako demon, należy użyć opcji -D (np. snort -d -D -c snort.conf). Reszta operatorów i ich opisy, jakie można wykorzystać przy starcie programu, przedstawia parametr -h.

Preprocesory

Preprocesory zostały wprowadzone do Snorta w wersji 1.5. Pozwalają użytkownikom i programistom w prosty sposób na rozbudowę funkcjonalności całego systemu poprzez pisanie dodatkowych modułów (ang. plugins).

Preprocesory analizują pakiety przed wykorzystaniem ich przez silnik detekcji. W ten sposób zwiększają możliwości całego procesu wykrywania ataków sieciowych, wzbogacając go o zdolność składania (reasemblacji) pakietów, wykonywania specyficznych dla poszczególnych protokołów operacji (np. konwersja na ASCII znaków z URI zakodowanych szesnastkowo, usuwanie ciągów binarnych z sesji FTP czy Telnet, normalizacja żądań RPC), jak i wykrywania niezgodności z tymi protokołami.

Poniżej pokrótce opiszemy standardowy zestaw preprocesorów wchodzących w skład darmowej dystrybucji Snorta w wersji 2.1.3.

  • Frag2 - defragmentuje i normalizuje dane przychodzące w postaci fragmentów, co utrudnia ukrywanie ataków prowadzonych za pomocą nieprawidłowo sfragmentowanych pakietów IP. W tym celu wykorzystuje ustalony przez użytkownika bufor pamięci, w której przez określony czas przetrzymuje do badania pakiety z tablicy stanów połączeń. Im większa liczba sfragmentowanych pakietów tym wymagany jest większy bufor. Defragmentacja, układając datagramy IP w jedną całość, ułatwia dalszą analizę danych poprzez pozostałe preprocesory i silnik detekcji. Frag2 umożliwia wychwytywanie znanych ataków wykorzystujących zniekształcenia fragmentów pakietów np. teardrop, fragroute.

  • Stream4 - rozwija model detekcji oparty na testowaniu pojedynczych pakietów umożliwiając śledzenie sesji (stanu połączenia) TCP i składanie (reasemblacji) strumieni TCP, co nie byłoby możliwe w mechanizmie opartym na wyszukiwaniu wzorców. Na tym poziomie działa także wykrywanie niektórych prób skanowania portów, gdzie wymagane jest notowanie prób łączenia się z poszczególnymi usługami w określonych odstępach czasu oraz wykrywanie prób oszukania Snorta za pomocą narzędzi takich, jak np. Stick lub Snot, które generują pojedyncze (niewchodzące w skład poprawnych sesji TCP) pakiety mające za zadanie zalać mechanizm detekcji masą fałszywych alarmów (są to pakiety budowane na losowo wybranych sygnaturach). Snort broni się przed takimi technikami wykorzystując stream4 preprocesor - losowe pakiety są dość łatwo identyfikowane (i ignorowane), ponieważ nie należą do prawidłowej sesji TCP. Stream4 wychwytuje próby skanowania technikami: stealth, null, xmas, fin; wykrywanie systemu operacyjnego - fingerprint i inne anomalia związane z protokołem TCP.

  • Flow i Flow-Portscan - posiada mechanizm śledzenia połączeń, zapisując całość do tablicy stanów w celu dalszego przetwarzania. Na tej podstawie flow-portscan wykrywa próby skanowania w bardziej wyrafinowany sposób niż preprocesory stream4 i portscan. Celem wykrywania, są skany z jednego hosta do wielu i z jednego hosta na wiele portów. Flow-portscan prowadzi statystyki na podstawie punktacji różnych rodzajów połączeń, np. jeśli jakaś usługa jest popularna i na jej port przychodzi dużo zapytań, jednocześnie dostaje najmniej punktów w ogólnej skali. Preprocesor posiada bardzo wiele opcji za pomocą, których reguluje się skale punktacji, rozmiary tablicy wyników, tolerancję niepowtarzalności zdarzeń itp.

  • HTTP Inspect - jest ogólnym dekoderem protokołu HTTP na poziomie warstwy aplikacyjnej. Za pomocą ustalonego bufora wynajduje odpowiednią składnie HTTP i ją normalizuje. HTTP Inspekt działa w obydwu trybach jednocześnie: client requests (pol. zapytania klienta) i server responses (pol. odpowiedzi serwera). Mnoga liczba dostępnych opcji w konfiguracji preprocesora, umożliwia dostosowanie ustawień do konkretnego typu serwera WWW. Głównymi zadaniami http_inspect jest przetwarzanie adresów URI, konwertując na ASCII znaki zakodowane w postaci szesnastkowej. Utrudnia to ukrycie ataku przed modułem wykrywającym sygnatury ataków przez zakodowanie typowych sekwencji. Dekoduje takż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, polegające na przekroczeniu pewnej progowej liczby prób połączeń z różnymi portami w określonym przedziale czasu. Ze względu na brak możliwości uniknięcia fałszywych alarmów w typowych przypadkach (np. obciążony serwer DNS), istnieje możliwość wyłączenia alarmów wzbudzanych przez określone adresy IP używając dodatkowego procesora portscan-ignorehosts. Pozwala także, zapisać wyniki w oddzielnym pliku dziennika.

  • Telnet Decode - usuwa z sesji TELNET i FTP binarne ciągi mogące utrudnić wyszukiwanie z udziałem sygnatur ataków.

  • RPC Decode - normalizuje żądania po protokole RPC, utrudniając ukrywanie podejrzanych pakietów za pomocą mniejszych operacji.

  • Back Orifice detektor - wyszukuje w pakietach UDP próby połączeń konia trojańskiego Back Orifice i próbuje złamać zabezpieczające je słabe kodowanie.

  • Arpspoof - wykrywa podejrzane pakiety ARP, mogące sygnalizować próby ARP spoofingu.

  • Performance Monitor - udostępnia wszelkiego rodzaju statystyki liczbowe, odnośnie ilości przeanalizowanych pakietów, zużycia procesora itp. Całość wyświetlana jest na ekranie konsoli lub zapisywana do pliku, wg ustalonych wcześniej wartości.

Zarówno preprocesory, jak i mechanizm detekcji mogą zareagować w określony sposób. Po wychwyceniu pakietów, spełniających warunki nadane konfiguracją preprocesorów lub regułami, podejmowane jest odpowiednie działanie (np. zapisanie pakietów bądź alarm).

Moduł sygnatur

Główny mechanizm systemu detekcji zagrożeń polega na dopasowaniu przetworzonych pakietów i ich zrekonstruowanych strumieni z bazą sygnatur. System detekcji porównuje cechy pakietu ze zbiorem reguł. Po dopasowaniu, zostaje podjęta odpowiednia akcja. Do porównywalnych cech należą atrybuty główne - adresy, porty źródłowe i docelowe oraz opcje pomocnicze: flagi TCP identyfikujące np. żądania związane z WWW, różne typy pakietów ICMP, opcje IP czy wreszcie sama treść pakietu. Na razie w głównej części reguł możliwe jest śledzenie protokołów IP, ICMP, TCP i UDP. Autorzy przewidują rozszerzenie Snorta o następne protokoły sieciowe, m.in. IPX, GRE, czy protokoły wymiany informacji między routerami - RIP, OSPF oraz IGRP.

Reguły identyfikowania ataku pozwalają na podjęcie pięciu rodzajów akcji: przepuszczenia pakietu (pass), zapisania informacji do dziennika (log), ogłoszenia alarmu (alert), alarmowania i podjęcia do działania innej dynamicznej reguły (activate) i pozostanie w spoczynku do czasu aktywowania przez regułę activate, po czym działanie jako reguła log (dynamic).

Sygnatury Snorta zazwyczaj składają się z dwóch głównych sekcji - nagłówka i ciała (treści). Nagłówek określa m.in., jaką akcję należy podjąć po przypasowaniu reguły, informacje o wykorzystanym protokole, adresy bądź porty źródłowe i docelowe. Ciało reguły pozwala rozwinąć informacje zawarte w nagłówku, tu także podaje sią treść wzbudzanych alarmów i różnego rodzaju informacje dodatkowe (np. odniesienia do bazy z opisami danego naruszenia, tzw. referencje - Bugtraq, CERT czy CVE).

Najprostsze sygnatury obejmują wskazanie akcji, protokołu, kierunku, adresów i portów będących przedmiotem obserwacji, jak np. poniższa reguła, stanowiąca reakcję na próbę skorzystania z usługi pop3 (port 110):

log tcp any any -> 192.168.1.0/24 110

W sygnaturach można umieszczać zmienne zdefiniowane jako adresy sieci (wg CIDR) lub porty zapisane w pliku konfiguracyjnym snort.conf:

log tcp $EXTERNAL_NET -> $HOME_NET 110

W podanych powyżej regułach wykorzystany był jednokierunkowy operator "->". Język sygnatur umożliwia zadeklarowanie reguły, który dopasuje pakiety poruszające się w obu stronach operatorem dwukierunkowym "<>", np.:

alert tcp any any <> $HOME_NET 23

Do zasadniczej części reguły można dodać ograniczone okrągłymi nawiasami pole opcjonalne (tzw. ciało), zawierające definicję bardziej złożonych i wyrafinowanych działań związanych z przejęciem danego pakietu. Użytkownik może także sformułować własny komunikat, np.:

log tcp $EXTERNAL_NET -> $HOME_NET 110 \
    ("msg: Proba polaczenia z pop3";)

Podjęte działania nie muszą być ograniczone do pojedynczej czynności. Średnik separuje deklaracje poszczególnych działań, jak w poniższym przykładzie, w którym opcją content testowana jest treść przesyłanego strumienia TCP, a w razie odnotowania podejrzanego ciągu 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 można użyć nawet kilka razy w jednej regule. Pozwala to na wyszukiwanie wielu różnych ciągów znaków w obrębie przesyłanych treści.

Warto nadmienić, iż do przeszukania treści pakietów i reasemblowanych strumieni używany jest obecnie najbardziej efektywny algorytm - Boyera-Moore'a, którego wydajność rośnie wraz z długością poszukiwanych ciągów. Możliwość rekonstrukcji całych strumieni transmisji TCP, wglądu w warstwę aplikacyjną i efektywne wyszukiwanie treści pozwala na walkę przy użyciu Snorta również z zainfekowanymi załącznikami elektronicznych listów. Oprócz przeszukiwania treści pakietów możemy badać pod różnymi kątami ich nagłówki, m.in. pola i kody ICMP, pole TTL, rozmiary fragmentacji czy numery sekwencji.

Bardzo silną konstrukcją w regułach Snorta jest możliwość aktywowania kolejnych reguł po pierwszym dopasowaniu. Konstrukcja ta nosi nazwę activate/dynamic rules i wygląda w następujący 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 wiążą reguły activate i dynamic. W powyższym przykładzie wykrycie ataku typu buffer overflow na serwer IMAP powoduje uruchomienie kolejnej, dynamicznej reguły, która zbiera treść następnych 50 pakietów (opcja count) w celu późniejszej analizy. Druga opcja w reguły dynamicznej jest obligatoryjna - reguła zawierająca wyłącznie opcję dowiązania do innej, macierzystej konstrukcji jest bezużyteczna.

Następne godne uwagi parametry, to resp i react wspierają mechanizm elastycznego reagowania na atak. Opcja resp może doprowadzić do zerwania połączenia, np. poprzez wysłanie do atakującego komunikatu ICMP o niedostępności trasy do zaatakowanego komputera, natomiast react służy do blokowania dostępu do usług związanych z WWW.

Ciekawe projekty

  • Nessus - sieciowy tester bezpieczeństwa, przydatny do określania skuteczności skonfigurowanego przez nas Snorta.

  • SnortALog - skrypt Perlowy pozwalający na generowanie różnego rodzaju raportów, grafów i statystyk. Korzystając z logów Snorta, format wygenerowanych raportów może stanowić plik tekstowy, HTML, a nawet PDF.

  • Snort Inline - poprawka dla Snorta, umożliwiająca współprace z regułami firewalla IPtables, stosowanego w systemach opartych na jądrze Linux. Specjalnie sformułowane sygnatury Snorta, reagują na atak i blokują bądź przekierowują za pomocą ściany ogniowej drogę pakietów pochodzących od intruza.

  • SnortSam - jest to zestaw pluginów do Snorta pełniących podobną funkcje jak Snort Inline, ale wspomagająca większą liczbę róż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).

  • FLoP - projekt ma na celu, przyspieszenie logowania w procesie wykrywania włamań. Do tego wykorzystuje odpowiednie bufory i możliwość szybkiego zapisu przez gniazdo unixowe do baz danych MySQL i PostgreSQL. Bardzo przydatne narzędzie przy pracy w sieciach o dużej przepustowości.

Syslog-ng

Wstęp

W PLD™ domyślnie instalowanym systemem magazynowania zdarzeń systemowych (logów) jest syslog-ng™ (syslog - new generation), zajął on miejsce klasycznego tandemu syslogd™ i kalogd™. Jest to program o bogatych opcjach konfiguracji, zapewniający większą pewność działania, a co za tym idzie większe bezpieczeństwo logów.

Większe bezpieczeństwo zapewnia możliwość użycia protokołu TCP w komunikacji z tzw. loghostem, aby jednak korzystać z dobrodziejstw tego protokołu na obu maszynach musi być użyty demon "nowej generacji". Możliwa jest także komunikacja z klasycznym syslogiem, w tym wypadku musimy użyć protokołu UDP i portu 514 (wartość domyś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ępnie połączenie ich ze sobą w reguły. Mamy trzy rodzaje obiektów: źródła, filtry i cele. Źródła wskazują miejsca pochodzenia komunikatów, filtry pozwalają selekcjonować dane, cele zaś wskazują sposób i miejsce magazynowania logów (zwyczajowo jako pliki tekstowe w katalogu /var/log). Całą konfigurację umieszczamy w jednym pliku: /etc/syslog-ng/syslog-ng.conf.

  • Źródła - definiujemy je następująco:

    source $nazwa { $źródło($opcje); };

    najpopularniejsze ź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  src  { internal(); };
    source  udp  { udp(); };
    source  tcp  { tcp(ip(192.168.1.5) port(1999) max-connections(20)); };

    Pierwszy z przykładów jest źródłem komunikatów syslog-a. Drugi tworzy źródło komunikatów wysyłanych z dowolnej maszyny w sieci - nasłuch na domyślnym porcie (514 UDP). Trzeci oczekuje komunikatów od komputera 192.168.1.5 na porcie 1999 z ograniczeniem do 20 połączeń.

  • Filtry:

    filter $nazwa { $rodzaj($wartość); };

    rodzaje:

    • 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 użyciem wyrażeń regularnych

    • program - filtrowane po nazwie programu z użyciem wyrażeń regularnych

    przykłady:

    filter f_emergency { level(emerg); };
    filter f_daemon    { facility(daemon); };
    filter f_foo       { host("foo"); };
    filter f_su_sudo   { program("^su|sudo$"); };

    Pierwszy przykładowy filtr przepuszcza jedynie powiadomienia o najpoważniejszych błędach. Drugi zdarzenia pochodzące od demonów, trzeci wybiera zdarzenia pochodzące od komputera mającego w nazwie ciąg "foo". Ostatni odfiltrowuje zdarzenia wywoływane w skutek działania programów su i sudo - użycie wyrażeń regularnych.

    W filtrach możemy używać operatorów logicznych (and, or, not):

    filter f_syslog  { not facility(authpriv, cron, lpr, mail, news); };
    filter f_ppp     { facility(daemon) and program(pppd) or program(chat); };

  • Cele - ogólna definicja:

    destination $nazwa { $cel($miejsce); };

    najpopularniejsze cele:

    • file - plik tekstowy / urządzenie znakowe (/dev/)

    • usertty - ekran terminala wskazanego użytkownika

    • tcp - komunikaty do loghosta (TCP)

    • udp - komunikaty do loghosta (UDP)

    przykłady:

    destination  kernel       { file("/var/log/kernel"); };		
    destination  console_all  { file("/dev/tty12"); };		
    destination  root         { usertty("root"); };			
    destination  loghost      { udp("10.0.0.1"); };

    W pierwszym przykładnie komunikaty są kierowane do pliku /var/log/kernel, w drugim będą wyświetlane na dwunastym wirtualnym terminalu. Trzeci cel spowoduje wyświetlanie komunikatu na ekranie terminala użytkownika root. Czwarty obiekt pozwoli na wysyłanie komunikatów do loghosta o adresie IP 10.0.0.1 (uwaga na zgodność protokołów TCP/UDP u nadawcy i odbiorcy).

  • Regułki - budujemy je na samym końcu, kiedy mamy już zdefiniowane źródła, filtry i cele:

    log { source($źródło); destination($cel); };

    log { source($źródło); filter($filtr1); filter($filtr2); destination($cel); };

    np.:

    log { source(src);  destination(console_all); };
    log { source(src);  filter(f_emergency);  destination(loghost); };

Aby zmiany weszły w życie oraz utworzone zostały nowe pliki dzienników, należy ponownie uruchomić demona:

# service syslog-ng reload

Test konfiguracji

Najlepszą metodą sprawdzenia konfiguracji sysloga jest wysłanie własnych komuników systemowych. Posłużymy się w tym celu programem logger, pozwalającym wysyłać dowolne komunikaty z wiersza poleceń. Dla naszych potrzeb wywołujemy program następująco:

logger -p {$źródło}.{$poziom} {$komunikat} np.:

# logger -p mail.warning Test ostrzeżenia

Uwagi

  • Podobnie jak poprzednik nie kontroluje objętości logów, tak więc nie można zapomnieć o programie rotującym np. logrotate™.

  • Domyślnie demon nie nasłuchuje komunikatów z sieci, definicja źródła za to odpowiedzialna jest wykomentowana.

  • W ramach ochrony przed atakami DoS syslog-ng obsługuje domyślnie do 10 połączeń sieciowych, aby to zmienić należy użyć parametru "max-connections" w opcjach źródła (patrz przykłady).

Dodatek

System operacyjny posiada wewnętrzny, niezależny od demona logów, schemat klasyfikowania zdarzeń, dzielą się one na dwie grupy:

Pochodzenie komunikatów (facility):

Tabela 16.2.

NazwaOpis
userróżnorodne programy zwykłych użytkowników
mailkomunikaty podsystemu poczty elektronicznej
daemonróżne demony systemowe
auth, authprivbezpieczeństwo (autoryzacja użytkowników)
syslogsyslog
lprdrukarka
newssystem grup dyskusyjnych (Usenet)
uucppodsystem UUCP
crondemony zegarowe: AT, CRON
ftpserwer FTP
local0 - local7uniwersalne źródła lokalne, możliwe do dowolnego zastosowania przez administratora

Priorytety (level):

Tabela 16.3.

NazwaOpis
emergsystem już nie nadaje się do użytku
alertpoważna awaria - należy podjąć natychmiastową akcję
critzdarzenie krytyczne
errbłędy
warningostrzeżenia
noticeważne zdarzenia
infoinformacje
debugdodatkowe informacje - przydatne przy odpluskwianiu

Rozdział 17. X-Window

Rozdział opisuje konfigurację środowiska graficznego.

Wstęp

W rozdziale tym postaramy pomóc w stworzeniu systemu "biurkowego", czyli systemu z X-Window. Będziemy tu opisywać implementację X.Org™, więcej na jej temat można znaleźć na witrynie projektu http://www.x.org/wiki/. Sam proces tworzenia desktopu możemy podzielić na dwa etapy:

  • Instalacja i konfiguracja serwera protokołu X11

  • Instalacja i konfiguracja menedżera okienek dla X.org (przedstawimy tutaj KDE™ i GNOME™)

Od razu należy przestrzec, że środowisko graficzne jest obsługiwane przez skończoną liczbę urządzeń (dotyczy to zwłaszcza kart graficznych) i może się niestety zdarzyć, że posiadamy kartę graficzną, która nie jest obsługiwana. Dotyczy to głównie najnowszego sprzętu, starsze modele mają dosyć dobre wsparcie.

W przypadku kart firm firm ATI i NVIDIA, mamy dostępne zarówno sterowniki będące częścią X.Org jak i sterowniki zamknięte, tworzone przez samych producentów. Nielicznymi zaletami tych drugich jest bardzo dobra wydajność i pełne wsparcie dla akceleracji grafiki trójwymiarowej.

X-Server

Instalacja

Na początku, korzystając z programu poldek™ instalujemy konieczne pakiety. W przypadku Ac™ będą 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ę nazwy pakietów i są 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 powinniśmy zainstalować sterownik karty graficznej, możemy zainstalować wszystkie dostępne (jeśli nie mamy pewności) lub ten właściwy. W ustaleniu, który sterownik będzie najbardziej odpowiedni pomoże nam zestawienie w dokumentacji X.Org. Nazwy pakietów ze sterownikami zaczynają 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

Jeśli mamy kartę ATI to wybieramy pakiet:

$ poldek -i xorg-driver-video-ati

Sterownikami z pełną obsługą 3D będziemy mogli się zająć później. Jeśli ciągle nie wiemy jaki wybrać, to możemy zainstalować uniwersalny sterownik dla kart zgodnych z VESA:

$ poldek -i xorg-driver-video-vesa

W Ac ten sterownik znajduje się w pakiecie X11-modules

Zanim zaczniemy konfigurację

Użytkownicy myszek PS/2 lub USB, którzy nie korzystają z dobrodziejstw udeva™ muszą załadować oprócz modułu huba USB moduły:

# modprobe psmouse
# modprobe usbhid

Aby moduły ładowały się za każdym razem, gdy uruchamiamy system, należy dodać ich nazwy do pliku /etc/modules. Więcej o zarządzaniu modułami w „Statyczne zarządzanie modułami”.

Pierwsze uruchomienie

X.Org™ nie wymaga pliku konfiguracji do podstawowego działania, po uruchomieniu automatycznie próbuje wykryć dołączony sprzęt. X-Serwer uruchamiamy następująco:

# X

Jeśli naszym oczom ukaże się drobna, szara kratka z kursorem myszy w kształcie krzyżyka (którym możemy poruszać), to oznacza, że aplikacja działa: wykryła sprzęt i załadowała prawidłowe sterowniki. Oznacza to też, że zainstalowaliśmy wszystkie potrzebne komponenty do działania serwera. Aby wyjść z tego dosyć surowego środowiska korzystamy ze skrótu Ctrl+Alt+Backspace

Teraz możemy przejść do konfiguracji X-Servera lub do uruchomienia środowiska graficznego. Warto przeprowadzić przynajmniej podstawową konfigurację, by uzyskać większą ergonomię pracy, ustawić układ klawiatury dla danego języka, czy obsłużyć dodatkowe możliwości sprzętu.

Konfiguracja

Generujemy wstępną konfigurację serwera X11:

# X -configure

W wyniku działania w/w polecenia w katalogu domowym użytkownika (w tym wypadku /root/) powstanie plik xorg.conf.new. X-Server stara się rozpoznać używany przez nas sprzęt i ustawia właściwe parametry w pliku konfiguracji.

Przenosimy plik we właściwe miejsce:

# mv ~/xorg.conf.new /etc/X11/xorg.conf

Teraz możemy spróbować, czy serwer nam się uruchamia:

# X

dokładnie jak to wcześniej opisaliśmy.

W ten oto sposób mamy wstępnie skonfigurowany X-Server i możemy rozpocząć pracę w środowisku graficznym. Wskazówki bardziej wyrafinowanej konfiguracji odnajdziemy w „Zaawansowane”. Część z nich będziemy mogli dokonać za pomocą poniżej opisanych programów (np. xorgcfg -textmode), bardziej zaawansowane opcje ustawimy wyłącznie edytując plik konfiguracji.

Inne sposoby konfiguracji

Z aplikacją dostarczane są dodatkowo dwa programy do konfiguracji, obydwie można użyć do generowania pliku konfiguracji zamiast operacji X -configure, pozwalają na precyzyjnie ustawianie parametrów X-Servera X -configure, jednak wymagają też więcej wiedzy i pracy.

  • xorgcfg - program który może działać w dwóch trybach: graficznym i tekstowym (z użyciem parametru -textmode). Program ma tą zaletę, że może modyfikować istniejący plik konfiguracji. O ile wygodę trybu graficznego można uznać za dyskusyjną, o tyle tryb tekstowy nie powinien sprawiać nikomu problemów.

  • xorgconfig - jest to konsolowe narzędzie, które prowadzi krok po kroku przez kolejne etapy konfiguracji. W zasadzie to przydaje się do generowania pliku konfiguracji po raz pierwszy (zamiast X -configure), jeśli chce się dokonać jakiejkolwiek zmiany trzeba przechodzić przez wszystkie kroki na nowo. Program ten dodatkowo dodaje do pliku liczne komentarze, co nie wszystkim odpowiada.

Rozwiązywanie problemów

Jeżeli pojawi się jakiś problem musimy przeanalizować komunikaty wypisywane na ekran i do pliku /var/log/Xorg.0.log. Błędy są oznaczane dwoma literkami EE np.:

(EE) Failed to load module "ati" (module does not exist, 0)

Powyższy komunikat informuje o brakującym sterowniku do karty graficznej, najprawdopodobniej nie jest zainstalowany konieczny pakiet.

Środowisko graficzne (GUI)

Do wyboru mamy dwa potężne, zintegrowane środowiska: KDE™ i Gnome™, nieco mniejsze XFCE4™, czy całkiem proste np. : blackbox™, fluxbox™ będące jedynie zarządcami okien i pulpitu. środowiska opisaliśmy w dalszych rozdziałach. Oprócz środowiska musimy wybrać sposób jego uruchamiania. Możemy uruchamiać je z wiersza poleceń za pomocą skryptu startx lub demonów GDM™/KDM™. Zagadnienia te szczegółowo omówiliśmy w „Uruchamianie środowiska graficznego”.

Zaawansowane

W tym miejscu zajmiemy się bardziej zaawansowaną konfiguracją X-Servera. Zakładam, że istnieje wstępnie skonfigurowany plik /etc/X11/xorg.conf, za pomocą polecenia X -configure. Wiele opisanych tu czynności konfiguracyjnych dla konkretnych podsystemów, wykonujemy za pomocą programu xorgcfg, uruchamiamy go w trybie tekstowym :

# xorgcfg -textmode

Po uruchomieniu zobaczymy listę dostępnych kategorii, odpowiadają one dalszym opisom. Przykładowo, aby skonfigurować myszkę, wybieramy z listy opcję: Configure mouse a następnie Edit Mouse0 itd. Po ustawieniu wszystkich interesujących nas opcji, wybieramy Write xorg.conf and quit

Bardziej zaawansowane będą wymagały ingerencji za pomocą edytora tekstu, przypominam, że "obrabiamy" plik # /etc/X11/xorg.conf.

Mysz

Zakładam, że w programie wybraliśmy sekcję konfiguracji myszki. Dla współczesnych myszek, w konfiguracji protokołu wybieramy Auto, dla myszek szeregowych wybierzemy Microsoft. Następnie konfigurator spyta o to, czy dla myszek dwuprzyciskowych włączyć emulację trzeciego klawisza, w przypadku myszek o większej ilości przycisków odpowiadamy negatywnie. Jako urządzenie wybieramy /dev/input/mice. Po zapisaniu wybranej konfiguracji, otrzymamy w sekcji ustawień myszy w pliku /etc/X11/xorg.conf fragment o zbliżonej konstrukcji:

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "Auto"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5 6 7"
EndSection

Jeśli posiadamy myszkę z wieloma klawiszami i rolkami, a standardowy sterownik nie radzi sobie z obsługą wszystkich zdarzeń, to możemy wybrać bardziej nowoczesny i elegancki sposób na uruchomienie naszego sprzętu - evdev. Przykładowa instalacja i konfiguracja zostanie przedstawiona dla popularnej myszki Logitech MX500. Pierwszym krokiem jest załadowanie modułu jądra modprobe evdev oraz instalacja pakietu xorg-driver-input-evdev (X11-driver-evdev dla Ac). Następnie odszukujemy w /proc/bus/input/devices numer urządzenia eventX naszej myszki i wpisujemy do konfiga X.Org™ poniższą sekcję:

Section "InputDevice"
    Identifier "Mouse1"
    Driver     "evdev"
    Option     "Device"   "/dev/input/event1"
    Option     "Buttons"  "10"
EndSection

Klawiatura

Nowo wygenerowany plik konfiguracji nie zawiera opcji lokalnych, aby je ustawić, z menu programu wybieramy Configure keyboard, Jako model (Keyboard model) wybieramy np. Generic 104-key PC, a w Keyboard layout ustawiamy Poland. Powyższa operacja wygeneruje następującą konfigurację klawiatury:

Section "InputDevice"
        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, należy go zmienić na kbd, jak na powyższym fragmencie. Możemy to wykonać za pomocą dowolnego edytora tekstu.

Jeśli posiadamy klawiaturę multimedialną i chcemy wykorzystywać jej dodatkowe klawisze, to musimy wybrać odpowiedni model klawiatury. Nasz wybór będzie dotyczył wartości parametru XkbModel, następnie musimy sprawdzić za pomocą programu xev czy wszystkie zdarzenia z klawiszy multimedialnych są prawidłowo obsługiwane przez X-serwer.

Monitor

Właściciele monitorów LCD/Plasma są na uprzywilejowanej pozycji, jeśli sterownik karty graficznej potrafi "porozumieć się" z monitorem (za pomocą DDC), to nie są wymagane żadne czynności konfiguracyjne. Aby detekcja następowała automatycznie musimy w pliku konfiguracji postawić znak komentarza ("#") przed opcjami HorizSync, VertRefresh.

W pozostałych przypadkach musimy określić parametry monitora. Wybierając opcje programu Configure monitor, będziemy będziemy mogli wybrać jakiś monitor z listy lub podać parametru własnego urządzenia: Enter your own horizontal sync range. Tu podajemy wartości HorizSync (w kHz) i VertRefresh w (Hz) zgodne ze specyfikacją naszego urządzenia. Po zapisaniu pliku konfiguracji otrzymamy:

Section "Monitor"
        Identifier  "Monitor0"
        HorizSync   31.5 - 96.0
        VertRefresh 50 - 100
        Option "DPMS"
EndSection

O ile HorizSync jest opcją ściśle zależną od możliwości monitora i pod żadnym pozorem nie powinniśmy jej dowolnie zmieniać, o tyle VertRefresh daje więcej swobody. Za jej pomocą ustawiamy odświeżanie obrazu, Nie możemy oczywiście przekroczyć parametrów monitora, ale możemy ustawić minimalne odświeżanie, np. 85 - 85 wymusi częstotliwość 85Hz. (oczywiście pod warunkiem, że nasz monitor, przy danej rozdzielczości pozwala na wyświetlanie z taką wartością).

Rozdzielczość obrazu

Wstępnie plik konfiguracji nie zawiera żadnych definicji rozdzielczości i będzie ona ustalana automatycznie, co jest wskazane przy monitorach LCD/Plasma. W przypadku monitorów CRT, zapewne będziemy chcieli użyć najbardziej ergonomicznej. Mamy tu dwa wyjścia, możemy nic nie ustawiać w X.Org, ale za to ustawić ją w aplikacjach konfiguracyjnych środowisk Gnome/KDE, lub ustawić ją na stałe w konfiguracji X-serwera. Możliwości ustawień konfiguratorów w środowiskach graficznych są dosyć skromne, dlatego niektórzy pokuszą się zapewne o ustawienie odpowiednich wartości na stałe.

Po wybraniu Configure screen w programie, zostaniemy zapytani o ilość dostępnych kolorów, dla współczesnego sprzętu bez zastanowienia możemy wybrać 24bity na piksel a następnie wybieramy listę rozdzielczości, które mają być dostępne. W większości wypadków wystarczy nam jedna rozdzielczość. Oczywiście musi być obsługiwana przez monitor. Zapisana konfiguracja może wyglądać następująco:

Section "Screen"                                                                                                              
        Identifier "Screen0"                                                                                                  
        Device     "Card0"                                                                                                    
        Monitor    "Monitor0"                                                                                                 
        SubSection "Display"                                                                                                  
                Viewport   0 0                                                                                                
                Depth     24                                                                                                  
		Modes "1024x768"
        EndSubSection                                                                                                         
EndSection

Zaawansowane - DPI

X.Org pozwala na wskazanie DPI (dots per inch), w celu lepszego dopasowania wielkości wyświetlanych czcionek ekranowych. W przypadku współczesnych monitorów, za pomocą DDC odczytywany jest rozmiar obszaru wyświetlania, by automatycznie określić DPI. Dla monitorów, które nie posiadają takiej możliwości lub podają ją nieprawidłowo, będziemy mogli sami ten parametr ustawić. Wartość DPI można też ustawić bezpośrednio w konfiguracji środowiska (np. w Gnome) my jednak pokażemy jak zrobić do w X-serwerze. W sekcji Monitor pliku konfiguracji należy dodać opcję:

DisplaySize $x $y

gdzie parametry $x i $y są wymiarami w milimetrach, odczytanymi z dokumentacji urządzenia lub po prostu zmierzonymi linijką. Sekcja konfiguracji monitora może wyglądać następująco:

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łożymy także, że będziemy korzystać z serwera czcionek X11-xfs™, który uruchamiamy poleceniem /etc/init.d/xfs start. Dlatego też sekcja dotycząca czcionek w pliku xorg.conf.new powinna wyglądać podobnie do podanego niż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 bezpośrednie do czcionek i przekazujemy obsługę zarządzania czcionkami serwerowi xfs™.

Uwagi

Parametry monitora mogą być odczytywane za pomocą modułu DDC, o ile monitor jest włączony. Powinniśmy zatem włączać monitor przed uruchomieniem X-Servera lub ustawić "na sztywno" jego parametry, inaczej w skrajnym wypadku obraz będzie miał rozdzielczość 640x480, przy odświeżaniu 60Hz.

Środowisko GNOME

Instalacja

GNOME™ jest rozbudowanym środowiskiem, dodatkowo filozofia mikropakietów w PLD nie ułatwia jego instalacji początkującym. Aby temu zaradzić stworzone zostały metapakiety, które oszczędzą nam sporej ilości pracy, oto ich zestawienie:

  • metapackage-gnome™ - główna część środowiska

  • metapackage-gnome-extras™ - dodatki

  • metapackage-gnome-extras-accessibility™ - narzędzie ułatwień dostępu

  • metapackage-gnome-office™ - pakiet aplikacji biurowych

Na początku powinien nam wystarczyć podstawowy metapakiet:

poldek> install metapackage-gnome

Teraz wystarczy uzbroić się w cierpliwość, po instalacji wymagań metapakietu, możemy już samodzielnie doinstalować te kilka pakietów, albo od razu uruchomić środowisko. Filozofię metapakietów omówiliśmy w „Cechy pakietów w PLD”.

Jeśli jednak jesteśmy zwolennikami instalacji tylko tego co jest potrzebne, musimy instalować każ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 imponująca, aby łatwiej było się odnaleźć w tym gąszczu, zachęcamy do zapoznania się z zestawieniem aplikacji w dalszej części rozdziału.

Internacjonalizacja

Aby GNOME i GDM obsługiwały język inny niż angielski, należy ustawić tzw. Locale, co zostało opisane w „Internacjonalizacja”, a następnie wybrać preferowany język: Language z menu GDM-a.

Dźwięk

Zakładam, że już została skonfigurowana już ALSA, zgodnie ze wskazówkami opisanymi w „ALSA - Dźwięk w Linuksie”. Od GNOME 2.26 dźwięk jest obsługiwany przez aplikację pulseaudio, zapewniającą programowe miksowanie dźwięku z wielu źródeł, czy też przesyłanie strumienia za pośrednictwem sieci. Instalujemy:

$ poldek -i pulseaudio pulseaudio-gconf pulseaudio-alsa gstreamer gstreamer-audiosink-esd

instalujemy pakiety z pluginami dekodującymi formaty wav,au oraz mp3:

$ poldek -i  gstreamer-audio-formats gstreamer-mad

instalujemy gnome-media, aplet do sterowania głośnością, odtwarzacz Totem™ i opcjonalnie pakiet dźwięków zdarzeń:

$ poldek -i gnome-media gnome-applets-mixer totem gnome-audio

Uruchomienie

Zanim uruchomimy środowisko, musimy się upewnić, czy nazwa hosta (opcja HOSTNAME z pliku /etc/sysconfig/network) jest przypisana do adresu IP. Aby to ustawić, należy dodać odpowiedni wpis do pliku /etc/hosts, zgodnie ze wskazówkami zawartymi w „Podstawowa konfiguracja sieci”, np.:

127.0.0.1       pldmachine

Szczegóły uruchamiania środowiska opisaliśmy w „Uruchamianie środowiska graficznego”.

Administracja - GNOME System Tools

GST™ to zestaw wygodnych narzędzi administracyjnych, obsługujących PolicyKit. Pozwala na zarządzanie m.in. usługami, użytkownikami oraz siecią. Instalacja:

$ poldek -i gnome-system-tools system-tools-backends

Uruchamiamy demona system-tools-backends:

# /etc/init.d/system-tools-backends start

Dodajemy użytkownika do grupy adm:

# groupmod -A jkowalski adm

Aplikacje administracyjne będziemy mogli używać po ponownym zalogowaniu.

Przydatne drobiazgi

O wygodzie pracy w środowisku czasami decydują drobiazgi, oto lista takich niewielkich narzędzi, przydatnych w codziennej pracy:

  • gnome-volume-manager™ - narzędzie do zarządzania woluminami wymiennymi: montowaniem nośnikow, odtwarzaniem muzyki i innymi

  • gnome-utils-screenshot™ - program do szybkiego wykonywania zrzutów ekranu.

  • nautilus-cd-burner™ - rozszerzenie do nautilusa służące 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ęp do wielu appletów, tematów graficznych i innych.

Godne polecenia aplikacje

Zaletą złożonych środowisk takich jak GNOME czy KDE jest duża liczba programów, które dobrze integrują się ze środowiskiem, poniżej została zamieszczona lista użytecznych programów.

  • gnome-terminal™ - rozbudowany emulator terminala z obsługą zakładek

  • gcalctool™ - wielofunkcyjny kalkulator

  • totem™ - odtwarzacz audio i video.

  • Exaile™, Quod Libet™ i Rhythmbox™ - wygodne odtwarzacze audio z dobrą obsługą dużych bibliotek muzyki, wszystkie obsługują gstreamera.

  • eog™ - Eye of GNOME - narzędzie do przeglądania obrazków

  • evince™ - program służący do przeglądania dokumentów w formatach pdf, postscript i wielu innych.

  • gedit2™ - edytor tekstu z obsługą kolorowania składni języków programowania i wtyczek.

  • epiphany™ - przeglądarka WWW z silnikiem renderującym Gecko

  • evolution™ - rozbudowany klient poczty i narzędzie do planowania zadań

  • gajim™ - klient Jabbera

  • file-roller™ - zarządca archiwów - jest graficznym interfejsem dla własciwych narzędzi archiwizacji danych

  • Brasero™ (dawniej Bonfire) - komfortowe narzędzie do nagrywania płyt CD/DVD.

Więcej na stronie www.gnome.org/projects/, warto też odwiedzić stronę www.gnomefiles.org, będącej bogatym zestawieniem aplikacji bardziej lub mniej związanych ze środowiskiem.

Pomoc i rozwiązywanie problemów

GNOME jest dostarczane z pokaźną dokumentacją - niestety brak jest polskiego tłumaczenia. Jest dostępna dla aktywnego okna po wciśnięciu przycisku F1 lub po wywołaniu programu yelp™ - przeglądarki dokumentacji. Musimy tylko doinstalować konieczne pakiety:

$ poldek -i gnome-user-docs yelp

Jeśli natkniemy się na jakieś problemy z działaniem aplikacji, na początek powinniśmy zajrzeć do specjalnego dziennika błędów:

$ cat ~/.xsession-errors

Możemy też spróbować uruchomić daną aplikację w wirtualnym terminalu (np. w programie gnome-terminal), w celu odczytania komunikatów programu.

Środowisko KDE

Poniżej przedstawiamy listę 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 uruchomić KDE™ dla danego użytkownika, w jego katalogu domowym wykonujemy polecenie:

$ echo "kde" >.desktop

Od tej chwili, domyślnym środowiskiem graficznym dla tego użytkownika jest KDE™, które możemy uruchomić za pomocą polecenia startx.

Blackbox - Szybki i lekki zarządca okien

Wstęp

Blackbox™ jest lekkim menedżerem okien dla XFree86™. Jest napisany w C++, a jego projekt zakładał wydajność, niskie użycie pamięci oraz brak zależności od zewnętrznych bibliotek. Blackbox™ zabiera bardzo niewiele miejsca na ekranie na dekoracje okien. Mimo swojego minimalizmu, jest bardzo wygodny i funkcjonalny. Zawiera wszystko, czego oczekuje się od menedżera okien - obsługę wirtualnych pulpitów, okna typu sticky, zwijanie okien, okna pozbawione dekoracji. Posiada też pasek dokowania, zwany slitem, na którym mogą umieszczać się aplety w stylu NEXTstep™ (np. Window Maker, AfterStep) oraz okna w trybie withdrawn (np. gkrellm). Te cechy sprawiły, że Blackbox™ stał się całkiem popularny wśród osób nie lubiących przeładowania towarzyszącego środowiskom KDE™ i GNOME

Dzięki swoim zaletom Blackbox stał się na tyle znany, że wypączkowało z niego kilka odmian z nowymi cechami. Należą do nich Fluxbox™, Openbox™ i Kahakai™. Blackbox™ i jego pochodne są doskonałym wyborem, jeśli pożądane jest oszczędzanie pamięci i niskie wykorzystanie procesora. Są też dobre dla tych, którzy wolą elegancję ponad nadmiar elementów, jaki występuje w popularnych środowiskach. My w tym opisie zajmiemy się instalacją Blackbox™.

Instalacja pakietów

Czas zainstalować potrzebne nam pakiety.

# poldek -i blackbox vfmg xinitrc

Instalacja zajmuje bardzo mało czasu, ponieważ jak już wspomniane zostało wcześniej Blackbox™ jest bardzo mało wymagający jeżeli chodzi o zasoby.

Konfiguracja

Teraz aby Blackbox™ był naszym domyślnym menadżerem okien należy ustawić 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 już skonfigurowanego Blackbox™ i w zasadzie można by go już uruchomić ale my skonfigurujemy sobie menu, aby było zgodne z zainstalowanymi przez nas programami

W tym celu z pomocą przyjdzie nam program vfmg™, który już wcześniej zainstalowaliśmy. Komendy które są poniżej należy wykonywać w katalogu domowym ~/

# mkdir ~/.blackbox
# vfmg blackbox > .blackbox/menu

Mamy już gotowe menu, ale nie ma w nim opcji "Wyjście", która jest niewątpliwie przydatną opcją.

W ~/.blackbox/menu należy pod sam koniec dopisać "Wyjście" tak, aby 3 ostatnie linijki wyglądały następująco:

# tail -3 ~/.blackbox/menu
[end]
        [exit] (Wyjście)
[end]

Dodatkowo należy edytować plik ~/.blackboxrc i zmienić w nim linijkę session.menuFile na:

# grep menu .blackboxrc
session.menuFile:       .blackbox/menu

Mając już menu Blackbox możemy go wreszcie uruchomić:

# startx

Aby wszystko poprawnie funkcjonowało należy zapoznać się z działem "Konfiguracja środowiska graficznego", który znajduje się w dokumentacji PLD.

Fluxbox - Następca BlackBoxa

Wstęp

Młodszym bratem BlackBoxa™ jest Fluxbox™, bazujący na kodzie Blackboxa™. Fluxbox™ wygląda tak samo jak Blackbox™, który korzysta z tych samych styli, kolorów, położenia okien i generalnie jest zachowana pełna kompatybilność z Blackboxem™.

Jakie są więc różnice? Odpowiedź brzmi: DUŻE. Np:

  • Konfigurowalne taby okien

  • Pasek ikon (do zminimalizowanych okien)

  • Scroll myszki używany do zmiany obszarów roboczych.

  • Wsparcie dla KDE i GNOME, a także rozszerzone wsparcie dla WindowMakera.

  • i jeszcze wiele innych udogodnień.

Instalacja pakietów

Czas zainstalować potrzebne nam pakiety.

# poldek -i fluxbox fluxconf

Właściwie do pracy potrzebny nam jest tylko fluxbox, ale fluxconf trochę ułatwia konfiguracje.

Konfiguracja

Aby fluxbox™ był naszym domyślnym menadżerem okien w .Xclients dajemy wpis.

exec fluxbox

wygląd menu można zmieniać edytując plik ~/.fluxbox/menu

Przykładowy wpis:

[begin] (Fluxbox)
	[exec]    (aterm) {aterm -tr}
	[exec] (Run) {fbrun }
	[submenu] (Net)
        	[exec] (PSI) {psi}
	[end]
[end]

Możemy także automatycznie wygenerować menu korzystając z programu vfmg™. Instalujemy go poleceniem:

# poldek -i vfmg

Następnie wydajemy polecenia:

# mkdir ~/.fluxbox
# vfmg blackbox > ~/.fluxbox/menu

Mamy już gotowe menu, ale nie ma w nim opcji "Wyjście", która jest niewątpliwie przydatną opcją.

W ~/.fluxbox/menu należy pod sam koniec dopisać "Wyjście" tak, aby 3 ostatnie linijki wyglądały następująco:

# tail -3 ~/.blackbox/menu
[end]
        [exit] (Wyjście)
[end]

Chcąc dodać tło pulpitu możemy się posłużyć 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 ImageMagick-coder-tiff-5.5.7.12-2

następnie w pliki ~/.fluxbox/init odszukujemy wpis:

session.screen0.rootCommand: i dodajemy: display -size ROZDZIELCOZŚĆ -window root NAZWA_PLIKU_Z_GRAFIKA

u mnie wpis ten wygląda następująco:

session.screen0.rootCommand:    display -size 1024x768 \
    -window root  ~/DREAMVISIONS.jpg

I to by było właściwie już tyle, można już uruchomić naszego menagera okien poleceniem

# startx

Uruchamianie środowiska graficznego

Istnieją dwie metody uruchamiania środowiska, pierwszą jest uruchamianie systemu na trzecim poziomie pracy (domyślnie) i autoryzowaniu się w terminalu tekstowym. Po zalogowaniu uruchamiamy program startx. Drugą możliwością jest instalacja jednego ze specjalnych demonów: gdm™ (dla Gnome™) kdm™ (dla KDE™) lub xdm i dokonywanie autoryzacji za ich pośrednictwem. Demony te działają na piątym poziomie pracy, dlatego musimy skonfigurować system by domyślnie startował na tym poziomie. Estetyka i wygoda to nie jedyne zalety demonów, są one silnie zintegrowane ze swoimi środowiskami, dzięki czemu zapewniają wiele dodatkowych funkcji.

Skrypt startx

W tej metodzie po zalogowaniu się w terminalu, użytkownik wydaje polecenie startx. Na podstawie wpisu w pliku .xinitrc (w katalogu użytkownika) uruchamiane jest wskazane tam środowisko. Aby używać tej metody, musimy doinstalować 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 środowiska w pliku .xinitrc. Plik ten jest pełnoprawnym skryptem powłoki i obowiązuje w nim jej składnia, wpis w nim można wykonać następująco:

$ echo "gnome-session" >~/.xinitrc

lub

$ echo "exec gnome-session" >~/.xinitrc

Aby uruchomić środowisko wykonujemy polecenie:

$ startx

Poniżej przedstawilimy listę programów startowych dla wybranych środowisk:

  • Gnome: gnome-session

  • KDE: startkde

  • XFCE: startxfce4

  • fluxbox: fluxbox

  • icewm: icewm

Jedynie w wyjątkowych sytuacjach powinniśmy używać tej metody do uruchamiania środowisk takich Gnome czy KDE, dla nich najlepiej korzytstać z opisanych poniżej GDM lub KDM.

GDM

Zaczynamy od instalacji demona GDM:

poldek> install gdm gdm-init

i już możemy go uruchomić:

# service gdm start

Powinniśmy móc się teraz zalogować i uruchomić środowisko, jeśli wszystko działa prawidłowo to możemy ustawić by system uruchamiał się ma piątem poziomie pracy, zgodnie ze wskazówkami pod koniec rozdziału.

KDM

Instalujemy KDM

# poldek -i kdm

Dla lokalnej pracy nie trzeba nic specjalnie konfigurować, więc od razu możemy uruchomić demona poleceniem:

# /etc/init.d/kdm start

Pozostało nam jeszcze poinformować nasz system, że chcemy, aby nasz zarządca uruchamiał się po starcie systemu (na piątym poziomie).

Ustawienie poziomu pracy

W przypadku demonów GDM/KDM powinniśmy jeszcze skonfigurować system tak, by domyślnie uruchamiał się na piątym poziomie. pracy. Owe usługi uruchamiają się tylko na tym poziomie, poza tym jest to domyślny poziom dla aplikacji X-Window. Powinniśmy zmodyfikować plik /etc/inittab, zgodnie ze wskazówkami przedstawionymi w „Zmiana poziomu pracy systemu”. Wiersz z opcją initdefault powinien wyglądać następująco:

id:5:initdefault:

Aby sprawdzić poprawność operacji, możemy zrestartować system.

Porady

Należy za wszelką cenę unikać logowania się jako administrator (root), jeśli chcemy używać aplikacji wymagających wysokich uprawnień, powinniśmy je uruchamiać za pomocą programu sudo.

Karty firmy nVidia

Do zainstalowania kart graficznych firmy NVIDIA zalecamy wykorzystać firmowe sterowniki nvidia™. Z serwerem X11™ dostarczany jest sterownik nv jednak w stosunku do firmowych sterowników jest zdecydowanie wolniejszy, chociaż w przypadku wykorzystania rivafb™ jesteśmy zmuszeni do użycia otwartych sterowników nv™.

Aby wczytać sterowniki firmowe, należy za pomocą programu poldek™ zainstalować pakiety:

# X11-driver-nvidia kernel-video-nvidia

Następnie w wygenerowanym pliku konfiguracyjnym serwera X11 dokonujemy zmian w sekcji Device Card0:

Identifier  "Card0"
Driver      "nvidia"
VendorName  "nVidia Corporation"
BoardName   "NV5M64 [RIVA TNT2 Model 64/Model 64 Pro]"
BusID       "PCI:1:0:0"
Option      "HWCursor"      "on"
Option      "CursorShadow"  "on"
Option      "DPMS"          "on"
Option      "noDCC"         "on"
Option      "NoLogo"        "on"

Czyli praktycznie zamieniamy ciąg znaków w linijce Driver z nv na nvidia.

Teraz wracamy do serwera X11 i jego testowego uruchomienia. W przypadku problemów standardowo zaglądamy w logi.

Karty firmy ATI

Do zainstalowania kart graficznych firmy ATI zalecamy wykorzystać firmowe sterowniki firegl™. Z serwerem X11™ dostarczane są także otwarte sterowniki X11-driver-ati™ - jednak nie wykorzystują one wszystkich możliwości jakie dają sterowniki firegl™ i dopiero przy dużych problemach z nimi możemy jako awaryjne skonfigurować serwer X11 z otwartymi sterownikami ATI.

Instalacja i konfiguracja

Aby wczytać firegl™, należy za pomocą programu poldek™ zainstalować pakiety:

# X11-driver-firegl kernel-video-firegl

Następnie za pomocą programu fglrxconfig™ generujemy plik konfiguracyjny dla serwera X11. Oprócz pytań związanych z serwerem odpowiemy na szereg pytań dotyczących karty graficznej i monitora (możemy np. zdecydować o tym czy chcemy pracować w systemie jedno-monitorowym, czy też z monitorem i odbiornikiem TV).

Wygenerowany plik, tak jak przedstawiono to w rozdziale dotyczącym instalacji X11 należy z katalogu domowego użytkownika root do katalogu /etc/X11/ i dokonać ewentualnych korekt dotyczących myszy i obsługi czcionek

Aby karta graficzna została poprawnie zainicjowana musimy wczytać odpowiednie moduły kernela. Na początku musi to być moduł, który umożliwi nam prace karty z AGP - moduł ten jest zależny od posiadanej płyty głównej. Przykładowo dla płyt z chipsetem nforce2™ jest to moduł:

# modprobe nvidia-agp

Następnie wczytujemy moduł kernela obsługujący 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ę upewnić, że mamy zamontowany pseudo-system plików shm używany do obsługi dzielonej pamięci POSIX. Wymagany wpis w /etc/fstab wygląda następująco:

none   /dev/shm   tmpfs  defaults  0 0

Test konfiguracji

Teraz możemy wrócić do konfigurowania serwera X11 i jego testowego uruchomienia. Kiedy uruchomimy X-Window możemy sprawdzić poprawność konfiguracji pomocą programów glxinfo™ oraz glxgears™ uruchamianych z emulatora terminala (np. xterm-a). Pierwszy z nich wyświetla dokładne informacje o naszej karcie i sterowniku, zaś drugi to program do testowania wydajności. Dobrze skonfigurowana karta graficzna pozwala osiągnąć wydajność kilku tysięcy klatek na sekundę. W przypadku problemów standardowo zaglądamy w logi.

Część V. Tworzenie PLD - Praktyczny poradnik

Rozdział 18. Możliwa droga do zostania szeregowym developerem PLD

Co jest potrzebne

Każdego użytkownika Linuxa pracującego na swojej maszynie nachodziła refleksja na tematy filozoficzne - kto to wymyślił? kto to zrobił? i jak to zrobił? Pytania ciekawe - Prezentując sposób pracy przy PLD możemy częściowo zrozumieć mechanizmy tworzenia takich projektów.

Naszym miejscem pracy będzie samo PLD i dodatki, które poniżej spróbuje opisać. W chwili pisania tego tekstu była to wersja 1.0 ''Ra''. Później jest już z górki - instalujemy parę pakietów - sam proces instalacji w praktycznie zostanie pominięty, gdyż użytkownicy już powinni wiedzieć co to jest poldek i jak się go uż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ę uwagę tylko na CVS. Sposób instalacji środowiska bardzo dobrze opisuje Baseciq - ten krok należy wykonać ze szczególną starannością

Innym ważnym pakietem jest rpm plus dodatki. Głównym zajęciem szeregowego developera jest tworzenie lub modyfikacja plików .spec, które są głównym czynnikiem budowania pakietów RPM. Są jeszcze potrzebne różne inne pakiety i źródła  - ale to już w zależności od tego co będziemy budować.

Źródła wiedzy

Największą skarbnicą wiedzy o RPMie i budowaniu pakietów możemy znaleźć w publikacji Maximum RPM - opis jest w języku angielskim i nie jest mi znane tłumaczenie na nasz język. Na szczęście są jeszcze inne źródełka, a także i niniejszy opis - więc powinno nam być lżej przyswajać wiedzę. Szczególnie polecam stronę Grzegorza Niewęgłowskiego (lub lokalną kopię) gdzie dużo teorii i praktycznych rad może nam rozjaśnić w naszych głowach czym jest praca ze "specami".

Jest dostępny także opis stworzony przez Developera PLD lecz z tego co się dowiedziałem jest już trochę leciwy i niektóre dane mogą być nieścisłe.

Po tej bombie teorii jaką niestety musimy przejść, czeka nas przestudiowanie jeszcze jednego dokumentu, którego najnowszą wersję możemy ściągnąć z CVS PLD. Będzie to nasze pierwsze ćwiczenie.

Uruchamiamy terminal (czy to zwykły, czy też np. przez SSH) i wykonujemy kroki:

$ cd rpm
$ cvs get PLD-doc/devel-hints-pl.txt
U PLD-doc/devel-hints-pl.txt
$

Jak widać kroki wykonujemy jako zwykły użytkownik (nie root) i tej zasady będziemy się konsekwentnie trzymali.

Do katalogu ~/rpm/PLD-doc/ ściągneliśmy z repozytorium PLD dokument tekstowy devel-hints-pl.txt. W tym dokumencie zawarte są zalecenia i ustalenia jakich powinniśmy się trzymać aby tworzyć właściwe dla PLD pakiety RPM.

Przykład budowania

Teraz spróbujemy ściągnąć jakiś .spec z CVS PLD i zbudujemy sobie jakąś paczkę - np. pakiet tar (przykład budowania 'ekg' mogliśmy obejrzeć także podczas instalacji CVS na stronie Baseciq):

$ cd rpm
$ cvs get SPECS/tar.spec
U SPECS/tar.spec
$ cd SPECS/
$ rpmbuild -ba tar.spec
błąd: 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 chcieliśmy zbudować pakiet - zaraz po ściągnięciu ''tar.spec''.

Sam .spec bez źródeł jest jak karabin bez amunicji... Można wykorzystać skrypt 'builder' (i później nawet zalecam go używać) w katalogu SPECS, który to sam przeanalizuje potrzeby i ściągnie odpowiedniego .speca (oczywiście jeżeli tylko zawiera go repozytorium CVS), źródła i wykona paczki rpm i srpms - ale my nie będziemy tutaj sobie za bardzo ułatwiać pracy :-)

Po ściągnięciu plików dobrze jest obejrzeć danego .speca aby zobaczyć, co jest jeszcze potrzebne do zbudowania - można to zrobić zwykłym edytorem tekstowym lub wykonać:

$ cat tar.spec |grep BuildReq
BuildRequires: autoconf
BuildRequires: automake
BuildRequires: bison
BuildRequires: gettext-devel

Wiemy już 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ęc 'poldek' rusza do boju (tutaj już lepiej użyć konta 'root' - chyba że mamy poldka skonfigurowanego do pracy 'sudo'):

# poldek
Wczytywanie ftp://ftp.pld-linux.org/dists/[...]/RPMS/packages.dir.gz...
Wczytywanie ftp://ftp.pld-linux.org/dists/ra/[...]/packages.dir.gz...
Wczytywanie ftp://ftp.pld-linux.org/dists/ra/[...]/packages.dir.gz...
Wczytywanie ftp://ep09.kernel.pl/pub/People/[...]/packages.dir.gz...
Wczytywanie ftp://ftp.pld-linux.org/dists/[...]/packages.dir.gz...
Wczytywanie http://pld.mysza.eu.org/Ra/i686/packages.dir.gz...
Przeczytano 6814 pakietów
	        
Usunięto 16 zdublowanych pakietów z listy dostępnych
Wczytywanie /root/.poldek-cache/packages.dir.dbcache.var.lib.rpm.gz...
Przeczytano 559 pakietów
		   
Witaj w poldekowym trybie interaktywnym. Wpisz "help" aby otrzymać pomoc.
	    
poldek> install bison gettext-devel
Przetwarzanie zależności...
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
Przetwarzanie zależności...
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 kochać Poldka? :-)

Mamy już teoretycznie wszystko aby zbudować pakiet 'tar'. Wracamy więc 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):
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ęte przeze mnie komunikaty jakie generuje kompilowany 'tar'.

Polecenie 'rpmbuild -ba ' każe nam zbudować ze speca kompletny pakiet - ale to już wiemy z teoretycznych szkoleń ;-)

Wszelkie komunikaty w razie jakiegoś błędu podczas budowania możemy odnaleźć w pliku: '/var/tmp/rpm-tmp.22007'

Widzimy, że gotowe pakiety mamy w określonych katalogach i możemy je spokojnie zainstalować. A komunikat 'exit 0' oznacza brak błędów podczas budowania.

Nasz pierwszy pakiet został zbudowany.

Pozostaje jednak niedosyt - ciągle czujemy, że jak na razie korzystamy z czyjeś pracy, a w końcu pragniemy także coś zrobić dla potomności i sami chcemy stworzyć plik .spec

Pierwszy spec

No to zaczynamy. Naszym pierwszym (a właściwie moim) wykonanym specem będzie Mantis czyli system kontroli błędów oparty o stronę WWW (PHP) i bazę SQL Mysql.

Tutaj mała dygresja - większość pakietów powstaje dlatego, że danemu Developerowi był on akurat potrzebny; oznacza to że nie ma sensu pisanie na listę dyskusyjną z prośbą o stworzenie określonego pakietu bo można otrzymać parę przykrych komentarzy (w najlepszym razie).

Pierwszą czynnością jest zainstalowanie pakietu ze źródeł. Potem notujemy sobie co należy zrobić aby dany pakiet zaczął działać - wszystko po to aby przewidzieć co dany .spec powinien zrobić aby pakiet pracował w miarę bezproblemowo po instalacji RPMa - Można to zanotować np. na kartce papieru - ale od czego mamy komputery?

Moje notatki wyglądały tak:

// MANTIS
	 
// Mysql init
# cd /etc/rc.d/init.d
# ./mysql init
# /usr/bin/mysqladmin -u mysql password 'password'
	     
// 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
Dodać nowe i skasować stare :-)
		        
// co potrzebne do uruchomienia
- mysql
- mysql-client
- php
- php-common
- php-pcre
- php-mysql
- apache
			        
// do rpma (zmiany w związku z językiem)
plik: config_defaults_inc.php
$g_default_language = 'english';
$g_default_language = 'polish'; 
// Zamiana łań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 każdego pakietu należy podchodzić indywidualnie - dlatego parę słów o samym mantisie. System jest oparty o gotowe pliki składające się na stronę WWW, dokumentacje i plik potrzebny do stworzenia odpowiedniej bazy Mysql. Nie będziemy dokonywali żadnych kompilacji - więc uprości to nasz proces budowania i testowania pakietu.

Łącząc informacje zawarte w dostarczonej dokumentacji i własnych notatek wiemy już że głównym zadaniem naszego RPMa będzie takie zaprojektowanie go, aby odpowiednie pliki PHP zostały przekopiowane w odpowiednie miejsce, dokonać niezbędnych poprawek w plikach konfiguracyjnych lub innych poprawek, które naszym zdaniem mogą ułatwić pracę przyszłym użytkownikom. Pamiętajmy jednak żeby nie przedobrzyć.

Niestety nie wszystko uda nam się zautomatyzować - dlatego stworzymy dwa pliki tekstowe (w dwóch wersjach językowych PL i EN) z krótkim opisem, co należy wykonać aby system zadziałał.

Wydaje mi się także, że dobrym zwyczajem jest po zainstalowaniu źródeł przewidzieć właściwe zależnoś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ędzie wyświetlał błędy. Okazuje się że pakiety w PLD są maksymalnie ''rozdrobnione'' i do działania potrzebny jest jeszcze pakiet 'php-pcre' - a do tego, żeby strony PHP odpowiednio komunikowały się z bazą 'mysql' jest potrzeba zainstalowania 'php-mysql'. Zależności może być wiele i moim skromnym zdaniem lepiej żebyśmy umieścili jakiś nadmiarowy pakiet w zależnościach niż żeby jakiegoś brakowało.

W naszym przypadku po zainstalowaniu i uruchomieniu pakietu Mantis ze źródeł, wystarczy wykonać np. 'rpm -qa |grep php' aby wybrać odpowiednie pliki. To samo robimy z 'mysql' i 'apache'.

Zaczynamy od stworzenia pliku (możemy użyć polecenia 'touch') lub korzystamy z innego pliku .spec w celu modyfikacji do naszych potrzeb (np. 'cvs get SPECS/template.spec' spowoduje ściągnięcie 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łędów
Name: mantis
Version: 0.18.0a4
# define _alpha a4
Release: 1
License: GPL
Group: Development/Tools 

[...]

Zaczynamy wypełniać tzw. preambułę, czyli wstęp w którym opisujemy nasz pakiet - myślę, że wyjaśnianie powyższego nie jest specjalnie potrzebne. Zwrócę tylko uwagę na linię 'Version' i 'Ralease' - zgodnie z devel-hints-pl.txt powinno ono raczej wyglądać tak (ponieważ ta wersja mantis'a jest określona jako alpha):

Version: 0.18.0 %define alpha a4 Release: 0.%{_alpha}.1

ale u mnie powodowało to błąd przy budowaniu, gdyż jak dalej zobaczymy nazwa źródeł korzysta z pola 'Version' i każda manipulacja na nim powoduje potrzebę przebudowania .speca lub zmianę nazwy archiwum w którym są źródła (co jest bardzo złym nawykiem i karygodnym błędem!). Tak więc w końcu zostawiłem tak jak jest i nikt specjalnie nie zwrócił mi na to uwagi :-) (przyp. autora: jednak późniejsza praktyka pokaże nam, że zmiany takie są jednak chlebem powszednim więc nie bójmy się ich dokonywać)

[...]
	 
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 źródełek - w PLD podaje się go najczęściej w formie linku plus fraza %{name}-%{version}.tar.gz i tak naprawdę ta fraza jest najważniejsza do zbudowania pakietu, ponieważ URL (w naszym przypadku http://dl.sourceforge.net/mantisbt/) jest ignorowany. Tak więc z makra %name i %version budowana jest nazwa pakietu i taka nazwa jest wyszukiwana w ~/rpm/SOURCES/

Źródeł programu może być kilka. U nas występuje jeszcze Source1 - jest to dodatkowa dokumentacja składająca się z dwóch plików tekstowych zawierająca dodatkowe wskazówki po instalacyjne. Pierwotnie próbowałem zrobić to korzystając z mechanizmu Patch i polecenia:

diff -urN katalog_z_oryginałem katalog_z_poprawionym_oryginałem > źródła-powód.patch

opisanego w devel-manual (rozdział 1.2.2), ale mechanizm ten nie pozwala tworzyć nowych plików więc pozostało tylko wykonać dodatkowe źródła.

Pamiętajmy także aby w żadnym przypadku nie modyfikować ręcznie źródeł programu. Prawidłowy .spec powinien wykorzystywać natywne źródła, a wszelkie zmiany dokonujemy w %build, %install lub za pomocą patch'ów.

Sygnatura md5 po # jest wynikiem wykorzystania tzw. distfiles i na razie to musi nam wystarczyć. Distfiles omówimy gdy będziemy zapisywać do CVS PLD - czyli nieprędko ;-)

[...]
	 
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 zależności, czyli co musi być zainstalowane aby dany pakiet działał lub żeby wykonały się poprawnie polecenia wykonywane przez .spec (np. sekcja %post)

W 'BuildArch' architekturę pod który przeznaczony jest RPM - u nas jest to 'noarch' czyli bez żadnej konkretnej architektury - z moich obserwacji wynika że developerzy PLD omijają to pole - chyba że jest to właśnie 'noarch'.

'BuildRoot' jest bardzo ważnym tagiem - na szczęście występuje zawsze w takiej postaci jak u nas - a oznacza katalog w którym rpm będzie 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łędów opartym na interfejsie \
    WWW i MySQL. 

[...]

W tej części wykorzystujemy przydatną właściwość RPMa czyli definiowanie stałych. W naszym przykładzie '_mantisdir' jest katalogiem w którym będą zainstalowane pliki dla serwera WEB. Tutaj mała uwaga dotycząca komentarza '#' - Gdy definiujemy makro wtedy komentarz nie działa, dlatego usunęliśmy '%' przed słowem 'define' (możemy także użyć frazy '%%') czyli gdybyśmy napisali:

%define _mantisdir /home/services/httpd/mantis

# %define _mantisdir /home/httpd/html/mantis

To wtedy stała '_mantisdir' miała by wartość /home/httpd/html/mantis, mimo że nie taka jest nasz intencja - Nie muszę chyba wyjaśniać jakie to może spowodować problemy?

W '%description' opisujemy krótko charakterystykę pakietu, a niżej widzimy jak to zrobić dla opisu w języku polskim - później RPM wykorzystując zmienne locale wyświetla odpowiednią wersję językową 'description' gdy sobie tego od RPMa życzymy.

[...]
	 
%prep
%setup -q -a1
	   
[...] 

Od tego momentu skończyliśmy wypełniać dane preambuły. Sekcja %prep może wykonać skrypt potrzebny przed instalacją plików. My akurat nic przed instalacją robić nie musimy dlatego sekcja ta jest pusta.

Dalej jest '%setup -q -a1' - czyli rozpakowanie źródeł do katalogu zdefiniowanego wcześniej przez 'BuildRoot'. Dodatkowe parametry tego tagu wyłączają komunikaty przy rozpakowaniu '-q', a parametr '-a1' określa które źródła należy rozpakować. Po '%setup' możemy także korzystać z makra '%patch' który nakłada łatki na źródła. Umożliwia to taką modyfikację źródeł jakie tylko chcemy bez potrzeby zmian w samych źródłach (o czym pisaliśmy wcześ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ę w większości pakietów przed '%install' wykonywane jest makro '%build', które kompiluje nam źródła, a w najprostszej postaci wygląda tak:

%build %configure make

U nas nie ma potrzeby wykonywania żadnych kompilacji więc od razu wykonywana jest sekcja '%install'. Na początku czyścimy sobie katalog w którym będziemy instalowali nasz program (czyli 'fake root') - mimo że prawdopodobnie jest pusty - ale lepiej dmuchać na zimne. Potem dokonujemy instalacji pakietu przekazując mu w parametrze '-d' że docelowo ma być zainstalowany w 'fake root', ale same pliki pojawią się w naszym katalogu tymczasowym (TMPDIR), dlatego później za pomocą polecenia 'cp' kopiujemy pliki, jakie są potrzebne, do właściwego 'fake root' - zauważmy że pominęliśmy np. katalog 'doc'.

Następnie jeszcze za pomocą komendy 'SED' dokonujemy drobnej poprawki w pliku konfiguracyjnym mantisa - zamieniając domyślnego użytkownika MYSQL z 'root' na 'mysql'. Taką poprawkę mogliśmy wykonać wcześniej w sekcji '%prep' i tagu '%patch' ale przy tak małych poprawkach bardziej efektywniej jest to zrobić tutaj.

[...]
	 
%clean
rm -rf $RPM_BUILD_ROOT
	   
[...]

Tag '%clean' jest w .specach tworzonych dla PLD obowiązkowy i określa co należy zrobić gdy cały pakiet zostanie zbudowany. Tutaj mała uwaga - ten tag w tym miejscu nie oznacza że jest w tej chwili wykonany - jeżeli by tak było, to występujący później tag '%files' miałby niejakie problemy z nieistniejącymi już plikami. Czyli po poprawnym zbudowaniu pakietu, wykonywane jest makro '%clean', a w przypadku jakiegokolwiek błędu, nie jest - czyli rozpakowane i zainstalowane źródła pozostają. Umożliwia nam to np. diagnostykę w przypadku błędów podczas budowania pakietu.

[...]
	 
%post
if [ "$LANG" = "pl_PL" ]; then
#sed -e "s/= 'english';/= 'polish';/g" \
    %{_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ęcej: /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 możemy zrobić z plikami, które będą instalowane po zbudowaniu pakietu. Makro '%post' wykonywane jest przez RPM podczas instalacji pakietu. Zakomentowane polecenia umożliwiają zmianę w zainstalowanym pliku 'config_defaults_inc.php' zgodnie z zawartością zmiennej locale 'LANG'. Później w zależności od tej zmiennej wyświetlany jest komunikat w języku PL lub EN.

Zadacie pytanie dlaczego część tych poleceń jest ''wyłączona" - otóż, później gdy dany .spec chcemy już udostępnić ogółowi zostanie on sprawdzony pod względem ''czystości rasowej'' :-) - W tym przypadku okazało się, że taka zmiana w plikach konfiguracyjnych, może spowodować kłopoty podczas np. zmiany użytkownika. Programy korzystające z 'locale' powinny odpowiednio reagować na zmiany 'locale' - np. po modyfikacji LANG na 'EN_en' zacząć pracować po angielsku - W naszym przypadku strona PHP nie zacznie pracować po angielsku, dlatego dodany został w/w komentarz, a w pliku 'PLD_Install_PL.txt.gz', który jest dodatkową instrukcją, co należy zrobić 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*
%{_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 określamy co, gdzie i jak ma zostać zainstalowane u użytkownika instalującego naszego RPMa. Tag %files jest bardzo ważny gdyż błędy spowodowane tutaj mogą uniemożliwić działanie pakietu u końcowego użytkownika. W 'podtagu':

%defattr(644,root,root,755)

określamy domyślne atrybuty instalowanych plików - możemy oczywiście określać atrybuty dla każdego pliku osobno.

Następnie w:

%doc doc/* PLD_Install_PL.txt PLD_Install_EN.txt config_inc.php.sample

określamy nasze pliki, które znajdą się w dokumentacji. Czyli katalog 'doc/' z katalogu 'TMPDIR' i pliki z 'SOURCE1' oraz 'config_inc.php.sample' zostaną spakowane i przy instalacji pakietu RPM umieszczone w domyś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łą '%{_mantisdir}' i kopiujemy pliki jakie są poniżej tego tagu. Na początku nie wypisywałem wszystkich tych katalogów i plików indywidualnie, a po prostu użyłem frazy:

%{_mantisdir}

Jednak przy takiej konstrukcji i wykorzystaniu makra %config(noreplace), pojawi się błąd 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ępowały na liście do skopiowania i jako pliki konfiguracyjne. Dlatego trzeba niestety zrobić listę plików jak to my zrobiliśmy minus pliki, które znajdą się w makro '%config'. Samo makro '%config' pozwala szczególnie traktować pliki konfiguracyjnie podczas kasowania RPMa lub jego aktualizacji.

Ostatnie makro:

'%exclude %{_mantisdir}/core/.cvsignore'

nakazuje wyłączenie pliku z pakietu RPM - w tym przypadku jest to pozostałość po CVS mantisa.

I to już koniec naszej pracy. Po wykonaniu polecenia 'rpmbuild -ba mantis.spec' powinien nam zbudować się pakiet rpm i srpm. Zostaje jeszcze przetestowanie czy wszystkie pliki są tam gdzie chcieliśmy, czy mają odpowiednie prawa i czy pakiet działa tak jak powinien. Jeszcze ewentualne poprawki i musimy przepuścić naszą pracę przez zestaw adaptujący 'adapter.awk'.

Ściągamy go z CVSu:

$ cvs get SPECS/adapter.awk
U SPECS/adapter.awk
$

następnie zmieniamy nazwę pliku .speca dodając na końcu np. org i wykonujemy:

$ ./adapter.awk mantis.spec.org > mantis.spec
$

W wyniku tej operacji otrzymamy 'mantis.spec' który zostaje przystosowany do wymagań PLD. Zainteresowanych zmianami, zapraszam do przestudiowania 'nowego' .speca.

Teraz możemy szukać kogoś, kto umieści naszego .speca i źródła w repozytorium CVS PLD. Mamy do dyspozycji listę developerów: w mailu umieszczając załącznik z naszym .specem (oczywiście bez źródeł - lub jeżeli mamy jakieś własne źródła to umieszczamy je na jakieś stronie WWW lub innym ftp. i podajemy linka - źródła natywne powinny dać się ściągnąć z lokacji jaką umieściliśmy w naszym .specu.). Załącznik powinien być typu plain-text.

Można także spróbować na grupie IRC #PLD znaleźć ofiarę, która umieści naszą pracę w repozytorium.

Dobrze też w czasie nauki robienia .speców podglądać jak to robią inni - W repozytorium CVS jest naprawdę z czego wybierać. A my nabywając umiejętność czytania plików .spec możemy skupić się już tylko na odpowiednim ich napisaniu.

W końcu otrzymamy możliwość zapisu do CVS i wtedy czytamy następną część poradnika ''W krainie CVS''

Rozdział 19. W krainie CVS - czyli wielki kocioł

Wstęp

Umiemy już w miarę klecić nowe spece, naprawiać stare - chcemy dołączyć do drużyny PLD... Musimy mieć więc możliwość pogrania na boisku, a nie tylko zasiadać na trybunach jako widz. Naszym boiskiem będzie CVS a możliwość czytania i pisania do niego (Read-Write) naszym sposobem na grę :)

Jak to życiu, aby coś dostać musimy najpierw się postarać i wykonać parę czynności.

Żeby otrzymać własne konto CVS należy uzyskać poparcie już aktywnych deweloperów. Zwykle osoby wykazujące się aktywnością na listach dyskusyjnych (podsyłające patche, itp.) prędzej czy później są wręcz proszone o zgłoszenie się po konto. W typowym przypadku wystarczy, że trzech deweloperów wyrazi poparcie kandydata na dewelopera (trzeci z nich powinien wskazać mu dokąd powinien się zgłosić po konto). Osoba popierająca kandydata jednocześnie staje się jego opiekunem i nadzoruje jego działania w początkowej fazie. W przypadku gdyby, mimo poparcia przez niektórych, osoba kandydata wywoływała kontrowersje, decyzja o jego przyjęciu (lub nie) będzie podjęta zgodnie z obowiązującą procedurą rozwiązywania konfliktów.

Kiedy już zostaniemy przyjęci, musimy wymyśleć sobie ksywkę i hasło. Potem z linii poleceń wykonujemy jednolinijkowe polecenie - wstawiając 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 ciąg znaków podobny do:

login:/APGG.cfeqPpk

Ciąg ten kopiujemy do listu e-mail z prośbą o możliwość RW na CVS PLD i wysyłamy na adres cvsadmin@pld-linux.org

To na razie wszystko co możemy zrobić - trzeba czekać na odpowiedź od władzy CVS. Po kilku, kilkunastu lub kilkudziesięciu dniach przyjdzie mail z odpowiedzią. U mnie była to wiadomość podobna do:

Quoting Marek Ciesielski <marekc@adres.email>: 

> Prosze o dostep RW do CVS PLD.
> dane do <login>:/APGG.cfeqPpk // oczywiście tej linii 
    // w mailu nie ma - dodałem ją dla przykładu :)

Witam, 

twoje konto zostało założone, proszę dopisz się do CVSROOT/users

-- 
Admin CVS <imię i nazwisko> :)

Czyli pierwsze formalności mamy za sobą. Możemy już działać na CVS. Jednak proponuję znowu trochę teorii - tym razem zdecydowana większość dokumentacji jest w języku angielskim. Mamy więc bardzo dobry, oficjalny podręcznik CVS (uwaga ponad 800KB), książkę kucharską CVS (uwaga ponad 600KB) - jest także opis po polsku - stworzony przez developerów PLD, a także książka z cyklu leksykon kieszonkowy "CVS" Gregor N. Purdy (koszt ok. 10PLN) - tak więc jest w czym wybierać.

Jeszcze raz zwróćmy uwagę na maila którego otrzymaliśmy. Jest tam coś o dopisaniu "users". Musimy wykonać zalecenie. Aby to zrobić musimy znowu przygotować sobie środowisko CVS - albo modyfikując istniejące, dotychczasowe konto "anonymous" albo tworząc od początku środowsko w nowym katalogu. Ja wybrałem pierwszy sposób (trochę wbrew zaleceniom z dokumentacji - ale za to szybszy), polega on na modyfikacji każdego pliku "Root" w podkatalogach "CVS" - należy tam wpisać frazę:

:pserver:<nasz_login>@cvs.pld-linux.org:/cvsroot

Czyli w naszym przypadku wchodzimy do katalogu ./rpm i wchodzimy do każdego podkatalogu "CVS" i zmieniamy ręcznie plik "Root" - nie ma w tej chwili tych katalogów wiele, więc nie powinno to sprawić kłopotu.

Proponuję także poustawiać sobie zmienne CVS np. CVSEDITOR itp. (szczegóły - oczywiście dokumentacja).

Następnie możemy już spróbować zalogować się do CVS PLD:

$ cvs login
Logging in to :pserver:<nasz_login>@cvs.pld-linux.org:2401/cvsroot
CVS password:
$

Wpisujemy hasło które wymyśleliśmy i jesteśmy zalogowani. Każdy komunikat błędu oznacza że coś wcześniej źle wykonaliśmy, albo że np. nie działa sieć. Login wykonujemy praktycznie raz i dopóki nie wykonamy polecenia "cvs logout" jesteśmy ciągle gotowi do pracy.

Czas już zabrać się za plik "users"

$ cvs get CVSROOT/users
U CVSROOT/users
$

Do naszego lokalnego repozytorium, do katalogu CVSROOT ściągneliśmy plik users, który służy w PLD do wpisania aliasu pocztowego - przy okazji możemy zobaczyć w jakim towarzystwie przyjdzie nam pracować :)

nasz_login:użytkownik_mail@domena_naszego_email:Imię i Nazwisko:user@jabber.domena

Ostatnie pole jest opcjonalne - wypełniamy je tylko jeśli posiadamy swój własny JID (o ile go posiadamy). Jeśli z różnych przyczyn nie korzystamy z Jabbera - omijamy tę część i zatrzymujemy się na imieniu i nazwisku. Dla zainteresowanych - istnieje oficjalny serwer Jabbera projektu PLD Linux - konta na nim zakłada Mariusz Mazur.

Edytujemy odpowiednio więc plik users (pamiętajmy, żeby zachować alfabetyczną kolejność wpisów) - wystarczy tylko drobna znajomość 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ę nasz ulubiony edytor i pojawi się coś podobnego do:

- added nasz_login // tu wpisujemy komentarz z kreseczką 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łaśnie dokonaliśmy pierwszej zmiany w repozytorium PLD. Od tej chwili każdy mail adresowany na <nasz_login>@pld-linux.org trafi na naszą skrzynkę pocztową.

Dalsza część naszych rozważań będzie już w formie konkretnych przykładów, ponieważ to co chcemy zrobić w repozytorium CVS PLD zależy od konkretnych potrzeb. Od tej chwili nikt już nas za rączkę nie będzie prowadził, a czekają nas pot, krew, łzy i pierwsze "recenzje" naszych poczynań - np. na grupie PLD-devel czy kanale #PLD - a jedynymi nagrodami będzie brak tych recenzji, zdobyta wiedza, satysfakcja i działające paczki, których przez chwilę nikt na świecie nie będzie miał :)

Dodawanie plików do CVS PLD

Każdy nowy plik, który chcemy umieścić w repozytorium należy dodać za pomocą 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 widać z komentarza, aby zakończyć dodanie pliku należy zatwierdzić zmianę za pomocą polecenia "cvs ci" (polecenia podaję w formie skróconej) - Samo zatwierdzanie (commit) robiliśmy już wcześniej przy okazji pliku "users".

Aktualizacja plików

Pliki możemy zaktualizować względem CVS - jeżeli nasz plik jest nowszy nie zostanie dokonana żadna zmiana na naszym lokalnym repozytorium. Aktualizacją nie dokonujemy zmian na zdalnym repozytorium.

Jeżeli w danym katalogu mamy już zdefiniowaną kartotekę (czyli mamy już odpowiedni podkatalog CVS) to aktualizacją możemy ściągnąć nowy plik.

$ cvs up python.spec
P python.spec
$

W powyższym przykładzie dokonaliśmy aktualizacji pliku "python.spec". Literka "P" określa stan aktualizacji. Poniżej przedstawię możlwe kody:

  • "A" - Plik dodany. Oznacza ż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. dokonaliśmy zmian na lokalnym repozytorium i nasz plik jest "nowszy" względem zdalnego repozytorium.

  • "M" - Plik został zmodyfikowany w zdalnym repozytorium ale nie było żadnych konfliktów.

  • "P" - Plik był "łatany" przez serwer (kod podobny do "U")

  • "R" - Plik usunięty 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

Zatwierdzanie zmian i Distfiles

Sam przykład zatwierdzania zmian mogliśmy poznać wcześniej. Jest to najczęściej wykonywana operacja na CVS.

Jednak chciałbym zwrócić uwagę na inny sposób składowania źródeł natywnych. W pewnym momencie okazuje się, że składowanie wszystkich plików w repozytorium CVS jest mało efektywne i powoduje zbyt duże obciążenia serwerów. Dlatego też w PLD zastosowano mechanizm Distfiles którego krótki opis możemy odszukać tu. W wielkim skrócie oznacza to że preparując odpowiednio spec (pamiętacie tajemnicze md5?) i korzystając z odpowiednich opcji programu ./builder możemy sterować ściąganiem plików do distfiles. Tak naprawdę najczęściej wykorzystane są dwie opcje ./builder - "5" i "U". Jest to także powód używania programu ./builder (a nie frazy "rpmbuild -ba"), którego kopię najlepiej ściągnąć z CVS. Pamiętajmy także o tym, że w systemie istnieje inny builder, który jest dostarczany z narzędziami rpm ale oczywiście nie ma on możliwości pracy z distfiles. I jeszcze jedna uwaga: Distfiles jest przeznaczony tylko dla źródeł natywnych - wszelkie patche i nasze pliki dodajemy normalnie do CVS (najczęściej do katalogu SOURCES).

Oto przykłady użycia ./builder z odpowiednimi opcjami:

$ ./builder -5 mantis.spec
# $Revision: 12145 $, $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.
Łączenie się z dl.sourceforge.net[193.1.219.87]:80... połączono się.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 200 OK
Długość: 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" są podobne, z tym że "5" próbuje poprawić md5 korzystając z istniejącego sources w lokalnym repozytorium. Natomiast "U" próbuje zawsze ściągnąć źródła z podanego przez spec URL. Taka jest teoria. Ja praktycznie używam opcji "U" kasując wcześniej źródła z lokalnego repozytorium, ponieważ w innym przypadku wyskakują dziwne błędy o konflikcie z parametrem -nd

$ ./builder -U mantis.spec
# $Revision: 12145 $, $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.
Łączenie się z dl.sourceforge.net[193.190.198.97]:80... połączono się.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 200 OK
Długość: 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 każdym większym CVSie, projekty główne rozgałęziają się tworząc tzw. branche - W przypadku PLD np. istnieje stabilny, lecz już troche leciwy branch "RA-branch", który wywodzi się z brancha głównego HEAD. W pewnym momencie RA-branch został "zamrożony" i dokonywane są na nim tylko zmiany zawierające poprawki poważnych błędów lub aktualizacje związane z bezpieczeństwem. Branch HEAD "żyje" dalej i są w nim dokonywane zmiany i powstają nowe pakiety. Odgałęzień może być (i jest) wiele, co na początku troche gmatwa spojrzenie na CVS ale później doceniamy zalety tego rozwiązania. Dane odnogi mają przydzielone odpowiednie etykiety "lepkie" (ang. sticky tag) - czyli etykieta jest przekazywana każdej następnej wersji w danej odnodze. Zwykłe etykiety (ang. tag) możemy użyć np. do okreslenia indywidualnego stanu danego pliku - określając np. tag STABLE, UNSTABLE lub DEVELOP.

Jeżeli chodzi o etykietowanie to trzeba zachować rozwagę. Musimy być pewni że wiemy co chcemy osiągnąć, bo możemy popsuć pracę komuś innemu (dotyczy to także zmian w cudzych specach).

Praktycznie najczęściej wykorzystywane są następujące opcje związane 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 dotyczące lepkiej etykiety - związanej z branchem (odnogą)
Sticky Date: (none)
Sticky Options: (none)

Existing Tags: // Istniejące 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 poczytać np. opis CVS PLD bo sam tego jeszcze nie robiłem :). Etykietowanie możemy wykonać np.: mając plik w naszym lokalnym repozytorium wydajemy polecenie:

cvs tag UNSTABLE plik.spec

czyli plik.spec otrzymał etykietę UNSTABLE.

Ostatnim przykładem będzie przenoszenie zmian między odnogami (branchami). Robiąc jakiś spec w głównej odnodze HEAD doszliśmy do wniosku, że zmiany można ogłosić w odnodze RA-branch. Można spróbować wykonać polecenie:

cvs update -r RA-branch -j HEAD mldonkey.init

ale najczęściej różnice między wersjami w odnogach są tak duże, że otrzymamy komunikat o braku automatycznej możliwości przeniesienia zmian. Wtedy można rozwiązać ten problem innym sposobem. Tworzymy np. w podkatalogu "SPECS" katalog "RA-branch" (nazwa katalogu jest nieistotna, ale pomocna). W podkatalogu "RA-branch" 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łaściwy z HEAD
$ cvs commit -r RA-branch plik.spec // zatwierdzamy zmiany jako RA-branch
$

Myślę że komentarze są czytelne. Gdy zrobimy co najmniej jedną taką operację, to istniejący katalog RA-branch może nam służyć do późniejszych operacji kopiowania zmian między odnogami (np. korzystając z opcji "cvs up".

Zlecenia dla builderów

Zdarza się często, że chcemy dać sygnał iż dany pakiet powinien zostać przebudowany przez buildery PLD (czyli takie zdalne komputery-muły robocze, które przygotowują pakiety) - wtedy podczas wpisywania komentarza po wydaniu polecenia "cvs ci" należy napisać np.

- updated to version 2.5.3. Release 1 STBR for RA update general

STBR jest skrótem od "Send To Builder Request"

Zakończenie

Zbliżamy się do końca naszego praktycznego poradnika. Nie zostało poruszonych wiele kwestii, które wyjdą w codziennej pracy. Dlatego mamy do pomocy dokumentację, listy dyskusyjne, IRC, zasoby CVS i przeglądarkę GOOGLE ;). Praca ta miała na celu wprowadzić w świat pracy developerskiej i pokazać praktyczne rozwiązania niektórych problemów - reszta zależy od naszej wiedzy i pracowitości - i pamiętajmy, że najważniejsze to rozwijać swoje zdolności, bo od tego zależy nasza przyszłość i przyszłość projektu dla którego pracujemy :)

Część VI. O podręczniku

Rozdział 20. O podręczniku

Autorzy dokumentacji PLD

W tworzeniu tej pracy pośrednio lub bezpośrednio udział wzieli (w kolejności alfabetycznej):

Rozdział 21. 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ęzyku angielskim możemy odnaleźć na stronie GNU Free Documentation License. Tłumaczenie starszej wersji 1.1 zostanie tutaj przytoczone i znajduje się na stronie GNU.org.pl. Różnice między wersją 1.1 a 1.2 niniejszej licencji w wersji angielskiej możemy przeczytać korzystając z tego odnośnika

Wersja 1.1, marzec 2000

Copyright (c) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Zezwala się na kopiowanie i rozpowszechnianie wiernych kopii niniejszego dokumentu licencyjnego, jednak bez prawa wprowadzania zmian.

0. Preambuła

Celem niniejszej licencji jest zagwarantowanie wolnego dostępu do podręcznika, treści książki i wszelkiej dokumentacji w formie pisanej oraz zapewnienie każdemu użytkownikowi swobody kopiowania i rozpowszechniania wyżej wymienionych, z dokonywaniem modyfikacji lub bez, zarówno w celach komercyjnych, jak i nie komercyjnych. Ponad to Licencja ta pozwala przyznać zasługi autorowi i wydawcy przy jednoczesnym ich zwolnieniu z odpowiedzialności za modyfikacje dokonywane przez innych.

Niniejsza Licencja zastrzega też, że wszelkie prace powstałe na podstawie tego dokumentu muszą nosić cechę wolnego dostępu w tym samym sensie co produkt oryginalny. Licencja stanowi uzupełnienie Powszechnej Licencji Publicznej GNU (GNU General Public License), która jest licencją dotyczącą wolnego oprogramowania.

Niniejsza Licencja została opracowana z zamiarem zastosowania jej do podręczników do wolnego oprogramowania, ponieważ wolne oprogramowanie wymaga wolnej dokumentacji: wolny program powinien być rozpowszechniany z podręcznikami, których dotyczą te same prawa, które wiążą się z oprogramowaniem. Licencja ta nie ogranicza się jednak do podręczników oprogramowania. Można ją stosować do różnych dokumentów tekstowych, bez względu na ich przedmiot oraz niezależnie od tego, czy zostały opublikowane w postaci książki drukowanej. Stosowanie tej Licencji zalecane jest głównie w przypadku prac, których celem jest instruktaż lub pomoc podręczna.

1. Zastosowanie i definicje

Niniejsza Licencja stosuje się do podręczników i innych prac, na których umieszczona jest pochodząca od właściciela praw autorskich informacja, że dana praca może być rozpowszechniana wyłącznie na warunkach niniejszej Licencji. Używane poniżej słowo "Dokument" odnosić się będzie do wszelkich tego typu publikacji. Ich odbiorcy nazywani będą licencjobiorcami.

"Zmodyfikowana wersja" Dokumentu oznacza wszelkie prace zawierające Dokument lub jego część w postaci dosłownej bądź zmodyfikowanej i/lub przełożonej na inny język.

"Sekcją drugorzędną" nazywa się dodatek opatrzony odrębnym tytułem lub sekcję początkową Dokumentu, która dotyczy wyłącznie związku wydawców lub autorów Dokumentu z ogólną tematyką Dokumentu (lub zagadnieniami z nią związanymi) i nie zawiera żadnych treści bezpośrednio związanych z ogólną tematyką (na przykład, jeżeli Dokument stanowi w części podręcznik matematyki, Sekcja drugorzędna nie może wyjaśniać zagadnień matematycznych). Wyżej wyjaśniany związek może się natomiast wyrażać w aspektach historycznym, prawnym, komercyjnym, filozoficznym, etycznym lub politycznym.

"Sekcje niezmienne" to takie Sekcje drugorzędne, których tytuły są ustalone jako tytuły Sekcji niezmiennych w nocie informującej, że Dokument został opublikowany na warunkach Licencji.

"Treść okładki" to pewne krótkie fragmenty tekstu, które w nocie informującej, że Dokument został opublikowany na warunkach Licencji, są opisywane jako "do umieszczenia na przedniej okładce" lub "do umieszczenia na tylnej okładce".

"Jawna" kopia Dokumentu oznacza kopię czytelną dla komputera, zapisaną w formacie, którego specyfikacja jest publicznie dostępna. Zawartość tej kopii może być oglądana i edytowana bezpośrednio za pomocą typowego edytora tekstu lub (w przypadku obrazów złożonych z pikseli) za pomocą typowego programu graficznego lub (w przypadku rysunków) za pomocą ogólnie dostępnego edytora rysunków. Ponadto kopia ta stanowi odpowiednie dane wejściowe dla programów formatujących tekst lub dla programów konwertujących do różnych formatów odpowiednich dla programów formatujących tekst. Kopia spełniająca powyższe warunki, w której jednak zostały wstawione znaczniki mające na celu utrudnienie dalszych modyfikacji przez czytelników, nie jest Jawna. Kopię, która nie jest "Jawna", nazywa się "Niejawną".

Przykładowe formaty kopii Jawnych to: czysty tekst ASCII bez znaczników, format wejściowy Texinfo, format wejściowy LaTeX, SGML lub XML wykorzystujące publicznie dostępne DTD, standardowy prosty HTML przeznaczony do ręcznej modyfikacji. Formaty niejawne to na przykład PostScript, PDF, formaty własne, które mogą być odczytywane i edytowane jedynie przez własne edytory tekstu, SGML lub XML, dla których DTD i/lub narzędzia przetwarzające nie są ogólnie dostępne, oraz HTML wygenerowany maszynowo przez niektóre procesory tekstu jedynie w celu uzyskania danych wynikowych.

"Strona tytułowa" oznacza, w przypadku książki drukowanej, samą stronę tytułową oraz kolejne strony zawierające informacje, które zgodnie z tą Licencją muszą pojawić się na stronie tytułowej. W przypadku prac w formatach nieposiadających strony tytułowej "Strona tytułowa" oznacza tekst pojawiający się najbliżej tytułu pracy, poprzedzający początek tekstu głównego.

2. Kopiowanie dosłowne

Licencjobiorca może kopiować i rozprowadzać Dokument komercyjnie lub niekomercyjnie, w dowolnej postaci, pod warunkiem zamieszczenia na każdej kopii Dokumentu treści Licencji, informacji o prawie autorskim oraz noty mówiącej, że do Dokumentu ma zastosowanie niniejsza Licencja, a także pod warunkiem nie umieszczania żadnych dodatkowych ograniczeń, które nie wynikają z Licencji. Licencjobiorca nie ma prawa używać żadnych technicznych metod pomiarowych utrudniających lub kontrolujących czytanie lub dalsze kopiowanie utworzonych i rozpowszechnianych przez siebie kopii. Może jednak pobierać opłaty za udostępnianie kopii. W przypadku dystrybucji dużej liczby kopii Licencjobiorca jest zobowiązany przestrzegać warunków wymienionych w punkcie 3.

Licencjobiorca może także wypożyczać kopie na warunkach opisanych powyżej, a także wystawiać je publicznie.

3. Kopiowanie ilościowe

Jeżeli Licencjobiorca publikuje drukowane kopie Dokumentu w liczbie większej niż 100, a licencja Dokumentu wymaga umieszczenia Treści okładki, należy dołączyć kopie okładek, które zawierają całą wyraźną i czytelną Treść okładki: treść przedniej okładki, na przedniej okładce, a treść tylnej okładki, na tylnej okładce. Obie okładki muszą też jasno i czytelnie informować o Licencjobiorcy jako wydawcy tych kopii. Okładka przednia musi przedstawiać pełny tytuł; wszystkie słowa muszą być równie dobrze widoczne i czytelne. Licencjobiorca może na okładkach umieszczać także inne informacje dodatkowe. Kopiowanie ze zmianami ograniczonymi do okładek, dopóki nie narusza tytułu Dokumentu i spełnia opisane warunki, może być traktowane pod innymi względami jako kopiowanie dosłowne.

Jeżeli napisy wymagane na którejś z okładek są zbyt obszerne, by mogły pozostać czytelne po ich umieszczeniu, Licencjobiorca powinien umieścić ich początek(taką ilość, jaka wydaje się rozsądna) na rzeczywistej okładce, a pozostałą część na sąsiednich stronach.

W przypadku publikowania lub rozpowszechniania Niejawnych kopii Dokumentu w liczbie większej niż 100, Licencjobiorca zobowiązany jest albo dołączyć do każdej z nich Jawną kopię czytelną dla komputera, albo wymienić w lub przy każdej kopii Niejawnej publicznie dostępną w sieci komputerowej lokalizację pełnej kopii Jawnej Dokumentu, bez żadnych informacji dodanych -- lokalizację, do której każdy użytkownik sieci miałby bezpłatny anonimowy dostęp za pomocą standardowych publicznych protokołów sieciowych. W przypadku drugim Licencjobiorca musi podjąć odpowiednie środki ostrożności, by wymieniona kopia Jawna pozostała dostępna we wskazanej lokalizacji przynajmniej przez rok od momentu rozpowszechnienia ostatniej kopii Niejawnej (bezpośredniego lub przez agentów albo sprzedawców) danego wydania.

Zaleca się, choć nie wymaga, aby przed rozpoczęciem rozpowszechniania dużej liczby kopii Dokumentu, Licencjobiorca skontaktował się z jego autorami celem uzyskania uaktualnionej wersji Dokumentu.

4. Modyfikacje

Licencjobiorca może kopiować i rozpowszechniać Zmodyfikowaną wersję Dokumentu na zasadach wymienionych powyżej w punkcie 2 i 3 pod warunkiem ścisłego przestrzegania niniejszej Licencji. Zmodyfikowana wersja pełni wtedy rolę Dokumentu, a więc Licencja dotycząca modyfikacji i rozpowszechniania Zmodyfikowanej wersji przenoszona jest na każdego, kto posiada jej kopię. Ponadto Licencjobiorca musi w stosunku do Zmodyfikowanej wersji spełnić następujące wymogi:

  • A. Użyć na Stronie tytułowej (i na okładkach, o ile istnieją) tytułu innego niż tytuł Dokumentu i innego niż tytuły poprzednich wersji (które, o ile istniały, powinny zostać wymienione w Dokumencie, w sekcji Historia). Tytułu jednej z ostatnich wersji Licencjobiorca może użyć, jeżeli jej wydawca wyrazi na to zgodę.

  • B. Wymienić na Stronie tytułowej, jako autorów, jedną lub kilka osób albo jednostek odpowiedzialnych za autorstwo modyfikacji Zmodyfikowanej wersji, a także przynajmniej pięciu spośród pierwotnych autorów Dokumentu (wszystkich, jeśli było ich mniej niż pięciu).

  • C. Umieścić na Stronie tytułowej nazwę wydawcy Zmodyfikowanej wersji.

  • D. Zachować wszelkie noty o prawach autorskich zawarte w Dokumencie.

  • E. Dodać odpowiednią notę o prawach autorskich dotyczących modyfikacji obok innych not o prawach autorskich.

  • F. Bezpośrednio po notach o prawach autorskich, zamieścić notę licencyjną zezwalającą na publiczne użytkowanie Zmodyfikowanej wersji na zasadach niniejszej Licencji w postaci podanej w Załączniku poniżej.

  • G. Zachować w nocie licencyjnej pełną listę Sekcji niezmiennych i wymaganych Treści okładki podanych w nocie licencyjnej Dokumentu.

  • H. Dołączyć niezmienioną kopię niniejszej Licencji.

  • I. Zachować sekcję zatytułowaną "Historia" oraz jej tytuł i dodać do niej informację dotyczącą przynajmniej tytułu, roku publikacji, nowych autorów i wydawcy Zmodyfikowanej wersji zgodnie z danymi zamieszczonymi na Stronie tytułowej. Jeżeli w Dokumencie nie istnieje sekcja pod tytułem "Historia", należy ją utworzyć, podając tytuł, rok, autorów i wydawcę Dokumentu zgodnie z danymi zamieszczonymi na stronie tytułowej, a następnie dodając informację dotyczącą Zmodyfikowanej wersji, jak opisano w poprzednim zdaniu.

  • J. Zachować wymienioną w Dokumencie (jeśli taka istniała) informację o lokalizacji sieciowej, publicznie dostępnej Jawnej kopii Dokumentu, a także o podanych w Dokumencie lokalizacjach sieciowych poprzednich wersji, na których został on oparty. Informacje te mogą się znajdować w sekcji "Historia". Zezwala się na pominięcie lokalizacji sieciowej prac, które zostały wydane przynajmniej cztery lata przed samym Dokumentem, a także tych, których pierwotny wydawca wyraża na to zgodę.

  • K. W każdej sekcji zatytułowanej "Podziękowania" lub "Dedykacje" zachować tytuł i treść, oddając również ton każdego z podziękowań i dedykacji.

  • L. Zachować wszelkie Sekcje niezmienne Dokumentu w niezmienionej postaci (dotyczy zarówno treści, jak i tytułu). Numery sekcji i równoważne im oznaczenia nie są traktowane jako należące do tytułów sekcji.

  • M. Usunąć wszelkie sekcje zatytułowane "Adnotacje". Nie muszą one być załączane w Zmodyfikowanej wersji.

  • N. Nie nadawać żadnej z istniejących sekcji tytułu "Adnotacje" ani tytułu pokrywającego się z jakąkolwiek Sekcją niezmienną.

Jeżeli Zmodyfikowana wersja zawiera nowe sekcje początkowe lub dodatki stanowiące Sekcje drugorzędne i nie zawierające materiału skopiowanego z Dokumentu, Licencjobiorca może je lub ich część oznaczyć jako sekcje niezmienne. W tym celu musi on dodać ich tytuły do listy Sekcji niezmiennych zawartej w nocie licencyjnej Zmodyfikowanej wersji. Tytuły te muszą być różne od tytułów pozostałych sekcji.

Licencjobiorca może dodać sekcję "Adnotacje", pod warunkiem, że nie zawiera ona żadnych treści innych niż adnotacje dotyczące Zmodyfikowanej wersji -- mogą to być na przykład stwierdzenia o recenzji koleżeńskiej albo o akceptacji tekstu przez organizację jako autorytatywnej definicji standardu.

Na końcu listy Treści okładki w Zmodyfikowanej wersji, Licencjobiorca może dodać fragment "do umieszczenia na przedniej okładce" o długości nie przekraczającej pięciu słów, a także fragment o długości do 25 słów "do umieszczenia na tylnej okładce". Przez każdą jednostkę (lub na mocy ustaleń przez nią poczynionych) może zostać dodany tylko jeden fragment z przeznaczeniem na przednią okładkę i jeden z przeznaczeniem na tylną. Jeżeli Dokument zawiera już treść okładki dla danej okładki, dodaną uprzednio przez Licencjobiorcę lub w ramach ustaleń z jednostką, w imieniu której działa Licencjobiorca, nowa treść okładki nie może zostać dodana. Dopuszcza się jednak zastąpienie poprzedniej treści okładki nową pod warunkiem wyraźnej zgody poprzedniego wydawcy, od którego stara treść pochodzi.

Niniejsza Licencja nie oznacza, iż autor (autorzy) i wydawca (wydawcy) wyrażają zgodę na publiczne używanie ich nazwisk w celu zapewnienia autorytetu jakiejkolwiek Zmodyfikowanej wersji.

5. Łączenie dokumentów

Licencjobiorca może łączyć Dokument z innymi dokumentami wydanymi na warunkach niniejszej Licencji, na warunkach podanych dla wersji zmodyfikowanych w części 4 powyżej, jednak tylko wtedy, gdy w połączeniu zostaną zawarte wszystkie Sekcje niezmienne wszystkich oryginalnych dokumentów w postaci niezmodyfikowanej i gdy będą one wymienione jako Sekcje niezmienne połączenia w jego nocie licencyjnej.

Połączenie wymaga tylko jednej kopii niniejszej Licencji, a kilka identycznych Sekcji niezmiennych może zostać zastąpionych jedną. Jeżeli istnieje kilka Sekcji niezmiennych o tym samym tytule, ale różnej zawartości, Licencjobiorca jest zobowiązany uczynić tytuł każdej z nich unikalnym poprzez dodanie na jego końcu, w nawiasach, nazwy oryginalnego autora lub wydawcy danej sekcji, o ile jest znany, lub unikalnego numeru. Podobne poprawki wymagane są w tytułach sekcji na liście Sekcji niezmiennych w nocie licencyjnej połączenia.

W połączeniu Licencjobiorca musi zawrzeć wszystkie sekcje zatytułowane "Historia" z dokumentów oryginalnych, tworząc jedną sekcję "Historia". Podobnie ma postąpić z sekcjami "Podziękowania" i "Dedykacje". Wszystkie sekcje zatytułowane "Adnotacje" należy usunąć.

6. Zbiory dokumentów

Licencjobiorca może utworzyć zbiór składający się z Dokumentu i innych dokumentów wydanych zgodnie z niniejszą Licencją i zastąpić poszczególne kopie Licencji pochodzące z tych dokumentów jedną kopią dołączoną do zbioru, pod warunkiem zachowania zasad Licencji dotyczących kopii dosłownych we wszelkich innych aspektach każdego z dokumentów.

Z takiego zbioru Licencjobiorca może wyodrębnić pojedynczy dokument i rozpowszechniać go niezależnie na zasadach niniejszej Licencji, pod warunkiem zamieszczenia w wyodrębnionym dokumencie kopii niniejszej Licencji oraz zachowania zasad Licencji we wszystkich aspektach dotyczących dosłownej kopii tego dokumentu.

7. Zestawienia z pracami niezależnymi

Kompilacja Dokumentu lub jego pochodnych z innymi oddzielnymi i niezależnymi dokumentami lub pracami nie jest uznawana za Zmodyfikowaną wersję Dokumentu, chyba że odnoszą się do niej jako do całości prawa autorskie. Taka kompilacja jest nazywana zestawieniem, a niniejsza Licencja nie dotyczy samodzielnych prac skompilowanych z Dokumentem, jeśli nie są to pochodne Dokumentu.

Jeżeli do kopii Dokumentu odnoszą się wymagania dotyczące Treści okładki wymienione w części 3 i jeżeli Dokument stanowi mniej niż jedną czwartą całości zestawienia, Treść okładki Dokumentu może być umieszczona na okładkach zamykających Dokument w obrębie zestawienia. W przeciwnym razie Treść okładki musi się pojawić na okładkach całego zestawienia.

8. Tłumaczenie

Tłumaczenie jest uznawane za rodzaj modyfikacji, a więc Licencjobiorca może rozpowszechniać tłumaczenia Dokumentu na zasadach wymienionych w punkcie 4. Zastąpienie Sekcji niezmiennych ich tłumaczeniem wymaga specjalnej zgody właścicieli prawa autorskiego. Dopuszcza się jednak zamieszczanie tłumaczeń wybranych lub wszystkich Sekcji niezmiennych obok ich wersji oryginalnych. Podanie tłumaczenia niniejszej Licencji możliwe jest pod warunkiem zamieszczenia także jej oryginalnej wersji angielskiej. W przypadku niezgodności pomiędzy zamieszczonym tłumaczeniem a oryginalną wersją angielską niniejszej Licencji moc prawną ma oryginalna wersja angielska.

9. Wygaśnięcie

Poza przypadkami jednoznacznie dopuszczonymi na warunkach niniejszej Licencji nie zezwala się Licencjobiorcy na kopiowanie, modyfikowanie, czy rozpowszechnianie Dokumentu ani też na cedowanie praw licencyjnych. We wszystkich pozostałych wypadkach każda próba kopiowania, modyfikowania lub rozpowszechniania Dokumentu albo cedowania praw licencyjnych jest nieważna i powoduje automatyczne wygaśnięcie praw, które licencjobiorca nabył z tytułu Licencji. Niemniej jednak w odniesieniu do stron, które już otrzymały od Licencjobiorcy kopie albo prawa w ramach niniejszej Licencji, licencje nie zostaną anulowane, dopóki strony te w pełni się do nich stosują.

10. Przyszłe wersje Licencji

W miarę potrzeby Free Software Foundation może publikować nowe poprawione wersje GNU Free Documenation License. Wersje te muszą pozostawać w duchu podobnym do wersji obecnej, choć mogą się różnić w szczegółach dotyczących nowych problemów czy zagadnień. Patrz http://www.gnu.org/copyleft/. Każdej wersji niniejszej Licencji nadaje się wyróżniający ją numer. Jeżeli w Dokumencie podaje się numer wersji Licencji, oznaczający, iż odnosi się do niego podana "lub jakakolwiek późniejsza" wersja licencji, Licencjobiorca ma do wyboru stosować się do postanowień i warunków albo tej wersji, albo którejkolwiek wersji późniejszej opublikowanej oficjalnie (nie jako propozycja) przez Free Software Foundation. Jeśli Dokument nie podaje numeru wersji niniejszej Licencji, Licencjobiorca może wybrać dowolną wersję kiedykolwiek opublikowaną (nie jako propozycja) przez Free Software Foundation.

Załącznik: Jak zastosować tę Licencję dla swojego dokumentu.

Aby zastosować tę Licencję w stosunku do dokumentu swojego autorstwa, dołącz kopię Licencji do dokumentu i zamieść następującą informację o prawach autorskich i uwagi o licencji bezpośrednio po stronie tytułowej.

Copyright (c) ROK TWOJE IMIE I NAZWISKO Udziela się zezwolenia do kopiowania rozpowszechniania i/lub modyfikację tego dokumentu zgodnie z zasadami Licencji GNU Wolnej Dokumentacji w wersji 1.1 lub dowolnej póź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łączona jest w sekcji zatytułowanej "GNU Free Documentation License"

Jeśli nie zamieszczasz Sekcji Niezmiennych, napisz "nie zawiera Sekcji Niezmiennych" zamiast spisu sekcji niezmiennych. Jeś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 postąp z "Tekstem na Tylnej Okładce"

Jeśli w twoim dokumencie zawarte są nieszablonowe przykłady kodu programu, zalecamy abyś także uwolnił te przykłady wybierając licencję wolnego oprogramowania, taką jak Powszechna Licencja Publiczna GNU, w celu zapewnienia możliwości ich użycia w wolnym oprogramowaniu.