Podstawowe informacje

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

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

Założenia PLD

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

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

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

Poniżej przedstawiono zestawienie najciekawszych cech systemu.

System

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

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

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

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

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

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

Bezpieczeństwo

• domyślne jądro zawiera grsecurity

• restrykcyjne uprawnienia dla użytkowników

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

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

Sieć

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

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

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

Pakiety

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

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

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

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

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

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

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

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

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

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

Cechy użytkowe

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

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

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

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

FTP - serwer podstawowy

• FUH KERNEL, VNET.sk, Bratysława, Słowacja - ftp://ftp.pld-linux.org/ , ftp://ftp.sk.pld-linux.org/ ,

FTP - serwery lustrzane

• Gdańsk, Polska - ftp://ftp2.pld-linux.org/

• Uniwersytet Kardynała Stefana Wyszyńskiego, Polska - ftp://ftp3.pld-linux.org/ , ftp://ftp.csi.pld-linux.org/

• ATM S.A., Warszawa, Polska - ftp://ftp4.pld-linux.org/ , ftp://ftp.atm.pld-linux.org/

• Uniwersytet Warszawski, Wydział Prawa i Administracji, Polska - ftp://ftp5.pld-linux.org/ , ftp://ftp.wpia.pld-linux.org/

• TASK, Gdańsk, Polska - ftp://ftp6.pld-linux.org/ , ftp://ftp.task.pld-linux.org/

• Politechnika Wrocławska, Polska - ftp://ftp.pwr.wroc.pl/pld/

• ICM, Polska - ftp://ftp.icm.edu.pl/pub/linux/distributions/pld-linux/

• Bratysława, Słowacja - ftp://spirit.bentel.sk/mirrors/PLD

HTTP - serwer podstawowy

• FUH KERNEL, VNET.sk, Bratysława, Słowacja - http://ftp.pld-linux.org/

HTTP - serwery lustrzane

• Gdańsk, Polska - http://ftp2.pld-linux.org/

• ATM S.A., Warszawa, Polska - http://ftp4.pld-linux.org/

• TASK, Gdańsk, Polska - http://ftp.task.pld-linux.org/

• Bratysława, Słowacja - http://spirit.bentel.sk/PLD/

RSYNC

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>

Instalator

Nośniki na których umieszczany jest instalator:

• Główna płyta CD (base iso)

  Jest to pierwsza z pełnych płyt CD, wystarcza do zainstalowania najważniejszych pakietów, aby zainstalować całość dystrybucji musisz zaopatrzyć się w pozostałe płyty. Lista serwerów z których pobierzemy obrazy ISO znajduje się w sekcja Źródła obrazów ISO w rozdział Zasoby sieciowe PLD.

• Płyta MINI-ISO

  Miniaturowa wersja dystrybucji przystosowana do nagrania płyty typu MINI-CD (płyty o średnicy 8cm). Zawiera najbardziej podstawowe pakiety. Lista serwerów z których pobierzemy obraz MINI-ISO znajduje się w sekcja Źródła obrazów ISO w rozdział Zasoby sieciowe PLD.

• Dyskietki

  Mamy do dyspozycji kilka dyskietek zawierających instalator lub dodatkowe moduły jądra. Oprócz nich konieczne będzie jeszcze jakieś źródło pakietów (sieć/CD-ROM/dysk twardy).

  Główne obrazy dyskietek (bootdisk_cd.img, bootdisk_net.img, bootdisk_pcmcia.img) obsługują jedynie najpowszechniej używany sprzęt, jeśli nasz nie jest obsługiwany, to instalator poprosi o jedną z dodatkowych dyskietek z modułami jądra. Z tego względu na wszelki wypadek można pobrać pliki o nazwie addons{$numer}.img

  Obraz dyskietki i resztę pakietów możemy pobrać z głównego serwera lub jednego z serwerów lustrzanych, listę adresów znajdziemy w sekcja Serwery z pakietami w rozdział Zasoby sieciowe PLD. Przykładowo użyjemy adresu: ftp.pld-linux.org/dists/{$wersja_PLD}/PLD/{$arch}/PLD/images/ ({$wersja_PLD} to interesująca nas wersja PLD zaś {$arch} oznacza architekturę procesora). Dostępne są obrazy dyskietek dla następujących architektur: i386, i586, i686 oraz athlon.

Instalacja z sieci

Jeżeli masz wystarczająco szybkie łącze możesz zainstalować system z sieci. W tym procesie mamy do wyboru instalację pakietów przy pomocy protokołów: FTP, HTTP lub NFS.

Możemy użyć MINI-ISO, pierwszej płyty instalacyjnej lub dyskietki. W przypadku dyskietki musimy użyć obrazu bootdisk_net.img lub bootdisk_pcmcia.img (urządzenia sieciowe PCMCIA).

Możemy też zainstalować rdzeń systemu z MINI-ISO lub pierwszej płyty instalacyjnej, a następnie kontynuować proces instalacji za pośrednictwem sieci z działającego już systemu.

Instalacja z płyty CD-ROM

Używamy w tym celu pierwszej z pełnych płyt CD (base) lub wszystkich dostępnych obrazów.

Jeśli BIOS naszej maszyny nie potrafi uruchamiać systemu operacyjnego z płyty CD, musimy wspomóc się dyskietką i obrazem bootdisk_cd.img. Po uruchomieniu instalatora z dyskietki jako źródło pakietów wybieramy CD-ROM.

Instalacja z dysku twardego

Istnieje możliwość instalacji z lokalnego dysku twardego, użyjemy do tego obrazu dyskietki bootdisk_cd.img. Musimy jeszcze przegrać zawartość obrazu płyty CD do katalogu na jednej z partycji dyskowych.

Dodatkowe informacje

Pobrane z internetu obrazy dyskietki nagrywamy poleceniem

# dd if=bootdisk.img of=/dev/fd0

lub przy pomocy programu rawrite.exe pod systemem Windows/DOS. Program rawrite.exe możemy pobrac przykładowo z ftp.pld-linux.org/dists/{$wersja_PLD}/PLD/{$arch}/PLD/dosutils/.

PLD jest przygotowane dla wielu architektur sprzętowych, zanim więc przystąpisz do instalacji upewnij się że wybierzesz właściwą wersję. Więcej na ten temat można znaleźć w sekcja Architektury pakietów w rozdział Zarządzanie pakietami

Wstęp

Jeżeli pierwszy raz instalujesz Linuksa, lub jesteś bardzo początkującym użytkownikiem warto abyś wiedział kilka rzeczy. Na początek zapoznaj się ze sposobem oznaczania dysków i partycji opisanych dokładniej w sekcja Nazewnictwo urządzeń masowych w rozdział Pamięci masowe

Kiedy już zaopatrzymy się we właściwy nośnik, uruchamiamy komputer i czekamy na pojawienie się ekranu instalatora. Zaczniemy od poznania sposobu poruszania się po instalatorze, do przesuwania/przewijania tekstu bądź opcji używasz "strzałek" na klawiaturze, wybór akceptujesz klawiszem ENTER. Klawiszem TAB poruszasz się pomiędzy opcjami instalatora.

Zaczynamy

Widząc standardowy ekran zgłoszeniowy naciskamy ENTER i czekamy aż uruchomi się instalator. Wybieramy język - w naszym przypadku polski. Przeczytawszy krótkie wprowadzenie jesteśmy w instalatorze.

Teraz pojawiło nam się menu, w którym mamy do wyboru sposoby instalacji. Jeżeli posiadasz większą niż podstawową wiedzę nt. linuksa możesz wybrać "Standartowe UI", gdzie większość opcji umieszczona jest na jednym przejrzystym ekranie. Także kolejne opcje pozwolą ustawić partycje, wybrać pakiety, prekonfigurować system oraz ustawić bootmanagera. Do edycji partycji mamy do wyboru program fdisk lub parted.

My wybieramy jednak opcję "Automagiczny Instalator", który sam przeprowadzi nas gładko przez proces instalacji.

Źródło

Partycje

Nadszedł czas na konfigurowanie partycji. Możemy wybrać proponowane przez instalator ustawienia albo skorzystać z bardzo przyjemnego narzędzia o nazwie parted. Jako, że na dysku możemy mieć inny system (Windows) lepiej dla bezpieczeństwa ustawić partycje ręcznie.

Wybierając opcję "ustaw partycje ręcznie" przechodzimy do parted

Interfejs jak widać jest bardzo prosty i intuicyjny. Jeżeli mamy jakieś wolne miejsce możemy utworzyć nową partycje, stworzyć macierz RAID, albo przeedytować istniejącą już partycję. UWAGA! Jeżeli posiadasz nowy sprzęt, możesz mieć problemy z instalacją systemu na raidzie. Problem ten wynika z tego, iż system, który właśnie instalujesz może nie obsługiwać Twojego raida.

Wchodząc w menu "Akcje" przechodzimy do menu edycji partycji.

Możemy zmienić punkt montowania, system plików, rozmiar albo usunąć partycję.

Po dokonaniu edycji tablicy partycji, oraz ustawieniu punktów montowań możemy opuścić parted i przejść do dalszej części instalacji.

Wybór pakietów

Przechodzimy teraz do kolejnej części instalacji, czyli wyboru pakietów.

Mamy do wyboru następujące gotowe zestawy pakietów. Przy każdym zestawie jest jego krótka charakterystyka, więc nie ma sensu się rozpisywać. Wybieramy taki zestaw jaki nam najbardziej pasuje, jednak nie warto przesadzać z pakietami, np stacja robocza z gnome nie będzie bardzo nadawała się na router. Po zainstalowaniu systemu będziesz zmuszony usunąć masę niepotrzebnych pakietów, przez co stracisz mnóstwo czasu.

Dalej mamy możliwość szczegółowej selekcji pakietów, jeżeli ufamy instalatorowi możemy pominąć ten krok, jeżeli natomiast znamy się trochę na linuksie wybieramy powyższą opcję i wchodzimy do menu.

Na ekranie widzimy zaznaczone grupy pakietów, możemy zaznaczać dodatkowe, albo zrezygnować z dotychczas wybranych. Możemy także rezygnować z pojedynczych pakietów z grup wchodząc w opcję standartowe pakiety. Pod linkiem "Wybierz opcjonalne pakiety" widzimy menu dzięki któremu mamy możliwość bardziej spersonalizowanego wyboru interesujących nas pakietów.

Kolejnym krokiem jest pytanie czy chcemy zainstalować dokumentację, na które lepiej odpowiedzieć twierdząco. Mamy także możliwość wyboru wersji językowych dokumentacji. Jeżeli nie jesteśmy pewni, możemy zostawić domyślne ustawienia, czyli "ALL", jednak gdy chcemy mieć dokumentację tylko po polsku i angielsku wpisujemy "pl:pl_PL:en:en_US". Należy pamiętać, że może zdarzyć się sytuacja iż pakiet nie ma jeszcze polskiej dokumentacji, więc zawsze warto zaznaczyć język angielski.

Następne kroki to prekonfiguracja instalowanego systemu.

Prekonfiguracja systemu

Dotarliśmy do punktu gdzie musimy ustawić podstawowe parametry instalowanego systemu.

Pierwszym krokiem będzie ustawienie parametrów sieci (jeżeli mamy do niej dostęp). Jeżeli wcześniej wybraliśmy instalację przez sieć, możemy zastosować te same preferencje także w naszym systemie, jeżeli jednak instalujemy z jakiegoś nośnika (cdrom, dysk) należy ręcznie wpisać ustawienia, lub pobrać je z serwera dhcp.

Kolejny krok to ustawienie hasła użytkownika root. Ten punkt chyba nie wymaga komentarza. Należy ustawić w miarę bezpieczne hasło, bo jak wiadomo serwer jest tak bezpieczny jak jego najsłabsze ogniwo :) Możemy również zlecić wygenerowanie hasła instalatorowi.

Następną czynnością jest ustawienie kont(a) użytkowników, możemy zrobić to teraz, albo po instalacji używając polecenia useradd.

Pozostał jeszcze wybór strefy czasowej i synchronizacja (lub nie) zegara systemowego z UTC, i na tym kończymy prekonfigurację systemu.

Bootmanager

Przyszła kolej na ustawienie bootmanagera. Jeżeli pld to nasz jedyny system na dysku możemy pominąć ten krok, w przeciwnym przypadku musimy dodać wpisy innych systemów, aby była możliwość uruchomienia ich przy starcie komputera. Oczywiście jeżeli nie chcemy teraz konfigurować bootmanagera można zawsze to zrobić po ukończeniu instalacji, edytując plik /etc/lilo.conf.

Wybieramy więc opcję "konfiguruj bootloader", która uruchamia skrypt konfigurujący.

Jak widać nie mamy jeszcze żadnych wpisów, wybieramy "Stwórz nową pozycję" aby dodać jakiś system operacyjny. Należy tutaj pamiętać iż wpisujemy istniejące systemy na lokalnych dyskach, oprócz tego, który właśnie instalujemy.

Pierwszym krokiem jest wybór systemu który chcemy ładować. Wybieramy np. DOS, następnie podajemy lokalizacje partycji na jakiej znajduje się system i przechodzimy do konfiguracji wpisu.

Jak widać na powyższym przykładzie, musimy wpisać etykietę - czyli nazwę jaka będzie nam się wyświetlała przy starcie komputera. Nazwa jest dowolna, jednak nie należy przesadzać z długością i lepiej nie używać polskich znaków. Dwa kolejne pola, czyli "system" i "katalog /" mamy już wypełnione automatycznie. Jeżeli dodajemy innego linuksa należy podać lokalizację jądra systemu (kernela) oraz initrd jeśli mamy. W systemie DOS/Windows te pola są zbędne.

Po ustawieniu etykiety i zatwierdzeniu zmian możemy obejrzeć nasz(e) wpis(y). Jeżeli mamy więcej systemów dodajemy je po kolei, po skończeniu opuszczamy konfigurator przechodząc do kolejnej opcji.

Ostatnią rzeczą jaką musimy zrobić aby zakończyć proces konfiguracji bootloadera to wybór urządzenia na jakim ma być on zainstalowany. Najlepszym rozwiązaniem jest instalacja go w MBR (Master Boot Record) dysku z którego jest ładowany system. Jeżeli jednak nie jesteśmy pewni co do tego (lub nie wiemy co to jest MBR) najlepiej zostawić opcję auto, dzięki której instalator sam wybierze najlepsze urządzenie.

