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.

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.

Osoby zainteresowane udostępnianiem serwera lustrzanego przy pomocy protokołu RSYNC proszone są o kontakt z nami w celu uzyskania szczeg�łowych informacji: <[email protected]>

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.

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.

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.

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

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

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

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.

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

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

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

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

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.

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 '*'

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

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.

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.

Do zarządzania pakietami (instalacja, deinstalacja, uzyskiwanie informacji) używa się specjalnych program�w zwanych menadżerami 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”.

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

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

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.

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

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.

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.

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

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"

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

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

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.

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.

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

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

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.

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

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.

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.

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.

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

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

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.

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.

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.

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.

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

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

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

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.

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.

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

# rpm -qa --last

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

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

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

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.

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

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.

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

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

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.

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.

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 (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”.

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.

Kiedy już skonfigurujemy nasz bootloader wydajemy polecenie lilo:

# lilo
Added pld *

następnie restartujemy system.

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

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

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 (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”.

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.

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.

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.

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

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

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.

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:

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.

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

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.

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

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.

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

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

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.

Istnieją dwie metody załadowania modułï¿½w:

Obydwie metody zostaną przedstawione w dalszych rozdziałach.

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

.

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:

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

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.

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.

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

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:

Przykładowa konfiguracja:

alias eth0 8139too
alias scsi_hostadapter sata_sil
alias char-major-116 snd
alias snd-card-0 snd-intel8x0

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.

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.

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.

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.

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

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

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