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: <feedback@pld-linux.org>

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

# mount /proc