Kończenie instalacji

Pozostała nam ostatnia rzecz, czyli instalacja pakietów. W tej części nie będziemy musieli nic robić, oprócz czekania. Więc jeżeli wybraliśmy instalację z sieci i jakiś większy zestaw pakietów możemy zaopatrzyć się w jakąś książkę i poczytać, bo proces instalacji trochę potrwa :)

Słowo komentarza na temat tego, co się dzieje na ekranie:

Tutaj widzimy jak system tworzy partycje, oraz system plików na nich. W zależności od wielkości partycji i szybkości dysku może to trochę potrwać.

Dalej po pobraniu indeksów system przechodzi do instalacji pakietów (więcej o tym co to są indeksy w rozdziale poświęconym poldkowi). To jest najdłuższa część instalacji.

Jeżeli nie wystąpiły żadne błędy zobaczysz taki ekran. Teraz wystarczy tylko zrestartować system, wyciągnąć płytkę/dyskietkę z napędu, bądź ustawić bootowanie z dysku na którym zainstalował się bootmanager (najczęściej /dev/hda) i mamy gotowy system :)

Uruchomienie

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

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

Partycje/woluminy

System możemy zainstalować na klasycznych partycjach dyskowych, woluminach LVM lub programowych macierzach, instalacja z chroot-a daje w tej kwestii dużą swobodę. Opis tworzenia woluminów LVM przedstawiliśmy w sekcja LVM w rozdział Pamięci masowe zaś macierzy w sekcja RAID programowy w rozdział Pamięci masowe. 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 sekcja Nazewnictwo urządzeń masowych w rozdział Pamięci masowe.

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

Systemy plików

Inicjujemy obszar wymiany:

# mkswap /dev/sda1

# mkfs.ext3 /dev/sda2

Zapamiętujemy układ partycji i systemów plików, gdyż będzie on nam potrzebny do prawidłowego skonfigurowania pliku /etc/fstab. Teraz przyszedł czas na utworzenie punktu montowania i podmontowania partycji np.:

# mkdir /pldroot
# mount /dev/sda2 /pldroot

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

Konfiguracja sieci

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

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

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

eth0 default via 10.0.0.254

nameserver 193.192.160.243

# service network restart

Proxy

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

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

Konfiguracja Poldka

Zaczynamy od ustawienia najlepiej dopasowanej architektury instalowanych pakietów, za pomocą opcji _pld_arch w pliku /etc/poldek/repos.d/pld.conf. Więcej o architekturach pakietów w sekcja Architektury pakietów w rozdział Zarządzanie pakietami. Dobrym pomysłem jest ustawienie opcji, umożliwiającej precyzyjne wybieranie alternatywnych pakietów (dla nieco bardziej zaawansowanych):

choose equivalents manually = yes

Teraz tworzymy katalog na indeksy Poldka np.:

# mkdir -p /pldroot/var/cache/poldek-cache

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

Instalacja pakietów

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

Instalację rozpoczynamy od inicjacji bazy danych pakietów:

# rpm --root /pldroot --initdb

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

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

# poldek --root /pldroot

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

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

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

Przygotowanie do instalacji kernela

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

• Montujemy pseudo-system plików /proc:

  # mount /proc /pldroot/proc -o bind

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

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

  Więcej w sekcja Kluczowe pliki w rozdział Konfiguracja systemu.

• Dokonać odpowiednich koniecznych operacji konfiguracyjnych w przypadku korzystania z macierzy RAID (plik /etc/mdadm.conf) lub woluminów LVM (/etc/lvm/lvm.conf).

Instalacja kernela

Musimy wybrać, który kernel zainstalujemy, na początek powinniśmy się zainteresować pakietami: kernel, kernel-grsecurity i ew. ich odmiany z SMP. W wyborze może pomóc nam opis kerneli w sekcja Jądro systemu w rozdział Kernel i urządzenia. Kiedy już wybraliśmy, instalujemy wybrany pakiet:

# poldek --root /pldroot -i kernel

Bootloader

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

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

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

Kiedy konfiguracja jest skończona wydajemy polecenie:

# chroot /pldroot /sbin/lilo

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

timeout 10

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

# chroot /pldroot /sbin/grub

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

Konfigurację bootloadera wyczerpująco przedstawiono w sekcja Wstęp w rozdział Bootloader. 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 sekcja RAID programowy w rozdział Pamięci masowe.

UDEV

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

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

Ping

Najczęściej używanym narzędziem diagnostycznym jest program ping - pozwala on zbadać istnienie połączenia między dwoma komputerami, drogę pomiędzy nimi, czas potrzebny na przejście pakietu oraz sprawdza czy drugi komputer pracuje w danym momencie w sieci. Przy okazji ping dokonuje tłumaczenia adresu domenowego na numer IP. Program ten jest przydatny do określania stanu sieci i określonych hostów, śledzenia i usuwania problemów sprzętowych, testowania, mierzenia i zarządzania siecią, oraz do badania sieci. Polecenie ping {$nazwa/$numer_IP} wysyła specjalne pakiety ICMP do wskazanego komputera i czeka na odpowiedź. Możemy podawać jako cel adres domenowy lub numer IP. Przy okazji program ten dokonuje tłumaczenia adresu domenowego na numer IP.

$ ping pld-linux.org

PING pld-linux.org (81.0.225.27) 56(84) bytes of data.
64 bytes from 81.0.225.27: icmp_seq=1 ttl=44 time=135 ms
64 bytes from 81.0.225.27: icmp_seq=2 ttl=44 time=99.8 ms
64 bytes from 81.0.225.27: icmp_seq=3 ttl=44 time=149 ms

--- pld-linux.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 99.840/128.084/149.144/20.761 ms

pracę programu przerywamy skrótem ctrl+c

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

Komenda może dać również efekt podobny do poniższego:

[root@g82 ~]# ping google.pl
PING google.pl (216.239.57.99) 56(84) bytes of data.
From 192.168.6.1 icmp_seq=1 Packet filtered
From 192.168.6.1 icmp_seq=2 Packet filtered

--- google.pl ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time
1000ms

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

Traceroute

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

$ traceroute pld-linux.org

traceroute to pld-linux.org (81.0.225.27), 30 hops max, 38 byte packets
 1  192.168.1.1 (192.168.1.1)  0.295 ms  0.608 ms  0.484 ms
 2  217.153.188.173 (217.153.188.173)  1.012 ms  0.648 ms  0.495 ms
 3  217.8.190.153 (217.8.190.153)  30.894 ms  28.983 ms  29.719 ms

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

MTR

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

$ mtr pld-linux.org

Wstęp

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

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

Pakiety w PLD

Elementy systemu operacyjnego dostępne są w tzw. pakietach (pot. "paczkach"). W PLD zastosowano system pakietów RPM (RPM Packet Manager), który został stworzony przez twórców dystrybucji Red Hat Linux. Istnieje możliwość instalacji pakietów RPM przygotowanych dla innych dystrybucji, jednak nie skorzystamy wtedy z dobrodziejstwa zależności dotyczących danego pakietu. Wymagane dodatkowe pakiety należy wtedy zainstalować samodzielnie.

Menadżery pakietów

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

• Poldek

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

• PackageKit

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

• RPM

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

Pobieranie pakietów

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

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

Zależności między pakietami

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

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

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

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

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

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

Ważnymi elementami mechanizmu zależności są tzw. wymagania i własności. Pierwsza z cech wskazuje listę wymaganych dodatkowo elementów (pakietów, plików) do działania instalowanej aplikacji, druga zaś informuje, które z elementów są dostarczane wraz z pakietem. Aby poznać wymagania pakietu posłużymy się Poldkiem w trybie interaktywnym:

poldek:/all-avail> desc -r logrotate

Package:        logrotate-3.7-2
PreReqs:        /bin/sh, fileutils
Requires:       /bin/mail, /bin/sh, config(logrotate) = 3.7-2, crondaemon,
    glibc, libc.so.6, libc.so.6(GLIBC_2.0), libc.so.6(GLIBC_2.1),
    libc.so.6(GLIBC_2.2), libc.so.6(GLIBC_2.3), libpopt.so.0, libselinux,
    libselinux.so.1, popt
RPMReqs:        rpmlib(CompressedFileNames) <= 3.0.4-1,
    rpmlib(PayloadFilesHavePrefix) <= 4.0-1,
    rpmlib(PayloadIsBzip2) <= 3.0.5-1

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)

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]

Zawartość pakietów

Pakiety mogą zawierać wiele małych programów i/lub bibliotek albo jeden duży program może być podzielony na kilka pakietów. W PLD najczęściej stosowane jest to drugie rozwiązanie: osobno przechowywane są pliki uruchomieniowe, osobno biblioteki, a jeszcze osobno moduły, wtyczki i dodatki. Ponadto jeśli tylko można to są umieszczane w pojedynczych pakietach, dzięki temu unikamy dużych, zbiorczych paczek. Pozwala to instalować tylko to co jest nam potrzebne. Przykładowo jeśli program ABC wymaga bibliotek programu XYZ to instalujemy tylko pakiet z bibliotekami tego drugiego. Skraca to czas instalacji (zwłaszcza przy pobieraniu plików z Internetu) i pozwala oszczędzać miejsce na dysku.

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

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

Aby ułatwić poruszanie się w tym gąszczu, możemy posłużyć się opisami pakietów:

poldek:/all-avail> desc proftpd-inetd

poldek:/all-avail> desc -f proftpd-inetd

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

Konwencja nazw pakietów w PLD

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

Metapakiety

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

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

Komunikaty

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

Adding group exim GID=79.
Adding user exim UID=79.
Run "/etc/rc.d/init.d/exim start" to start exim daemon.

Wpływ pakietów na pracę systemu

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

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

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

Wpływ pakietów na pliki konfiguracji

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

Kiedy odnajdziemy plik *rpmnew to możemy łatwo sprawdzić czym różni się jego zawartość w stosunku do obecnie używanego pliku konfiguracji. Posłużymy się w tym celu programem diff z pakietu diffutils np.:

# diff jakis_plik.conf jakis_plik.conf.rpmnew

W przypadku niektórych programów, po odinstalowaniu pakietu, pozostawiane są jego pliki konfiguracji, posiadają one rozszerzenie ".rpmsave", możemy je zachować lub skasować jeśli uznamy że są nam zbędne.

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

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

Wybór architektury

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

/dists/{$wersjaPLD}/PLD/{$architektura}

Procesory

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

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

Poldek jest dostarczany z właściwie skonfigurowanymi etykietami, są one zdefiniowane w plikach /etc/poldek/source.conf i /etc/poldek/repos.d/pld.conf. Adresy oficjalnych serwerów i mirrorów znajdziemy w sekcja Serwery z pakietami w rozdział Zasoby sieciowe PLD. Etykieta źródła rozpoczyna się od przedrostka określającego wersję dystrybucji, zapisaną małymi literami, poniżej przedstawiono ją jako ciąg {$wersja}, który może mieć wartość np. ra, ac lub th. Ciąg {$arch} to architektura pakietów.

• main: dists/{$wersja}/PLD/{$arch}/PLD/RPMS

• obsolete: dists/{$wersja}/obsolete/{$arch}/RPMS

• test: dists/{$wersja}/test/${arch}/

• ready: dists/{$wersja}/ready/${arch}/

• home: katalog lokalny: ~/rpm/RPMS

Cykl życia pakietu

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

Wstęp

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

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

Budowanie

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

Opis budowania pakietów odnajdziemy w przewodniku dla deweloperów PLD, wszystkie potrzebne informacje odnajdziemy pod adresem pld-linux.org/DevelopingPLD oraz w sekcja Co jest potrzebne w rozdział Możliwa droga do zostania szeregowym developerem PLD.

Zarządzanie

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

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

Wstęp

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

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

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

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

Pliki konfiguracji

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

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

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

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

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

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

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

Konfiguracja pobierania pakietów

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

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 sekcja Proxy w rozdział Podstawy.

Inne opcje

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

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

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

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

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

Tryby pracy

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

Tryb interaktywny

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

poldek>

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

poldek> upgrade

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

poldek> install gnome-theme*

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

Mamy do dyspozycji potoki:

poldek> ls perl* | grep curses

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

poldek> ls perl* | !wc -l

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

Tryb wsadowy

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

$ poldek --help

$ poldek --shcmd="desc apache"

$ ipoldek desc apache

Pierwsze kroki z Poldkiem

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

$ poldek --up

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}

poldek> {$polecenie} -?

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

Zarządzanie pakietami

Mamy dostępne następujące polecenia zarządzania pakietami: operacje instalacji (install), aktualizacji pakietów (upgrade), usuwania pakietów (uninstall), pobierania pakietów bez instalacji (get). Ponadto mamy polecenia do zbierania danych o pakietach: wyświetlanie listy dostępnych (ls), wyświetlenia informacji (desc) oraz przeszukiwania bazy (search). W wielu przypadkach pomocna będzie opcja -t, która przeprowadzi symulację całej operacji, dzięki której dowiemy się jak duże i jak istotne zmiany zostaną dokonane w systemie po operacji. Najczęściej jest używana przy aktualizacji i usuwaniu pakietów.

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

poldek> ls zsh*

poldek> desc zsh

poldek> install zsh

poldek> uninstall zsh

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

Źródła

Poldek ma kilka zdefiniowanych źródeł pakietów w plikach source.conf i repos.d/pld.conf, pierwszy z plików jest głównym plikiem konfiguracji źródeł, drugi zaś zawiera wpisy dla oficjalnych źródeł PLD. Aby wyświetlić listę skonfigurowanych źródeł, wraz użytymi opcjami użyjemy polecenia:

$ poldek -l
ac           ftp://ftp.ac.pld-linux.org/dists/ac/PLD/athlon/PLD/RPMS/  (type=pndir)
ac-ready     ftp://ftp.ac.pld-linux.org/dists/ac/ready/athlon/  (noauto,type=pndir)
ac-supported ftp://ftp.ac.pld-linux.org/dists/ac/supported/athlon/  (noauto,type=pndir)
ac-test      ftp://ftp.ac.pld-linux.org/dists/ac/test/athlon/  (noauto,type=pndir)
ac-updates-general ftp://ftp.ac.pld-linux.org/dists/ac/updates/general/athlon/  (noauto,type=pndir)
ac-updates-security ftp://ftp.ac.pld-linux.org/dists/ac/updates/security/athlon/  (type=pndir)
home         /home/users/qwiat/rpm/RPMS/  (noauto,noautoup,type=dir)

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

$ poldek -n ac -n ac-ready

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

poldek -s /jakis/katalog

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

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

Porady

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

Instalowanie pakietów

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

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

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

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

# rpm -i libghttp-devel-1.0.9-4.i686.rpm
error: failed dependencies:
		libghttp = 1.0.9 is needed by libghttp-devel-1.0.9-4

Tym razem instalacja się nie powiodła, ponieważ pakiet libghttp-devel wymaga zainstalowanego pakietu libghttp. Aby instalacja pakietu się powiodła wykonujemy następujące polecenie:

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

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

Aktualizowanie pakietów

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

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

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

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

Odinstalowywanie pakietów

Zainstalowaliśmy kilka pakietów, teraz możemy spróbować je odinstalować - wykonujemy to przy użyciu opcji -e.

# rpm -e libghttp-devel-1.0.9-4.i686.rpm libghttp-1.0.9-4.i686.rpm
error: package libghttp-devel-1.0.9-4.i686.rpm is not installed
error: package libghttp-1.0.9-4.i686.rpm is not installed

Cóż tu się stało? Podano nieprawidłową nazwę pakietu, należy pamiętać o tym, że przy odinstalowaniu pakietu nie podaje się rozszerzenia pakietu. Poprawne polecenie przedstawiono poniżej:

# rpm -e libghttp-devel libghttp

lub:

# rpm -e libghttp-devel-1.0.9-4 libghttp-1.0.9-4

Uwaga: pierwszy przykład stosuje się w przypadku zainstalowania jednej wersji pakietu, drugi zaś używa się w przypadku kilku różnych (np. dwie różne wersje jądra).

Uwagi

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

Uruchamianie Poldka

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

use sudo = yes

Podpisy pakietów

W PLD mamy możliwość kontrolowania podpisów pakietów, dzięki czemu zyskujemy pewność, że instalujemy pakiety z zaufanego źródła. Importując klucz klucz publiczny GPG unikamy również zasypywania następującymi komunikatami:

Nagłówek V3 sygnatura DSA: NOKEY, key ID 1bbd5459

Zaczynamy od zaimportowania klucza publicznego (dla Ac) z serwera FTP:

rpm --import ftp://ftp.pld-linux.org/dists/2.0/PLD-2.0-Ac-GPG-key.asc

signed = yes

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

Lista ostatnio instalowanych pakietów

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

# rpm -qa --last

Odinstalowanie "opornych" pakietów

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

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

Repackage - bezpieczna aktualizacja

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

%_repackage_all_erasures    1

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

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

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

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

Kontrola integralności systemu

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

Aby uzyskać listę zmodyfikowanych plików użyjemy programu rpm:

# rpm --verify --all
......G.   /etc/cups
S.5....T   /usr/lib/libsasl2.so.2.0.22
S....... c /etc/xml/catalog
.M...UG. c /etc/samba/smb.conf

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

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

# poldek --reinstall --pset pakiety.txt

Naprawa bazy RPM

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

# lsof | grep /var/lib/rpm

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

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

# rpm --rebuilddb

# rpm -qa

Reinstalacja wszystkich pakietów - zmiana architektury

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

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

Parametry jadra

Oba bootloadery pozwalają na przekazywanie do jądra specjalnych parametrów, dzięki którym możemy wpływać na start lub pracę systemu jeszcze przed jego załadowaniem. Parametry przekazane przed startem systemu będą przesłaniać te użyte w konfiguracji bootloadera. W poniższej tabeli przedstawiono najczęściej używane opcje.

Przekazywanie parametrów jądra wygląda podobnie w obu wypadkach, po włączeniu specjalnego trybu w bootloaderze otrzymujemy wiersz, na końcu którego dopisujemy potrzebne nam parametry lub modyfikować istniejące. Poniżej przedstawiamy przykładowe dodanie parametru init w bootloaderze Grub:

grub append> root=/dev/sda2 init=/bin/sh

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 sekcja Parametry jądra w rozdział Kernel i urządzenia.

MBR czy bootsector?

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

Frame buffer (bufor ramki)

Frame Buffer (bufor ramki) to m.in. mechanizm pozwalający na pracę konsoli w wyższych rozdzielczościach. Aby go włączyć przekazujemy parametr vga przy uruchomieniu bootloadera lub dodajemy go do pliku konfiguracji np.:

vga=0x303

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.

Konfiguracja podstawowa

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

boot=/dev/hda
read-only
lba32

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

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

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

Opcję root szerzej opisano w sekcja Wstęp. Z nazewnictwem urządzeń masowych zapoznamy się w sekcja Nazewnictwo urządzeń masowych w rozdział Pamięci masowe.

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

Inne systemy operacyjne

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

other=/dev/hda3
	label=windows

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

default=pld

Frame Buffer

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

vga=0x303

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

Graficzne menu

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

Wskazujemy interesujący nas obrazek:

bitmap = /boot/lilo-pldblue8.bmp

bmp-table = 17,9;1,14,16,4
bmp-colors = 0,213,137;152,24,1
bmp-timer = 2,29;152,52,1

Zakończenie

Kiedy już skonfigurujemy nasz bootloader wydajemy polecenie lilo:

# lilo
Added pld *

Nazewnictwo urządzeń

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

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

Urządzenia masowe opisano szerzej w sekcja Nazewnictwo urządzeń masowych w rozdział Pamięci masowe.

Konfiguracja podstawowa

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

timeout 15

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

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

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

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

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

Instalacja

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

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

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.

grub> quit

Inne systemy operacyjne

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

title Windows
rootnoverify (hd0,1)
chainloader +1

default 2

Frame Buffer

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

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

Graficzne menu

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

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

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

foreground  = ffffff
background  = 000000

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

Bezpieczeństwo bootloadera

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

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

Uwagi

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

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

Wstęp

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

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

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

Podstawowa konfiguracja

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

DOIT=yes

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

LOADER=grub

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

BOOT=mbr

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

DEFAULT=pld

Tworzenie "obrazów"

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

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

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

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

TYPE=dos
ROOT=/dev/hda1

Na koniec generujemy bootloader używając polecenia rc-boot.

# rc-boot
pld taken as defult image
image: pld * is linux on /dev/hda3
image: windows is dos on /dev/hda1

Uwagi

Program rc-boot nadpisze plik konfiguracji wybranego bootloadera, zanim więc użyjemy tego narzędzia powinniśmy na wszelki wypadek zrobić kopię bezpieczeństwa właściwego pliku.

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

Koncepcja jądra w PLD

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

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

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

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

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

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

Informacje o używanym jądrze

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

# uname -r
2.6.14.7-5

# zcat /proc/config.gz

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

Rodzaje jąder systemowych

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

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

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

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

Aktualizacja

Kernel jest kluczową częścią systemu, dlatego zaleca się inaczej podejść do jego aktualizacji niż do innych pakietów, dobrym zwyczajem jest instalacja nowej wersji, zamiast aktualizacji np.:

poldek> install -I kernel-2.6.14.7-5

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

Zależności

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

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

Uwagi

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

Czym są?

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

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

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

Istnieją dwie metody załadowania modułów:

• statyczna - metoda tradycyjna, polega na wskazaniu modułów do załadowania przez administratora

• dynamiczna - automatyczne ładowanie modułów, kiedy urządzenie zostaje wykryte

Konfiguracja modułów

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

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

alias eth0 8139too

alias parport_lowlevel 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

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

blacklist rivafb

Określenie modułu dla urządzenia

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

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

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

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

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

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

  # dmesg | less

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

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

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

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

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

• Po nazwie modułu: modprobe -l {$słowo_kluczowe} - tak możemy próbować odnaleźć moduł wg. szukanego klucza np:

  # modprobe -l *snd* /lib/modules/2.6.11.6-4/kernel/sound/pcmcia/pdaudiocf/snd-pdaudiocf.ko.gz /lib/modules/2.6.11.6-4/kernel/sound/pcmcia/vx/snd-vxp440.ko.gz /lib/modules/2.6.11.6-4/kernel/sound/pcmcia/vx/snd-vx-cs.ko.gz /lib/modules/2.6.11.6-4/kernel/sound/pcmcia/vx/snd-vxpocket.ko.gz /lib/modules/2.6.11.6-4/kernel/sound/drivers/snd-serial-u16550.ko.gz /lib/modules/2.6.11.6-4/kernel/sound/drivers/mpu401/snd-mpu401-uart.ko.gz /lib/modules/2.6.11.6-4/kernel/sound/drivers/mpu401/snd-mpu401.ko.gz

• modinfo - program ten zwraca informacje o module, którego nazwę podajemy jako parametr. Program jest pomocny jeśli zawęziliśmy listę pasujących modułów do kilku pozycji.

Zarządzanie modułami

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

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

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

Wczytanie modułu do pamięci:

# modprobe ne2k-pci

# modprobe -r ne2k-pci

# 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

# modprobe -l

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

/etc/modules

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

echo "via82cxxx_audio" >> /etc/modules

/etc/modprobe.conf

W sekcja 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

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

• ide_hostadapter, scsi_hostadapter - aliasy do modułów kontrolerów pamięci masowych, używane są m.in. przez skrypt geninitrd.

• char-major-116, snd-card-{$Nr}, char-major-14, sound-* - aliasy dla modułów kart muzycznych (ALSA).

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

Instalacja

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

# poldek -i udev
# poldek -e dev

Konfiguracja

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

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

UDEV_STARTER="udevsynthesize"

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

Udev w praktyce

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

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

blacklist rivafb
blacklist nvidiafb

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

Uwagi

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

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

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

Wstęp

W PLD wszystkie możliwe sterowniki są dostępne w postaci tzw. modułów, przez co nie są one "widoczne" dla jądra w trakcie startu systemu. Aby system wystartował wymaganych jest kilka modułów i innych komponentów koniecznych do zamontowania głównego systemu plików (root filesystem):

• moduły kontrolera urządzeń masowych (IDE/SATA/SCSI) np.: sata_nv, sata_sil, sd_mod

• systemu plików na głównej partycji systemowej np.: xfs, reiserfs

• elementy konieczne do złożenia woluminów opartych o LVM lub programowy RAID

Jedynym sposobem dostarczenia tych sterowników jest umieszczenie ich w specjalnym "obrazie" zwanym initrd (initial ramdisk). Obraz ten jest plikiem wczytywanym przez bootloader, tak więc dodatkowo musimy właściwie skonfigurować bootloader - wskazać położenie obrazu. Obraz przechowywany jest w katalogu /boot i ma nazwę initrd-{$wersja_jądra}.gz, do niego zaś prowadzi łącze o nazwie initrd.

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

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

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

Przygotowanie

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

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

# mount /proc

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

Automatyczne generowanie initrd

W razie potrzeby edytujemy plik /etc/sysconfig/geninitrd i ustawiamy jaki rodzaj urządzenia (SCSI, IDE, RAID) ma być automatycznie wykrywany:

## Do install SCSI modules (if / is on SCSI partition)?
PROBESCSI=yes

## Do install IDE modules (if / is on IDE partition)?
PROBEIDE=yes

## Do install RAID modules (if RAID is used)?
PROBERAID=yes

geninitrd [opcje] {$initrd} {$wersja_jądra} np.:

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

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

Ręczne generowanie initrd

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

Możemy wpisać listę koniecznych modułów do odpowiedniej sekcji w pliku /etc/sysconfig/geninitrd:

## Basic modules to be loaded
BASICMODULES=""

## Modules that should be loaded before anything (i.e. jbd for ext3)
PREMODS=""

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

Dużym ułatwieniem zadania jest automatyczne dołączanie modułów zależnych od wskazanego (o ile takie są). Poniżej zamieszczono przykładowe wywołanie geninitrd dla systemu plików ext3 i kontrolera IDE PDC20268 firmy Promise:

# geninitrd -v --with=ext3 --with=pdc202xx_new  /boot/initrd-2.6.16.35-1.gz 2.6.16.35-1

Gdy zawiedzie geninitrd

Możemy zmodyfikować zawartość obrazu wygenerowanego przez geninitrd, aby to zrobić rozpoczynamy od skopiowania initrd w inne miejsce i rozpakowania go:

# gunzip initrd-2.6.16.35-1.gz

mkdir /tmp/initrd-src
# mount -o loop initrd-2.6.16.35-1 /tmp/initrd-src

Tworzenie initrd rozpocznijmy od skopiowania zawartości katalogu w inne miejsce:

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

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

Przyszedł czas na wygenerowanie initrd:

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

# gzip -9 initrd-nowy

Bootloader

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

# lilo

W przypadku Grub-a nic nie musimy robić.

Na koniec restartujemy komputer i system powinien uruchomić się bez problemu. Konfigurację bootloaderów szerzej opisano w sekcja Wstęp w rozdział Bootloader.

Uwagi

Częste zmiany używanego obrazu initrd mogą być uciążliwe, można to obejść łącząc do jednego obrazu większą ilość modułów. Aby to zrobić możemy dopisać nazwy modułów do przedstawionych poniżej opcji w pliku /etc/sysconfig/geninitrd:

## Basic modules to be loaded
BASICMODULES=""

## Modules that should be loaded before anything (i.e. jbd for ext3)
PREMODS=""

Podstawowe informacje o urządzeniu

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

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

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

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

Systemy plików-urządzeń

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

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

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

UDEV

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

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

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

Jaki system wybrać?

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

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

Konfiguracja skryptów startowych

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

COLOR_INIT=yes

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

INIT_COL=75

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

FASTRC=no

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

RC_PROMPT=yes

Opcje związane z jądrem

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

CONSOLE_LOGLEVEL=1

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

PANIC_REBOOT_TIME=60

Opcje uruchamiania systemu

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

RUN_SULOGIN_ON_ERR=yes

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

DELAY_LOGIN=yes

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

CLEAN_TMP=yes

Wskazuje czy ma być zamontowany podsystem devfs:

MOUNT_DEVFS=no

Usługi

Domyślny priorytet (liczba nice) dla usług, którym nie go zdefiniowano w zmiennej SERVICE_RUN_NICE_LEVEL umieszczanej w pliku podstawowej konfiguracji usługi (/etc/sysconfig/{$usługa}):

DEFAULT_SERVICE_RUN_NICE_LEVEL=0

Lista katalogów przechowujących systemy typu chroot, które mają być zarządzane przez skrypt /etc/init.d/sys-chroots:

SYSTEM_CHROOTS=/jakis_katalog

Wstęp

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

Internacjonalizacja konsoli i programów

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

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

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

# poldek -i localedb-src kbd

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

Przykładowy zapis dla kilku języków w pliku /etc/sysconfig/i18n może wyglądać tak:

LANG=pl_PL

# list of supported locales
SUPPORTED_LOCALES="pl_PL/ISO-8859-2 de_DE/ISO-8859-2 \
    en_GB/ISO-8859-1 en_US/ISO-8859-1"

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

# poldek -i glibc-localedb-all

Aby sprawdzić czy wszystko przebiegło pomyślnie wydajemy polecenie:

$ locale
LANG=pl_PL
LC_CTYPE="pl_PL"
LC_NUMERIC="pl_PL"
LC_TIME="pl_PL"
LC_COLLATE="pl_PL"
LC_MONETARY="pl_PL"
LC_MESSAGES="pl_PL"
LC_PAPER="pl_PL"
LC_NAME="pl_PL"
LC_ADDRESS="pl_PL"
LC_TELEPHONE="pl_PL"
LC_MEASUREMENT="pl_PL"
LC_IDENTIFICATION="pl_PL"
LC_ALL=

Sprawdzamy czy wszystkie wpisy się zgadzają.

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

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

Przykładowo jako domyślnego języka, możemy używać angielskiego jednak ze wsparciem dla polskich czcionek i polskich walut. Wszelkiego typu zmiany dokonujemy poprzez dodanie do pliku ~/.bash_profile odpowiednich wpisów:

LANG=en_EN
export LANG
LC_CTYPE=pl_PL
export LC_CTYPE

Wstęp

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

# poldek -i gpm

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

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

Szeregowa

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

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

DEVICE=/dev/ttyS0
MOUSETYPE=ms3

PS/2, TouchPad, TrackPoint

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

# modprobe psmouse

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

DEVICE=/dev/input/mice
MOUSETYPE=ps2

USB

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

# modprobe usbhid
# modprobe usbmouse

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

DEVICE=/dev/input/mice
MOUSETYPE=ps2

Zakończenie

Teraz wystarczy tylko uruchomić usługę gpm:

# /etc/init.d/gpm start

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

Porady

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

  # gpm -m /dev/input/mice -t help

• Pożyteczną opcją jest BUTTON_COUNT, która definiuje liczbę przycisków myszy.

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

Przeglądanie

Zmienne środowiskowe to prosty sposób modyfikowania konfiguracji środowiska użytkownika. Listę zmiennych i przypisanych im wartości uzyskamy za pomocą polecenia powłoki set, na poniższym przykładzie przedstawiono fragment wyniku polecenia:

$ set
BASH=/bin/bash
BASH_VERSINFO=([0]="2" [1]="05b" [2]="0" [3]="2" [4]="release" [5]="i686-pld-linux-gnu")
BASH_VERSION='2.05b.0(2)-release'
COLORTERM=gnome-terminal
COLUMNS=125

Konfiguracja globalna

Administrator może ustawić globalnie wszystkim użytkownikom zmienne środowiskowe. Do tego wykorzystuje się mechanizm env.d. Jest to katalog umieszczony w /etc, zawierający pliki tekstowe o nazwach takich samych jak nazwy zmiennych, wewnątrz każdego z nich podana nazwa zmiennej i jej wartość. Przykładowo zmienna EDITOR zostanie zainicjowana jeśli utworzymy plik /etc/env.d/EDITOR, jego treść może wyglądać następująco:

EDITOR=vim

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

Konfiguracja lokalna

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

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

# export EDITOR=mcedit

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

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

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

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

/etc/inittab

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

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

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

  id:3:initdefault:

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

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

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

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

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

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

  si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0

• Obsługa specjalnych zdarzeń np. wciśnięcia kombinacji klawiszy ctrl+alt+del:

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

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

/etc/fstab

Plik ten przechowuje szczegółowe informacje o systemach plików, które mają być montowane do odpowiednich katalogów. Informacje w nim zawarte są odczytywane w trakcie startu systemu, dzięki temu automatycznie są montowane wszystkie woluminy (partycje) nie oznaczone opcją "noauto". Plik ten jest zazwyczaj tworzony przez instalator, jednak administrator ma możliwość, a nawet obowiązek dokonywać w nim zmian. Dla lepszego zrozumienia tematu przyjrzyjmy się przykładowemu plikowi i przeanalizujmy funkcje jakie spełniają poszczególne wpisy.

#(fs_spec)	(fs_file)(fs_vfstype)	(fs_mntops)	(fs_freq) (fs_passno)
/dev/hda2	/		ext3	defaults		0	0
/dev/hda3	swap		swap	defaults		0	0
proc		/proc		proc	defaults		0	0
pts		/dev/pts	devpts	gid=5,mode=600		0	0
/dev/fd0	/media/floppy	vfat	noauto			0	0
/dev/cdrom	/media/cdrom	iso9660	noauto,ro,user,unhide	0	0

Jak widzimy plik jest podzielony na wiersze, z których każdy odpowiada jednemu obsługiwanemu woluminowi. Poszczególne pola oddzielone są od siebie spacją lub tabulatorem. Dane odpowiedniego rekordu wczytywane są przez skrypty startowe oraz programy takie jak: fsck, mount czy umount przez co muszą one być zapisane w uporządkowany sposób.

Pole (fs_spec) - określa urządzenie blokowe lub zasób sieciowy przeznaczony do zamontowania, na przykład partycję dysku, CDROM czy udział NFS. Opis urządzeń masowych przedstawiono w sekcja Nazewnictwo urządzeń masowych w rozdział Pamięci masowe, montowanie udziałów NFS przedstawiono w sekcja NFS - Network File System w rozdział Usługi dostępne w PLD.

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

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

• ext2 - podstawowy system plików w Linuksie

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

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

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

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

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

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

• nfs - sieciowe udziały dyskowe NFS

• swap - obszar wymiany

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

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

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

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

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

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

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

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

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

/etc/passwd

Jeden z najważniejszych plików w systemie - przechowuje informacje o kontach wszystkich użytkowników. Jeden wiersz w tym pliku zawiera informacje o jednym użytkowniku. Każdy składa się z pól rozdzielonych dwukropkiem:

login:haslo:UID:GID:komentarz:katalog_domowy:powłoka
np.:
marek:x:502:1000:Marek Kowalski:/home/users/marek:/bin/bash

Uwagi: Znak "x" w miejscu hasła oznacza że jest przechowywane w osobnym pliku (/etc/shadow). UID to unikalny identyfikator użytkownika, zaś GID to unikalny numer grupy głównej użytkownika - zdefiniowany w pliku /etc/group. Powłoka (shell) musi być zdefiniowana w pliku /etc/shells. Oznaczenie powłoki jako /bin/false oznacza że jest to konto użytkownika systemowego. Jest to specjalny rodzaj kont na które zwykli użytkownicy nie mogą się zalogować

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

/etc/shadow

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

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

/etc/group

Plik zawierający nazwy utworzonych grup i przypisanych do nich użytkowników według schematu:

nazwa_grupy::GID:login1,login2,login3,...
np.:
audio::23:kasia,marek

Uwagi: Pierwsze pole to unikalna nazwa grupy, drugie nie ma we współczesnych systemach uniksowych już zastosowania, GID to niepowtarzalny identyfikator grupy, trzecie pole zawiera listę identyfikatorów użytkowników zapisanych do tej grupy.

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

/etc/shells

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

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

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

/etc/motd

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

/etc/nologin

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

Numerowanie partycji

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

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

# fdisk -l /dev/hda

Urządenia ATA (IDE)

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

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

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

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

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

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

Urządenia SCSI/SATA/USB Storage

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

Dyskietki elastyczne

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

LVM

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

RAID programowy

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

Urządzenia w GRUB-ie

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

Partycje

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

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

Zanim zaczniemy

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

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

# sfdisk /dev/hda < hda.out

Wymagane miejsce na system

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

• instalacja minimalna - poniżej 150MB

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

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

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

Plan podziału dysku

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

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

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

Programy do zarządzania partycjami

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

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

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

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

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

Podział

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

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

# fdisk -l /dev/sda

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

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

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

Zakończenie

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

Wybór systemu plików

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

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

Aby z partycji mogły również korzystać systemy Microsoftu musimy utworzyć na niej system plików vfat. Utracimy jednak wtedy wszystkie zalety uniksowych systemów plików.

Tworzenie systemu plików

Programy do tworzenia konkretnych systemów plików różnią się nazwami, łatwo je rozpoznamy gdyż ich nazwy zaczynają się od "mkfs." np.:

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

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

# /sbin/mkfs.ext2 /dev/sda2

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

Tworzenie obszaru wymiany

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

# mkswap /dev/hda5

Podmontowanie partycji / aktywacja swapu

Partycje i obszary wymiany są montowane/włączane przez rc-skrypty w trakcie uruchamiania systemu wg. opcji zawartych w pliku /etc/fstab (o ile tam zostały dodane). W pozostałych wypadkach systemy plików montujemy poleceniem mount z odpowiednimi opcjami np.:

# mount /dev/sda2 /katalog_docelowy

Obszary wymiany aktywujemy następująco:

# /sbin/swapon /dev/hda5

Szczegółowy opis pliku /etc/fstab oraz rc-skryptów przedstawiono w sekcja Kluczowe pliki w rozdział Konfiguracja systemu.

Poznanie typu systemu plików

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

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

# blkid
/dev/md/0: UUID="4f6fc9cc-9a3a-42bd-9e47-50ecfbeb090b" TYPE="xfs" 
/dev/hda1: UUID="6d7abd95-9731-4406-b154-78ee66fc6c7f" TYPE="ext2" 
/dev/sda: UUID="4f6fc9cc-9a3a-42bd-9e47-50ecfbeb090b" TYPE="xfs" 
/dev/sdb: UUID="4f6fc9cc-9a3a-42bd-9e47-50ecfbeb090b" TYPE="xfs"

/dev/hda1 on /boot type ext2 (rw,sync)
/dev/md/0 on /vservers type xfs (rw,noatime,usrquota)

Instalacja

Instalujemy następujące pakiety:

# poldek -i mdadm

# poldek -i mdadm-initrd

# poldek -i dmraid

Planowanie macierzy

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

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

Garść porad:

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

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

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

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

Tworzenie macierzy RAID

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

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

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

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

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

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

• -v --verbose - tryb "gadatliwy"

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

Przykłady tworzenia macierzy różnego typu:

• RAID0 na dwóch partycjach - /dev/sda1 i /dev/sdb1 jako /dev/md0

  # mdadm -C -v /dev/md0 --level=0 -n 2 /dev/sda1 /dev/sdb1

• RAID1 na dwóch partycjach - /dev/sdc1 i /dev/sdd1 jako /dev/md1

  # mdadm -C -v /dev/md1 --level=1 -n 2 /dev/sdc1 /dev/sdd1

• RAID5 na 4 partycjach w tym jedna jako zapasowa (hot spare), jeśli nie podasz ile ma być zapasowych partycji domyślnie 1 zostanie zarezerwowana na zapasową

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

Konfiguracja

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

# mkfs.xfs /dev/md0

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

DEVICE /dev/sd[abcd][123]

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

ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md1 devices=/dev/sdc1,/dev/sdd1
ARRAY /dev/md2 devices=/dev/sda3,/dev/sdb3,/dev/sdc3,/dev/sdd3

Macierze (inne niż rootfs) są składane przez rc-skrypt /etc/rc.d/rc.sysinit, na podstawie powyższych wpisów konfiguracyjnych, zatem po restarcie maszyny będziemy już z nich korzystać. Jeśli mamy macierz z głównym systemem plików, to musimy jeszcze przygotować initrd i bootloader (poniżej).

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

# mdadm --examine --scan -v

Initrd

Jeśli główny system plików ma być na macierzy to musimy wygenerować obraz initrd z modułami, które pozwolą na złożenie macierzy. Na początek musimy mieć zainstalowany pakiet mdadm-initrd. Generowanie takiego initrd przebiega dokładnie tak samo jak dla zwykłego urządzenia blokowego, musimy się tylko upewnić, że do obrazu trafiły dodatkowo moduły: md-mod, odpowiednio raid0, raid1... i ewentualnie xor. Generowanie obrazu initrd szczegółowo zostało opisane w sekcja Initrd w rozdział Kernel i urządzenia.

Bootloader

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

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

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

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

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

# grub
grub>

grub>find /boot/grub/stage1

(hd0,0)
(hd1,0)


Now you want to make sure that grub gets installed into the master boot
record of your additional raid drives so that if id0 is gone then the next
drive has a mbr loaded with grub ready to go.  Systems will automatically go
in drive order for both ide and scsi and use the first mbr and active
partitions it finds so you can have multiple drives that have mbr's as well
as active partitions and it won't affect your system booting at all.

So using what was shown with the find above and already knowing that hd0
already has grub in mbr, we then run:

Grub>device (hd0)/dev/sda (/dev/hda for ide)
Grub>root (hd0,0)
Grub>setup (hd0)

Grub>device (hd1) /dev/sdb (/dev/hdb for ide)
Grub>root (hd1,0)
Grub>setup (hd1)

Grub will then spit out all the commands it runs in the background of setup
and will end with a successful embed command and then install command and
end with .. succeeded on both of these commands and then Done returning to
the grub> prompt.

Notice that we made the second drive device 0.  Why is that you ask?
Because device 0 is going to be the one with mbr on the drive so passing
these commands to grub temporarily puts the 2nd mirror drive as 0 and will
put a bootable mbr on the drive and when you quit grub you still have the
original mbr on sda and will still boot to it till it is missing from the
system.

You have then just succeeded in installing grub to the mbr of your other
mirrored drive and marked the boot partition on it active as well.  This
will insure that if id0 fails that you can still boot to the os with id0
pulled and not have to have an emergency boot floppy.

Diagnostyka

Skrócone informacje o macierzy:

# mdadm --query /dev/md0

# mdadm --detail /dev/md0

# cat /proc/mdstat

Porady

• Mając dwie macierze RAID1 np: /dev/md0 i /dev/md1, możemy utworzyć macierz RAID10 (strip dwóch mirrorów) jako /dev/md2

  # mdadm -C -v /dev/md2 --level=1 -n 2 /dev/md0 /dev/md1

  analogicznie RAID01 tworzymy mając dwie macierze RAID0.

• Aby samemu złożyć macierz (z np: PLD Live CD) wydajemy polecenie, które może wyglądać następująco:

  # mdadm -A /dev/md0 /dev/hda /dev/hdb

• Jeśli macierz jest składana w trakcie startu systemu to automatycznie tworzony jest plik urządzenia /dev/mdX. W trakcie tworzenia macierzy, lub gdy macierz nie startuje wraz z systemem, możemy skorzystać z gotowych urządzeń w /dev (pakiet dev) lub samemu je utworzyć (pakiet udev). Udev nie tworzy urządzeń /dev/md0, więc musimy w tym celu użyć parametru --auto=yes w wywołaniach programu mdadm, lub utworzyć je poleceniem mknod. Urządzeniu nadajemy major o wartości 9 i kolejny, niepowtarzalny numer minor. Nie musimy się martwić o moduły, są on ładowane automatycznie przez mdadm lub initrd. Więcej o UDEV w sekcja Udev - dynamiczna obsługa sprzętu w rozdział Kernel i urządzenia.

• Wraz z pakietem mdadm dostarczany jest rc-skrypt uruchamiający mdadm w trybie monitorowania (jako demona). Więcej szczegółów w dokumentacji programu mdadm.

• Migracja z pojedynczego dysku na RAID1

  Instalacja linuksa na raid1

  Naprawa zdegradowanej macierzy

Dodatki

Literatura:

• http://www.eioba.com/a70652/konfiguracja_i_objasnienie_raid_oraz_lvm

• http://lists.us.dell.com/pipermail/linux-poweredge/2003-July/008898.html

• http://www.linuxsa.org.au/mailing-list/2003-07/1270.html

• http://gentoo-wiki.com/HOWTO_Gentoo_Install_on_Software_RAID

Planowanie woluminów

Musimy wyznaczyć urządzenia blokowe których chcemy użyć do stworzenia struktur PV. Jeśli główny system plików ma być umieszczony na woluminie logicznym to musimy przeznaczyć małą partycję dla gałęzi /boot, gdyż bootloadery lilo i grub nie potrafią czytać danych z woluminów. Szczegółowy opis dzielenia dysków na partycje zamieściliśmy w sekcja Podział na partycje.

Załóżmy, że mamy dwa dyski twarde po 250GB (/dev/sda i /dev/sdb), których powierzchnię chcemy połączyć i rozdysponować pod system operacyjny. Jako, że rootfs także będzie na woluminie to rozplanowanie miejsca może wyglądać następująco:

• /dev/sda1: mała partycja na /boot o pojemności 50MB

• /dev/sda2: druga partycja dla woluminów (reszta dysku)

• /dev/sdb: cały dysk dla woluminów

• swap: 5GB

• / (rootFS): 25GB

• /home: 370GB

Instalacja

Omawiamy implementację LVM2, zatem instalujemy pakiet lvm2, jeśli LVM ma być użyty jako główny system plików to potrzebujemy jeszcze pakiet lvm2-initrd do wygenerowania odpowiedniego obrazu initrd.

Budowanie woluminów

Ładujemy moduł device mappera:

# modprobe dm-mod

Dzielimy dysk /dev/sda na dwie opisane powyżej partycje, a następnie wskazujemy urządzenia Physical Volumes:

# pvcreate /dev/sda2 /dev/sdb

# vgcreate vgsys /dev/sda2 /dev/sdb

# lvcreate -L 5GB -n swap vgsys
# lvcreate -L 25GB -n rootfs vgsys
# lvcreate -L 370GB -n home vgsys

# mkswap /dev/vgsys/swap
# mkfs.xfs /dev/vgsys/rootfs
# mkfs.xfs /dev/vgsys/home

# mkfs.ext2 /dev/sda1

Konfiguracja startowa

Woluminy są automatycznie aktywowane przez rc-skrypt /etc/rc.d/rc.sysinit lub initrd. Moduł device mappera również jest ładowany automatycznie. Jeśli chcemy umieścić główny system plików na LV, to musimy jeszcze wygenerować nowy obraz initrd, z obsługą LVM. Zostało to szczegółowo przedstawione w sekcja Initrd w rozdział Kernel i urządzenia. W konfiguracji bootloadera ustawiamy opcję 'root=' na /dev/vgsys/rootfs. Teraz instalujemy system, instalujemy bootloader i możemy zrestartować maszynę.

Gdy zajdzie potrzeba "ręcznego" aktywowania woluminów (np. spod RescueCD), to na początek musimy się upewnić, że jest załadowany moduł dm-mod. Kernel nie zgłasza komunikatów o odnalezieniu woluminów, tak jak ma to miejsce z partycjami, należy je odszukać za pomocą odpowiednich narzędzi: lvmdiskscan i lvscan. Jeśli odnaleźliśmy żądane struktury, to możemy je aktywować:

# vgchange -a y

Narzędzia diagnostyczne

Skrócone informacje o każdym z rodzaju komponentów (PV/VG/LV) wyświetlimy za pomocą programów pvs, vgs, lvs. Więcej informacji uzyskamy za pomocą programów: pvdisplay, vgdisplay, lvdisplay.

Do niektórych operacji z woluminami będziemy musieli je odmontować i deaktywować. Aby deaktywować wszystkie woluminy użyjemy polecenia

# vgchange -a n

# vgchange -a y

Zarządzanie: powiększanie woluminu

Teraz przedstawimy potęgę LVM-a: pokażemy jak powiększyć wolumin, gdy dochodzimy do wniosku, że przeznaczonego miejsca jest za mało. Załóżmy, że mamy woluminy utworzone zgodnie z wcześniejszymi przykładami i chcemy przeznaczyć całą dostępną wolną przestrzeń na naszym VG (100GB) dla /dev/vgsys/homes:

# lvextend  -l 100%VG  /dev/vgsys/home

# xfs_growfs /home

Porady

Woluminy LVM powodują zwiększone ryzyko uszkodzenia danych, gdyż awaria jednego dysku może spowodować utratę wszystkich danych. Z tego powodu zaleca się tworzenie woluminów na macierzach RAID.

Uszkodzenia fizyczne

Uszkodzenia fizyczne sprawdzamy programem badblocks z pakietu e2fsprogs, uruchamiamy go poleceniem:

# badblocks -s /dev/sda

Naprawa systemu plików

Nazwy programów, podobnie jak programy do tworzenia systemów plików, są ujednolicone (poza XFS). Zaczynają się od "fsck.":

fsck.ext2
fsck.reiserfs
fsck.vfat
fsck.jfs

# xfs_repair /dev/sda2

Programy te nie pozwolą na sprawdzanie na systemie plików podmontowanym w trybie do odczytu i zapisu. Powinniśmy w ogóle nie montować takiego systemu plików, a przynajmniej podmontować w trybie tylko do odczytu.

Nieco bardziej złożone jest sprawdzanie głównego systemu plików jeśli uruchomiliśmy system w trybie jednego użytkownika. Problemem jest konieczność przemontowania systemu plików w tryb ro. Niektóre programy mogą sprawdzać w pliku /etc/mtab czy system plików jest w trybie tylko do odczytu. Może to dać nieprawidłowe wyniki, gdyż zazwyczaj gałąź /etc leży na głównym systemie plików i w pliku tym nie nastąpią żadne zmiany po takim przemontowaniu. Można to obejść wcześniej modyfikując wpis w /etc/mtab, kiedy już to zrobimy wykonujemy polecenie:

# mount / -o ro,remount

Naprawienie systemu plików nie gwarantuje, że nie zostały uszkodzone żadne pliki. Jeśli na naprawianym systemie plików były jakieś dane systemowe, to powinniśmy wykonać kontrolę ich integralności, opisaną dokładnie w sekcja Zaawansowane operacje w rozdział Zarządzanie pakietami.

Wstęp

W tym rozdziale pokażemy co można zrobić w wypadku, jeśli nastąpiła awaria systemu, uniemożliwiająca normalne uruchomienie. Musimy uzyskać dostęp do urządzeń lub plików na dysku twardym, możemy w tym celu spróbować uruchomić system na niskim poziomie pracy, a jeśli to się nie powiedzie, to użyć operacji chroota z innego systemu np. dystrybucji typu live.

Uruchomienie na niskim poziomie pracy

Możemy uruchomić system z pominięciem wielu czynności wykonywanych przez skrypty startowe. Operacja polega na przekazaniu do kernela odpowiednich parametrów, które wymuszą użycie przez proces init specjalnie przygotowanego zestawu rc-skryptów.

Interesuje nas poziom 1 lub single (tryb jednego użytkownika), tak też nazywają się parametry, które musimy przekazać do kernela. Parametry przekazujemy do jądra za pośrednictwem bootloadera, w trakcie uruchomienia systemu np.:

grub append> root=/dev/sda2 single

Uruchomienie RescueCD

Jako dystrybucję Live najlepiej wybrać RescueCD lub PLD Live. Oba projekty są dobrze przygotowane do pracy z naszą dystrybucją, gdyż zawierają program rpm i poldek.

Na początek musimy zadbać o to, aby system mógł się uruchomić z płyty CD, uzyskamy to modyfikując odpowiednią opcję BIOS-u komputera. Teraz uruchamiamy komputer z RescueCD umieszczonym w napędzie CD-ROM i czekamy aż system się uruchomi.

Aby dokonać napraw musi zostać załadowany moduł kontrolera masowego. Większość współczesnych dystrybucji typu live sama wykrywa sprzęt, jeśli jednak to się nie powiedzie lub używamy starej wersji RescueCD to musimy sami załadować moduł. Jeśli potrzebujemy obsłużyć kontroler typu IDE musimy załadować moduł ide-disk

# modprobe ide-disk

# mdadm -A --auto=yes /dev/md0 /dev/hda /dev/hdb

Teraz kiedy mamy załadowane odpowiednie moduły i dostęp do plików urządzeń (w katalogu /dev) możemy wykonać liczne operacje diagnostyczne i naprawcze (opisane dalej).

Naprawa systemu plików

Do naprawy systemu plików konieczny jest tylko dostęp do plików urządzeń z katalogu /dev. Aby sprawdzić i naprawić system plików XFS wydajemy polecenie:

# xfs_repair /dev/sda2

Naprawa konfiguracji

W przypadku podniesienia systemu w trybie single mamy swobodny dostęp do plików konfiguracji, w przeciwnym wypadku musimy najpierw podmontować odpowiednią partycję aby uzyskać dostęp do plików. W tym celu tworzymy nowy katalog, a następnie montujemy do niego właściwe urządzenie np.:

# mkdir -p /mnt/rootfs
# mount /dev/hda3 /mnt/rootfs

# mount /dev/hda1 /mnt/rootfs/boot 

Operacja chroota

Jeśli uruchomiliśmy system z RescueCD i mamy podmontowane systemy plików to wielu wypadkach wygodniejsze, a czasami nawet konieczne będzie wykonanie tzw. chroot-a.. Polega to na podmianie głównego systemu plików używanego przez dany program na główny system plików ratowanego systemu operacyjnego. Będzie to konieczne przy problemach z jądrem, bootloaderem czy initrd. Aby wykonać tą operację należy wykonać komendę:

# chroot /mnt/rootfs

To polecenie uruchomi powłokę /bin/sh w taki sposób, że wszystkie działania z jej poziomu będą odbywały się przeźroczyście na podmontowanym systemie plików. Zanim jednak zabierzemy się do pracy proszę o zapoznanie się z uwagami na końcu rozdziału. Jeśli używamy powłoki korzystającej z chroot-a, wystarczy że zakończymy jej pracę wydając polecenie exit lub skrótem klawiszowym ctrl+d. Na koniec odmontowujemy systemy plików jeśli takie są i restartujemy komputer.

Uwagi

• Niektóre operacje w środowisku chroot wymagają (np. tworzenie initrd) podmontowania pseudo systemu plików /proc:

  # mount /proc /mnt/rootfs/proc -o bind

• Użytkownicy udeva powinni pamiętać, że wiele operacji w podmontowanym środowisku wymagają istnienia kompletu plików urządzeń:

  # mount /dev /mnt/rootfs/dev -o bind

  Udev dokładniej opisano w sekcja Udev - dynamiczna obsługa sprzętu w rozdział Kernel i urządzenia.

• Może się zdarzyć, że poldek się nie uruchamia w chroocie. Sposobem na obejście tego jest uruchomienie go z flagą -r , np:

  # poldek -r /mnt/rootfs

• Dużą zaletą RescueCD jest to, że automatycznie "podnosi" interfejs sieciowy z obsługą DHCP oraz serwer SSH. Pozwala to na zdalną naprawę, wystarczy, że ktoś umieści płytę z dystrybucją w napędzie i uruchomi komputer. My zalogujemy się na odpowiedni adres za pośrednictwem SSH; login: root, hasło: pld.

Budowa systemu rc-skryptów

Katalog /etc/rc.d przechowuje konfigurację uruchamiania usług i podsystemów, poniżej pokrótce omówiono składniki systemu rc-skryptów:

• /etc/rc.d/init.d - katalog z skryptami startowymi usług

• /etc/rc.d/rc{$NR}.d - katalogi tak oznaczone zawierają łącza symboliczne do skryptów zawartych w katalogu init.d. Wartość {$NR} jest liczbą wskazującą poziom pracy (run level), dla którego uruchamiana jest zawartość danego katalogu.

• /etc/rc.d/rc - skrypt uruchamiający i zatrzymujący usługi

• /etc/rc.d/rc.init - skrypt ustawiający opcje narodowe (język, waluta) pobiera konfigurację z pliku /etc/sysconfig/i18n

• /etc/rc.d/rc.local - uruchamiany na samym końcu wszystkich skryptów, użytkownicy mogą dodawać tu swoje wpisy jeśli nie chcą używać init.d i rc{$NR}.d

• /etc/rc.d/rc.serial - konfiguracja portów szeregowych

• rc.sysinit - główny skrypt startowy uruchamiany jednokrotnie (w trakcie startu)

• /etc/rc.d/rc.modules - załadowanie modułów z /etc/modules

• /etc/rc.d/rc.shutdown - główny skrypt uruchamiany przy zatrzymaniu systemu lub restarcie.

• /etc/profile - plik startowy przy pomocy którego są ustawiane głównie zmienne systemowe

Zarzadzanie podsystememi/usługami

Usługami/podsystemami zarządzamy ręcznie, wykonujemy to za pomocą uruchomienia odpowiedniego skryptu z katalogu /etc/rc.d/init.d/. Dodatkowo podajemy odpowiednim parametr określający akcję, którą skrypt ma wykonać. Uruchomienie bez parametru podaje listę możliwych dla niego akcji, dla przykładu wyświetlimy listę dostępnych parametrów podsystemu sieci:

# /etc/rc.d/init.d/network
Usage: /etc/rc.d/init.d/network {start|stop|restart|status}

Poniżej przedstawiono wyłączenie obsługi sieci, oraz ponowne jej uruchomienie. W ten sposób zmusza się usługę lub podsystem do ponownego odczytania swojej konfiguracji. W tym wypadku nastąpi skonfigurowanie na nowo interfejsów, zaktualizowanie ustawień, tablic routingu itd...

# /etc/rc.d/init.d/network stop
Shutting down interface eth0.......................................[ DONE ]
Shutting down interface eth1.......................................[ DONE ]

# /etc/rc.d/init.d/network start
Setting network parameters.........................................[ DONE ]
Bringing up interface eth0.........................................[ DONE ]
Bringing up interface eth1.........................................[ DONE ]

Lista dostępnych parametrów będzie się zmieniać w zależności od usługi, w poniższej tabeli przedstawiono znacznie tych najczęściej spotykanych:

Niektóre usługi posiadają inne, użyteczne tylko dla nich parametry. Przykładem może być argument init, który zazwyczaj musi być użyty przed pierwszym uruchomieniem usługi.

Nieco wygodniej zarządza się skryptami przy pomocy programu service. Aby wykonać za jego pomocą taki sam efekt jak powyżej musimy go wywołać z dwoma parametrami, pierwszy to nazwa skryptu, drugi zaś to wybrana akcja:

# service network stop
# service network start

Domyślnie po zainstalowaniu nowego podsystemu lub usługi, dodawane są potrzebne skrypty startowe. Dzięki temu nowo zainstalowane oprogramowanie uruchamia się automatycznie w trakcie startu systemu lub przy zmianie poziomu pracy. Aby uruchomić dopiero co zainstalowany podsystem lub usługę musimy wykonać to "ręcznie".

• Zarządzanie skryptami startowymi w trakcie instalacji/aktualizacji pakietów opisano w sekcja Cechy pakietów w PLD w rozdział Zarządzanie pakietami

• Jeśli zechcemy utworzyć własny rc-skrypt to z pomocą przyjdzie nam szablon z pliku /usr/share/doc/rc-scripts{$wersja}/template.init.gz

Konfiguracja rc-skryptów

Skryptów startowych typu System-V nie konfigurujemy bezpośrednio, w PLD służy ku temu zestaw plików konfiguracyjnych umieszczony w katalogu /etc/sysconfig. Znajdziemy w nim zarówno pliki konfiguracji systemu jak i konfiguracji zainstalowanych usług.

Większość tych plików jest bezpośrednio załączana do kodu rc-skryptów, zatem ich składnia musi odpowiadać składni powłoki wskazanej w skrypcie (w PLD jest to /bin/sh). Dotyczy to także plików konfiguracji interfejsów sieciowych w katalogu /etc/sysconfig/interfaces. W plikach tych występują jedynie konstrukcje przypisania zamiennych oraz ewentualne komentarze. Możemy co prawda umieszczać tam dowolne komendy wiersza poleceń, jednak należy być przy tym niezwykle ostrożnym i robić to tylko w uzasadnionych przypadkach. Jest jednak kilka plików konfiguracji, które są traktowane inaczej - mają własną składnię, przykładem tego rozwiązania są np. pliki /etc/sysconfig/static-*, nimi jednak nie będziemy się zajmować w tym rozdziale.

Opcje w plikach konfiguracji można podzielić na dwie grupy: ogólnego stosowania i specyficzne dla rc-skryptu. Pierwsza z nich to uniwersalne opcje, z którymi możemy się zetknąć w wielu w innych plikach konfiguracji np.:

• SERVICE_RUN_NICE_LEVEL - priorytet procesów usługi (liczba nice)

• RPM_SKIP_AUTO_RESTART - mówi programowi rpm czy usługa ma być automatycznie restartowana po aktualizacji, więcej o tej opcji w sekcja Cechy pakietów w PLD w rozdział Zarządzanie pakietami

Zależności

Pomiędzy niektórymi demonami i podsystemami istnieją ścisłe powiązania, jako przykład można wymienić usługi sieciowe i podsystem sieci. Usługa jest zależna od działania sieci i próba wyłączenia najpierw tej drugiej może niekiedy zaowocować problemami, gdyż PLD nie dba o to za nas. Musimy samemu się zatroszczyć o wyłączanie usług we właściwej kolejności.

Pewną wskazówką będą numery przy nazwach łączy symbolicznych w katalogach /etc/rc.d/rc{$nr}.d (przy literze S). Numery te określają kolejność ładowania usług w trakcie startu systemu.

Usługi a poziomy pracy

W PLD zastosowano klasyczny, oparty na rc-skryptach typu System-V system poziomów pracy. Poziomami na których pracują usługi można zarządzać ręcznie, jest to jednak niezalecany sposób, lepszym pomysłem jest użycie programu chkconfig. Aby wyświetlić listę usług uruchamianych przy w danych poziomach pracy wydajemy polecenie:

# chkconfig --list
crond           0:wył.  1:wył.  2:wł.   3:wł.   4:wł.   5:wł.   6:wył.
cups            0:wył.  1:wył.  2:wł.   3:wł.   4:wł.   5:wł.   6:wył.
sshd            0:wył.  1:wył.  2:wył.  3:wł.   4:wł.   5:wł.   6:wył.
gdm             0:wył.  1:wył.  2:wył.  3:wył.  4:wył.  5:wł.   6:wył.
network         0:wył.  1:wył.  2:wł.   3:wł.   4:wł.   5:wł.   6:wył.
sshd            0:nie   1:nie   2:nie   3:nie   4:tak   5:nie   6:nie

W PLD najczęściej korzysta się z trybów 3 i 5 rzadziej z: 1, 2 i 4, nigdy nie ustawiamy trybu 0 (restart) i 6 (wyłączenie). Na powyższym przykładzie podsystem network jest uruchamiana dla poziomów: 2,3,4,5, zaś gdm tylko dla trybu 5. Aby włączyć/wyłączyć uruchamianie jakiejś usługi wywołujemy program następująco: chkconfig {$usługa} on/off. Wyłączenie usługi sshd (domyślnie jest włączona):

# chkconfig sshd off

# chkconfig sshd on

$ grep chkconfig /etc/init.d/sshd
# chkconfig:    345 55 45

# chkconfig --level 5 sshd off

Dodawanie lub usuwanie usług w poziomach pracy nie powoduje ich uruchomienia lub zatrzymywania, aby to zrobić musimy wykonać to ręcznie lub zmienić tryb pracy. Poziomy pracy zostały szerzej omówione w sekcja Zmiana poziomu pracy systemu.

Dodanie

Konto użytkownika dodajemy poleceniem useradd -m {$nazwa_użytkownika} np.:

# useradd -m jkowalski

• GROUP - identyfikator grupy głównej - domyślnie: 1000 (users)

• HOME - miejsce przechowywania katalogów domowych - domyślnie: /home/users

• SHELL - powłoka - domyślnie: /bin/bash

Drugi określa bardziej zaawansowane opcje, najważniejsze z nich to:

• PASS_MAX_DAYS - liczba dni do wygaśnięcia hasła -domyślnie: 99999

• PASS_MIN_DAYS - minimalna liczba dni do między zmianami hasła -domyślnie: 0

• PASS_WARN_AGE - ilość dni przez które będzie pokazywane ostrzeżenie o wygaśnięciu hasła - domyślnie: 7

Wiele opcji kont zawartych w tych plikach można łatwo modyfikować, poprzez przekazanie odpowiednich parametrów do programu useradd oraz passwd, więcej informacji na ten temat uzyskamy w podręczniku systemowym. Jeśli chcemy utworzyć większa ilość kont o zmodyfikowanych parametrach to wygodniejsze będzie ustawienie interesujących nas wartości w podanych powyżej plikach.

Jeśli użytkownik ma konto na wielu maszynach dobrym zwyczajem jest nadawanie takiego samego numeru użytkownika (UID) dla każdego z kont. W przypadku programu useradd należy użyć opcji "-u".

Na koniec administrator musi ustawić hasło dla danego użytkownika.

Usunięcie

Aby usunąć konto użyjemy programu userdel:

# userdel jkowalski

Ze względów bezpieczeństwa można polecić blokowanie kont użytkowników w miejsce ich usuwania, w ten sposób możemy się ochronić przed sytuacją powrotu do użytku numeru UID usuniętego użytkownika.

Modyfikacja

Dane użytkownika modyfikujemy poleceniem usermod, dokładny opis tego programu znajdziemy w manualu.

Hasło

Pierwsze hasło dla użytkownika jest nadawane przez administratora, każdą następną jego modyfikację użytkownik może wykonywać samodzielnie.

Ustawienie hasła przez administratora: passwd {$nazwa_użytkownika}

# passwd jkowalski
Changing password for jkowalski.
New UNIX password:  
Retype new UNIX password:

# passwd -e jkowalski

Zarządzanie kontami

Hasło blokujemy poleceniem: passwd -l {$nazwa_użytkownika} np.:

# passwd -l jkowalski

# passwd -u jkowalski

# usermod -s /bin/false jkowalski

Dodanie grupy

Używamy polecenia groupadd {$nazwa_grupy} np.:

# groupadd kadry

Jeśli tworzymy takie same grupy na wielu maszynach, to dobrym zwyczajem jest nadawanie takiego samego numeru grupy (GID) dla każdej z grup. Dowolny GID narzucamy w trakcie tworzenia grupy programem groupadd z użyciem opcji "-g".

Zapisanie do grup

Dzięki poleceniu id {$nazwa_użytkownika} sprawdzimy do jakich grup zapisany jest użytkownik, jeśli nie podamy nazwy konta to zostanie wyświetlona informacja o aktualnie używanym koncie np.

$id jkowalski
uid=500(jkowalski) gid=1000(users) grupy=1000(users),10(wheel),19(floppy),23(audio)

Zapisanie do grupy następuje po wykonaniu polecenia groupmod -A {$konto_użytkownika} {$grupa} np.

groupmod -A jkowalski kadry

Aby wyrejestrować użytkownika z grupy musimy użyć parametru "-R" np.

groupmod -R jkowalski kadry

Usunięcie grupy

Używamy polecenia groupdel {$nazwa_grupy}:

# groupdel kadry

Uwagi

• Po każdej modyfikacji uczestnictwa w grupach, użytkownik musi się ponownie zalogować, aby wprowadzone zmiany zaczęły obowiązywać.

• Zapisanie użytkownika do grupy służy podniesieniu jego uprawnień, listę przywilejów jakie uzyska zamieszczono w sekcja Zarządzanie uprawnieniami.

Dostępne narzędzia

PLD jako dystrybucja "robiona przez administratorów dla administratorów" ma duże zasoby programów użytecznych w zakresie bezpieczeństwa, poczynając od NetCata (nc), a na wiresharku i nessusie kończąc.

Dostęp do konta root

Nasza polityka bezpieczeństwa wymaga, aby użytkownik należał do grupy wheel, jeśli chce zwiększyć swoje uprawnienia za pomocą su i sudo. W ten sposób atakujący musi zgadnąć trzy parametry zamiast jednego (nazwa użytkownika, hasło i hasło administratora zamiast samego hasła administratora). Nie ma też możliwości zdalnego zalogowania się bezpośrednio na konto roota (z tych samych powodów). Dodatkowo root nie może zdalnie używać innych usług (ftp, imap, pop3, smtp) m.in z powodu niedostatecznie silnego szyfrowania transmisji.

SUID

Domyślnie zwykli użytkownicy nie mają prawa wykonania programów z ustawionym bitem SUID. Aby takie prawo uzyskać muszą być zapisani do odpowiedniej grupy. Przykładowo program ping wymaga zapisania do grupy adm. Poglądowe zestawienie grup zamieściliśmy w sekcja Zarządzanie uprawnieniami.

/proc

Domyślnie użytkownicy nie widzą żadnych procesów poza swoimi. Jest to nie tylko krok w stronę bezpieczeństwa, ale i w wygody, użytkownik nie głowi się nad długimi listami procesów generowanych przez program top czy ps. Podobnie jak z programami z bitem SUID jest to oparte o grupy, aby użytkownik widział wszystkie procesy należy go zapisać do grupy /proc.

chroot i vserver

PLD oferuje system sys-chroot, wbudowany w rc-skrypty, służący do wygodnego zarządzania środowiskami typu chroot. Usługi, które wspierają natywnie chrooty (np. Bind) działają w izolowanym środowisku od razu po instalacji.

PLD wspiera także mechanizm Linux VServers, zwany potocznie "chrootem na sterydach". Wymaga on zainstalowania odpowiedniej wersji kernela i odpowiedniego zestawu narzędzi.

Statyczny VIM

Najważniejszym narzędziem administracyjnym jest edytor tekstu, dlatego nie powinniśmy pozostać bez takiego programu, co może mieć miejsce np. przy uszkodzeniu systemu plików. Tu z pomocą przychodzi nam statycznie zlinkowany VIM z pakietu vim-static. Aby nie kolidował ze "zwykłym" vimem, plik wykonywalny jest umieszczany w /bin/vim.

Pakiety

Zagadnienia związane z bezpieczeństwem zostały omówione w sekcja Bezpieczeństwo w rozdział Zarządzanie pakietami.

Brama domyślna

Jeśli nie korzystamy z serwera DHCP ustawiamy statyczną trasę routingu do domyślnej bramy, w tym celu edytujemy plik /etc/sysconfig/static-routes - wpis może wyglądać następująco:

eth0 default via 192.168.0.1

Odwzorowanie nazw - serwery DNS

Wskazanie serwerów DNS jest obowiązkową pozycją konfiguracji resolvera nazw. Operacja ta następuje automatycznie, o ile korzystamy z serwera DHCP, w przeciwnym wypadku musimy podać ich adresy samodzielnie. Serwery nazw ustawiamy edytując plik /etc/resolv.conf. Jeśli go nie ma, to możemy go utworzyć za pomocą dowolnego edytora lub poleceniem touch. Podajemy przynajmniej jeden (zazwyczaj nie więcej niż dwa) serwer nazw za pomocą słowa kluczowego nameserver np.:

nameserver 192.168.0.12

Nazwa hosta

Możemy ustawić nazwę, za pomocą której nasza maszyna będzie się przedstawiała zalogowanym użytkownikom, i niektórym programom. W pliku /etc/sysconfig/network ustawiamy:

HOSTNAME=pldmachine

Odwzorowanie nazw - konfiguracja zaawansowana

Plik /etc/host.conf zawiera podstawowe opcje resolvera nazw, w większości wypadków wystarczy domyślna konfiguracja:

order hosts,bind
multi on

W pliku /etc/hosts można dodawać odwzorowania hostów, które są uzupełnieniem dla usługi DNS, jedyny wymagany wpis to wskazanie adresu IP pętli zwrotnej dla nazwy localhost:

127.0.0.1       localhost

127.0.0.1       localhost styx

213.25.115.88 platinum.elsat.net.pl

Jeśli często odwołujemy się do maszyn w naszej domenie to możemy ułatwić sobie życie i ustawić domenę domyślną w pliku /etc/resolv.conf. Od tej pory podanie samej nazwy hosta (bez części domenowej), będzie uważane za podanie pełnego adresu. Przykładowe ustawienie domyślnej domeny (np. jakasdomena.cos) podano poniżej:

domain jakasdomena.cos

Inne opcje

Edytujemy plik /etc/sysconfig/network, domyślne wartości opcji z tego pliku w zupełności wystarczają do typowego korzystania z sieci i nie ma potrzeby nic modyfikować w nim.

NETWORKING=yes

Ustawiamy na "yes" jeżeli w ogóle chcemy komunikować się z siecią.

IPV4_NETWORKING=yes

Ustawiamy na "yes" jeżeli będziemy korzystać z protokołu IPv4 (wymagany do korzystania z Internetu).

NISDOMAIN=

Domena NIS, jeśli nie korzystasz z tej usługi sieciowej, lub nie jesteś pewien pozostaw to pole puste.

GATEWAY=192.168.0.254
GATEWAYDEV=eth0

Opcje za pomocą których możemy ustawić trasę routingu do domyślnej bramy. Opcje te zostały uznane za przestarzałe, obecnie należy korzystać z pliku /etc/sysconfig/static-routes.

Urządzenie

Większość dostępnych na rynku kart sieciowych jest oparta na układach Realteka, 3Com bądź Intela, dzięki temu nie będzie problemów z uruchomieniem urządzenia. Karty sieciowe są automatycznie wykrywane przez jądro i nadawane są im nazwy kolejno: eth0, eth1, eth2, itd. Jedyną rzeczą jaka pozostaje to załadowanie odpowiedniego modułu dla danego urządzenia, proces ten dokładnie opisano tutaj: sekcja Moduły jądra w rozdział Kernel i urządzenia.

Pliki konfiguracyjne interfejsów są przechowywane w katalogu /etc/sysconfig/interfaces, nazwy tych plików będą miały kolejno nazwy ifcfg-eth0, ifcfg-eth1, ifcfg-eth2, itd. W tym rozdziale założono, że konfigurujemy pierwszy interfejs (eth0). Pliki te modyfikujemy za pomocą dowolnego edytora tekstu np.

# vim /etc/sysconfig/interfaces/ifcfg-eth0

Statyczna konfiguracja karty sieciowej

Zaczynamy od zmodyfikowania lub utworzenia pliku /etc/sysconfig/interfaces/ifcfg-eth0, aby karta działała poprawnie powinieneś mieć tam podobne ustawienia:

DEVICE="eth0"

Powyższa opcja ta określa nazwę urządzenia.

IPADDR="192.168.0.2/24"

Ta opcja określa adres karty sieciowej oraz maskę podsieci. Maskę podsieci podajemy w notacji CIDR - "/24" odpowiada masce 255.255.255.0.

ONBOOT="yes"

Ustaw na "yes" jeśli chcesz aby interfejs automatycznie podnosił się razem z podsystemem sieci.

BOOTPROTO="none"

Ta opcja pozwala dokonać wyboru, w jaki sposób karta sieciowa ma otrzymywać konfigurację. Powyższy wpis sprawia, że system pobiera wszystkie ustawienia z posiadanych plików konfiguracyjnych.

Na końcu aktywujemy sieć.

Dynamiczna konfiguracja karty sieciowej (DHCP)

Na początek wybieramy jeden z programów klienckich: dhcpcd lub pump:

# poldek -i dhcpcd

Nasze zadanie ogranicza się do zmiany jednego parametru w pliku /etc/sysconfig/interfaces/ifcfg-eth0. Odszukujemy w nim opcję BOOTPROTO i wskazujemy klienta DHCP, który ma być użyty:

BOOTPROTO="dhcp"

Na koniec dokonujemy aktywacji interfejsu.

Mała uwaga: przy użyciu DHCP statyczne opcje sieciowe (adres IP, maska podsieci, brama) umieszczone w plikach konfiguracyjnych będą ignorowane, zaś zawartość pliku /etc/resolv.conf będzie nadpisywana informacjami przyznanymi przez serwer DHCP.

Aktywacja sieci

Ostatnią czynnością jest uruchomienie lub restart podsystemu sieci:

# /etc/rc.d/init.d/network start
Ustawianie parametrów sieci....................[ ZROBIONE ]
Podnoszenie interfejsu eth0....................[ ZROBIONE ]

Wstęp

W przypadku laptopa dobrym pomysłem jest użycie jakiejś aplikacji X-Window do konfiguracji WiFi, z możliwością łatwego przełączania pomiędzy sieciami oraz automatycznym wykrywanie podłączenia kabla do karty Ethernet. Takie możliwości zapewnia np. NetworkManager (korzysta z aplikacji wpa_supplicant), przeznaczony dla środowiska Gnome. W przypadku stacjonarnych maszyn konfiguracja rc-skryptów powinna być wystarczająca w większości wypadków.

W naszych przykładach przedstawimy konfigurację dla sieci bezprzewodowej działającej w trybie trybie infrastruktury (managed), o określonym identyfikatorze SSID i zabezpieczonej kluczem WEP oraz WPA2-PSK (WPA2 Personal). WEP zawiera zbyt dużo słabych punktów i jest podatny na szybkie złamanie, dlatego o ile nie jesteśmy ograniczeni sprzętem to należy używać właśnie WPA2.

Niektóre karty sieciowe WiFi mają dedykowane sterowniki i ich konfiguracja nie sprawia większych kłopotów, w pozostałych wypadkach posłużymy się sterownikami dla systemu Microsoft Windows, uruchomionymi dzięki aplikacji NdisWrapper. Jest to możliwe dzięki temu, że większość sterowników jest napisana zgodnie ze standardem NDIS. Po załadowaniu modułów, dalsza konfiguracja interfejsu w obu przypadkach przebiega niemal identycznie.

Sterowniki dedykowane

Do kernela w wersji 2.6.24 trafiło wiele modułów obsługujących sterowniki kart WLAN, sterowniki rozwijane niezależnie są dostępne w osobnych pakietach kernel-net-* Przykładowo zainstalujemy moduł dla kart Atheros:

$ poldek -i kernel-net-madwifi-ng

# modprobe ath_pci

Sterowniki z NdisWrapperem

Instalujemy pakiety kernel-net-ndiswrapper oraz ndiswrapper:

$ poldek -i ndiswrapper kernel-net-ndiswrapper

Potrzebne nam będą teraz sterowniki windowsowe naszej karty sieciowej. Konkretnie chodzi o pliki z rozszerzeniami *.inf oraz *.sys. Możesz je skopiować z dostarczonej przez producenta płytki ze sterownikami

# mkdir /lib/windrivers
# cd /lib/windrivers
# cp /media/cdrom/sciezka/do/sterownikow/sterownik.inf .
# cp /media/cdrom/sciezka/do/sterownikow/sterownik.sys .

Musimy teraz zainstalować te sterowniki przy użyciu NdisWrappera.

# ndiswrapper -i /lib/windrivers/sterownik.inf

Jeśli chcemy aby stworzył się alias w pliku /etc/modprobe.conf wykonujemy polecenie:

# ndiswrapper -m

Sieć WEP

Domyślnie rc-skrypty do obsługi WLAN używają pakietu wireless-tools:

$ poldek -i wireless-tools

DEVICE=wlan0
IPADDR=192.168.0.2/24
ONBOOT=yes
BOOTPROTO=dhcp

WLAN_ESSID=nasza_nazwa_sieci
WLAN_KEY=A638FED41027EA086ECD6825B0

Jako urządzenie w opcji DEVICE wskazujemy nadaną przez kernel nazwę. Kartom nadawane są zwykle nazwy wlan0, wlan1, itd. Wyjątkiem od tej reguły są niektóre sterowniki, rozwijane niezależnie od kernela np. ath{$NR} dla kart z układami Atheros Communications, czy ra{$NR} dla Ralink Technology (w kernelach do 2.6.24). To jaka nazwa została przydzielona naszemu urządzeniu możemy odczytać z komunikatów jądra.

Poniżej przedstawione zostaną parametry sieci WLAN:

WLAN_ESSID=moja_siec

WLAN_KEY=A638FED41027EA086ECD6825B0

Dodatkowo możemy ustawić szybkość interfejsu:

WLAN_BITRATE=auto

Sieć WPA2-PSK

Opisane powyżej wireless-tools nie potrafią używać szyfrowania WPA/WPA2, dlatego konieczny nam będzie pakiet wpa_supplicant:

$ poldek -i wpa_supplicant

Edytujemy plik /etc/wpa_supplicant.conf, w którym definiujemy opcje sieci WLAN:

ap_scan=1
		
network={
   ssid="nasza_nazwa_sieci"
   key_mgmt=WPA-PSK
   proto=RSN
   pairwise=CCMP TKIP
   group=CCMP TKIP WEP104 WEP40
   psk=anejdlf7323e64ekjlkbdsxhjsldjf3fda
}

Testujemy połączenie z WiFi:

# ifconfig wlan0 up
# wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf -dd

DEVICE=wlan0
IPADDR=192.168.0.2/24
ONBOOT=yes
BOOTPROTO=dhcp

WLAN_WPA=yes
WLAN_WPA_DRIVER=wext

Restartujemy ponownie naszą sieć:

# /etc/init.d/network restart

Aktywacja i diagnostyka

Na wszelki wypadek powinniśmy się upewnić, że nasza maszyna jest w zasięgu sieci radiowej:

# iwlist wlan0 scan

# /etc/rc.d/init.d/network start
Ustawianie parametrów sieci....................[ ZROBIONE ]
Podnoszenie interfejsu wlan0...................[ ZROBIONE ]

# iwconfig
lo      no wireless extensions.
 
eth0    no wireless extensions.
 
wlan0   IEEE 802.11g  ESSID:"nasza_nazwa_sieci" Nickname:"foo.com"
        Mode:Managed  Frequency:2.412 GHz  Access Point: 8A:1C:F0:6F:43:2D
        Bit Rate=300 Mb/s   Sensitivity=-200 dBm
        RTS thr=2346 B   Fragment thr=2346 B
        Encryption key:ABFA-155B-E90F-1D1C-FC34-66ED Security mode:restricted
        Power Management:off
        Link Quality:100/100  Signal level:-30 dBm  Noise level:-96 dBm
        Rx invalid nwid:0  Rx invalid crypt:0
        Rx invalid frag:0
        Tx excessive retries:0  Invalid misc:0  Missed beacon:0

W przypadku użycia pakietu wpa_supplicant możemy użyć programu wpa_cli:

wpa_cli status
Selected interface 'wlan0'
bssid=00:1e:e5:6d:62:5e
ssid=nasza_nazwa_sieci
id=0
pairwise_cipher=CCMP
group_cipher=TKIP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=192.168.0.2

Jeżeli mamy kartę obsługującą tryb "n" może nam się przydać polecenie iwpriv z pakietu wireless-tools. Możemy przełączyć wtedy kartę wifi w szybszy tryb, ponieważ często z automatu włączony jest wolniejszy np. "g". Uruchamiamy więc:

# iwpriv wlan0 network_type n

# iwlist bitrate
lo	no bit-rate information.
		
eth0	no bit-rate information.
		
wlan0   8 available bit-rates :
        6 Mb/s
        9 Mb/s
        12 Mb/s
        18 Mb/s
        24 Mb/s
        36 Mb/s
        48 Mb/s
        54 Mb/s
        Current Bit Rate=270 Mb/s

Wprowadzenie

Na samym początku musimy włączyć w biosie komputera port USB oraz zainstalować takie pakiety jak eagle oraz kernel-usb-eagle. Dodatkowo musimy jeszcze zainstalować pakiet ppp. Jeżeli zainstalowałeś system z płytki MINI-iso, powinieneś je tam znaleźć. W przypadku, kiedy instalowałeś system z dyskietki, znajdziesz je na jednej lub kilku dyskietek "addons" czyli dyskietek zawierających dodatkowe pakiety.

Instalacja

Przystępujemy do instalacji. Należy przejść do do lokalizacji w której znajdują się owe pakiety a następnie wydać następujące polecenie.

# rpm -Uvh kernel-usb-eagle* eagle-usb* ppp*

Kiedy już upewniliśmy się, że mamy włączony port USB w biosie, musimy go zainicjować w systemie. Możemy to zrobić za pomocą pliku /etc/modules.conf w którym umieszczamy przykładową linijkę

alias usb-controller usb-uhci

Jeżeli posiadasz zainstalowany kernel z serii 2.6.x powinieneś umieścić następujący wpis w pliku /etc/modprobe.conf

alias usb-controller uhci-hcd

Po ponownym uruchomieniu komputera powinniśmy posiadać w systemie obecny moduł usb-uhci (uhci-hcd dla jądra 2.6.x). W przypadku, kiedy ten moduł po prostu nie zadziała spróbuj załadować usb-ohci (ohci-hcd dla jądra 2.6.x). Jeżeli podłączyłeś modem do portu USB 2.0 powinieneś użyć modułu usb-ehci (ehci-hcd dla jądra 2.6.x).

Możemy teraz podłączyć modem do komputera. Nasze urządzenie zostanie od razu wykryte i zainicjowane w systemie. Poprawna inicjalizacja powinna zakończyć się załadowaniem do pamięci modułu adiusbadsl. UWAGA! Jeżeli posiadasz kernel 2.6.x powinieneś załadować moduł eagle-usb.

Konfiguracja

Możemy zacząć od pliku /etc/resolv.conf. Opis znajdziecie w rozdziale poświęconym konfiguracji sieci. Przystępujemy teraz do konfiguracji pliku /etc/eagle-usb/eagle-usb.conf. Należy w nim zmienić wartość opcji VPI na taką jaką widzicie poniżej.

VPI=00000000

Skonfigurujemy teraz demona PPP. Utworzonemu w wyniku instalacji plikowi /etc/ppp/options zmieniamy nazwę na options.old. Tworzymy nowy plik options z zawartością taką jaka została przedstawiona na poniższym listingu. Najważniejszą rzeczą jest podanie w nim nazwy użytkownika, która jest konieczna do ustanowienia połączenia. Możemy również dopisać opcję debug, jeśli chcemy być informowani o tym co się dzieje.

# cat /etc/ppp/options
user "user@neostrada.pl"
mru 1492
mtu 1492
noipdefault
defaultroute
usepeerdns
noauth
#ipcp-accept-remote
#ipcp-accept-loacal
nobsdcomp
nodeflate
nopcomp
novj
novjccomp
#novaccomp -am
noaccomp -am
#włączam debug.
debug

Musimy jeszcze wpisać hasło. Aby tego dokonać wyedytujmy plik /etc/ppp/chap-secrets. UWAGA! Jeżeli się pomylisz i wpiszesz hasło do /etc/ppp/pap-secrets, hasło nie zadziała.

# cat /etc/ppp/chap-secrets
user@neostrada.pl	*	haslo	*

Na tym zakończymy konfigurację połączenia z Neostradą. Jesteśmy już gotowi aby wszystko uruchomić.

Uruchomienie i post konfiguracja

Najbardziej wygodnym sposobem będzie wykorzystanie mechanizmu rc-scripts do uruchamiania usługi. Do tego potrzebny będzie odpowiedni plik konfiguracji, przykładowy taki plik umieszczono w katalogu /usr/share/doc/rc-scipts/ oraz na poniższym wydruku:

DEVICE=ppp0
ONBOOT=yes
PPPOA_EAGLE=yes
AUTH=no
MTU=1452
PERSIST=yes
DEFROUTE=yes
USEPEERDNS=yes
PAPNAME=XXX@neostrada.pl
# put password in /etc/ppp/pap-secrets or install
# ppp-plugin-ifcfg-password and uncommend following lines
# PLUGIN_IFCFG_PASSWORD=yes
# PASSWORD=YYYY

Plik zapisujemy jako /etc/sysconfig/interfaces/ifcfg-ppp0 i wydajemy polecenie:

# ifup ppp0

Dzięki opcji ONBOOT=yes połączenie będzie nawiązywane wraz z uruchamianiem systemu.

Możemy sprawdzić np. pingiem łączność z jakimś zewnętrznym serwerem, np. ping www.pld-linux.org. Jeżeli posiadasz jakąś sieć LAN, lub kilka komputerów w mieszkaniu, powinieneś przeczytać rozdział poświęcony maskaradzie.

Przygotowanie do instalacji

Oto krótka lista tego, co będzie nam potrzebne do uruchomienia modemu.

• Port USB w komputerze

• Jądro z serii 2.4 lub 2.6

• Programy: modem_run oraz pppoa3

• Pakiet: ppp-plugin-pppoatm

• Firmware do modemu.

Firmware dla modemu można ściągnąć z stąd: http://speedtouch.sourceforge.net/files/firmware.bin.

Jeżeli już upewniłeś się, że masz wszystkie wymagane rzeczy, możemy przystąpić do instalacji.

Konfiguracja

W pierwszej kolejności musimy zainicjować w systemie USB, oraz kilka modułów do obsługi ppp. Możemy to zrobić wykonując następujące polecenie

# for i in usbcore uhci acm ppp_generic \
    ppp_synctty;do modprobe $i;done

Komentarza wymaga tutaj obsługa USB. W przykładzie został podany moduł uhci. Jeżeli nie załaduje się poprawnie (zostaniesz o tym poinformowany) powinieneś wybrać jeden z następujących: usb-uhci, usb-ohci lub dla USB 2.0 usb-ehci. Posiadacze jąder z serii 2.6 mają do wyboru następujący zestaw modułów: uhci-hcd, ohci-hcd lub ehci-hcd. Ta różnorodność jest uwarunkowana sprzętowo, w zależności od rodzaju chipsetu obsługującego porty USB. Ważną rolę tutaj odgrywa moduł acm, gdyż bez niego nie będzie możliwe załadowanie firmware do modemu. W kernelach z serii 2.6.x odpowiednikiem acm jest moduł cdc-acm.

Posiadacze kernela z serii 2.6.x mogą użyć poniższej pętli która załaduje wszystkie potrzebne moduły. Oczywiście należy zwrócić uwagę aby załadować odpowiedni dla Twojego sprzętu moduł obsługujący kontroler USB na płycie głównej.

# for i in usbcore uhci-hcd cdc-acm ppp_generic ppp_synctty;do modprobe $i;done

Następnym krokiem jest podmontowanie systemu plików w proc.

# mount none /proc/bus/usb -t usbfs

W tym momencie możemy sprawdzić, czy SpeedTouch rzeczywiście jest widziany przez system. Aby tego dokonać wykonaj poniższe polecenie

# cat /proc/bus/usb/devices
[...]
S:  Manufacturer=ALCATEL
S:  Product=Speed Touch 330
[...]

Musisz teraz zainstalować oprogramowanie do modemu. Robimy to wydając następujące polecenie:

# poldek -U speedtouch

Podłącz modem do komputera. Będzie on potrzebował do działania specjalnego pliku, tak zwanego firmware. Program modem_run potrafi odczytywać firmware w formatach przygotowanych dla Linuksa, Windowsa oraz MacOS. Jakie są możliwości pobrania pliku firmware? Możemy pobrać go z adresu podanego na początku rozdziału. Jest to firmware przygotowany dla systemu MacOS. Linuksowy firmware możemy pobrać ze strony Alcatela: www.speedtouchdsl.com/dvrreg_lx.htm. Wymagana jest rejestracja. Możemy również go wziąć z płytki dostarczonej przez TPSA. Powinien on znajdować się w archiwum Linux/ThomsonST330/pliki.tar.gz. Po jego rozpakowaniu powinniśmy mieć coś takiego jak: drivers/speedmgmt.tar.gz. Posiadając już plik speedmgmt.tar.gz możemy sobie zbudować pakiet rpm z firmwarem przy użyciu speedtouch-firmware.spec. Musimy tylko skopiować archiwum do katalogu ~/rpm/SOURCES. Dalsze instrukcje dotyczące budowania pakietów znajdziesz w tej dokumentacji w rozdziale: Tworzenie PLD. Po zainstalowaniu zbudowanego pakietu z firmwarem, możemy go załadować wydając poniższe polecenie:

# modem_run -v 1 -m -f /ścieżka/do/firmware

Ładowanie firmware do modemu może trochę potrwać. Jeżeli chcesz widzieć co się dzieje wpisz następujące polecenie

# tail -f /var/log/messages

W trakcie ładowania pliku firmware, zaczną migać diody urządzenia. Będzie to oznaczać synchronizację linii. Po kilkunastu sekundach modem się ustabilizuje. Diody powrócą do zielonego koloru.

Jeżeli masz zainstalowany kernel z serii 2.6 lub 2.4.22+ wykonaj poniższe polecenia:

# modprobe speedtch
# modem_run -k -m -v 1 -f /usr/share/speedtouch/mgmt.o
# modprobe pppoatm

Moduł speedtch jest potrzebny do użycia opcji -k (może być ładowany automatycznie przez hotplug. Z kolei pppoatm będzie potrzebny do uruchomienia pppd. Nie ładuje się on automatycznie, dlatego należy go dopisać np. do /etc/modules.

W porządku. Po zakończonej operacji ładowania firmware jesteśmy gotowi aby skonfigurować nasze ppp do neostrady. Zanim to zrobimy będziemy musieli zainstalować pakiet ppp-plugin-pppoatm.

# poldek -U ppp-plugin-pppoatm

W zależności od wersji zainstalowanego kernela (2.6 lub 2.4) konfiguracja demona pppd będzie się różniła kilkoma szczegółami. Poniżej przedstawiam przykłady dla obu serii jąder.

Linux z serii 2.4

# cat /etc/ppp/peers/neostrada
debug
lock
noipdefault
defaultroute
pty "/usr/sbin/pppoa3 -v 1 -e 1 -c -m 1 -vpi 0 -vci 35"
asyncmap 0
lcp-echo-interval  2
lcp-echo-failure   7
sync
user "user@neostrada.pl"
noauth
holdoff 3
persist
maxfail 25
mru 1500
mtu 1500

Linux z serii 2.6 lub 2.4.22+

# cat /etc/ppp/peers/neostrada
noauth
usepeerdns
noipdefault
defaultroute
pty "/usr/sbin/pppoa3 -e 1 -v 1 -m 1 -c -vpi 0 -vci 35"
sync
user nasz_login
noaccomp
nopcomp
noccp
holdoff 4
persist
maxfail 25

Ważną rolę odgrywa tu parametr -e 1, gdyż bez niego nie uzyskamy połączenia.

Oczywiście musimy jeszcze odpowiednio skonfigurować pap-secrets oraz chap-secrets

# cat /etc/ppp/chap-secrets
user@neostrada.pl     *       haslo        *

Uruchomienie i zakończenie

W celu nawiązania połączenia, które uprzednio skonfigurowaliśmy, wydajemy takie oto polecenie

pppd call neostrada

Jeżeli nie chcemy, bądź z jakichś powodów nie możemy korzystać z programu hotplug nie musimy tego robić. Nie jest on tak naprawdę niezbędny. W takim przypadku za każdym razem będziemy musieli ładować firmware modemu programem modem_run.

Wprowadzenie

Coraz więcej dostawców usług internetowych oferuje dzierżawę linii xDSL z portem LAN typu Ethernet, takie usługi oferują np. Telekomunikacja Polska (Internet DSL) oraz Dialog (DIALNET DSL).

Konfiguracja

W celu uruchomienia usługi, wystarczy jedynie skonfigurować interfejs sieciowy Ethernet w naszym komputerze, zgodnie z informacjami uzyskanymi od dostawcy łącza (konfiguracja statyczna). Poniżej przedstawiono skrócony opis konfiguracji tego typu interfejsu, szczegółowy opis znajdziemy tutaj: sekcja Ethernet

Podniesienie interfejsu eth0 możemy osiągnąć tworząc lub edytując (jeśli istnieje) plik /etc/sysconfig/interfaces/ifcfg-eth0 i wpisując dane otrzymane od dostawcy:

DEVICE="eth0"
IPADDR="80.55.203.222/30"
ONBOOT="yes"
BOOTPROTO="none"

Istotną kwestią jest przypisanie odpowiedniego prefiksu (maski podsieci) przy podaniu adresu IP zarezerwowanego dla abonenta. Prefiks wykorzystywane w usłudze InternetDSL, to: /30 Internet DSL 512 oraz Internet DSL 1 (przydzielone 4 adresy IP, co odpowiada masce podsieci 255.255.255.252), /29 Internet DSL 2 (przydzielone 8 adresów IP, co odpowiada masce podsieci 255.255.255.248). Należy pamiętać że 3 adresy IP są zarezerwowane do obsługi połączenia (adres sieci,brama,broadcast)

Ostatnią zmianą potrzebną do prawidłowego działania sieci jest wyedytowanie pliku /etc/sysconfig/network. Należy tam podać adres bramy (IP modemu DSL).

GATEWAY="80.55.203.221"
GATEWAYDEV="eth0"

Na koniec pozostaje nam uruchomienie podsystemu sieci:

# service network start

Uwagi

Jeśli przy łączu Internet DSL 1 zdarzają się przypadki zerwania połączenia, należy przywiązać wszystkie 5 adresów IP jako wirtualne interfejsy

IPADDR1="ip1/29"
IPADDR2="ip2/29"
IPADDR3="ip3/29"
IPADDR4="ip4/29"
IPADDR5="ip5/29"

HotPlug

HotPlug jest mechanizmem pozwalającym na automatyczne konfigurwanie systemu po podłączeniu określonego urządzenia. W przypadku urządzeń sieciowych PCMCIA i USB możliwe jest automatyczne aktywowanie interfejsu od razu po podłączeniu urządzenia.

Aby uruchomić ten mechanizm musimy najpierw zainstalować odpowiednie oprogramowanie:

# poldek -i hotplug*

Kolejnym krokiem będzie umieszczenie odpowiedniego wpisu w pliku konfiguracji interfejsu sieciowego. Dodajemy opcję:

HOTPLUG=yes

Narzędzia

Narzędzia do zarządzania i diagnostyki interfejsów sieciowych opisano w sekcja Narzędzia sieciowe w rozdział Zastosowania sieciowe.

Inne opcje

Zaawansowane opcje sieciowe interfejsów nie są umieszczane w plikach generowanych w trakcie instalacji systemu. Ich opis znajdziemy w pliku /usr/share/doc/rc-scripts/ifcfg-description.gz.

Wzory konfiguracji

Wiele przykładowych konfiguracji interfejsów sieciowych odnajdziemy w katalogu z dokumentacją do rc-skryptów: /usr/share/doc/rc-scripts. Są to pliki tekstowe zarchiwizowane programem Gzip.

Wstępna konfiguracja

Konfigurację routingu obowiązkowo rozpoczynamy od włączenia przekazywania pakietów między interfejsami sieciowymi, opcję tą możemy ustawić tymczasowo wykonując polecenie

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

Możemy też w pliku /etc/sysctl.conf ustawić następująca opcję:

net.ipv4.ip_forward = 1

# service network restart

Tablica routingu

Aby wyświetlić tablicę routingu posłużymy się poleceniem ip route:

# ip route
10.0.0.4/32 dev eth0  proto kernel  scope link  src 10.0.0.4
10.0.0.0/24 dev eth1  proto kernel  scope link  src 10.0.0.1
default via 10.0.0.100 dev eth0 onlink

Zarządzanie trasami

Zarządzenia routingiem na kilku przykładach:

Dodanie trasy do hosta